lkml.org 
[lkml]   [2012]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] percpu: use raw_local_irq_* in _this_cpu op
From
Hi,

On Tue, Feb 14, 2012 at 1:23 AM, Tejun Heo <tj@kernel.org> wrote:
> On Mon, Feb 13, 2012 at 07:03:38PM +0800, Ming Lei wrote:
>> It doesn't make sense to trace irq off or do irq flags
>> lock proving inside 'this_cpu' operations, so replace local_irq_*
>> with raw_local_irq_* in 'this_cpu' op.
>>
>> Also the patch fixes one lockdep warning[1], which is caused
>> by the added local_irq_save/restore(flags) in this_cpu_inc
>> called by __debug_atomic_inc: kernel/lockdep.c
>
> I think this isn't gonna hurt anything but I don't understand why the
> lockdep warning is triggering when using traced version.  Can you
> please explain that in a bit more detail in the patch description?

In trace_hardirqs_on_caller:kernel/lockdep.c, __debug_atomic_inc
will be called to add on 'this_cpu' variable, so may introduce recursive
trace_hardirqs_on|off_caller called.

For the lockdep warning, I reproduced it on ARM, see the path below:

kernel_thread_helper /*irq disabled*/
->entry: trace_hardirqs_on_caller /*hardirqs_enabled was set*/
->trace_hardirqs_off_caller /*hardirqs_enabled cleared*/
__this_cpu_add(redundant_hardirqs_on)
->trace_hardirqs_off_caller /*irq disabled, so call here*/

so the 'unannotated irqs-on' warning will be triggered somewhere
because irq will be enabled just after the irq trace inside
kernel_thread_helper.
You can refer to log of commit ac78884e6d89714d18b32b5b7d574116ecfb7c88
(ARM: lockdep: fix unannotated irqs-on) about irq trace inside
kernel_thread_helper.


thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-02-14 04:33    [W:0.064 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site