From: Will Deacon <will@kernel.org>
To: Federico Vaga <federico.vaga@vaga.pv.it>
Cc: Jonathan Corbet <corbet@lwn.net>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] doc:lock: remove reference to clever use of read-write lock
Date: Thu, 12 Sep 2019 14:32:27 +0100 [thread overview]
Message-ID: <20190912133226.oeo3eecvzfr52yv3@willie-the-truck> (raw)
In-Reply-To: <20190908062901.4218-1-federico.vaga@vaga.pv.it>
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
next prev parent reply other threads:[~2019-09-12 13:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-08 6:29 [PATCH v3] doc:lock: remove reference to clever use of read-write lock Federico Vaga
2019-09-12 13:32 ` Will Deacon [this message]
2019-09-14 7:55 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190912133226.oeo3eecvzfr52yv3@willie-the-truck \
--to=will@kernel.org \
--cc=corbet@lwn.net \
--cc=federico.vaga@vaga.pv.it \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).