Messages in this thread | | | Date | Thu, 19 Mar 2020 09:04:26 -0600 | From | Jonathan Corbet <> | Subject | Re: [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
| |