On 29/05/18(Tue) 10:00, Mathieu - wrote: > Mark Kettenis wrote: > > > Date: Mon, 28 May 2018 12:24:22 +0200 > > > From: Mathieu - <naa...@poolp.org> > > > > > > Mark Kettenis wrote: > > > > > Date: Mon, 28 May 2018 11:23:47 +0200 > > > > > From: Martin Pieuchot <m...@openbsd.org> > > > > > > > > > > As found by tb@ and visa@, `f_mtx' need to block interrupts as long as > > > > > it can be taken w/ and w/o the KERNEL_LOCK(). Otherwise a deadlock is > > > > > possible if an interrupt tries to grab the KERNEL_LOCK(). > > > > > > > > > > I'm not switching to a rwlock because code paths are short, I don't > > > > > want to introduce new sleeping points and in the long run we should > > > > > be using SRPs or atomic operations for reference counts. > > > > > > > > > > ok? > > > > > > > > I suppose IPL_VM is the most sensible default for mutexes that need to > > > > block all interrupts that might need the kernel lock. > > > > > > > > ok kettenis@ > > > > > > > > > Hello, > > > > > > Wouldn't IPL_MPFLOOR be more appropriate? After all mutexes are already > > > raising the ipl level to IPL_MPFLOOR (expect for IPL_NONE and above). > > > > The problem is that IPL_MPFLOOR doesn't exist on all platforms. Maybe > > it should... > > Ah yeah right, my bad, my grep-foo isn't up to par it seems. Landisk > tricked me by using the MI mutex implementation.
Then go ahead and submit a diff (in a new thread)! You seem to understand quite well our code, time to contribute 8) We always need more kernel hackers!
