Messages in this thread | | | Date | Tue, 14 Feb 2012 11:30:06 +0800 | Subject | Re: [PATCH] percpu: use raw_local_irq_* in _this_cpu op | From | Ming Lei <> |
| |
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/
| |