lkml.org 
[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: irq lock inversion

[ added LKML to CC so that the lockdep message is at least indexed by
search engines in archives ]

On Thu, 5 Nov 2009, Tejun Heo wrote:

> > lockdep only considers a lock irq-safe if it was used from an irq
> > context before.
> >
> > _irqsave() API usage alone does not trigger this.
>
> Thanks for the explanation. It's about the same tho. sched_init() is
> calling it with irq disabled but that's an exception to might_sleep()
> rule. Maybe making lockdep recognize the same exception as
> might_sleep() so that lockdep doesn't consider a lock irq-safe if it's
> called with irq off but before system_state is set to SYSTEM_RUNNING
> works around the problem?

Hmm, I wonder why I don't see this lockdep warning myself with
head on 1836d9592, even though I have

CONFIG_PROVE_LOCKING=y
CONFIG_TRACE_IRQFLAGS=y

... ?

Anyway, how about something like this? (I can't verify myself that it even
fixes the warning, as I don't see it for some odd reason)




From: Jiri Kosina <jkosina@suse.cz>
Subject: lockdep: avoid false positives about irq-safety

Commit 403a91b1 ("percpu: allow pcpu_alloc() to be called
with IRQs off") introduced this warning:

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.32-rc5-tip-04815-g12f0f93-dirty #745
---------------------------------------------------------
hub 1-3:1.0: state 7 ports 2 chg 0000 evt 0004
ksoftirqd/65/199 just changed the state of lock:
(pcpu_lock){..-...}, at: [<ffffffff81130e04>] free_percpu+0x38/0x104
but this lock took another, SOFTIRQ-unsafe lock in the past:
(vmap_area_lock){+.+...}

and interrupts could create inverse lock ordering between them.

This warning is bogus -- sched_init() is being called very early with IRQs
disabled, and the irqsave/restore code paths in pcpu_alloc() are only for early
init. The path can never be called from irq context once the early init
finishes. Rationale for this is explained in changelog of the commit mentioned
above.

This problem can be encountered generally in any other early code running
with IRQs off and using irqsave/irqrestore.

Reported-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

---
kernel/lockdep.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 9af5672..996b395 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2487,6 +2487,14 @@ void lockdep_trace_alloc(gfp_t gfp_mask)

static int mark_irqflags(struct task_struct *curr, struct held_lock *hlock)
{
+ /*
+ * This is exception similar to the might_sleep() one.
+ * We don't care about irq-safety of the locks this early, as
+ * it will produce false positives (sched_init() is called with
+ * irqs off, but needs to use irqsave/irqrestore API)
+ */
+ if (system_state != SYSTEM_RUNNING)
+ return 1;
/*
* If non-trylock use in a hardirq or softirq context, then
* mark the lock as used in these contexts:

\
 
 \ /
  Last update: 2009-11-05 15:35    [W:0.067 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site