On 01/06/19(Sat) 23:22, Mark Kettenis wrote: > > Date: Sat, 1 Jun 2019 17:32:52 -0300 > > From: Martin Pieuchot <[email protected]> > > > > 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?
