Re: [PATCH] sched/core: Drop debugging leftover trace_printk call

[Juri Lelli]

On 07/04/15 14:56, Steven Rostedt wrote:
> On Tue, 07 Apr 2015 14:47:50 +0100
> Juri Lelli <juri.lelli@xxxxxxx> wrote:
> 
>> On 03/04/2015 09:42, Borislav Petkov wrote:
>>> From: Borislav Petkov <bp@xxxxxxx>
>>>
>>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/