Messages in this thread | | | Date | Fri, 6 Nov 2009 08:17:11 +0100 | From | Ingo Molnar <> | Subject | Re: irq lock inversion |
| |
* Tejun Heo <tj@kernel.org> wrote:
> > 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> > > Looks good to me. Ingo, what do you think?
Ugh, this explanation is _BOGUS_. As i said, taking a lock with irqs disabled does _NOT_ mark a lock as 'irq safe' - if it did, we'd have false positives left and right.
Read the lockdep message please, consider all the backtraces it prints, it says something different.
Ingo
| |