On Thu, Nov 30, 2006 at 09:29:34AM +0100, Ingo Molnar wrote: > > * Gautham R Shenoy <[EMAIL PROTECTED]> wrote: > > > Ok, I see that we are already doing it :(. So we can end up in a > > deadlock. > > > > Here's the culprit callpath: > > in general lockdep is 100% correct when it comes to "individual locks". > The overwhelming majority of lockdep false-positives is not due to > lockdep not getting the dependencies right, but due to the "lock class" > not being correctly identified. That's not an issue here i think.
You're right. That's not the issue. > > what lockdep does is it observes actual locking dependencies as they > happen individually in various contexts, and then 'completes' the > dependency graph by combining all the possible scenarios how contexts > might preempt each other. So if lockdep sees independent dependencies > and concludes that they are circular, there's nothing that saves us from > the deadlock. > Ah! I get it now. I had taken neither preemption nor the SMP scenario into account before concluding that the warning might be a false positive. All I need to do is to run my test cases on a preemptible kernel or in parallel on a smp box. It'll definitely deadlock there! > The only way for those dependencies to /never/ trigger simultaneously on > different CPUs would be via the use of a further 'outer' exclusion > mechanism (i.e. a lock) - but all explicit kernel-API exclusion > mechanisms are tracked by lockdep => Q.E.D. (Open-coded exclusion might > escape the attention of lockdep, but those are extremely rare and are > also easily found.) Thanks for making it clear :-) > > Ingo regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/