From: Paulo Marques <pmarques@grupopie.com>
To: Jesper Juhl <jj@chaosbits.net>
Cc: Steven Rostedt <rostedt@goodmis.org>,
stufever@gmail.com, linux-kernel@vger.kernel.org,
Wang Shaoyan <wangshaoyan.pt@taobao.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] TRACING: Fix a copmile warning
Date: Tue, 26 Jul 2011 14:32:06 +0100 [thread overview]
Message-ID: <4E2EC1D6.4020102@grupopie.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1107261516550.11180@swampdragon.chaosbits.net>
Jesper Juhl wrote:
> On Tue, 26 Jul 2011, Paulo Marques wrote:
>
>> Steven Rostedt wrote:
>>> On Mon, 2011-07-18 at 17:40 +0800, stufever@gmail.com wrote:
>>>> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>>>>
>>>> It's harmless but annyoing.
>>>> kernel/trace/trace_printk.c: In function 'module_trace_bprintk_format_notify':
>>>> kernel/trace/trace_printk.c:52: warning: 'fmt' may be used uninitialized in this function
>>> I prefer not to add this patch. Fix gcc. Actually some gcc's do not warn
>>> on this, others do. Here's the code that confuses gcc:
>>>
>>> tb_fmt = kmalloc(sizeof(*tb_fmt), GFP_KERNEL);
>>> if (tb_fmt)
>>> fmt = kmalloc(strlen(*iter) + 1, GFP_KERNEL);
>>> if (tb_fmt && fmt) {
>>> list_add_tail(&tb_fmt->list, &trace_bprintk_fmt_list);
>>> strcpy(fmt, *iter);
>>> tb_fmt->fmt = fmt;
>>> *iter = tb_fmt->fmt;
>>>
>>>
>>> fmt will never be looked at if tb_fmt is NULL, and fmt is initialized if
>>> tb_fmt is not NULL.
>> Yes, changing code just to please gcc is not nice. In this case,
>> changing the code to the more straightforward / naive implementation
>> might make it more readable (IMHO) and maybe even improve code
>> generation. I.e., something like this:
>>
>> tb_fmt = kmalloc(sizeof(*tb_fmt), GFP_KERNEL);
>> if (tb_fmt) {
>> fmt = kmalloc(strlen(*iter) + 1, GFP_KERNEL);
>> if (fmt) {
>> list_add_tail(&tb_fmt->list, &trace_bprintk_fmt_list);
>> strcpy(fmt, *iter);
>> tb_fmt->fmt = fmt;
>> *iter = tb_fmt->fmt;
>> } else {
>> kfree(tb_fmt);
>> *iter = NULL;
>> }
>> } else {
>> *iter = NULL;
>> }
>>
>> The downside is that the "*iter = NULL" gets repeated twice...
>>
>
> You could avoid that like this:
>
> *iter = NULL;
> tb_fmt = kmalloc(sizeof(*tb_fmt), GFP_KERNEL);
> if (tb_fmt) {
> fmt = kmalloc(strlen(*iter) + 1, GFP_KERNEL);
> if (fmt) {
> list_add_tail(&tb_fmt->list, &trace_bprintk_fmt_list);
> strcpy(fmt, *iter);
> tb_fmt->fmt = fmt;
> *iter = tb_fmt->fmt;
> } else {
> kfree(tb_fmt);
> }
> }
Yes, but this way you always set *iter to NULL, whereas in the previous
version that was the very unlikely case (kmalloc returning NULL).
Probably gcc is smart enough to generate the same code for both
versions, to avoid setting *iter twice for the likely case (and even if
it doesn't, then the cache will be hot and probably not written back
yet, yadda, yadda)...
--
Paulo Marques - www.grupopie.com
"I used to be indecisive, but now I'm not so sure."
next prev parent reply other threads:[~2011-07-26 13:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 9:40 [PATCH] TRACING: Fix a copmile warning stufever
2011-07-25 18:32 ` Steven Rostedt
2011-07-25 19:43 ` Arnaud Lacombe
2011-07-25 20:19 ` Steven Rostedt
2011-07-25 20:28 ` Arnaud Lacombe
2011-07-25 22:38 ` Arnaud Lacombe
2011-07-25 23:49 ` Steven Rostedt
2011-07-25 23:52 ` Arnaud Lacombe
2011-07-26 0:14 ` Steven Rostedt
2011-07-25 23:50 ` Arnaud Lacombe
2011-07-25 23:58 ` Arnaud Lacombe
2011-07-26 0:08 ` Steven Rostedt
2011-07-26 0:35 ` Steven Rostedt
2011-07-26 0:44 ` Ian Lance Taylor
2011-07-26 0:41 ` Ian Lance Taylor
2011-07-26 1:08 ` Arnaud Lacombe
2011-07-26 1:12 ` Steven Rostedt
2011-07-26 1:19 ` Arnaud Lacombe
2011-07-26 20:43 ` Jeff Law
2011-07-26 1:10 ` Steven Rostedt
2011-07-26 5:55 ` Ian Lance Taylor
2011-07-26 12:00 ` Paulo Marques
2011-07-26 13:18 ` Jesper Juhl
2011-07-26 13:32 ` Paulo Marques [this message]
2011-07-26 13:55 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2011-07-18 9:35 stufever
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=4E2EC1D6.4020102@grupopie.com \
--to=pmarques@grupopie.com \
--cc=fweisbec@gmail.com \
--cc=jj@chaosbits.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stufever@gmail.com \
--cc=wangshaoyan.pt@taobao.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox