linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] doc:lock: remove reference to clever use of read-write lock
@ 2019-08-31 13:41 Federico Vaga
  2019-08-31 14:43 ` Jonathan Corbet
  0 siblings, 1 reply; 9+ messages in thread
From: Federico Vaga @ 2019-08-31 13:41 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, linux-kernel,
	linux-doc, Federico Vaga

Remove the clever example about read-write lock because these type of
lock is not reccomended anymore (according to the very same document).
So there is no reason to teach cleaver things that people should not do.

(and by the way there was a little typo)

Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
 Documentation/locking/spinlocks.rst | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
index e93ec6645238..8053fd4c3544 100644
--- a/Documentation/locking/spinlocks.rst
+++ b/Documentation/locking/spinlocks.rst
@@ -106,7 +106,7 @@ and on other architectures it can be worse).
 
 If you have a case where you have to protect a data structure across
 several CPU's and you want to use spinlocks you can potentially use
-cheaper versions of the spinlocks. IFF you know that the spinlocks are
+cheaper versions of the spinlocks. If you know that the spinlocks are
 never used in interrupt handlers, you can use the non-irq versions::
 
 	spin_lock(&lock);
@@ -139,18 +139,6 @@ on other CPU's, because an interrupt on another CPU doesn't interrupt the
 CPU that holds the lock, so the lock-holder can continue and eventually
 releases the lock).
 
-Note that you can be clever with read-write locks and interrupts. For
-example, if you know that the interrupt only ever gets a read-lock, then
-you can use a non-irq version of read locks everywhere - because they
-don't block on each other (and thus there is no dead-lock wrt interrupts.
-But when you do the write-lock, you have to use the irq-safe version.
-
-For an example of being clever with rw-locks, see the "waitqueue_lock"
-handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
-within an interrupt, they only read the queue in order to know whom to
-wake up. So read-locks are safe (which is good: they are very common
-indeed), while write-locks need to protect themselves against interrupts.
-
 		Linus
 
 ----
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-09-05  8:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-31 13:41 [PATCH] doc:lock: remove reference to clever use of read-write lock Federico Vaga
2019-08-31 14:43 ` Jonathan Corbet
2019-09-02  7:01   ` Federico Vaga
2019-09-02 18:10     ` Ingo Molnar
2019-09-02 19:19       ` Federico Vaga
2019-09-02 20:21         ` Jonathan Corbet
2019-09-02 21:07           ` Federico Vaga
2019-09-03  2:38           ` Matthew Wilcox
2019-09-05  8:21   ` Federico Vaga

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).