lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 27 Jun 2019 16:01:35 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Jiunn Chang <c0d1n61at3@...il.com>
Cc:     linux-kernel-mentees@...ts.linuxfoundation.org,
        paulmck@...ux.ibm.com, josh@...htriplett.org, rostedt@...dmis.org,
        mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
        joel@...lfernandes.org, corbet@....net, rcu@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        "skh >> Shuah Khan" <skhan@...uxfoundation.org>
Subject: Re: [Linux-kernel-mentees][PATCH] doc: RCU callback locks need only
 _bh, not necessarily _irq

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@...ux.ibm.com>

Should this by Suggested-by?

> Signed-off-by: Jiunn Chang <c0d1n61at3@...il.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

Powered by blists - more mailing lists