From: Ingo Molnar <mingo@elte.hu>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
Valdis.Kletnieks@vt.edu, Jiri Slaby <jirislaby@gmail.com>,
Andrew Morton <akpm@osdl.org>,
arjan@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net, netdev@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: 2.6.17-rc5-mm3-lockdep -
Date: Mon, 12 Jun 2006 08:38:07 +0200 [thread overview]
Message-ID: <20060612063807.GA23939@elte.hu> (raw)
In-Reply-To: <20060607071208.GA1951@gondor.apana.org.au>
* Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jun 06, 2006 at 04:39:21PM +0000, 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
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Andrew Morton <akpm@osdl.org>,
linux1394-devel@lists.sourceforge.net, Valdis.Kletnieks@vt.edu,
Jiri Slaby <jirislaby@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@redhat.com, Stefan Richter <stefanr@s5r6.in-berlin.de>,
"David S. Miller" <davem@davemloft.net>,
arjan@infradead.org
Subject: Re: 2.6.17-rc5-mm3-lockdep -
Date: Mon, 12 Jun 2006 08:38:07 +0200 [thread overview]
Message-ID: <20060612063807.GA23939@elte.hu> (raw)
In-Reply-To: <20060607071208.GA1951@gondor.apana.org.au>
* Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jun 06, 2006 at 04:39:21PM +0000, 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
next prev parent reply other threads:[~2006-06-12 6:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-06 2:50 2.6.17-rc5-mm3-lockdep - Valdis.Kletnieks
2006-06-06 7:01 ` Jiri Slaby
2006-06-06 12:48 ` Stefan Richter
2006-06-06 16:39 ` Stefan Richter
2006-06-07 7:12 ` Herbert Xu
2006-06-07 7:12 ` Herbert Xu
2006-06-12 6:38 ` Ingo Molnar [this message]
2006-06-12 6:38 ` Ingo Molnar
2006-06-12 6:41 ` Herbert Xu
2006-06-12 6:41 ` Herbert Xu
2006-06-12 6:57 ` [patch] undo AF_UNIX _bh locking changes and split lock-type instead Ingo Molnar
2006-06-12 6:57 ` Ingo Molnar
2006-06-12 7:03 ` Herbert Xu
2006-06-12 7:03 ` Herbert Xu
2006-06-12 7:18 ` David Miller
2006-06-12 7:18 ` David Miller
2006-06-12 8:49 ` Ingo Molnar
2006-06-12 8:49 ` Ingo Molnar
2006-06-12 20:08 ` David Miller
2006-06-12 20:08 ` David Miller
2006-06-12 6:50 ` 2.6.17-rc5-mm3-lockdep - David Miller
2006-06-06 13:01 ` Valdis.Kletnieks
2006-06-06 13:45 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060612063807.GA23939@elte.hu \
--to=mingo@elte.hu \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.