linux-kernel - Re: [PATCH 2/4] rcu: No need to reset the poll request flag before completion

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: <20220330112752.GA1245830@lothringen>
Date:   Wed, 30 Mar 2022 13:27:52 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     "Paul E . McKenney" <paulmck@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Uladzislau Rezki <uladzislau.rezki@...y.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH 2/4] rcu: No need to reset the poll request flag before
 completion

On Wed, Mar 16, 2022 at 03:42:53PM +0100, Frederic Weisbecker wrote:
> The flag allowing to requeue the polling work is reset before the
> polling even starts. However there is no point in having two competing
> polling on the same grace period. Just reset the flag once we have
> completed the grace period only.
> 
> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> Cc: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> Cc: Boqun Feng <boqun.feng@...il.com>
> Cc: Uladzislau Rezki <uladzislau.rezki@...y.com>
> Cc: Joel Fernandes <joel@...lfernandes.org>
> ---
>  kernel/rcu/tree_exp.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index b6fd857f34ba..763ec35546ed 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -911,7 +911,6 @@ static void sync_rcu_do_polled_gp(struct work_struct *wp)
>  
>  	raw_spin_lock_irqsave(&rnp->exp_poll_lock, flags);
>  	s = rnp->exp_seq_poll_rq;
> -	rnp->exp_seq_poll_rq |= 0x1;

On a second (or actually twentieth) thought, this patch and all those following
make wrapping issues more likely:

* Before this patch, wrapping occuring *after* the 0x1 is set on the beginning
  of the workqueue is fine. The last vulnerable wrapping scenario is when
  the wrapping happens before we reach the beginning of the workqueue
  execution that sets the 0x1, so the work may happen not to be queued.

* After this patch, wrapping occuring *before* the GP completion in the
  workqueue will be ignored and fail. Still unlikely, but less unlikely than
  before this patch.

So please revert this series. Only the first patch "rcu: Remove needless polling
work requeue for further waiter" still seem to make sense.

Thanks.