linux-toradex.git/Documentation/locking, branch v6.0-rc6

Documentation: Fix duplicate statement about raw_spinlock_t type

2022-03-25T19:30:08+00:00

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 
Fixes: 919e9e6395cf ("Documentation: Add lock ordering and nesting documentation")
Signed-off-by: Guilherme G. Piccoli 
Link: https://lore.kernel.org/r/20220321144133.49804-1-gpiccoli@igalia.com
Signed-off-by: Jonathan Corbet

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

2022-03-04T17:13:19+00:00

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 
Signed-off-by: Andrew Halaney 
Reviewed-by: Boqun Feng 
Link: https://lore.kernel.org/r/20220224212312.2601153-1-ahalaney@redhat.com
Signed-off-by: Jonathan Corbet

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

2021-11-30T14:40:31+00:00

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 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20211127163200.10466-2-bigeasy@linutronix.de

doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup

2021-10-01T17:01:05+00:00

The previous commits do exactly what this entry in the TODO file asks
for, thus we can remove it now as it is no longer applicable.

Signed-off-by: Fernando Ramos 
Reviewed-by: Sean Paul 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-18-greenfoo@u92.eu

Documentation: locking: fix references

2021-08-24T19:20:39+00:00

This patch fixes file references from txt to rst file ending in
ww-mutex-design.rst and futex-requeue-pi.rst. While on it fix a spelling
issue "desgin" to "design" reported by Matthew Wilcox.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210823183143.1691344-1-aahringo@redhat.com
Signed-off-by: Jonathan Corbet

locking/lockdep,doc: Improve readability of the block matrix

2021-05-31T08:14:54+00:00

The block condition matrix is using 'E' as the writer notation,
however, the writer reminder below the matrix is using 'W', to make
them consistent and make the matrix more readable, we'd better to use
'W' to represent writer.

Suggested-by: Waiman Long 
Suggested-by: Boqun Feng 
Signed-off-by: Xiongwei Song 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Boqun Feng 
Link: https://lkml.kernel.org/r/1621868745-23311-1-git-send-email-sxwjean@me.com

Documentation: seqlock: s/LOCKTYPE/LOCKNAME/g

2020-12-09T16:08:49+00:00

Sequence counters with an associated write serialization lock are called
seqcount_LOCKNAME_t. Fix the documentation accordingly.

While at it, remove a paragraph that inappropriately discussed a
seqlock.h implementation detail.

Fixes: 6dd699b13d53 ("seqlock: seqcount_LOCKNAME_t: Standardize naming convention")
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20201206162143.14387-2-a.darwish@linutronix.de

docs: lockdep-design: fix some warning issues

2020-10-28T17:41:15+00:00

There are several warnings caused by a recent change
224ec489d3cd ("lockdep/Documention: Recursive read lock detection reasoning")

Those are reported by htmldocs build:

Documentation/locking/lockdep-design.rst:429: WARNING: Definition list ends without a blank line; unexpected unindent.
Documentation/locking/lockdep-design.rst:452: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/locking/lockdep-design.rst:453: WARNING: Unexpected indentation.
Documentation/locking/lockdep-design.rst:453: WARNING: Blank line required after table.
Documentation/locking/lockdep-design.rst:454: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/locking/lockdep-design.rst:455: WARNING: Unexpected indentation.
Documentation/locking/lockdep-design.rst:455: WARNING: Blank line required after table.
Documentation/locking/lockdep-design.rst:456: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/locking/lockdep-design.rst:457: WARNING: Unexpected indentation.
Documentation/locking/lockdep-design.rst:457: WARNING: Blank line required after table.

Besides the reported issues, there are some missing blank
lines that ended producing wrong html output, and some
literals are not properly identified.

Also, the symbols used at the irq enabled/disable table
are not displayed as expected, as they're not literals.
Also, on another table they're using a different notation.

Fixes: 224ec489d3cd ("lockdep/Documention: Recursive read lock detection reasoning")
Signed-off-by: Mauro Carvalho Chehab
Link: https://lore.kernel.org/r/3b9431ac5c01e38111cd59928a93e7259ab7db0f.1603791716.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet

seqlock: Introduce seqcount_latch_t

2020-09-10T09:19:28+00:00

Latch sequence counters are a multiversion concurrency control mechanism
where the seqcount_t counter even/odd value is used to switch between
two copies of protected data. This allows the seqcount_t read path to
safely interrupt its write side critical section (e.g. from NMIs).

Initially, latch sequence counters were implemented as a single write
function above plain seqcount_t: raw_write_seqcount_latch(). The read
side was expected to use plain seqcount_t raw_read_seqcount().

A specialized latch read function, raw_read_seqcount_latch(), was later
added. It became the standardized way for latch read paths.  Due to the
dependent load, it has one read memory barrier less than the plain
seqcount_t raw_read_seqcount() API.

Only raw_write_seqcount_latch() and raw_read_seqcount_latch() should be
used with latch sequence counters. Having *unique* read and write path
APIs means that latch sequence counters are actually a data type of
their own -- just inappropriately overloading plain seqcount_t.

Introduce seqcount_latch_t. This adds type-safety and ensures that only
the correct latch-safe APIs are to be used.

Not to break bisection, let the latch APIs also accept plain seqcount_t
or seqcount_raw_spinlock_t. After converting all call sites to
seqcount_latch_t, only that new data type will be allowed.

References: 9b0fd802e8c0 ("seqcount: Add raw_write_seqcount_latch()")
References: 7fc26327b756 ("seqlock: Introduce raw_read_seqcount_latch()")
References: aadd6e5caaac ("time/sched_clock: Use raw_read_seqcount_latch()")
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20200827114044.11173-4-a.darwish@linutronix.de

lockdep/Documention: Recursive read lock detection reasoning

2020-08-26T10:42:03+00:00

This patch add the documentation piece for the reasoning of deadlock
detection related to recursive read lock. The following sections are
added:

*	Explain what is a recursive read lock, and what deadlock cases
	they could introduce.

*	Introduce the notations for different types of dependencies, and
	the definition of strong paths.

*	Proof for a closed strong path is both sufficient and necessary
	for deadlock detections with recursive read locks involved. The
	proof could also explain why we call the path "strong"

Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20200807074238.1632519-3-boqun.feng@gmail.com