From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <sumit.garg@linaro.org>
Cc: <acme@kernel.org>, <alexander.shishkin@linux.intel.com>,
<alexandru.elisei@arm.com>, <catalin.marinas@arm.com>,
<jolsa@redhat.com>, <lecopzer.chen@mediatek.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <mark.rutland@arm.com>,
<matthias.bgg@gmail.com>, <mingo@redhat.com>,
<namhyung@kernel.org>, <oliver.sang@intel.com>,
<peterz@infradead.org>, <will@kernel.org>,
<yj.chiang@mediatek.com>
Subject: Re: [PATCH v2] arm64: perf: Fix access percpu variables in preemptible context
Date: Fri, 8 Jan 2021 20:55:27 +0800 [thread overview]
Message-ID: <20210108125527.14175-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <CAFA6WYNepUP=SeHWnDDbxx=ggwPq2jDd5JmrcXD5GoMC5dYH2g@mail.gmail.com>
Hi Sumit,
Thanks for your reply.
> On Mon, 21 Dec 2020 at 21:53, Lecopzer Chen <lecopzer.chen@mediatek.com> wrote:
> >
> > commit 367c820ef08082 ("arm64: Enable perf events based hard lockup detector")
> > reinitilizes lockup detector after arm64 PMU is initialized and open
> > a window for accessing smp_processor_id() in preemptible context.
> > Since hardlockup_detector_perf_init() always called in init stage
> > with a single cpu, but we initialize lockup detector after the init task
> > is migratable.
> >
> > Fix this by utilizing lockup detector reconfiguration which calls
> > softlockup_start_all() on each cpu and calls watatchdog_nmi_enable() later.
> > Because softlockup_start_all() use IPI call function to make sure
> > watatchdog_nmi_enable() will bind on each cpu and fix this issue.
>
> IMO, this just creates unnecessary dependency for hardlockup detector
> init via softlockup detector (see the alternative definition of
> lockup_detector_reconfigure()).
The arm64/Kconfig select HAVE_HARDLOCKUP_DETECTOR_PERF if we have NMI:
select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI
And in lib/Kconfig.debug HARDLOCKUP_DETECTOR select SOFTLOCKUP_DETECTOR automatically.
config HARDLOCKUP_DETECTOR_PERF
bool
select SOFTLOCKUP_DETECTOR
So we don't need to explicitly select softlockup.
And actually this patch is not a perfect solution like you said
(hardlockup depends on softlockup),
but the key point is that lockup_detector_init() seems only design for
using in early init stage and not for calling in later deffered initial process.
>
> >
> > BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
>
> How about just the below fix in order to make CONFIG_DEBUG_PREEMPT happy?
>
> diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
> index 247bf0b1582c..db06ee28f48e 100644
> --- a/kernel/watchdog_hld.c
> +++ b/kernel/watchdog_hld.c
> @@ -165,7 +165,7 @@ static void watchdog_overflow_callback(struct
> perf_event *event,
>
> static int hardlockup_detector_event_create(void)
> {
> - unsigned int cpu = smp_processor_id();
> + unsigned int cpu = raw_smp_processor_id();
> struct perf_event_attr *wd_attr;
> struct perf_event *evt;
>
This won't solve the issue that arm64 called this in preemptible context,
I was trying to find a balance that can pass CONFIG_DEBUG_PREEMPT and
calling lockup_detector_init() in non-preemptive context.
watchdog_nmi_probe() and the following hardlockup_detector_event_create use
this_cpu_read/write, thus the topic of solution is better to be
'how to call lockup_detector_init() in preemptive context'
we can't just use preempt_disable/enable between lockup_detector_init() because
the call tree inside it will use kamlloc() with GFP_KERNEL which would check by might_sleep()
The v2 is now what I can find to solve this and the smallest change.
But the drawback, again, is hardlockup depends on softlockup.
The other solution may be executed lockup_detector_init in a binded thread
which only bind to one cpu.
BRs,
Lecopzer
> -Sumit
>
> > caller is debug_smp_processor_id+0x20/0x2c
> > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0+ #276
> > Hardware name: linux,dummy-virt (DT)
> > Call trace:
> > dump_backtrace+0x0/0x3c0
> > show_stack+0x20/0x6c
> > dump_stack+0x2f0/0x42c
> > check_preemption_disabled+0x1cc/0x1dc
> > debug_smp_processor_id+0x20/0x2c
> > hardlockup_detector_event_create+0x34/0x18c
> > hardlockup_detector_perf_init+0x2c/0x134
> > watchdog_nmi_probe+0x18/0x24
> > lockup_detector_init+0x44/0xa8
> > armv8_pmu_driver_init+0x54/0x78
> > do_one_initcall+0x184/0x43c
> > kernel_init_freeable+0x368/0x380
> > kernel_init+0x1c/0x1cc
> > ret_from_fork+0x10/0x30
>
next prev parent reply other threads:[~2021-01-08 12:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-21 16:22 Lecopzer Chen
2021-01-08 10:34 ` Sumit Garg
2021-01-08 12:55 ` Lecopzer Chen [this message]
2021-01-12 15:07 ` Will Deacon
2021-01-12 16:32 ` Mark Rutland
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=20210108125527.14175-1-lecopzer.chen@mediatek.com \
--to=lecopzer.chen@mediatek.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oliver.sang@intel.com \
--cc=peterz@infradead.org \
--cc=sumit.garg@linaro.org \
--cc=will@kernel.org \
--cc=yj.chiang@mediatek.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
Powered by JetHome