All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Jiunn Chang <c0d1n61at3@gmail.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	josh@joshtriplett.org, rostedt@goodmis.org,
	mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com,
	joel@joelfernandes.org, corbet@lwn.net, rcu@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Linux-kernel-mentees][PATCH] doc: RCU callback locks need only _bh, not necessarily _irq
Date: Thu, 27 Jun 2019 15:10:45 -0700	[thread overview]
Message-ID: <20190627221045.GH26519@linux.ibm.com> (raw)
In-Reply-To: <bc2ce605-56ab-33aa-c94d-d7774e6ce8cd@linuxfoundation.org>

On Thu, Jun 27, 2019 at 04:01:35PM -0600, Shuah Khan wrote:
> On 6/27/19 3:01 PM, Jiunn Chang wrote:
> >The UP.rst file calls for locks acquired within RCU callback functions
> >to use _irq variants (spin_lock_irqsave() or similar), which does work,
> >but can be overkill.  This commit therefore instead calls for _bh variants
> >(spin_lock_bh() or similar), while noting that _irq does work.
> >
> >Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> 
> Should this by Suggested-by?

I wrote it and Jiunn converted my change to .rst, so I believe that
this is correct as is.

							Thanx, Paul

> >Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
> >---
> >  Documentation/RCU/UP.rst | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> >diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
> >index 67715a47ae89..e26dda27430c 100644
> >--- a/Documentation/RCU/UP.rst
> >+++ b/Documentation/RCU/UP.rst
> >@@ -113,12 +113,13 @@ Answer to Quick Quiz #1:
> >  Answer to Quick Quiz #2:
> >  	What locking restriction must RCU callbacks respect?
> >-	Any lock that is acquired within an RCU callback must be
> >-	acquired elsewhere using an _irq variant of the spinlock
> >-	primitive.  For example, if "mylock" is acquired by an
> >-	RCU callback, then a process-context acquisition of this
> >-	lock must use something like spin_lock_irqsave() to
> >-	acquire the lock.
> >+	Any lock that is acquired within an RCU callback must be acquired
> >+	elsewhere using an _bh variant of the spinlock primitive.
> >+	For example, if "mylock" is acquired by an RCU callback, then
> >+	a process-context acquisition of this lock must use something
> >+	like spin_lock_bh() to acquire the lock.  Please note that
> >+	it is also OK to use _irq variants of spinlocks, for example,
> >+	spin_lock_irqsave().
> >  	If the process-context code were to simply use spin_lock(),
> >  	then, since RCU callbacks can be invoked from softirq context,
> >
> 
> thanks,
> -- Shuah
> 


WARNING: multiple messages have this Message-ID (diff)
From: paulmck at linux.ibm.com (Paul E. McKenney)
Subject: [Linux-kernel-mentees] [PATCH] doc: RCU callback locks need only _bh, not necessarily _irq
Date: Thu, 27 Jun 2019 15:10:45 -0700	[thread overview]
Message-ID: <20190627221045.GH26519@linux.ibm.com> (raw)
In-Reply-To: <bc2ce605-56ab-33aa-c94d-d7774e6ce8cd@linuxfoundation.org>

On Thu, Jun 27, 2019 at 04:01:35PM -0600, Shuah Khan wrote:
> On 6/27/19 3:01 PM, Jiunn Chang wrote:
> >The UP.rst file calls for locks acquired within RCU callback functions
> >to use _irq variants (spin_lock_irqsave() or similar), which does work,
> >but can be overkill.  This commit therefore instead calls for _bh variants
> >(spin_lock_bh() or similar), while noting that _irq does work.
> >
> >Signed-off-by: Paul E. McKenney <paulmck at linux.ibm.com>
> 
> Should this by Suggested-by?

I wrote it and Jiunn converted my change to .rst, so I believe that
this is correct as is.

							Thanx, Paul

> >Signed-off-by: Jiunn Chang <c0d1n61at3 at gmail.com>
> >---
> >  Documentation/RCU/UP.rst | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> >diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
> >index 67715a47ae89..e26dda27430c 100644
> >--- a/Documentation/RCU/UP.rst
> >+++ b/Documentation/RCU/UP.rst
> >@@ -113,12 +113,13 @@ Answer to Quick Quiz #1:
> >  Answer to Quick Quiz #2:
> >  	What locking restriction must RCU callbacks respect?
> >-	Any lock that is acquired within an RCU callback must be
> >-	acquired elsewhere using an _irq variant of the spinlock
> >-	primitive.  For example, if "mylock" is acquired by an
> >-	RCU callback, then a process-context acquisition of this
> >-	lock must use something like spin_lock_irqsave() to
> >-	acquire the lock.
> >+	Any lock that is acquired within an RCU callback must be acquired
> >+	elsewhere using an _bh variant of the spinlock primitive.
> >+	For example, if "mylock" is acquired by an RCU callback, then
> >+	a process-context acquisition of this lock must use something
> >+	like spin_lock_bh() to acquire the lock.  Please note that
> >+	it is also OK to use _irq variants of spinlocks, for example,
> >+	spin_lock_irqsave().
> >  	If the process-context code were to simply use spin_lock(),
> >  	then, since RCU callbacks can be invoked from softirq context,
> >
> 
> thanks,
> -- Shuah
> 

WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.ibm.com (Paul E. McKenney)
Subject: [Linux-kernel-mentees] [PATCH] doc: RCU callback locks need only _bh, not necessarily _irq
Date: Thu, 27 Jun 2019 15:10:45 -0700	[thread overview]
Message-ID: <20190627221045.GH26519@linux.ibm.com> (raw)
Message-ID: <20190627221045.UANe-a9Ocd4O837y9lFyGV38ufeDHUnxy6HeadHC3zs@z> (raw)
In-Reply-To: <bc2ce605-56ab-33aa-c94d-d7774e6ce8cd@linuxfoundation.org>

On Thu, Jun 27, 2019 at 04:01:35PM -0600, Shuah Khan wrote:
> On 6/27/19 3:01 PM, Jiunn Chang wrote:
> >The UP.rst file calls for locks acquired within RCU callback functions
> >to use _irq variants (spin_lock_irqsave() or similar), which does work,
> >but can be overkill.  This commit therefore instead calls for _bh variants
> >(spin_lock_bh() or similar), while noting that _irq does work.
> >
> >Signed-off-by: Paul E. McKenney <paulmck at linux.ibm.com>
> 
> Should this by Suggested-by?

I wrote it and Jiunn converted my change to .rst, so I believe that
this is correct as is.

							Thanx, Paul

> >Signed-off-by: Jiunn Chang <c0d1n61at3 at gmail.com>
> >---
> >  Documentation/RCU/UP.rst | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> >diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
> >index 67715a47ae89..e26dda27430c 100644
> >--- a/Documentation/RCU/UP.rst
> >+++ b/Documentation/RCU/UP.rst
> >@@ -113,12 +113,13 @@ Answer to Quick Quiz #1:
> >  Answer to Quick Quiz #2:
> >  	What locking restriction must RCU callbacks respect?
> >-	Any lock that is acquired within an RCU callback must be
> >-	acquired elsewhere using an _irq variant of the spinlock
> >-	primitive.  For example, if "mylock" is acquired by an
> >-	RCU callback, then a process-context acquisition of this
> >-	lock must use something like spin_lock_irqsave() to
> >-	acquire the lock.
> >+	Any lock that is acquired within an RCU callback must be acquired
> >+	elsewhere using an _bh variant of the spinlock primitive.
> >+	For example, if "mylock" is acquired by an RCU callback, then
> >+	a process-context acquisition of this lock must use something
> >+	like spin_lock_bh() to acquire the lock.  Please note that
> >+	it is also OK to use _irq variants of spinlocks, for example,
> >+	spin_lock_irqsave().
> >  	If the process-context code were to simply use spin_lock(),
> >  	then, since RCU callbacks can be invoked from softirq context,
> >
> 
> thanks,
> -- Shuah
> 

  reply	other threads:[~2019-06-27 22:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 21:01 [Linux-kernel-mentees][PATCH] doc: RCU callback locks need only _bh, not necessarily _irq Jiunn Chang
2019-06-27 21:01 ` [Linux-kernel-mentees] [PATCH] " Jiunn Chang
2019-06-27 21:01 ` c0d1n61at3
2019-06-27 22:01 ` [Linux-kernel-mentees][PATCH] " Shuah Khan
2019-06-27 22:01   ` [Linux-kernel-mentees] [PATCH] " Shuah Khan
2019-06-27 22:01   ` skhan
2019-06-27 22:10   ` Paul E. McKenney [this message]
2019-06-27 22:10     ` Paul E. McKenney
2019-06-27 22:10     ` paulmck
2019-06-27 22:11     ` [Linux-kernel-mentees][PATCH] " Shuah Khan
2019-06-27 22:11       ` [Linux-kernel-mentees] [PATCH] " Shuah Khan
2019-06-27 22:11       ` skhan
2019-06-27 22:29     ` [Linux-kernel-mentees][PATCH] " Steven Rostedt
2019-06-27 22:29       ` [Linux-kernel-mentees] [PATCH] " Steven Rostedt
2019-06-27 22:29       ` rostedt
2019-06-27 22:42       ` [Linux-kernel-mentees][PATCH] " Paul E. McKenney
2019-06-27 22:42         ` [Linux-kernel-mentees] [PATCH] " Paul E. McKenney
2019-06-27 22:42         ` paulmck
2019-06-28 15:11 ` [Linux-kernel-mentees][PATCH] " Jonathan Corbet
2019-06-28 15:11   ` [Linux-kernel-mentees] [PATCH] " Jonathan Corbet
2019-06-28 15:11   ` 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=20190627221045.GH26519@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=c0d1n61at3@gmail.com \
    --cc=corbet@lwn.net \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.