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]
Message-ID: <eeda52c2-5397-4aad-ad01-ca04e5b0b80f@paulmck-laptop>
Date: Wed, 26 Mar 2025 15:33:21 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: linux-kernel@...r.kernel.org, Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Joel Fernandes <joel@...lfernandes.org>,
	Josh Triplett <josh@...htriplett.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang1211@...il.com>, rcu@...r.kernel.org
Subject: Re: [PATCH 1/3] rcu: Replace magic number with meaningful constant
 in rcu_seq_done_exact()

On Mon, Mar 24, 2025 at 01:01:53PM -0400, Joel Fernandes wrote:
> The rcu_seq_done_exact() function checks if a grace period has completed by
> comparing sequence numbers. It includes a guard band to handle sequence number
> wraparound, which was previously expressed using the magic number calculation
> '3 * RCU_SEQ_STATE_MASK + 1'.
> 
> This magic number is not immediately obvious in terms of what it represents.
> 
> Instead, the reason we need this tiny guardband is because of the lag between
> the setting of rcu_state.gp_seq_polled and root rnp's gp_seq in rcu_gp_init().
> 
> This guardband needs to be at least 2 GPs worth of counts, to avoid recognizing
> the newly started GP as completed immediately, due to the following sequence
> which arises due to the delay between update of rcu_state.gp_seq_polled and
> root rnp's gp_seq:
> 
> rnp->gp_seq = rcu_state.gp_seq = 0
> 
>     CPU 0                                           CPU 1
>     -----                                           -----
>     // rcu_state.gp_seq = 1
>     rcu_seq_start(&rcu_state.gp_seq)
>                                                     // snap = 8
>                                                     snap = rcu_seq_snap(&rcu_state.gp_seq)
>                                                     // Two full GP differences
>                                                     rcu_seq_done_exact(&rnp->gp_seq, snap)
>     // rnp->gp_seq = 1
>     WRITE_ONCE(rnp->gp_seq, rcu_state.gp_seq);
> 
> This can happen due to get_state_synchronize_rcu_full() sampling
> rcu_state.gp_seq_polled, however the poll_state_synchronize_rcu_full()
> sampling the root rnp's gp_seq. The delay between the update of the 2
> counters occurs in rcu_gp_init() during which the counters briefly go
> out of sync.
> 
> Make the guardband explictly 2 GPs. This improves code readability and
> maintainability by making the intent clearer as well.
> 
> Suggested-by: Frederic Weisbecker <frederic@...nel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>

One concern is that a small error anywhere in the code could cause this
minimal guard band to be too small.  This is not a problem for some
use cases (rcu_barrier() just does an extra operation, and normal grace
periods are protected from forever-idle CPUs by ->gpwrap), but could be
an issue on 32-bit systems for user of polled RCU grace periods.

In contrast, making the guard band a bit longer than it needs to be
has little or no downside.

							Thanx, Paul

> ---
>  kernel/rcu/rcu.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index eed2951a4962..5e1ee570bb27 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -57,6 +57,9 @@
>  /* Low-order bit definition for polled grace-period APIs. */
>  #define RCU_GET_STATE_COMPLETED	0x1
>  
> +/* A complete grace period count */
> +#define RCU_SEQ_GP (RCU_SEQ_STATE_MASK + 1)
> +
>  extern int sysctl_sched_rt_runtime;
>  
>  /*
> @@ -162,7 +165,7 @@ static inline bool rcu_seq_done_exact(unsigned long *sp, unsigned long s)
>  {
>  	unsigned long cur_s = READ_ONCE(*sp);
>  
> -	return ULONG_CMP_GE(cur_s, s) || ULONG_CMP_LT(cur_s, s - (3 * RCU_SEQ_STATE_MASK + 1));
> +	return ULONG_CMP_GE(cur_s, s) || ULONG_CMP_LT(cur_s, s - (2 * RCU_SEQ_GP));
>  }
>  
>  /*
> -- 
> 2.43.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ