[PATCH v3] doc:lock: remove reference to clever use of read-write lock

[PATCH v3] doc:lock: remove reference to clever use of read-write lock

[Federico Vaga]

Remove the clever example about read-write lock because this 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.

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

diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
index e93ec6645238..66e3792f8a36 100644
--- a/Documentation/locking/spinlocks.rst
+++ b/Documentation/locking/spinlocks.rst
@@ -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

Re: [PATCH v3] doc:lock: remove reference to clever use of read-write lock

[Will Deacon]

On Sun, Sep 08, 2019 at 08:29:01AM +0200, Federico Vaga wrote:
> Remove the clever example about read-write lock because this type of
> lock is not reccomended anymore (according to the very same document).

reccomended => recommended

> So there is no reason to teach cleaver things that people should not do.

cleaver => clever

> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
> ---
>  Documentation/locking/spinlocks.rst | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
> index e93ec6645238..66e3792f8a36 100644
> --- a/Documentation/locking/spinlocks.rst
> +++ b/Documentation/locking/spinlocks.rst
> @@ -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.
> -

With the typos fixed in the commit message:

Acked-by: Will Deacon <will@kernel.org>

Will

Re: [PATCH v3] doc:lock: remove reference to clever use of read-write lock

[Jonathan Corbet]

On Thu, 12 Sep 2019 14:32:27 +0100
Will Deacon <will@kernel.org> wrote:

> > So there is no reason to teach cleaver things that people should not do.  
> 
> cleaver => clever

I dunno...personally I'm also opposed to teaching people tricks with
cleavers too, at least in the kernel-development context.  Our flame wars
are bad enough as it is...:)

Applied with the typo tweaks, thanks.

jon