rcu.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lai Jiangshan <laijs@linux.alibaba.com>
To: paulmck@kernel.org
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 02/11] rcu: fix bug when rcu_exp_handler() in nested interrupt
Date: Thu, 31 Oct 2019 23:14:23 +0800	[thread overview]
Message-ID: <6b621228-4cab-6e2c-9912-cddc56ad6775@linux.alibaba.com> (raw)
In-Reply-To: <20191031143119.GA15954@paulmck-ThinkPad-P72>



On 2019/10/31 10:31 下午, Paul E. McKenney wrote:
> On Thu, Oct 31, 2019 at 06:47:31AM -0700, Paul E. McKenney wrote:
>> On Thu, Oct 31, 2019 at 10:07:57AM +0000, Lai Jiangshan wrote:
>>> These is a possible bug (although which I can't triger yet)
>>> since 2015 8203d6d0ee78
>>> (rcu: Use single-stage IPI algorithm for RCU expedited grace period)
>>>
>>>   rcu_read_unlock()
>>>    ->rcu_read_lock_nesting = -RCU_NEST_BIAS;
>>>    interrupt(); // before or after rcu_read_unlock_special()
>>>     rcu_read_lock()
>>>      fetch some rcu protected pointers
>>>      // exp GP starts in other cpu.
>>>      some works
>>>      NESTED interrupt for rcu_exp_handler();
> 
> Also, which platforms support nested interrupts?  Last I knew, this was
> prohibited.
> 
>>>        report exp qs! BUG!
>>
>> Why would a quiescent state for the expedited grace period be reported
>> here?  This CPU is still in an RCU read-side critical section, isn't it?
> 
> And I now see what you were getting at here.  Yes, the current code
> assumes that interrupt-disabled regions, like hardware interrupt
> handlers, cannot be interrupted.  But if interrupt-disabled regions such
> as hardware interrupt handlers can be interrupted (as opposed to being
> NMIed), wouldn't that break a whole lot of stuff all over the place in
> the kernel?  So that sounds like an arch bug to me.
> 

I don't know when I started always assuming hardware interrupt
handler can be nested by (other) interrupt. I can't find any
documents say Linux don't allow nested interrupt handler.
Google search suggests the opposite.

grep -rIni nested Documentation/memory-barriers.txt Documentation/x86/
It still have some words about nested interrupt handler.

The whole patchset doesn't depend on this patch, and actually
it is reverted later in the patchset. Dropping this patch
can be an option for next round.

thanks
Lai

> 							Thanx, Paul
> 
>>>      // exp GP completes and pointers are freed in other cpu
>>>      some works with the pointers. BUG
>>>     rcu_read_unlock();
>>>    ->rcu_read_lock_nesting = 0;
>>>
>>> Although rcu_sched_clock_irq() can be in nested interrupt,
>>> there is no such similar bug since special.b.need_qs
>>> can only be set when ->rcu_read_lock_nesting > 0
>>>
>>> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
>>> ---
>>>   kernel/rcu/tree_exp.h    | 5 +++--
>>>   kernel/rcu/tree_plugin.h | 9 ++++++---
>>>   2 files changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
>>> index 6dec21909b30..c0d06bce35ea 100644
>>> --- a/kernel/rcu/tree_exp.h
>>> +++ b/kernel/rcu/tree_exp.h
>>> @@ -664,8 +664,9 @@ static void rcu_exp_handler(void *unused)
>>>   	 * Otherwise, force a context switch after the CPU enables everything.
>>>   	 */
>>>   	rdp->exp_deferred_qs = true;
>>> -	if (!(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK)) ||
>>> -	    WARN_ON_ONCE(rcu_dynticks_curr_cpu_in_eqs())) {
>>> +	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);
>>> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>>> index d4c482490589..59ef10da1e39 100644
>>> --- a/kernel/rcu/tree_plugin.h
>>> +++ b/kernel/rcu/tree_plugin.h
>>> @@ -549,9 +549,12 @@ 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) ||
>>> -		READ_ONCE(t->rcu_read_unlock_special.s)) &&
>>> -	       t->rcu_read_lock_nesting <= 0;
>>> +	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);
>>>   }
>>>   
>>>   /*
>>> -- 
>>> 2.20.1
>>>

  reply	other threads:[~2019-10-31 15:14 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 [this message]
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
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=6b621228-4cab-6e2c-9912-cddc56ad6775@linux.alibaba.com \
    --to=laijs@linux.alibaba.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=paulmck@kernel.org \
    --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).