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 <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
