On Sat, Jun 01, 2019 at 07:04:23PM -0300, Martin Pieuchot wrote: > On 01/06/19(Sat) 23:22, Mark Kettenis wrote: > > > Date: Sat, 1 Jun 2019 17:32:52 -0300 > > > From: Martin Pieuchot <m...@openbsd.org> > > > > > > Currently it isn't safe to call mtx_enter_try(9) if you're already > > > holding the mutex. That means it isn't safe to call that function > > > in hardclock(9), like with `windup_mtx'. That's why the mutex needs > > > to be initialized as IPL_CLOCK. > > > > > > I'm working on removing the SCHED_LOCK() from inside hardclock(9). > > > That leads me to wonder if I should initialize all mutexes to IPL_SCHED, > > > possibly blocking clock interrupts, or if we should change the mutex API > > > to allow mtx_enter_try(9) to deal with recursion. > > > > > > The diff below removes the recursion check for mtx_enter_try(9). > > > > > > Comments? Oks? > > > > My initial reaction is that if you're trying to lock when you already > > have the lock, there is something wrong with your locking strategy and > > that this is something we don't want. > > Could you elaborate? Are you saying that preventing hardclock(9) to run > is the way to move forward to unlock its internals? Why isn't that > strategy wrong? > > In the `windup_mtx' case, does it matter if the mutex is taken by > another CPU or by myself? What's the problem when CPU0 is one holding > the lock?
mutex(9) is not and should not become recursive. Recursive locking works when it is voluntary. If recursion was allowed with interrupts, the CPU could re-enter the critical section at any moment, possibly seeing inconsistent state or breaking assumptions made by the original entry.
