The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt
@ 2025-04-22 17:38 Uladzislau Rezki (Sony)
  2025-04-22 17:56 ` Paul E. McKenney
  0 siblings, 1 reply; 5+ messages in thread
From: Uladzislau Rezki (Sony) @ 2025-04-22 17:38 UTC (permalink / raw)
  To: Paul E . McKenney, Joel Fernandes
  Cc: RCU, LKML, Frederic Weisbecker, Neeraj upadhyay, Uladzislau Rezki,
	Oleksiy Avramchenko

The SRCU read-side critical sections describes the difference between
srcu_down_read()/srcu_up_read() and srcu_read_lock()/srcu_read_unlock()
in a way that a last pair must occur on the same CPU.

This is not true, the srcu_read_unlock() can happen on any CPU, but it
must be performed by the same task that invoked srcu_read_lock().

Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
 tools/memory-model/Documentation/explanation.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
index 6dc8b3642458..34aa3172071b 100644
--- a/tools/memory-model/Documentation/explanation.txt
+++ b/tools/memory-model/Documentation/explanation.txt
@@ -1896,7 +1896,7 @@ following respects:
 
 3.	The srcu_down_read() and srcu_up_read() primitives work
 	exactly like srcu_read_lock() and srcu_read_unlock(), except
-	that matching calls don't have to execute on the same CPU.
+	that matching calls don't have to execute within the same context.
 	(The names are meant to be suggestive of operations on
 	semaphores.)  Since the matching is determined by the domain
 	pointer and index value, these primitives make it possible for
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt
  2025-04-22 17:38 [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt Uladzislau Rezki (Sony)
@ 2025-04-22 17:56 ` Paul E. McKenney
  2025-04-22 22:55   ` Joel Fernandes
  0 siblings, 1 reply; 5+ messages in thread
From: Paul E. McKenney @ 2025-04-22 17:56 UTC (permalink / raw)
  To: Uladzislau Rezki (Sony)
  Cc: Joel Fernandes, RCU, LKML, Frederic Weisbecker, Neeraj upadhyay,
	Oleksiy Avramchenko

On Tue, Apr 22, 2025 at 07:38:30PM +0200, Uladzislau Rezki (Sony) wrote:
> The SRCU read-side critical sections describes the difference between
> srcu_down_read()/srcu_up_read() and srcu_read_lock()/srcu_read_unlock()
> in a way that a last pair must occur on the same CPU.
> 
> This is not true, the srcu_read_unlock() can happen on any CPU, but it
> must be performed by the same task that invoked srcu_read_lock().
> 
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

Good catch!

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

> ---
>  tools/memory-model/Documentation/explanation.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
> index 6dc8b3642458..34aa3172071b 100644
> --- a/tools/memory-model/Documentation/explanation.txt
> +++ b/tools/memory-model/Documentation/explanation.txt
> @@ -1896,7 +1896,7 @@ following respects:
>  
>  3.	The srcu_down_read() and srcu_up_read() primitives work
>  	exactly like srcu_read_lock() and srcu_read_unlock(), except
> -	that matching calls don't have to execute on the same CPU.
> +	that matching calls don't have to execute within the same context.
>  	(The names are meant to be suggestive of operations on
>  	semaphores.)  Since the matching is determined by the domain
>  	pointer and index value, these primitives make it possible for
> -- 
> 2.39.5
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt
  2025-04-22 17:56 ` Paul E. McKenney
@ 2025-04-22 22:55   ` Joel Fernandes
  2025-04-22 22:56     ` Joel Fernandes
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Fernandes @ 2025-04-22 22:55 UTC (permalink / raw)
  To: paulmck, Uladzislau Rezki (Sony)
  Cc: Joel Fernandes, RCU, LKML, Frederic Weisbecker, Neeraj upadhyay,
	Oleksiy Avramchenko



On 4/22/2025 1:56 PM, Paul E. McKenney wrote:
> On Tue, Apr 22, 2025 at 07:38:30PM +0200, Uladzislau Rezki (Sony) wrote:
>> The SRCU read-side critical sections describes the difference between
>> srcu_down_read()/srcu_up_read() and srcu_read_lock()/srcu_read_unlock()
>> in a way that a last pair must occur on the same CPU.
>>
>> This is not true, the srcu_read_unlock() can happen on any CPU, but it
>> must be performed by the same task that invoked srcu_read_lock().
>>
>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> 
> Good catch!
> 
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

Applied, thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt
  2025-04-22 22:55   ` Joel Fernandes
@ 2025-04-22 22:56     ` Joel Fernandes
  2025-04-22 23:06       ` Paul E. McKenney
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Fernandes @ 2025-04-22 22:56 UTC (permalink / raw)
  To: paulmck, Uladzislau Rezki (Sony)
  Cc: Joel Fernandes, RCU, LKML, Frederic Weisbecker, Neeraj upadhyay,
	Oleksiy Avramchenko



On 4/22/2025 6:55 PM, Joel Fernandes wrote:
> 
> 
> On 4/22/2025 1:56 PM, Paul E. McKenney wrote:
>> On Tue, Apr 22, 2025 at 07:38:30PM +0200, Uladzislau Rezki (Sony) wrote:
>>> The SRCU read-side critical sections describes the difference between
>>> srcu_down_read()/srcu_up_read() and srcu_read_lock()/srcu_read_unlock()
>>> in a way that a last pair must occur on the same CPU.
>>>
>>> This is not true, the srcu_read_unlock() can happen on any CPU, but it
>>> must be performed by the same task that invoked srcu_read_lock().
>>>
>>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
>>
>> Good catch!
>>
>> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Applied, thanks.
> 

Oops, though this is memory model and not RCU per-se. Paul do you want to take
it or should I? ;)

 - Joel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt
  2025-04-22 22:56     ` Joel Fernandes
@ 2025-04-22 23:06       ` Paul E. McKenney
  0 siblings, 0 replies; 5+ messages in thread
From: Paul E. McKenney @ 2025-04-22 23:06 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Uladzislau Rezki (Sony), Joel Fernandes, RCU, LKML,
	Frederic Weisbecker, Neeraj upadhyay, Oleksiy Avramchenko

On Tue, Apr 22, 2025 at 06:56:17PM -0400, Joel Fernandes wrote:
> 
> 
> On 4/22/2025 6:55 PM, Joel Fernandes wrote:
> > 
> > 
> > On 4/22/2025 1:56 PM, Paul E. McKenney wrote:
> >> On Tue, Apr 22, 2025 at 07:38:30PM +0200, Uladzislau Rezki (Sony) wrote:
> >>> The SRCU read-side critical sections describes the difference between
> >>> srcu_down_read()/srcu_up_read() and srcu_read_lock()/srcu_read_unlock()
> >>> in a way that a last pair must occur on the same CPU.
> >>>
> >>> This is not true, the srcu_read_unlock() can happen on any CPU, but it
> >>> must be performed by the same task that invoked srcu_read_lock().
> >>>
> >>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> >>
> >> Good catch!
> >>
> >> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > Applied, thanks.
> > 
> 
> Oops, though this is memory model and not RCU per-se. Paul do you want to take
> it or should I? ;)

Heh!  I will take this one.  One of those days, I guess!

						Thanx, Pau

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-04-22 23:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-22 17:38 [PATCH] tools/memory-model/Documentation: Fix SRCU section in explanation.txt Uladzislau Rezki (Sony)
2025-04-22 17:56 ` Paul E. McKenney
2025-04-22 22:55   ` Joel Fernandes
2025-04-22 22:56     ` Joel Fernandes
2025-04-22 23:06       ` Paul E. McKenney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox