From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Zhouyi Zhou" <zhouzhouyi@gmail.com>
Cc: <mpe@ellerman.id.au>, <christophe.leroy@csgroup.eu>,
<atrajeev@linux.vnet.ibm.com>, <linuxppc-dev@lists.ozlabs.org>,
<linux-kernel@vger.kernel.org>, <lance@osuosl.org>,
<paulmck@kernel.org>, <rcu@vger.kernel.org>
Subject: Re: [PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline
Date: Wed, 28 Sep 2022 12:51:14 +1000 [thread overview]
Message-ID: <CN7OZ6TMLLFS.2HER50Q3SO480@bobo> (raw)
In-Reply-To: <CAABZP2wYcNXkTo=tgX-ARziwgD2rng+-wCZ-qfQ6M30+vmLEug@mail.gmail.com>
On Wed Sep 28, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> Thank Nick for reviewing my patch
>
> On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> > > This is second version of my fix to PPC's "WARNING: suspicious RCU usage",
> > > I improved my fix under Paul E. McKenney's guidance:
> > > Link: https://lore.kernel.org/lkml/20220914021528.15946-1-zhouzhouyi@gmail.com/T/
> > >
> > > During the cpu offlining, the sub functions of xive_teardown_cpu will
> > > call __lock_acquire when CONFIG_LOCKDEP=y. The latter function will
> > > travel RCU protected list, so "WARNING: suspicious RCU usage" will be
> > > triggered.
> > >
> > > Avoid lockdep when we are offline.
> >
> > I don't see how this is safe. If RCU is no longer watching the CPU then
> > the memory it is accessing here could be concurrently freed. I think the
> > warning is valid.
> Agree
> >
> > powerpc's problem is that cpuhp_report_idle_dead() is called before
> > arch_cpu_idle_dead(), so it must not rely on any RCU protection there.
> > I would say xive cleanup just needs to be done earlier. I wonder why it
> > is not done in __cpu_disable or thereabouts, that's where the interrupt
> > controller is supposed to be stopped.
> Yes, I learn flowing events sequence from kgdb debugging
> __cpu_disable -> pseries_cpu_disable -> set_cpu_online(cpu, false) =
> leads to => do_idle: if (cpu_is_offline(cpu) -> arch_cpu_idle_dead
> so xive cleanup should be done in pseries_cpu_disable.
It's a good catch and a reasonable approach to the problem.
> But as a beginner, I afraid that I am incompetent to do above
> sophisticated work without error although I am very like to,
> Could any expert do this for us?
This will be difficult for anybody, it's tricky code. I'm not an
expert at it.
It looks like the interrupt controller disable split has been there
since long before xive. I would try just move them together than see
if that works.
Documentation/core-api/cpu_hotplug.rst says that __cpu_disable should
shut down the interrupt handler. So if there is a complication it
would probably be from powerpc-specific CPU hotplug or interrupt
code.
Thanks,
Nick
next prev parent reply other threads:[~2022-09-28 2:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 1:48 [PATCH linux-next][RFC] powerpc: avoid lockdep when we are offline Zhouyi Zhou
2022-09-27 4:25 ` Nicholas Piggin
2022-09-28 1:48 ` Zhouyi Zhou
2022-09-28 2:51 ` Nicholas Piggin [this message]
2022-09-29 1:48 ` Zhouyi Zhou
2022-10-10 3:49 ` Nicholas Piggin
2022-10-09 20:25 ` Zhouyi Zhou
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=CN7OZ6TMLLFS.2HER50Q3SO480@bobo \
--to=npiggin@gmail.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=lance@osuosl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=zhouzhouyi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox