From: "Paul E. McKenney" <paulmck@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
mingo@kernel.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, joel@joelfernandes.org
Subject: Re: [PATCH] sched/fair: Fix call walk_tg_tree_from() without hold rcu_lock
Date: Tue, 21 Apr 2020 10:39:19 -0700 [thread overview]
Message-ID: <20200421173919.GQ17661@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20200421162452.GV20730@hirez.programming.kicks-ass.net>
On Tue, Apr 21, 2020 at 06:24:52PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 21, 2020 at 08:43:12AM -0700, Paul E. McKenney wrote:
> > On Tue, Apr 21, 2020 at 03:52:58PM +0200, Peter Zijlstra wrote:
> > > On Mon, Apr 06, 2020 at 08:10:08PM +0800, Muchun Song wrote:
> > > > The walk_tg_tree_from() caller must hold rcu_lock,
> > >
> > > Not quite; with the RCU unification done 'recently' having preemption
> > > disabled is sufficient. AFAICT preemption is disabled.
> > >
> > > In fact; and I mentioned this to someone the other day, perhaps Joel; we
> > > can go and delete a whole bunch of rcu_read_lock() from the scheduler --
> > > basically undo all the work we did after RCU was split many years ago.
> >
> > "If only I knew then what I know now..."
> >
> > Then again, I suspect that we all have ample opportunity to use that
> > particular old phrase. ;-)
>
> Quite so; I'm just fearing that rcu-lockdep annotation stuff. IIRC that
> doesn't (nor can it, in general) consider the implicit preempt-disable
> from locks and such for !PREEMPT builds.
Heh! Now that might be me using that phrase again some time in the
future rather than you using it. ;-)
But what exactly are you looking for? After all, in !PREEMPT builds,
preemption is always disabled. It should not be too hard to make
something that looked at the state provided by DEBUG_ATOMIC_SLEEP when
selected, for example. Alternatively, there is always the option
of doing the testing in CONFIG_PREEMPT=y kernels.
But again, what exactly are you looking for?
Thanx, Paul
prev parent reply other threads:[~2020-04-21 17:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 12:10 [PATCH] sched/fair: Fix call walk_tg_tree_from() without hold rcu_lock Muchun Song
2020-04-06 18:17 ` bsegall
2020-04-13 15:00 ` [External] " 宋牧春
2020-04-21 13:52 ` Peter Zijlstra
2020-04-21 15:43 ` Paul E. McKenney
2020-04-21 16:24 ` Peter Zijlstra
2020-04-21 17:39 ` Paul E. McKenney [this message]
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=20200421173919.GQ17661@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joel@joelfernandes.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=songmuchun@bytedance.com \
--cc=vincent.guittot@linaro.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).