From: Petr Mladek <pmladek@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG)
Date: Thu, 28 May 2020 12:59:43 +0200 [thread overview]
Message-ID: <20200528105942.GB11286@linux-b0ei> (raw)
In-Reply-To: <e3b30905-4497-29b4-4636-a313283dbc56@i-love.sakura.ne.jp>
On Thu 2020-05-28 08:33:37, Tetsuo Handa wrote:
> On 2020/05/28 0:55, Petr Mladek wrote:
> >>> Well, it would be possible to call vsprintf() with NULL buffer. It is
> >>> normally used to calculate the length of the message before it is
> >>> printed. But it also does all the accesses without printing anything.
> >>
> >> OK. I think that redirecting pr_debug() to vsnprintf(NULL, 0) will be
> >> better than modifying dynamic_debug path, for
> >
> > It might get more complicated if you would actually want to see
> > pr_debug() messages for a selected module in the fuzzer.
>
> I don't expect that automated testing can afford selectively enabling
> DYNAMIC_DEBUG_BRANCH(id) conditions. But we could evaluate all arguments
> by calling snprintf(NULL, 0) if the condition to call printk() is false.
>
> > vsprintf(NULL, ) can be called for pr_debug() messages in
> > vprintk_store(). It will be again only a single place for
> > all printk() wrappers.
>
> I couldn't catch what you mean. The problem of pr_debug() is that
> vprintk_store() might not be called because of
>
> #define no_printk(fmt, ...) \
> ({ \
> if (0) \
> printk(fmt, ##__VA_ARGS__); \
> 0; \
> })
>
> #define pr_debug(fmt, ...) \
> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>
> or
>
> #define __dynamic_func_call(id, fmt, func, ...) do { \
> DEFINE_DYNAMIC_DEBUG_METADATA(id, fmt); \
> if (DYNAMIC_DEBUG_BRANCH(id)) \
> func(&id, ##__VA_ARGS__); \
> } while (0)
>
> #define _dynamic_func_call(fmt, func, ...) \
> __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
>
> #define dynamic_pr_debug(fmt, ...) \
> _dynamic_func_call(fmt, __dynamic_pr_debug, \
> pr_fmt(fmt), ##__VA_ARGS__)
>
> #define pr_debug(fmt, ...) \
> dynamic_pr_debug(fmt, ##__VA_ARGS__)
That is exactly the problem. Your current patch [1] adds checks
for the CONFIG_TWIST into 15 different locations.
This is perfectly fine for testing in linux-next whether this twist
is worth the effort. But I do not like this as a long term solution.
If the testing shows that it was really helpful and you would want
to get this into Linus' tree. Then I would like to do the twist at different
level:
1. Add twist into ddebug_add_module() and enable all newly added
entries by default. For example, by calling
ddebug_exec_query("*:+p", const char *modname) or what is the syntax.
This will cause that any pr_devel() variant will always get called.
2. Add twist into vprintk_store(). In the current, implementation
it would do:
#if TWIST
return text_len;
#endif
return log_output(facility, level, lflags,
dict, dictlen, text, text_len);
Something similar would need to be done also in printk_safe().
Hot you could ignore this because it would be used only in
very few scenarios.
In the lock_less variant, we would need to format the message
into small buffer on stack to detect the log level from the first
few bytes.
The approach will cause that pr_devel() message will never get really
printed when this TWIST is enabled. But you mention that automatic
testing would not do so anyway.
[1] https://lore.kernel.org/r/20200528065603.3596-1-penguin-kernel@I-love.SAKURA.ne.jp
Best Regards,
Petr
next prev parent reply other threads:[~2020-05-28 10:59 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 14:50 [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG) Tetsuo Handa
2020-05-24 17:38 ` Joe Perches
2020-05-24 19:18 ` Ondrej Mosnacek
2020-05-25 5:03 ` Tetsuo Handa
2020-05-25 6:07 ` Joe Perches
2020-05-25 7:38 ` Dmitry Vyukov
2020-05-25 8:42 ` Petr Mladek
2020-05-25 9:11 ` Sergey Senozhatsky
2020-05-25 10:43 ` Tetsuo Handa
2020-05-27 8:37 ` Petr Mladek
2020-05-27 10:13 ` Tetsuo Handa
2020-05-27 15:55 ` Petr Mladek
2020-05-27 23:33 ` Tetsuo Handa
2020-05-28 6:56 ` [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() Tetsuo Handa
2020-05-28 11:06 ` Petr Mladek
2020-05-28 15:16 ` Tetsuo Handa
2020-05-28 19:10 ` Andrew Morton
2020-05-28 19:50 ` Linus Torvalds
2020-05-28 20:01 ` Linus Torvalds
2020-05-29 0:07 ` Tetsuo Handa
2020-05-29 0:28 ` Linus Torvalds
2020-05-29 2:13 ` Tetsuo Handa
2020-05-29 2:24 ` Linus Torvalds
2020-05-29 4:47 ` Tetsuo Handa
2020-05-29 13:26 ` Tetsuo Handa
2020-06-03 11:03 ` twist: allow disabling reboot request Tetsuo Handa
2020-06-03 12:44 ` Petr Mladek
2020-06-03 13:35 ` Tetsuo Handa
2020-06-04 10:21 ` Petr Mladek
2020-06-08 7:48 ` [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() Dmitry Vyukov
2020-06-08 10:30 ` Tetsuo Handa
2020-06-08 11:31 ` Andrey Konovalov
2020-05-29 8:17 ` Petr Mladek
2020-06-08 16:39 ` Geert Uytterhoeven
2020-05-28 10:59 ` Petr Mladek [this message]
2020-05-28 11:33 ` [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG) Tetsuo Handa
2020-05-28 12:14 ` Petr Mladek
2020-05-28 14:13 ` Tetsuo Handa
2020-05-28 17:08 ` Joe Perches
2020-05-29 2:04 ` Sergey Senozhatsky
2020-05-29 5:06 ` Tetsuo Handa
2020-05-27 9:59 ` kbuild test robot
2020-05-27 9:59 ` kbuild test robot
2020-05-27 13:41 ` Tetsuo Handa
2020-05-27 13:41 ` Tetsuo Handa
2020-05-27 12:37 ` kbuild test robot
2020-05-27 12:37 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200528105942.GB11286@linux-b0ei \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.