Re: 2.6.17-rc5-mm3-lockdep -
From: Ingo Molnar <[EMAIL PROTECTED]> Date: Mon, 12 Jun 2006 08:38:07 +0200 > yeah. I'll investigate - it's quite likely that sk_receive_queue.lock > will have to get per-address family locking rules - right? That's right. > Maybe it's enough to introduce a separate key for AF_UNIX alone (and > still having all other protocols share the locking rules for > sk_receive_queue.lock) , by reinitializing its spinlock after > sock_init_data()? AF_NETLINK and/or AF_PACKET might be in a similar situation as AF_UNIX. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3-lockdep -
On Mon, Jun 12, 2006 at 08:38:07AM +0200, Ingo Molnar wrote:
>
> yeah. I'll investigate - it's quite likely that sk_receive_queue.lock
> will have to get per-address family locking rules - right?
Yes that's the issue.
> Maybe it's enough to introduce a separate key for AF_UNIX alone (and
> still having all other protocols share the locking rules for
> sk_receive_queue.lock) , by reinitializing its spinlock after
> sock_init_data()?
This could work. AF_UNIX is probably the only family that does not
interact with hardware.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3-lockdep -
* Herbert Xu <[EMAIL PROTECTED]> wrote: > On Tue, Jun 06, 2006 at 04:39:21PM +, Stefan Richter wrote: > > > > BTW, the locking in -mm's net/unix/af_unix.c::unix_stream_connect() > > differs a bit from stock unix_stream_connect(). I see spin_lock_bh() in > > 2.6.17-rc5-mm3 where 2.6.17-rc5 has spin_lock(). > > Hi Ingo: > > Looks like this change was introduced by the validator patch. Any > idea why this was done? AF_UNIX is a user-space-driven socket so there > shouldn't be any need for BH to be disabled there. yeah. I'll investigate - it's quite likely that sk_receive_queue.lock will have to get per-address family locking rules - right? Maybe it's enough to introduce a separate key for AF_UNIX alone (and still having all other protocols share the locking rules for sk_receive_queue.lock) , by reinitializing its spinlock after sock_init_data()? Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3-lockdep -
On Tue, Jun 06, 2006 at 04:39:21PM +, Stefan Richter wrote:
>
> BTW, the locking in -mm's net/unix/af_unix.c::unix_stream_connect()
> differs a bit from stock unix_stream_connect(). I see spin_lock_bh() in
> 2.6.17-rc5-mm3 where 2.6.17-rc5 has spin_lock().
Hi Ingo:
Looks like this change was introduced by the validator patch. Any idea
why this was done? AF_UNIX is a user-space-driven socket so there shouldn't
be any need for BH to be disabled there.
Even if it does this patch should go through the normal channels rather
than the lock validator.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3-lockdep -
[EMAIL PROTECTED] napsal(a):
...
[ 464.687000] [ BUG: illegal lock usage! ]
[ 464.687000]
[ 464.687000] illegal {in-hardirq-W} -> {hardirq-on-W} usage.
[ 464.687000] id/2700 [HC0[0]:SC0[1]:HE1:SE0] takes:
[ 464.687000] (&list->lock){++..}, at: []
unix_stream_connect+0x334/0x408
[ 464.687000] {in-hardirq-W} state was registered at:
[ 464.687000] [] lockdep_acquire+0x67/0x7f
[ 464.687000] [] _spin_lock_irqsave+0x30/0x3f
[ 464.687000] [] skb_dequeue+0x18/0x49
[ 464.687000] [] hpsb_bus_reset+0x5e/0xa2 [ieee1394]
[ 464.687000] [] ohci_irq_handler+0x370/0x726 [ohci1394]
[ 464.687000] [] handle_IRQ_event+0x1d/0x52
[ 464.687000] [] handle_level_irq+0x97/0xe3
[ 464.687000] [] do_IRQ+0x8b/0xaf
[ 464.687000] irq event stamp: 2964
[ 464.687000] hardirqs last enabled at (2963): []
_spin_unlock_irqrestore+0x3b/0x6d
[ 464.687000] hardirqs last disabled at (2962): []
_spin_lock_irqsave+0x14/0x3f
[ 464.687000] softirqs last enabled at (2956): []
__do_softirq+0x9d/0xa5
[ 464.687000] softirqs last disabled at (2964): []
_spin_lock_bh+0x10/0x3a
[ 464.687000]
[ 464.687000] other info that might help us debug this:
[ 464.687000] 1 locks held by id/2700:
[ 464.687000] #0: (&u->lock){--..}, at: []
unix_stream_connect+0xe8/0x408
[ 464.687000]
[ 464.687000] stack backtrace:
[ 464.687000] [] show_trace_log_lvl+0x64/0x125
[ 464.687000] [] show_trace+0x1b/0x20
[ 464.687000] [] dump_stack+0x1f/0x24
[ 464.687000] [] print_usage_bug+0x1a8/0x1b4
[ 464.687000] [] mark_lock+0x2ba/0x4e5
[ 464.687000] [] __lockdep_acquire+0x476/0xa91
[ 464.687000] [] lockdep_acquire+0x67/0x7f
[ 464.687000] [] _spin_lock_bh+0x2c/0x3a
[ 464.687000] [] unix_stream_connect+0x334/0x408
[ 464.687000] [] sys_connect+0x6e/0xa3
[ 464.687000] [] sys_socketcall+0x96/0x190
[ 464.687000] [] sysenter_past_esp+0x63/0xa1
On second look it doesn't seem to be a problem of the ieee1394 stack but
rather of underlying skb and net infrastructure.
BTW, the locking in -mm's net/unix/af_unix.c::unix_stream_connect()
differs a bit from stock unix_stream_connect(). I see spin_lock_bh() in
2.6.17-rc5-mm3 where 2.6.17-rc5 has spin_lock().
(added Cc: netdev)
--
Stefan Richter
-=-=-==- -==- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
