lkml.org 
[lkml]   [2020]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
    On Wed, 18 Mar 2020 21:43:10 +0100
    Thomas Gleixner <tglx@linutronix.de> wrote:

    > From: Thomas Gleixner <tglx@linutronix.de>
    >
    > The kernel provides a variety of locking primitives. The nesting of these
    > lock types and the implications of them on RT enabled kernels is nowhere
    > documented.
    >
    > Add initial documentation.

    ...time to add a a couple of nits...:)

    > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    > ---
    > V2: Addressed review comments from Randy
    > ---
    > Documentation/locking/index.rst | 1
    > Documentation/locking/locktypes.rst | 298 ++++++++++++++++++++++++++++++++++++
    > 2 files changed, 299 insertions(+)
    > create mode 100644 Documentation/locking/locktypes.rst
    >
    > --- a/Documentation/locking/index.rst
    > +++ b/Documentation/locking/index.rst
    > @@ -7,6 +7,7 @@ locking
    > .. toctree::
    > :maxdepth: 1
    >
    > + locktypes
    > lockdep-design
    > lockstat
    > locktorture
    > --- /dev/null
    > +++ b/Documentation/locking/locktypes.rst
    > @@ -0,0 +1,298 @@
    > +.. _kernel_hacking_locktypes:
    > +

    So ... I vaguely remember that some Thomas guy added a document saying we
    should be putting SPDX tags on our files? :)

    > +==========================
    > +Lock types and their rules
    > +==========================

    [...]

    > +PREEMPT_RT caveats
    > +==================
    > +
    > +spinlock_t and rwlock_t
    > +-----------------------
    > +
    > +The substitution of spinlock_t and rwlock_t on PREEMPT_RT enabled kernels
    > +with RT-mutex based implementations has a few implications.
    > +
    > +On a non PREEMPT_RT enabled kernel the following code construct is
    > +perfectly fine::
    > +
    > + local_irq_disable();
    > + spin_lock(&lock);
    > +
    > +and fully equivalent to::
    > +
    > + spin_lock_irq(&lock);
    > +
    > +Same applies to rwlock_t and the _irqsave() suffix variant.
    > +
    > +On a PREEMPT_RT enabled kernel this breaks because the RT-mutex
    > +substitution expects a fully preemptible context.
    > +
    > +The preferred solution is to use :c:func:`spin_lock_irq()` or
    > +:c:func:`spin_lock_irqsave()` and their unlock counterparts.

    We don't need (and shouldn't use) :c:func: anymore; just saying
    spin_lock_irq() will cause the Right Things to happen.

    Thanks,
    jon

    \
     
     \ /
      Last update: 2020-03-19 16:05    [W:4.054 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site