On 07/04/15 14:56, Steven Rostedt wrote:
> On Tue, 07 Apr 2015 14:47:50 +0100
> Juri Lelli <[email protected]> wrote:
> 
>> On 03/04/2015 09:42, Borislav Petkov wrote:
>>> From: Borislav Petkov <[email protected]>
>>>
>>> Commit
>>>
>>>   3c18d447b3b3 ("sched/core: Check for available DL bandwidth in 
>>> cpuset_cpu_inactive()")
>>>
>>> forgot a trace_printk debugging piece in and Steve's banner blew in
>>> dmesg. Remove it.
>>>
>>
>> Argh! Sorry about that! Shame on me, I didn't pay much attention to
>> Rostedt's banner because I was working on several fixes at once :(.
> 
> Right, but it lets other people notice it :-)
> 

Sure, that was entirely my fault not having paid attention to it :/.
And it might stayed there for a while if the banner wasn't there.

> 
> 
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index d124359..1fc454c5 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -3257,6 +3257,12 @@ sub process {
>>                           "Prefer printk_ratelimited or 
>> pr_<level>_ratelimited to printk_ratelimit\n" . $herecurr);
>>              }
>>  
>> +# check for uses of trace_printk
>> +            if ($line =~ /\btrace_printk\s*\(/) {
>> +                    ERROR("TRACE_PRINTK",
>> +                          "Never use trace_printk in production code!\n" . 
>> $herecurr);
>> +            }
>> +
> 
> if you want to be robust here. You probably want to make an exception
> when the code is in kernel/trace/ because "trace_printk" in patches
> there would be to fix the trace_printk implementation, and not its use.
> 

Oh, right. I'll try to follow-up with a v2 addressing Joe's comments as
well.

Thanks a lot,

- Juri

> -- Steve
> 
> 
>>  # printk should use KERN_* levels.  Note that follow on printk's on the
>>  # same line do not need a level, so we use the current block context
>>  # to try and find and validate the current printk.  In summary the current
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to