mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yeoreum Yun" <yeoreum.yun@arm.com>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 3/9] coresight: etm4x: fix inconsistencies with sysfs configuration
Date: Tue, 15 Sep 2026 11:53:33 +0000	[thread overview]
Message-ID: <20260915115334.49FB91F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915-separate_etm_cfg_v2-v11-3-d2b258d51747@arm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] coresight: data race when updating cntr_val in etm4_disable_sysfs()
- [Medium] coresight: feat_csdev_lock macro fails to disable IRQs when __lock is NULL
--

commit 5571e5128409a42536b24f594b727e037107f3f4
Author: Yeoreum Yun <yeoreum.yun@arm.com>

coresight: etm4x: fix inconsistencies with sysfs configuration

This commit separates the active configuration applied to the current session
from the sysfs configuration to resolve inconsistencies. It applies configfs
settings after taking the appropriate mode and removes the lock/unlock around
sysfs enable/disable paths except when accessing config fields.

> diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
> index 90fd937d3bd83..ae6295e308131 100644
> --- a/drivers/hwtracing/coresight/coresight-config.h
> +++ b/drivers/hwtracing/coresight/coresight-config.h

[ ... ]

> @@ -259,4 +260,25 @@ void cscfg_csdev_disable_config(struct cscfg_config_csdev *config_csdev);
>  /* reset a feature to default values */
>  void cscfg_reset_feat(struct cscfg_feature_csdev *feat_csdev);
>  
> +#define feat_csdev_lock(feat_csdev, flags)				\
> +	do {								\
> +		raw_spinlock_t *__lock = feat_csdev->drv_spinlock;	\
> +		typecheck(unsigned long, flags);			\
> +		if (__lock)						\
> +			raw_spin_lock_irqsave(__lock, flags);		\
> +	} while (0)
> +
> +#define feat_csdev_unlock(feat_csdev, flags)				\
> +	do {								\
> +		raw_spinlock_t *__lock = feat_csdev->drv_spinlock;	\
> +		typecheck(unsigned long, flags);			\
> +		if (__lock)						\
> +			raw_spin_unlock_irqrestore(__lock, flags);	\
> +	} while (0)

[Severity: Medium]
Will these macros fail to disable IRQs when __lock is NULL?

The intent is to let cfg-configfs operate without grabbing the drv_spinlock
when it is NULL. However, raw_spin_lock_irqsave() also saves and disables
IRQs. If the lock is bypassed completely here, IRQs are left enabled.

Could this lead to reentrancy bugs or deadlocks if generic coresight configfs
routines like cscfg_csdev_enable_active_config() are called from contexts
where IRQs are enabled? Should there be a fallback like local_irq_save() when
__lock is NULL to ensure the critical section remains protected from
interrupts?

> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 2247ad55d4442..2df7f592bb5cf 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c

[ ... ]

> @@ -1140,9 +1152,17 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
>  	smp_call_function_single(drvdata->cpu, etm4_disable_sysfs_smp_call,
>  				 drvdata, 1);
>  
> -	raw_spin_unlock(&drvdata->spinlock);
> +	/*
> +	 * Userspace may read ss_status and cntr_val through sysfs after
> +	 * the sysfs-session has been disabled.
> +	 */
> +	for (i = 0; i < drvdata->nr_ss_cmp; i++)
> +		config->ss_status[i] = active_config->ss_status[i];
>  
> -	cscfg_csdev_disable_active_config(csdev);
> +	for (i = 0; i < drvdata->nr_cntr; i++)
> +		config->cntr_val[i] = active_config->cntr_val[i];

[Severity: Medium]
Does this create a data race with sysfs operations?

The etm4_disable_sysfs() function removes drvdata->spinlock but continues to
copy active_config values into config->cntr_val locklessly.

Meanwhile, concurrent sysfs show and store functions access these fields under
the spinlock:

cntr_val_store() {
        ...
        raw_spin_lock(&drvdata->spinlock);
        idx = config->cntr_idx;
        config->cntr_val[idx] = val;
        raw_spin_unlock(&drvdata->spinlock);
        ...
}

If etm4_disable_sysfs() runs while another thread concurrently reads or
writes cntr_val through sysfs, can it corrupt the configuration state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-separate_etm_cfg_v2-v11-0-d2b258d51747@arm.com?part=3

  reply	other threads:[~2026-09-15 11:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 11:34 [PATCH v11 0/9] fix several inconsistencies with sysfs configuration in etmX Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 1/9] coresight: etm4x: prohibit modifying ss_status and cntr_val while session is enabled Yeoreum Yun
2026-09-15 11:51   ` sashiko-bot
2026-09-15 13:26     ` Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 2/9] coresight: etm3x: prohibit modifying cntr_val and reset " Yeoreum Yun
2026-09-15 11:48   ` sashiko-bot
2026-09-15 13:30     ` Yeoreum Yun
2026-09-15 13:55       ` Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 3/9] coresight: etm4x: fix inconsistencies with sysfs configuration Yeoreum Yun
2026-09-15 11:53   ` sashiko-bot [this message]
2026-09-15 12:36     ` Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 4/9] coresight: etm3x: " Yeoreum Yun
2026-09-15 11:47   ` sashiko-bot
2026-09-15 13:42     ` Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 5/9] coresight: etm3x: remove redundant cpu online check on etm_enable_sysfs() Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 6/9] coresight: etm4x: introduce struct etm4_caps Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 7/9] coresight: etm4x: exclude ss_status from drvdata->config Yeoreum Yun
2026-09-15 11:49   ` sashiko-bot
2026-09-15 13:35     ` Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 8/9] coresight: etm4x: remove s_ex_level from config Yeoreum Yun
2026-09-15 11:34 ` [PATCH v11 9/9] coresight: etm3x: introduce struct etm_caps 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=20260915115334.49FB91F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yeoreum.yun@arm.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

all inboxes | Powered by JetHome®