linux-kernel - Re: [PATCH] rcu: Update rcu_preempt_deferred

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] [day] [month] [year] [list]

Message-ID: <20220627220207.GR1790663@paulmck-ThinkPad-P17-Gen-1>
Date:   Mon, 27 Jun 2022 15:02:07 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Zqiang <qiang1.zhang@...el.com>
Cc:     frederic@...nel.org, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: Update rcu_preempt_deferred_qs() comments for no
 preemptible RCU

On Mon, Jun 20, 2022 at 02:42:24PM +0800, Zqiang wrote:
> For no preemptible RCU, the rcu_preempt_deferred_qs() only report
> expedited QS state of current CPU, since preemption does not occur
> in RCU critical sections, there are no tasks insert to leaf rnp
> blocked-tasks list, that is to say the tasks structure's ->rcu_blocked_node
> and the leaf rnp structure's  ->blkd_tasks are always empty.
> 
> Signed-off-by: Zqiang <qiang1.zhang@...el.com>

Good catch -- that comment is quite misleading.

Is the wordsmithed version shown below OK?

							Thanx, Paul

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

commit 5ddf65777c8d0f60ff9137eef3b23dd4c77e6108
Author: Zqiang <qiang1.zhang@...el.com>
Date:   Mon Jun 20 14:42:24 2022 +0800

    rcu: Update rcu_preempt_deferred_qs() comments for !PREEMPT kernels
    
    In non-premptible kernels, tasks never do context switches within
    RCU read-side critical sections.  Therefore, in such kernels, each
    leaf rcu_node structure's ->blkd_tasks list will always be empty.
    The comment on the non-preemptible version of rcu_preempt_deferred_qs()
    confuses this point, so this commit therefore fixes it.
    
    Signed-off-by: Zqiang <qiang1.zhang@...el.com>
    Signed-off-by: Paul E. McKenney <paulmck@...nel.org>

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 86772c95ed0ae..4152816dd29f6 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -932,10 +932,13 @@ static notrace bool rcu_preempt_need_deferred_qs(struct task_struct *t)
 	return false;
 }
 
-// Except that we do need to respond to a request by an expedited grace
-// period for a quiescent state from this CPU.  Note that requests from
-// tasks are handled when removing the task from the blocked-tasks list
-// below.
+// Except that we do need to respond to a request by an expedited
+// grace period for a quiescent state from this CPU.  Note that in
+// non-preemptible kernels, there can be no context switches within RCU
+// read-side critical sections, which in turn means that the leaf rcu_node
+// structure's blocked-tasks list is always empty.  is therefore no need to
+// actually check it.  Instead, a quiescent state from this CPU suffices,
+// and this function is only called from such a quiescent state.
 notrace void rcu_preempt_deferred_qs(struct task_struct *t)
 {
 	struct rcu_data *rdp = this_cpu_ptr(&rcu_data);