linux-kernel - Re: [RFC PATCH 13/37] mm: implement speculative handling in __handle_mm

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:   Mon, 3 May 2021 09:32:49 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Michel Lespinasse <michel@...pinasse.org>
Cc:     Andy Lutomirski <luto@...nel.org>, Linux-MM <linux-mm@...ck.org>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michal Hocko <mhocko@...e.com>,
        Matthew Wilcox <willy@...radead.org>,
        Rik van Riel <riel@...riel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Rom Lemarchand <romlem@...gle.com>,
        Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 13/37] mm: implement speculative handling in
 __handle_mm_fault().

On Sun, May 02, 2021 at 09:34:30PM -0700, Michel Lespinasse wrote:
> On Sun, May 02, 2021 at 08:40:49PM -0700, Paul E. McKenney wrote:
> > @@ -634,6 +644,12 @@ do {									      \
> >   * sections, invocation of the corresponding RCU callback is deferred
> >   * until after the all the other CPUs exit their critical sections.
> >   *
> > + * In recent kernels, synchronize_rcu() and call_rcu() also wait for
> > + * regions of code with preemption disabled, including regions of code
> > + * with interrupts or softirqs disabled.  If your kernel is old enough
> > + * for synchronize_sched() to be defined, only code enclosed within
> > + * rcu_read_lock() and rcu_read_unlock() are guaranteed to be waited for.
> > + *
> >   * Note, however, that RCU callbacks are permitted to run concurrently
> >   * with new RCU read-side critical sections.  One way that this can happen
> >   * is via the following sequence of events: (1) CPU 0 enters an RCU
> 
> You still have "old enough" / "recent kernels" here. But maybe it's OK
> given that you added relevant version numbers elsewhere.
> 
> Everything else looks great to me.

Good point!  Like this?

							Thanx, Paul

------------------------------------------------------------------------

commit fd8393a2a8a5ffd25d0766abb262137c36bda9f3
Author: Paul E. McKenney <paulmck@...nel.org>
Date:   Mon May 3 09:32:14 2021 -0700

    fixup! rcu: Improve comments describing RCU read-side critical sections
    
    Signed-off-by: Paul E. McKenney <paulmck@...nel.org>

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 901ab6fa252b..323954363389 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -644,11 +644,11 @@ do {									      \
  * sections, invocation of the corresponding RCU callback is deferred
  * until after the all the other CPUs exit their critical sections.
  *
- * In recent kernels, synchronize_rcu() and call_rcu() also wait for
- * regions of code with preemption disabled, including regions of code
- * with interrupts or softirqs disabled.  If your kernel is old enough
- * for synchronize_sched() to be defined, only code enclosed within
- * rcu_read_lock() and rcu_read_unlock() are guaranteed to be waited for.
+ * In v5.0 and later kernels, synchronize_rcu() and call_rcu() also
+ * wait for regions of code with preemption disabled, including regions of
+ * code with interrupts or softirqs disabled.  In pre-v5.0 kernels, which
+ * define synchronize_sched(), only code enclosed within rcu_read_lock()
+ * and rcu_read_unlock() are guaranteed to be waited for.
  *
  * Note, however, that RCU callbacks are permitted to run concurrently
  * with new RCU read-side critical sections.  One way that this can happen