From: Dave Jiang <dave.jiang@intel.com>
To: Richard Cheng <icheng@nvidia.com>
Cc: linux-cxl@vger.kernel.org, linux-perf-users@vger.kernel.org,
jic23@kernel.org, will@kernel.org, mark.rutland@arm.com,
dave@stgolabs.net, robin.murphy@arm.com, sashiko-bot@kernel.org
Subject: Re: [PATCH v3 9/9] perf/cxl: Don't log through pmu.dev in the overflow interrupt handler
Date: Mon, 3 Aug 2026 09:39:44 -0700 [thread overview]
Message-ID: <fb57cfe8-cb70-4e4f-8fea-77e82bf1cb68@intel.com> (raw)
In-Reply-To: <anAVpO--i5heVfz9@MWDK4CY14F>
On 8/2/26 10:29 PM, Richard Cheng wrote:
> On Fri, Jul 31, 2026 at 04:28:27PM +0800, Dave Jiang wrote:
>> perf_pmu_unregister() frees pmu->dev without clearing the pointer, and
>> cxl_pmu_probe() registers its devm actions so that teardown runs
>> perf_pmu_unregister() first, then the hotplug instance removal, then
>> free_irq(). Nothing before free_irq() masks the interrupt, so the handler
>> stays live across a window where info->pmu.dev is freed and its dev_dbg()
>> walks that pointer.
>>
>> Unsharing the interrupt does not close that window. cxl_pmu_event_stop()
>> leaves the counter's overflow status bit set, and only the handler clears
>> it, so an overflow taken just before teardown is still delivered and still
>> gets past the "did anything overflow" early-out. It lands in the !event
>> branch, where the dev_dbg() is.
>>
>> Log through info->pmu.parent instead, which is devm-managed and outlives
>> every teardown action.
>>
>> Clear the overflow status before requesting the interrupt too, since the
>> driver never touched it at probe and a counter left enabled with
>> INT_ON_OVRFLW by firmware or a previous kernel can raise an interrupt at
>> any point.
>>
>> Fixes: 5d7107c72796 ("perf: CXL Performance Monitoring Unit driver")
>> Reported-by: sashiko-bot@kernel.org
>> Closes: https://sashiko.dev/#/patchset/20260715191454.459673-1-dave@stgolabs.net?part=1
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
>> ---
>> v3:
>> - Clear CXL_PMU_OVERFLOW_REG at probe, before the handler is armed. A stale
>> status bit from firmware can cause overflow interrupt. (Robin)
>> - Ack dropped as the patch grew a hunk.
>> - Drop the cxl_pmu_offline_cpu() hunk. That dev_err() cannot be reached.
>> ---
>> drivers/perf/cxl_pmu.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/perf/cxl_pmu.c b/drivers/perf/cxl_pmu.c
>> index 37742ce43d9f..3683427fbb7e 100644
>> --- a/drivers/perf/cxl_pmu.c
>> +++ b/drivers/perf/cxl_pmu.c
>> @@ -806,7 +806,7 @@ static irqreturn_t cxl_pmu_irq(int irq, void *data)
>> struct perf_event *event = info->hw_events[i];
>>
>> if (!event) {
>> - dev_dbg(info->pmu.dev,
>> + dev_dbg(info->pmu.parent,
>> "overflow but on non enabled counter %d\n", i);
>> continue;
>> }
>> @@ -903,6 +903,15 @@ static int cxl_pmu_probe(struct device *dev)
>> if (!irq_name)
>> return -ENOMEM;
>>
>> + /*
>> + * Clear any overflow status left set by firmware or a previous kernel
>> + * before the handler goes live, so it cannot mistake a stale bit for an
>> + * overflow on a counter no event owns yet. The register is RW1C, and
>> + * bits above the implemented counters are RsvdZ, so only write those.
>> + */
>> + writeq(GENMASK_ULL(info->num_counters - 1, 0),
>> + info->base + CXL_PMU_OVERFLOW_REG);
>> +
>
> Hi Dave,
>
> I have a question here, since you are adding a clear, event_start() covers more than probe does. The block is frozen there, and it closes the reuse case as well as the boot one.
> If a counter's overflow MSI is still in flight when perf reschedule that counter
> to another event, the handler charges the full period to an event whose
> prev_count was just zeroed.
You are correct. v4 will add to event_start():
writeq(BIT_ULL(hwc->idx), base + CXL_PMU_OVERFLOW_REG);
>
> Also if FW can leave a counter enabled, I'm not sure whether it's possible or not, but if that's the case, is clearing the status bit enough?
> A leftoever counter with Global Freeze on Overflow but not Interrupt on Overflow
> will wrap, freeze the whole CPMU, and raise nothing.
Also right. This series is already large enough. Will have follow on patches to address this.
>
> Best regards,
> Richard Cheng.
>
>
>
>> /*
>> * The handler must run on info->on_cpu, so the interrupt cannot be
>> * shared - IRQF_NOBALANCING is only honoured for the first action on a
>> --
>> 2.55.0
>>
>>
prev parent reply other threads:[~2026-08-03 17:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 23:28 [PATCH v3 0/9] perf/cxlpmu: Misc sashiko raised issues fixes Dave Jiang
2026-07-31 23:28 ` [PATCH v3 1/9] perf/cxl: Program the requested event group on configurable counters Dave Jiang
2026-07-31 23:38 ` sashiko-bot
2026-07-31 23:28 ` [PATCH v3 2/9] perf/cxl: Clear stale event fields before reprogramming a counter Dave Jiang
2026-07-31 23:40 ` sashiko-bot
2026-07-31 23:28 ` [PATCH v3 3/9] perf/cxl: Fix the counter overflow delta fixup Dave Jiang
2026-07-31 23:37 ` sashiko-bot
2026-07-31 23:28 ` [PATCH v3 4/9] perf/cxl: Split the MSI vector out of info->irq Dave Jiang
2026-07-31 23:45 ` sashiko-bot
2026-08-03 12:04 ` Robin Murphy
2026-08-03 16:01 ` Dave Jiang
2026-07-31 23:28 ` [PATCH v3 5/9] perf/cxl: Accept an overflow interrupt on MSI message number 0 Dave Jiang
2026-08-03 5:57 ` Richard Cheng
2026-08-03 14:30 ` Dave Jiang
2026-08-03 14:40 ` Richard Cheng
2026-07-31 23:28 ` [PATCH v3 6/9] perf/cxl: Don't share the overflow interrupt, and keep it pinned Dave Jiang
2026-07-31 23:50 ` sashiko-bot
2026-07-31 23:28 ` [PATCH v3 7/9] perf/cxl: Unfreeze counters after handling an overflow interrupt Dave Jiang
2026-07-31 23:40 ` sashiko-bot
2026-08-03 4:00 ` Richard Cheng
2026-08-03 11:26 ` Robin Murphy
2026-07-31 23:28 ` [PATCH v3 8/9] perf/cxl: Validate the hardware-reported counter width Dave Jiang
2026-07-31 23:28 ` [PATCH v3 9/9] perf/cxl: Don't log through pmu.dev in the overflow interrupt handler Dave Jiang
2026-07-31 23:46 ` sashiko-bot
2026-08-03 5:29 ` Richard Cheng
2026-08-03 16:39 ` Dave Jiang [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=fb57cfe8-cb70-4e4f-8fea-77e82bf1cb68@intel.com \
--to=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=icheng@nvidia.com \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=sashiko-bot@kernel.org \
--cc=will@kernel.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