rcu.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Lai Jiangshan <laijs@linux.alibaba.com>
Cc: linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	rcu@vger.kernel.org
Subject: Re: [PATCH 08/11] rcu: don't use negative ->rcu_read_lock_nesting
Date: Fri, 1 Nov 2019 05:33:23 -0700	[thread overview]
Message-ID: <20191101123323.GC17910@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20191031100806.1326-9-laijs@linux.alibaba.com>

On Thu, Oct 31, 2019 at 10:08:03AM +0000, Lai Jiangshan wrote:
> Negative ->rcu_read_lock_nesting was introduced to prevent
> scheduler deadlock which was just prevented by deferred qs.
> So negative ->rcu_read_lock_nesting is useless now and
> rcu_read_unlock() can be simplified.
> 
> And negative ->rcu_read_lock_nesting is bug-prone,
> it is good to kill it.
> 
> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
> ---
>  kernel/rcu/tree_exp.h    | 30 ++----------------------------
>  kernel/rcu/tree_plugin.h | 21 +++++----------------
>  2 files changed, 7 insertions(+), 44 deletions(-)
> 
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index c0d06bce35ea..9dcbd2734620 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -621,11 +621,11 @@ static void rcu_exp_handler(void *unused)
>  	 * report the quiescent state, otherwise defer.
>  	 */
>  	if (!t->rcu_read_lock_nesting) {
> +		rdp->exp_deferred_qs = true;
>  		if (!(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK)) ||
>  		    rcu_dynticks_curr_cpu_in_eqs()) {
> -			rcu_report_exp_rdp(rdp);
> +			rcu_preempt_deferred_qs(t);
>  		} else {
> -			rdp->exp_deferred_qs = true;
>  			set_tsk_need_resched(t);
>  			set_preempt_need_resched();
>  		}
> @@ -646,32 +646,6 @@ static void rcu_exp_handler(void *unused)
>  		WRITE_ONCE(t->rcu_read_unlock_special.b.exp_hint, true);
>  		return;
>  	}
> -
> -	/*
> -	 * The final and least likely case is where the interrupted
> -	 * code was just about to or just finished exiting the RCU-preempt
> -	 * read-side critical section, and no, we can't tell which.
> -	 * So either way, set ->deferred_qs to flag later code that
> -	 * a quiescent state is required.
> -	 *
> -	 * If the CPU is fully enabled (or if some buggy RCU-preempt
> -	 * read-side critical section is being used from idle), just
> -	 * invoke rcu_preempt_deferred_qs() to immediately report the
> -	 * quiescent state.  We cannot use rcu_read_unlock_special()
> -	 * because we are in an interrupt handler, which will cause that
> -	 * function to take an early exit without doing anything.
> -	 *
> -	 * Otherwise, force a context switch after the CPU enables everything.
> -	 */
> -	rdp->exp_deferred_qs = true;
> -	if (rcu_preempt_need_deferred_qs(t) &&
> -	    (!(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK)) ||
> -	    WARN_ON_ONCE(rcu_dynticks_curr_cpu_in_eqs()))) {
> -		rcu_preempt_deferred_qs(t);
> -	} else {
> -		set_tsk_need_resched(t);
> -		set_preempt_need_resched();
> -	}
>  }
>  
>  /* PREEMPTION=y, so no PREEMPTION=n expedited grace period to clean up after. */
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index dbded2b8c792..c62631c79463 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -344,8 +344,6 @@ static int rcu_preempt_blocked_readers_cgp(struct rcu_node *rnp)
>  }
>  
>  /* Bias and limit values for ->rcu_read_lock_nesting. */
> -#define RCU_NEST_BIAS INT_MAX
> -#define RCU_NEST_NMAX (-INT_MAX / 2)
>  #define RCU_NEST_PMAX (INT_MAX / 2)
>  
>  /*
> @@ -373,21 +371,15 @@ void __rcu_read_unlock(void)
>  {
>  	struct task_struct *t = current;
>  
> -	if (t->rcu_read_lock_nesting != 1) {
> -		--t->rcu_read_lock_nesting;
> -	} else {
> +	if (--t->rcu_read_lock_nesting == 0) {
>  		barrier();  /* critical section before exit code. */
> -		t->rcu_read_lock_nesting = -RCU_NEST_BIAS;
> -		barrier();  /* assign before ->rcu_read_unlock_special load */

But if we take an interrupt here, and the interrupt handler contains
an RCU read-side critical section, don't we end up in the same hole
that resulted in this article when the corresponding rcu_read_unlock()
executes?  https://lwn.net/Articles/453002/

							Thanx, Paul

>  		if (unlikely(READ_ONCE(t->rcu_read_unlock_special.s)))
>  			rcu_read_unlock_special(t);
> -		barrier();  /* ->rcu_read_unlock_special load before assign */
> -		t->rcu_read_lock_nesting = 0;
>  	}
>  	if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
>  		int rrln = t->rcu_read_lock_nesting;
>  
> -		WARN_ON_ONCE(rrln < 0 && rrln > RCU_NEST_NMAX);
> +		WARN_ON_ONCE(rrln < 0);
>  	}
>  }
>  EXPORT_SYMBOL_GPL(__rcu_read_unlock);
> @@ -535,12 +527,9 @@ rcu_preempt_deferred_qs_irqrestore(struct task_struct *t, unsigned long flags)
>   */
>  static bool rcu_preempt_need_deferred_qs(struct task_struct *t)
>  {
> -	return (__this_cpu_read(rcu_data.exp_deferred_qs) &&
> -		(!t->rcu_read_lock_nesting ||
> -		 t->rcu_read_lock_nesting == -RCU_NEST_BIAS))
> -		||
> -		(READ_ONCE(t->rcu_read_unlock_special.s) &&
> -		 t->rcu_read_lock_nesting <= 0);
> +	return (__this_cpu_read(rcu_data.exp_deferred_qs) ||
> +		READ_ONCE(t->rcu_read_unlock_special.s)) &&
> +	       !t->rcu_read_lock_nesting;
>  }
>  
>  /*
> -- 
> 2.20.1
> 

  reply	other threads:[~2019-11-01 12:33 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 10:07 [PATCH 00/11] rcu: introduce percpu rcu_preempt_depth Lai Jiangshan
2019-10-31 10:07 ` [PATCH 01/11] rcu: avoid leaking exp_deferred_qs into next GP Lai Jiangshan
2019-10-31 13:43   ` Paul E. McKenney
2019-10-31 18:19     ` Lai Jiangshan
2019-10-31 19:00       ` Paul E. McKenney
2019-10-31 10:07 ` [PATCH 02/11] rcu: fix bug when rcu_exp_handler() in nested interrupt Lai Jiangshan
2019-10-31 13:47   ` Paul E. McKenney
2019-10-31 14:20     ` Lai Jiangshan
2019-10-31 14:31     ` Paul E. McKenney
2019-10-31 15:14       ` Lai Jiangshan
2019-10-31 18:52         ` Paul E. McKenney
2019-11-01  0:19           ` Boqun Feng
2019-11-01  2:29             ` Lai Jiangshan
2019-10-31 10:07 ` [PATCH 03/11] rcu: clean up rcu_preempt_deferred_qs_irqrestore() Lai Jiangshan
2019-10-31 13:52   ` Paul E. McKenney
2019-10-31 15:25     ` Lai Jiangshan
2019-10-31 18:57       ` Paul E. McKenney
2019-10-31 19:02         ` Paul E. McKenney
2019-10-31 10:07 ` [PATCH 04/11] rcu: cleanup rcu_preempt_deferred_qs() Lai Jiangshan
2019-10-31 14:10   ` Paul E. McKenney
2019-10-31 14:35     ` Lai Jiangshan
2019-10-31 15:07       ` Paul E. McKenney
2019-10-31 18:33         ` Lai Jiangshan
2019-10-31 22:45           ` Paul E. McKenney
2019-10-31 10:08 ` [PATCH 05/11] rcu: clean all rcu_read_unlock_special after report qs Lai Jiangshan
2019-11-01 11:54   ` Paul E. McKenney
2019-10-31 10:08 ` [PATCH 06/11] rcu: clear t->rcu_read_unlock_special in one go Lai Jiangshan
2019-11-01 12:10   ` Paul E. McKenney
2019-11-01 16:58     ` Paul E. McKenney
2019-10-31 10:08 ` [PATCH 07/11] rcu: set special.b.deferred_qs before wake_up() Lai Jiangshan
2019-10-31 10:08 ` [PATCH 08/11] rcu: don't use negative ->rcu_read_lock_nesting Lai Jiangshan
2019-11-01 12:33   ` Paul E. McKenney [this message]
2019-11-16 13:04     ` Lai Jiangshan
2019-11-17 21:53       ` Paul E. McKenney
2019-11-18  1:54         ` Lai Jiangshan
2019-11-18 14:57           ` Paul E. McKenney
2019-10-31 10:08 ` [PATCH 09/11] rcu: wrap usages of rcu_read_lock_nesting Lai Jiangshan
2019-10-31 10:08 ` [PATCH 10/11] rcu: clear the special.b.need_qs in rcu_note_context_switch() Lai Jiangshan
2019-10-31 10:08 ` [PATCH 11/11] x86,rcu: use percpu rcu_preempt_depth Lai Jiangshan
2019-11-01 12:58   ` Paul E. McKenney
2019-11-01 13:13     ` Peter Zijlstra
2019-11-01 14:30       ` Paul E. McKenney
2019-11-01 15:32         ` Lai Jiangshan
2019-11-01 16:21           ` Paul E. McKenney
2019-11-01 15:47       ` Lai Jiangshan

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=20191101123323.GC17910@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=laijs@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).