Re: CVS commit: src/sys/kern

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Aug 29, 2009 at 09:53:14AM +0000, Andrew Doran wrote:
> On Wed, Aug 26, 2009 at 10:34:47PM +0000, Manuel Bouyer wrote:
> > Module Name:        src
> > Committed By:       bouyer
> > Date:               Wed Aug 26 22:34:47 UTC 2009
> > 
> > Modified Files:
> >     src/sys/kern: uipc_usrreq.c
> > 
> > Log Message:
> > In uipc_usrreq(PRU_ACCEPT), grab the unp_streamlock before 
> > unp_setpeerlocks().
> > This fixes a race where, for a short period of time, so->so_lock and
> > so2->so_lock are not sync. This makes solocked2() and solocked()
> > unreliable and cause DIAGNOSTIC kernel panics. This also fixes a possible
> > panic in unp_setaddr() which expects the socket locked.
> > Should fix kern/38968, fix proposed in
> > http://mail-index.netbsd.org/tech-kern/2009/08/17/msg005863.html
> 
> I think this is wrong and could cause a deadlock.

How ? All what we do with the lock grabbed is calling unp_setpeerlocks(),
which  AFAIK doesn't take another lock, and unp_setaddr() which expects
the socket locked.
Or do you mean something else may want a lock we already have while holding
sotounpcb(so2)->unp_streamlock ?

> We know that the modus
> operandi breaks solocked2(), but does it really break solocked()?

Yes, I explained a possible senario in
http://mail-index.netbsd.org/tech-kern/2009/08/17/msg005863.html

> I think we
> should revert this one.

What about the unp_setaddr() issue ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--