From: Thomas Renninger on 26 Jul 2010 09:50 On Monday 26 July 2010 14:14:30 Thomas Renninger wrote: > This patch is based on 2.6.35-rc5 + this patchset I posted recently: > [patch 0/3] Dynamic Debug providing early boot debug messages via boot parameter > > It would be great to see these getting merged into 2.6.36... and this time with some Documentation added... Please use this patch instead of my first post. Thanks, Thomas ---------- Dynamic Debug: Introduce global fake module param module.ddebug Dynamic Debug allows enabling of pr_debug or KERN_DEBUG messages at runtime. This is controlled via /sys/kernel/debug/dynamic_debug/control. One major drawback is that the whole initialization of a module cannot be tracked, because ddebug is only aware of debug strings of loaded modules. But this is the most interesting part... This patch introduces a fake module parameter module.ddebug(not shown in /sys/module/*/parameters, thus it does not use any resources/memory). If a module passes ddebug as a module parameter (e.g. via module.ddebug kernel boot param or via "modprobe module ddebug"), all debug strings of this module get activated by issuing "module module_name +p" internally (not via sysfs) when the module gets loaded. Possible enhancements for the future if ddebug might get extended with further flags: module.ddebug=flags Then module.ddebug="p" would be the same as module.ddebug, but if there is a "x" ddebug flag added, one could pass: module.ddebug="xp" which would result in such a dynamic debug query: module module_name +xp One not handled side-effect of this patch: Modules must not use "ddebug" module parameter or it will get ignored. I tried to find a compile time check, but I could not see how that is possible. Possibly a run-time check or at least documentation (where?) should get added, that "ddebug" must not get used as a module parameter. Tested with: options hp-wmi ddebug in modprobe.conf -> works and pr_debug messages issued at module initialization time show up. Also "p" flag gets set for the whole hp-wmi module: grep hp-wmi /sys/../dynamic_debug/control Signed-off-by: Thomas Renninger <trenn(a)suse.de> --- Documentation/dynamic-debug-howto.txt | 28 +++++++++++++++++++++++++++- include/linux/dynamic_debug.h | 5 +++++ kernel/params.c | 9 ++++++++- lib/dynamic_debug.c | 2 +- 4 files changed, 41 insertions(+), 3 deletions(-) diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 58ea64a..ebbbbdd 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -213,7 +213,7 @@ Note also that there is no convenient syntax to remove all the flags at once, you need to use "-psc". -Debug messages during boot process +Debug Messages during Boot Process ================================== To be able to activate debug messages during the boot process, @@ -232,6 +232,32 @@ PCI (or other devices) initialization also is a hot candidate for using this boot parameter for debugging purposes. +Debug Messages at Module Initialization Time +============================================ + +Enabling debug messages inside a module is only possible if the module itself +is loaded already. If you unload a module, the dynamic debug flags associated +to its debug messages are lost. +Therefore, enabling debug messages that get processed at module initialization +time through the <debugfs>/dynamic_debug/control interface is not possible. +Instead, a "ddebug" module paramter can be passed: + + - via kernel boot parameter: + module.ddebug + + - as an ordinary module parameter via modprobe + modprobe module ddebug + + - or the parameter can be used permanently via modprobe.conf(.local) + options module ddebug + +The ddebug option is not implemented as an ordinary module parameter and thus +will not show up in /sys/module/module_name/parameters/ddebug +The settings can get reverted through the sysfs interface again when the +module got loaded as soon as debug messages are not needed anymore: +echo "module module_name -p" > <debugfs>/dynamic_debug/control +as described in the "Command Language Reference" chapter above. + Examples ======== diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index 52c0da4..095adf6 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -41,6 +41,7 @@ int ddebug_add_module(struct _ddebug *tab, unsigned int n, #if defined(CONFIG_DYNAMIC_DEBUG) extern int ddebug_remove_module(const char *mod_name); +extern int ddebug_exec_query(char *query_string); #define __dynamic_dbg_enabled(dd) ({ \ int __ret = 0; \ @@ -77,6 +78,10 @@ static inline int ddebug_remove_module(const char *mod) { return 0; } +static inline int ddebug_exec_query(char *query_string) +{ + return 0; +} #define dynamic_pr_debug(fmt, ...) \ do { if (0) printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); } while (0) diff --git a/kernel/params.c b/kernel/params.c index 0b30ecd..85d58e9 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -24,6 +24,7 @@ #include <linux/err.h> #include <linux/slab.h> #include <linux/ctype.h> +#include <linux/dynamic_debug.h> #if 0 #define DEBUGP printk @@ -132,7 +133,7 @@ int parse_args(const char *name, unsigned num, int (*unknown)(char *param, char *val)) { - char *param, *val; + char *param, *val, ddebug[1024]; DEBUGP("Parsing ARGS: %s\n", args); @@ -144,6 +145,12 @@ int parse_args(const char *name, int irq_was_disabled; args = next_arg(args, ¶m, &val); + if (parameq(param, "ddebug")) { + sprintf(ddebug, "module %s +p", name); + ddebug_exec_query(ddebug); + continue; + } + irq_was_disabled = irqs_disabled(); ret = parse_one(param, val, params, num, unknown); if (irq_was_disabled && !irqs_disabled()) { diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index a687d90..7f8ba5f 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -429,7 +429,7 @@ static int ddebug_parse_flags(const char *str, unsigned int *flagsp, return 0; } -static int ddebug_exec_query(char *query_string) +int ddebug_exec_query(char *query_string) { unsigned int flags = 0, mask = 0; struct ddebug_query query; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Renninger on 5 Aug 2010 12:10 On Thursday 05 August 2010 17:39:10 Jason Baron wrote: > On Mon, Jul 26, 2010 at 02:14:30PM +0200, Thomas Renninger wrote: > > This patch is based on 2.6.35-rc5 + this patchset I posted recently: > > [patch 0/3] Dynamic Debug providing early boot debug messages via > > boot parameter > > > > It would be great to see these getting merged into 2.6.36... .... > patch looks pretty good to me. I'm not sure how we reserve the > 'ddebug' keyword. Yep, I also was not sure about that. > However, I think its probably ok, if we mention it > in 'kernel-parameters.txt' and in the dynamic debug documentation. I added some documentation to the dynamic debug docu file and posted the patch again (as a reply on my initial post, should be the same mail thread). > Also, ddebug could show up in /sys/module/$(modulename}/parameters/ , > but this can probably be done in a followup patch. This was intentional. At the time /sys is available one can also use /sys/kernel/debug/dynamic_debug/control echo "module my_module_to_debug +p" >/sys/kernel/debug/dynamic_debug/control would exactly do the same as /sys/module/$(modulename}/parameters The advantage of not having it, is it saves quite some resources, in fact it uses none. Otherwise every module would have an addtional parameter added with a sysfs file associated with it with no additional functional gain. > Also, if 'ddebug' alone is set on the kernel command line, i'd like to > see us enable all debug statements. We could implement this by adding > a special 'meta' module to the control file which is just has a module > name of of 'All' or something like that. This could also be done in a > subsequent patch. Is there a single query which could do it? If not, possibly a keyword like file/module called "all" could be added. Then you could simply do that by ddebug_query="all +p" > We also need to at least remove the 'dynamic_printk' doc from > kernel-parameters.txt. Don't know about this one. So, I have your acked-by for this one? Let's get this pushed into a tree, with some luck it still could make it into 2.6.36? The other three have been taken by Pekka? He said something about taking them, but I haven't received any confirmation. Ah no, he acked-by them only. As these are rather general ones, which tree should they go through, possibly Andrew could take them? I can resubmit, if someone could tell me a list/maintainer that fits best, so that they really make it in... Thanks, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Renninger on 5 Aug 2010 16:20 On Thursday 05 August 2010 07:25:54 pm Greg KH wrote: > On Thu, Aug 05, 2010 at 06:05:40PM +0200, Thomas Renninger wrote: > > On Thursday 05 August 2010 17:39:10 Jason Baron wrote: .... > > So, I have your acked-by for this one? > > Let's get this pushed into a tree, with some luck it still could make it > > into 2.6.36? The other three have been taken by Pekka? He said something > > about taking them, but I haven't received any confirmation. > > Ah no, he acked-by them only. > > It's too late for .36 as none of this has been tested in linux-next yet. > How about for .37? No problem. I send you a clean patchset tomorrow. I have one additional idea I'll try to build in: Complain if a module uses ddebug as module parameter at module insertion time that this is a reserved keyword/param that must not be used. I'll leave out lkml, Andrew and Pekka (I thought they could queue these). Thanks everybody, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: (none) Next: PROBLEM: oom killer and swap weirdness on 2.6.3* kernels |