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
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
> sti
* 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
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 w
[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_c
