From: Joel Fernandes <joel@joelfernandes.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
urezki@gmail.com, neeraj.iitr10@gmail.com, paulmck@kernel.org,
rostedt@goodmis.org
Subject: Re: [RFC] rcu/nocb: Fix possible bugs in rcu_barrier()
Date: Mon, 19 Sep 2022 17:00:39 -0400 [thread overview]
Message-ID: <c244a304-1689-274e-2bba-2ee1ce5f1bff@joelfernandes.org> (raw)
In-Reply-To: <20220919093411.GB56640@lothringen>
On 9/19/2022 5:34 AM, Frederic Weisbecker wrote:
> On Sun, Sep 18, 2022 at 10:12:31PM +0000, Joel Fernandes (Google) wrote:
>> When going through the lazy-rcu work, I noticed that
>> rcu_barrier_entrain() does not really wake up the rcuog GP thread in any
>> path after entraining. This means it is possible the GP thread is not
>> awakened soon (say there were no CBs in the cblist after entraining
>> time).
>
> Right.
>
>>
>> Further, nothing appears to be calling the rcu_barrier callback
>> directly in the case the ->cblist was empty which means if the IPI gets
>> delayed enough to make the ->cblist empty and it turns out to be the last
>> CPU holding, then nothing calls completes rcu_state.barrier_completion.
>
> No need for that, if the cblist is empty there is no need for a callback
> to enqueue.
>
Thanks! I was worried about the race where an smp_call_function_single() takes a
long time to IPI. But I missed that the smp_call_function_single() in
rcu_barrier() is in a synchronous wait. I wrongly thought thought that the
waiting was facilitated by barrier_completion which has a whole different purpose.
- Joel
next prev parent reply other threads:[~2022-09-19 21:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 22:12 [RFC] rcu/nocb: Fix possible bugs in rcu_barrier() Joel Fernandes (Google)
2022-09-18 22:17 ` Joel Fernandes
2022-09-19 9:34 ` Frederic Weisbecker
2022-09-19 21:00 ` Joel Fernandes [this message]
2022-09-21 7:49 ` [rcu/nocb] 79b696b5c3: WARNING:at_kernel/rcu/tree_nocb.h:#rcu_barrier_entrain kernel test robot
2022-09-21 7:49 ` kernel test robot
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=c244a304-1689-274e-2bba-2ee1ce5f1bff@joelfernandes.org \
--to=joel@joelfernandes.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.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.