All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: boqun.feng@gmail.com, rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: One potential issue with concurrent execution of RCU callbacks...
Date: Tue, 8 Dec 2020 16:54:57 +0100	[thread overview]
Message-ID: <20201208155457.GA3916@lothringen> (raw)
In-Reply-To: <20201208145810.GA4875@paulmck-ThinkPad-P72>

On Tue, Dec 08, 2020 at 06:58:10AM -0800, Paul E. McKenney wrote:
> Hello, Frederic,
> 
> Boqun just asked if RCU callbacks ran in BH-disabled context to avoid
> concurrent execution of the same callback.  Of course, this raises the
> question of whether a self-posting callback can have two instances of
> itself running concurrently while a CPU is in the process of transitioning
> between softirq and rcuo invocation of callbacks.
> 
> I believe that the answer is "no" because BH-disabled context is
> an implicit RCU read-side critical section.  Therefore, the initial
> invocation of the RCU callback must complete in order for a new grace
> period to complete, and a new grace period must complete before the
> second invocation of that same callback to start.
> 
> Does that make sense, or am I missing something?

Sounds like a good explanation. But then why are we actually calling
the entire rcu_do_batch() under BH-disabled context? Was it to quieten
lockdep against rcu_callback_map ?

Wouldn't rcu_read_lock() around callbacks invocation be enough? Or is
there another reason for the BH-disabled context that I'm missing?

Untested below:

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bd04b09b84b3..207eff8a4e1a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2468,6 +2468,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
 
 		debug_rcu_head_unqueue(rhp);
 
+		rcu_read_lock();
 		rcu_lock_acquire(&rcu_callback_map);
 		trace_rcu_invoke_callback(rcu_state.name, rhp);
 
@@ -2476,6 +2477,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
 		f(rhp);
 
 		rcu_lock_release(&rcu_callback_map);
+		rcu_read_unlock();
 
 		/*
 		 * Stop only if limit reached and CPU has something to do.
@@ -2494,11 +2496,9 @@ static void rcu_do_batch(struct rcu_data *rdp)
 		}
 		if (offloaded) {
 			WARN_ON_ONCE(in_serving_softirq());
-			local_bh_enable();
 			lockdep_assert_irqs_enabled();
 			cond_resched_tasks_rcu_qs();
 			lockdep_assert_irqs_enabled();
-			local_bh_disable();
 		}
 	}
 
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index fd8a52e9a887..2a3d3c59d650 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2095,9 +2095,7 @@ static void nocb_cb_wait(struct rcu_data *rdp)
 	local_irq_save(flags);
 	rcu_momentary_dyntick_idle();
 	local_irq_restore(flags);
-	local_bh_disable();
 	rcu_do_batch(rdp);
-	local_bh_enable();
 	lockdep_assert_irqs_enabled();
 	rcu_nocb_lock_irqsave(rdp, flags);
 	if (rcu_segcblist_nextgp(&rdp->cblist, &cur_gp_seq) &&


  reply	other threads:[~2020-12-08 15:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 14:58 One potential issue with concurrent execution of RCU callbacks Paul E. McKenney
2020-12-08 15:54 ` Frederic Weisbecker [this message]
2020-12-08 17:19   ` Paul E. McKenney
2020-12-08 17:52     ` Frederic Weisbecker
2020-12-08 18:24       ` Paul E. McKenney
2020-12-08 22:04         ` Frederic Weisbecker
2020-12-09  0:03           ` Paul E. McKenney
2020-12-09  2:14           ` Boqun Feng
2020-12-10  0:50             ` 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=20201208155457.GA3916@lothringen \
    --to=frederic@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.