From: Yeoreum Yun <yeoreum.yun@arm.com>
To: sashiko-reviews@lists.linux.dev
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v13 05/14] coresight: etm3x: fix inconsistencies with sysfs configuration
Date: Sat, 3 Oct 2026 03:47:25 +0100 [thread overview]
Message-ID: <asBsvTTuYXSLT4Zn@e129823.arm.com> (raw)
In-Reply-To: <20261003013344.D438A1F00898@smtp.kernel.org>
On Sat, Oct 03, 2026 at 01:33:44AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] coresight: etm3x: race condition exposes powered-down hardware reads
> - [Medium] coresight: etm3x: data race on cntr_idx in sysfs read
> --
>
> commit 6e8889b8f94797194e00dbd7c1a4354b7b49c21d
> Author: Yeoreum Yun <yeoreum.yun@arm.com>
>
> coresight: etm3x: fix inconsistencies with sysfs configuration
>
> This commit separates ETM3x configuration into curr_config and config to
> resolve inconsistencies when modified via sysfs during an active perf session.
> It also removes the spinlock from sysfs enable/disable paths and uses IPIs to
> read registers on the proper CPU.
>
> > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> > index 862ad0786699c..dcadcc3830123 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> [ ... ]
> > @@ -640,7 +641,14 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
> > smp_call_function_single(drvdata->cpu, etm_disable_sysfs_smp_call,
> > drvdata, 1);
> >
> > - spin_unlock(&drvdata->spinlock);
> > + /*
> > + * Userspace may read seq_curr_state and cntr_val through sysfs
> > + * after the sysfs-session has been disabled.
> > + */
> > + for (i = 0; i < drvdata->nr_cntr; i++)
> > + config->cntr_val[i] = curr_config->cntr_val[i];
> > +
> > + config->seq_curr_state = curr_config->seq_curr_state;
> >
> > /*
> > * we only release trace IDs when resetting sysfs.
> > @@ -649,6 +657,8 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
> > * prior trace id allocation method
> > */
> >
> > + coresight_set_mode(drvdata->csdev, CS_MODE_DISABLED);
> > +
>
> [Severity: High]
> Can this expose a window where hardware registers are read while the device
> is powered down?
>
> The commit removes the drvdata->spinlock that previously serialized sysfs
> reads against enable/disable paths. In etm_disable_sysfs(), the hardware is
> powered down via smp_call_function_single(), but the mode is not changed
> to CS_MODE_DISABLED until much later here.
>
> During this window, could a concurrent sysfs reader like
> seq_curr_state_show() observe coresight_get_mode() as CS_MODE_SYSFS and
> proceed to call etm_readl_cslocked()? Reading from hardware registers such
> as ETMSQR when the ETM power-down bit is set can lead to bus faults (SError)
> or return garbage.
This is not true. etm_read_cslocked() caa pm_runtime_get_sync() and
then try to smpcall to read the hardware register.
>
> > dev_dbg(&csdev->dev, "ETM tracing disabled\n");
> > }
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > index cdb70a4382eb8..284998f180170 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> [ ... ]
> > @@ -730,7 +765,10 @@ static ssize_t cntr_val_show(struct device *dev,
> > val = config->cntr_val[config->cntr_idx];
> > spin_unlock(&drvdata->spinlock);
> > } else {
> > - val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx));
> > + ret = etm_readl_cslocked(drvdata, ETMCNTVRn(config->cntr_idx), &val2);
>
> [Severity: Medium]
> Is it safe to read config->cntr_idx here without holding drvdata->spinlock?
>
> Concurrent updates from cntr_idx_store() via sysfs could change this value
> mid-execution. Since the spinlock was removed from this branch, could this
> data race cause the lockless read to fetch an inconsistent index and target
> an unintended counter register?
This is ridiculous anyway foremerly too who got the lock first affect
the result.when *concurrent* enable and store together.
So it's igrnoable since we don't expect user config somthing while
enabling session.
>
> > + if (ret)
> > + return ret;
> > + val = val2;
> > }
> >
> > return sysfs_emit(buf, "%#x\n", val);
> [ ... ]
> > @@ -946,15 +985,10 @@ static ssize_t seq_curr_state_show(struct device *dev,
> > goto out;
> > }
> >
> > - pm_runtime_get_sync(dev->parent);
> > - spin_lock_irqsave(&drvdata->spinlock, flags);
> > -
> > - CS_UNLOCK(drvdata->csa.base);
> > - val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
> > - CS_LOCK(drvdata->csa.base);
> > -
> > - spin_unlock_irqrestore(&drvdata->spinlock, flags);
> > - pm_runtime_put(dev->parent);
> > + ret = etm_readl_cslocked(drvdata, ETMSQR, &val);
>
> [Severity: High]
> This is where a concurrent reader could read a powered-down register due to
> the window mentioned above in etm_disable_sysfs().
no. etm_readl_cslocked() calls pm_runtime_get_sync().
>
> > + if (ret)
> > + return ret;
> > + val &= ETM_SQR_MASK;
> > out:
> > return sprintf(buf, "%#lx\n", val);
> > }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261002-separate_etm_cfg_v2-v13-0-fe429d8d96fb@arm.com?part=5
--
Sincerely,
Yeoreum Yun
next prev parent reply other threads:[~2026-10-03 2:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 19:03 [PATCH v13 00/14] fix several inconsistencies with sysfs configuration in etmX Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 01/14] coresight: etm4x: read-back TRCSEQSTR at disabling and prohibit modifying seq_state while enabling Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 1:47 ` Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 02/14] coresight: etm4x: prohibit modifying cntr_val while session is enabled Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 1:50 ` Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 03/14] coresight: etm3x: prohibit modifying cntr_val and reset " Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 2:02 ` Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 04/14] coresight: etm4x: fix inconsistencies with sysfs configuration Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 2:30 ` Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 05/14] coresight: etm3x: " Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 2:47 ` Yeoreum Yun [this message]
2026-10-02 19:03 ` [PATCH v13 06/14] coresight: etm3x: remove redundant cpu online check on etm_enable_sysfs() Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 07/14] coresight: etm4x: introduce struct etm4_caps Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 08/14] coresight: etm4x: exclude ss_status from drvdata->config Yeoreum Yun
2026-10-03 1:33 ` sashiko-bot
2026-10-03 2:38 ` Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 09/14] coresight: etm4x: remove s_ex_level from config Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 10/14] coresight: etm4x: rename local config as curr_config referring drvdata->curr_config Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 11/14] coresight: etm4x: rename drvdata->config to sysfs_config Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 12/14] coresight: etm3x: introduce struct etm_caps Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 13/14] coresight: etm3x: rename local config as curr_config referring drvdata->curr_config Yeoreum Yun
2026-10-02 19:03 ` [PATCH v13 14/14] coresight: etm3x: rename drvdata->config to sysfs_config Yeoreum Yun
2026-10-03 2:49 ` [PATCH v13 00/14] fix several inconsistencies with sysfs configuration in etmX Yeoreum Yun
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=asBsvTTuYXSLT4Zn@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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
all inboxes | Powered by JetHome®