[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1GpKC4-0005Vc-00@gondolin.me.apana.org.au>
Date: Wed, 29 Nov 2006 18:49:24 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: a.p.zijlstra@...llo.nl (Peter Zijlstra)
Cc: davem@...emloft.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, akpm@...l.org, mingo@...e.hu,
gandalf@...g.westbo.se
Subject: Re: [PATCH] lockdep: fix sk->sk_callback_lock locking
Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> =========================================================
> [ 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.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists