On 29-11-2006 08:49, Herbert Xu wrote:

Peter Zijlstra [off-list ref] wrote:

quoted

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.19-rc6 #4
---------------------------------------------------------
nc/1854 just changed the state of lock:
(af_callback_keys + sk->sk_family#2){-.-?}, at: [<c0268a7f>] sock_def_error_report+0x1f/0x90
but this lock was taken by another, soft-irq-safe lock in the past:
(slock-AF_INET){-+..}

and interrupts could create inverse lock ordering between them.

I think this is bogus.  The slock is not a standard lock.  When we
hold it in process context we don't actually hold the spin lock part
of it.  However, it does prevent the softirq path from running in
critical sections which also prevents any attempt to grab the
callback lock from softirq context.

If you still think there is a problem, please show an actual scenario
where it dead locks.

It would be nice to have a look at other parts of stack
backtraces probably with softirq part, which took that
lock: sk->sk_family#2){-.-?}

Jarek P.