mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	jiangshanlai@gmail.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
	rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
	fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org,
	"Paul E. McKenney" <paulmck@linux.ibm.com>
Subject: [PATCH tip/core/rcu 04/18] rcu: Make exit_rcu() handle non-preempted RCU readers
Date: Tue, 26 Mar 2019 16:13:00 -0700	[thread overview]
Message-ID: <20190326231314.19518-4-paulmck@linux.ibm.com> (raw)
In-Reply-To: <20190326231253.GA18343@linux.ibm.com>

The purpose of exit_rcu() is to handle cases where buggy code causes a
task to exit within an RCU read-side critical section.  It currently
does that in the case where said RCU read-side critical section was
preempted at least once, but fails to handle cases where preemption did
not occur.  This case needs to be handled because otherwise the final
context switch away from the exiting task will incorrectly behave as if
task exit were instead a preemption of an RCU read-side critical section,
and will therefore queue the exiting task.  The exiting task will have
exited, and thus won't ever execute rcu_read_unlock(), which means that
it will remain queued forever, blocking all subsequent grace periods,
and eventually resulting in OOM.

Although this is arguably better than letting grace periods proceed
and having a later rcu_read_unlock() access the now-freed task
structure that once belonged to the exiting tasks, it would obviously
be better to correctly handle this case.  This commit therefore sets
->rcu_read_lock_nesting to 1 in that case, so that the subsequence call
to __rcu_read_unlock() causes the exiting task to exit its dangling RCU
read-side critical section.

Note that deferred quiescent states need not be considered.  The reason
is that removing the task from the ->blkd_tasks[] list in the call to
rcu_preempt_deferred_qs() handles the per-task component of any deferred
quiescent state, and all other components of any deferred quiescent state
are associated with the CPU, which isn't going anywhere until some later
CPU-hotplug operation, which will report any remaining deferred quiescent
states from within the rcu_report_dead() function.

Note also that negative values of ->rcu_read_lock_nesting need not be
considered.  First, these won't show up in exit_rcu() unless there is
a serious bug in RCU, and second, setting ->rcu_read_lock_nesting sets
the state so that the RCU read-side critical section will be exited
normally.

Again, this code has no effect unless there has been some prior bug
that prevents a task from leaving an RCU read-side critical section
before exiting.  Furthermore, there have been no reports of the bug
fixed by this commit appearing in production.  This commit is therefore
absolutely -not- recommended for backporting to -stable.

Reported-by: ABHISHEK DUBEY <dabhishek@iisc.ac.in>
Reported-by: BHARATH Y MOURYA <bharathm@iisc.ac.in>
Reported-by: Aravinda Prasad <aravinda@iisc.ac.in>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Tested-by: ABHISHEK DUBEY <dabhishek@iisc.ac.in>
---
 kernel/rcu/tree_plugin.h | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 97dba50f6fb2..d408661d5fb7 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -804,19 +804,25 @@ static void rcu_flavor_sched_clock_irq(int user)
 
 /*
  * Check for a task exiting while in a preemptible-RCU read-side
- * critical section, clean up if so.  No need to issue warnings,
- * as debug_check_no_locks_held() already does this if lockdep
- * is enabled.
+ * critical section, clean up if so.  No need to issue warnings, as
+ * debug_check_no_locks_held() already does this if lockdep is enabled.
+ * Besides, if this function does anything other than just immediately
+ * return, there was a bug of some sort.  Spewing warnings from this
+ * function is like as not to simply obscure important prior warnings.
  */
 void exit_rcu(void)
 {
 	struct task_struct *t = current;
 
-	if (likely(list_empty(&current->rcu_node_entry)))
+	if (unlikely(!list_empty(&current->rcu_node_entry))) {
+		t->rcu_read_lock_nesting = 1;
+		barrier();
+		t->rcu_read_unlock_special.b.blocked = true;
+	} else if (unlikely(t->rcu_read_lock_nesting)) {
+		t->rcu_read_lock_nesting = 1;
+	} else {
 		return;
-	t->rcu_read_lock_nesting = 1;
-	barrier();
-	t->rcu_read_unlock_special.b.blocked = true;
+	}
 	__rcu_read_unlock();
 	rcu_preempt_deferred_qs(current);
 }
-- 
2.17.1


  parent reply	other threads:[~2019-03-26 23:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-26 23:12 [PATCH tip/core/rcu 0/18] Miscellaneous fixes for v5.2 Paul E. McKenney
2019-03-26 23:12 ` [PATCH tip/core/rcu 01/18] rcu: Unconditionally expedite during suspend/hibernate Paul E. McKenney
2019-03-26 23:12 ` [PATCH tip/core/rcu 02/18] rcu: Avoid unnecessary softirq when system is idle Paul E. McKenney
2019-03-26 23:12 ` [PATCH tip/core/rcu 03/18] rcu: rcu_qs -- Use raise_softirq_irqoff to not save irqs twice Paul E. McKenney
2019-03-26 23:13 ` Paul E. McKenney [this message]
2019-03-26 23:13 ` [PATCH tip/core/rcu 05/18] rcu: Set rcutree.kthread_prio sysfs access to read-only Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 06/18] MAINTAINERS: RCU now has its own email list Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 07/18] MAINTAINERS: Add -rcu branch name ("dev") Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 08/18] rcu: Move common code out of if-else block Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 09/18] rcu: Allow rcu_nocbs= to specify all CPUs Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 10/18] rcu: Report error for bad rcu_nocbs= parameter values Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 11/18] rcu: Fix self-wakeups for grace-period kthread Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 12/18] rcu: Default jiffies_to_sched_qs to jiffies_till_sched_qs Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 13/18] rcu: Do a single rhp->func read in rcu_head_after_call_rcu() Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 14/18] rcu: Update jiffies_to_sched_qs and adjust_jiffies_till_sched_qs() comments Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 15/18] rcu: Fix force_qs_rnp() header comment Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 16/18] rcu: Eliminate redundant NULL-pointer check Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 17/18] rcu: Fix typo in tree_exp.h comment Paul E. McKenney
2019-03-26 23:13 ` [PATCH tip/core/rcu 18/18] rcu: Correct READ_ONCE()/WRITE_ONCE() for ->rcu_read_unlock_special Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190326231314.19518-4-paulmck@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®