From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: "\"“tiejun.chen”\"" <tiejun.chen@windriver.com>,
bigeasy@linutronix.de, tglx@linutronix.de
Cc: <linux-rt-users@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/1] rcutree/rcu_bh_qs: disable irq while calling rcu_preempt_qs()
Date: Fri, 6 Dec 2013 12:13:04 -0500 [thread overview]
Message-ID: <52A205A0.2030707@windriver.com> (raw)
In-Reply-To: <52A12F04.8040402@windriver.com>
On 13-12-05 08:57 PM, "“tiejun.chen”" wrote:
> On 12/05/2013 11:26 PM, Paul Gortmaker wrote:
>> On 13-12-05 04:52 AM, Tiejun Chen wrote:
>>> Any callers should make sure irq is disabled before calling rcu_preempt_qs().
>>
>> Can we stick to the standard rule of three here for commit logs please?
>>
>> 1) Describe what the end user symptoms look like (crash, bug, splat)
>>
>> 2) Describe the underlying problem, i.e. why it happens.
>>
>> 3) Describe why the fix proposed is the _right_ fix, in cases
>> where it isn't obvious what the impact of the change will be etc.
>>
>> Maybe it seems obvious to you what the 1,2,3 are -- but it won't
>> be obvious to everyone, and I hate having to guess.
>
> This is required according to that comments from rcu_preempt_qs():
>
> rcutree_plugin.h:
>
> /*
> * Record a preemptible-RCU quiescent state for the specified CPU. Note
> * that this just means that the task currently running on the CPU is
> * not in a quiescent state. There might be any number of tasks blocked
> * while in an RCU read-side critical section.
> *
> * Unlike the other rcu_*_qs() functions, callers to this function
> * must disable irqs in order to protect the assignment to
> * ->rcu_read_unlock_special.
> */
> static void rcu_preempt_qs(int cpu)
> ...
>
> But in RT case, rcu_bh_qs() as the wrapper of rcu_preempt_qs() is called in some
> scenarios where irq is enabled, like this path,
>
> do_single_softirq()
> |
> + local_irq_enable();
> + handle_softirq()
> | |
> | + rcu_bh_qs()
> | |
> | + rcu_preempt_qs()
> |
> + local_irq_disable()
OK, that is a good start, but it largely only covers #2 in my list.
We still don't know what the symptoms are (#1), or whether the added
irqsave will be problematic for other rcu_bh_qs callers (i.e. #3).
It would be really nice to have that additional information.
Thanks,
Paul.
--
>
> So I think we'd better disable irq directly inside of rcu_bh_qs() to fix this
> problem, and especially this is also kind for the potential rcu_bh_qs() usage
> elsewhere in the future.
>
> If you guy like this explanation, I'm happy for posting this as a long log in
> this patch head description.
>
> Thanks,
>
> Tiejun
>
>>
>> Thanks,
>> Paul.
>> --
>>
>>>
>>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>>> ---
>>> kernel/rcutree.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
>>> index 7ec834d..6f6d133 100644
>>> --- a/kernel/rcutree.c
>>> +++ b/kernel/rcutree.c
>>> @@ -186,7 +186,12 @@ static void rcu_preempt_qs(int cpu);
>>>
>>> void rcu_bh_qs(int cpu)
>>> {
>>> + unsigned long flags;
>>> +
>>> + /* Callers to this function, rcu_preempt_qs(), must disable irqs. */
>>> + local_irq_save(flags);
>>> rcu_preempt_qs(cpu);
>>> + local_irq_restore(flags);
>>> }
>>> #else
>>> void rcu_bh_qs(int cpu)
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-12-06 17:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 9:52 [PATCH 1/1] rcutree/rcu_bh_qs: disable irq while calling rcu_preempt_qs() Tiejun Chen
2013-12-05 15:26 ` Paul Gortmaker
2013-12-06 1:57 ` "“tiejun.chen”"
2013-12-06 17:13 ` Paul Gortmaker [this message]
2013-12-15 12:01 ` Sebastian Andrzej Siewior
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=52A205A0.2030707@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=tiejun.chen@windriver.com \
/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.