Linuxkpi lock types

[Emmanuel Vadot]

On Tue, 28 Apr 2020 18:03:57 +0300
Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Tue, Apr 28, 2020 at 04:44:08PM +0200, Emmanuel Vadot wrote:
> > 
> >  Hello,
> > 
> >  I was looking at the linuxkpi locks and notice something that I don't
> > understand.
> > 
> >  For linux struct mutex we use or sx locks but looking at the doc in
> > linux (Documentation/locking/mutex-design.rst) it seems that those are
> > almost 1:1 our mtx, is there a reason that sx where chosen ?
> >  For the linux spinlocks we use MTX_DEF lock, which doesn't seems right
> > at all so same question.
> > 
> >  Thanks for your answers,
> 
> Linux spinlocks must protect interrupt handlers. Since Linuxkpi runs
> handlers threaded, they should (or must) use normal mutexes in FreeBSD
> land, so translation of spinlocks to mutexes is fine. If handlers were
> non-threaded but fast, then linux spinlocks-> FreeBSD mtx_spin is
> somewhat reasonable, but I believe that Linux interrupt handlers might
> try to do things like memory allocation which cannot work from FreeBSD
> fast handlers.
> 
> Also, running handlers with interrupts enabled improves system responsibility
> to other events.
> 
> After spinlocks are translated to sleepable mutexes, it is natural to
> convert sleepable Linux mutexes to sx'es. I do not think that Linux
> mutexes provide priority propagation (but I can be wrong), which
> matches sx behaviour. Also sx provide some more required features like
> interruptible sleep, which mtx lacks.
> 
> In other words, it all starts with the decision to run interrupt handlers
> threaded as most FreeBSD drivers do, and then it is logical to 'step up'
> each locking primitive.  I have some memories the realtime Linux patches
> did the same.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

 Thanks for your answer that explain a lot of things.
 I guess this should be written somewhere ? A comment block in the
header file of linuxkpi might be enough.

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>