History log of /linux-master/Documentation/locking/locktypes.rst
Revision Date Author Comments
# d56b699d 14-Aug-2023 Bjorn Helgaas <bhelgaas@google.com>

Documentation: Fix typos

Fix typos in Documentation.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 8d6451b9 21-Mar-2022 Guilherme G. Piccoli <gpiccoli@igalia.com>

Documentation: Fix duplicate statement about raw_spinlock_t type

Unless it was duplicate on purpose, to emphasize that a raw_spinlock_t
is always a spinning lock regardless of PREEMPT_RT or kernel config,
it's a bit odd that this text is duplicate. So, this patch just clean
it up, keeping the consistency with the other sections of the text.

Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 919e9e6395cf ("Documentation: Add lock ordering and nesting documentation")
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Link: https://lore.kernel.org/r/20220321144133.49804-1-gpiccoli@igalia.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 0d2be10b 24-Feb-2022 Andrew Halaney <ahalaney@redhat.com>

Documentation/locking/locktypes: Fix PREEMPT_RT _bh() description

With PREEMPT_RT the _bh() version of a spinlock leaves preemption
enabled, align the doc to say that instead of the opposite.

Reported-by: Leah Leshchinsky <lleshchi@redhat.com>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20220224212312.2601153-1-ahalaney@redhat.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 6a631c04 27-Nov-2021 Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Documentation/locking/locktypes: Update migrate_disable() bits.

The initial implementation of migrate_disable() for mainline was a
wrapper around preempt_disable(). RT kernels substituted this with
a real migrate disable implementation.

Later on mainline gained true migrate disable support, but the
documentation was not updated.

Update the documentation, remove the claims about migrate_disable()
mapping to preempt_disable() on non-PREEMPT_RT kernels.

Fixes: 74d862b682f51 ("sched: Make migrate_disable/enable() independent of RT")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211127163200.10466-2-bigeasy@linutronix.de


# 92b4e9f1 26-Jul-2020 Marta Rybczynska <rybczynska@gmail.com>

Documentation/locking/locktypes: Fix local_locks documentation

Fix issues with local_locks documentation:

- fix function names, local_lock.h has local_unlock_irqrestore(), not
local_lock_irqrestore()

- fix mapping table, local_unlock_irqrestore() maps to
local_irq_restore(), not _save()

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/CAApg2=SKxQ3Sqwj6TZnV-0x0cKLXFKDaPvXT4N15MPDMKq724g@mail.gmail.com


# 94dea151 26-Jul-2020 Marta Rybczynska <rybczynska@gmail.com>

Documentation/locking/locktypes: fix local_locks documentation

Fix issues with local_locks documentation:
- fix function names, local_lock.h has local_unlock_irqrestore(),
not local_lock_irqrestore()
- fix mapping table, local_unlock_irqrestore() maps to local_irq_restore(),
not _save()

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/CAApg2=SKxQ3Sqwj6TZnV-0x0cKLXFKDaPvXT4N15MPDMKq724g@mail.gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 1edcd467 13-Aug-2020 Huang Shijie <sjhuang@iluvatar.ai>

Documentation/locking/locktypes: fix the typo

We have three categories locks, not two.

Signed-off-by: Huang Shijie <sjhuang@iluvatar.ai>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200813060220.18199-1-sjhuang@iluvatar.ai
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# cb75c95c 13-Aug-2020 Huang Shijie <sjhuang@iluvatar.ai>

Documentation/locking/locktypes: Fix a typo

We have three categories locks, not two.

Signed-off-by: Huang Shijie <sjhuang@iluvatar.ai>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200813060220.18199-1-sjhuang@iluvatar.ai


# 91710728 27-May-2020 Thomas Gleixner <tglx@linutronix.de>

locking: Introduce local_lock()

preempt_disable() and local_irq_disable/save() are in principle per CPU big
kernel locks. This has several downsides:

- The protection scope is unknown

- Violation of protection rules is hard to detect by instrumentation

- For PREEMPT_RT such sections, unless in low level critical code, can
violate the preemptability constraints.

To address this PREEMPT_RT introduced the concept of local_locks which are
strictly per CPU.

The lock operations map to preempt_disable(), local_irq_disable/save() and
the enabling counterparts on non RT enabled kernels.

If lockdep is enabled local locks gain a lock map which tracks the usage
context. This will catch cases where an area is protected by
preempt_disable() but the access also happens from interrupt context. local
locks have identified quite a few such issues over the years, the most
recent example is:

b7d5dc21072cd ("random: add a spinlock_t to struct batched_entropy")

Aside of the lockdep coverage this also improves code readability as it
precisely annotates the protection scope.

PREEMPT_RT substitutes these local locks with 'sleeping' spinlocks to
protect such sections while maintaining preemtability and CPU locality.

local locks can replace:

- preempt_enable()/disable() pairs
- local_irq_disable/enable() pairs
- local_irq_save/restore() pairs

They are also used to replace code which implicitly disables preemption
like:

- get_cpu()/put_cpu()
- get_cpu_var()/put_cpu_var()

with PREEMPT_RT friendly constructs.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20200527201119.1692513-2-bigeasy@linutronix.de


# 51e69e65 25-Mar-2020 Randy Dunlap <rdunlap@infradead.org>

Documentation/locking/locktypes: Minor copy editor fixes

Minor editorial fixes:
- remove 'enabled' from PREEMPT_RT enabled kernels for consistency
- add some periods for consistency
- add "'" for possessive CPU's
- spell out interrupts

[ tglx: Picked up Paul's suggestions ]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://lkml.kernel.org/r/ac615f36-0b44-408d-aeab-d76e4241add4@infradead.org


# 7ecc6aa5 25-Mar-2020 Thomas Gleixner <tglx@linutronix.de>

Documentation/locking/locktypes: Further clarifications and wordsmithing

The documentation of rw_semaphores is wrong as it claims that the non-owner
reader release is not supported by RT. That's just history biased memory
distortion.

Split the 'Owner semantics' section up and add separate sections for
semaphore and rw_semaphore to reflect reality.

Aside of that the following updates are done:

- Add pseudo code to document the spinlock state preserving mechanism on
PREEMPT_RT

- Wordsmith the bitspinlock and lock nesting sections

Co-developed-by: Paul McKenney <paulmck@kernel.org>
Signed-off-by: Paul McKenney <paulmck@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/87wo78y5yy.fsf@nanos.tec.linutronix.de


# 919e9e63 20-Mar-2020 Thomas Gleixner <tglx@linutronix.de>

Documentation: Add lock ordering and nesting documentation

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.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113242.026561244@linutronix.de