CoreSight

coresight@lists.linaro.org

5 participants
2671 discussions

Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()

by Leo Yan

On Fri, Nov 21, 2025 at 12:23:50AM +0000, Kuan-Wei Chiu wrote: [...] > I noticed this issue while browsing the coresight code after attending > a technical talk on the subject. This code dates back to the initial > driver submission over 10 years ago, so I was surprised it hadn't been > caught earlier. Although I cannot perform runtime testing, the logic > error seems obvious to me, so I still decided to submit this patch. I have a question for maintainers. The ETMv4 architecture specification shows that ETMv4 was released as a non-confidential module in May 2013 (with the confidential release even a year earlier). So ETMv4 has been a public IP for more than 12+ years, and ETMv3 has been gradually retired since then. This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel? Thanks, Leo

10 months, 3 weeks

[PATCH v7 00/13] coresight: Update timestamp attribute to be an interval instead of bool

by James Clark

Do some cleanups then expand the timestamp format attribute from 1 bit to 4 bits for ETMv4 in Perf mode. The current interval is too high for most use cases, and particularly on the FVP the number of timestamps generated is excessive. This change not only still allows disabling or enabling timestamps, but also allows the interval to be configured. The old bit is kept deprecated and undocumented for now. There are known broken versions of Perf that don't read the format attribute positions from sysfs and instead hard code the timestamp bit. We can leave the old bit in the driver until we need the bit for another feature or enough time has passed that these old Perfs are unlikely to be used. The interval option is added as an event format attribute, rather than a Coresight config because it's something that the driver is already configuring automatically in Perf mode using any unused counter, so it's not possible to modify this with a config. Applies to coresight/next Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v7: - Change TRCCNTCTLRn and TRCTSCTLR register definitions to use a combined field for TYPE and SEL (EVENT) so that they can be used with the new utilities. - Add utility functions for creating resource selectors that do compile and runtime checking of the resource selector ID. - Link to v6: https://lore.kernel.org/r/20251119-james-cs-syncfreq-v6-0-740d24a29e51@lina… Changes in v6: - #ifdef out format attributes for ETMv3 instead of using is_visible(). Then the same block can be used to define format_attr_contextid_show() which avoids an awkward WARN_ONCE() and comments in arm32 for a function that's never called. - Link to v5: https://lore.kernel.org/r/20251118-james-cs-syncfreq-v5-0-82efd7b1a751@lina… Changes in v5: - Add parens to interval calculation in docs (Randy) - Swap "minimum interval" and "maximum interval" in docs. (Leo) - Add TRCSYNCPR.PERIOD to docs (Leo) - Use CONFIG_ARM64 to avoid is_kernel_in_hyp_mode() (Leo) - Add a comment for hidden ETMv3 format attributes (Leo) - Hide configid for ETMv3 (Leo) - Link to v4: https://lore.kernel.org/r/20251112-james-cs-syncfreq-v4-0-165ba21401dc@lina… Changes in v4: - Add #defines for true and false resources ETM_RES_SEL_TRUE/FALSE - Reword comment about finding a counter to say if there are no resources there are no counters. - Extend existing timestamp format attribute instead of adding a new one - Refactor all the config definitions and parsing to use GEN_PMU_FORMAT_ATTR()/ATTR_CFG_GET_FLD() so we can see where the unused bits are. - Link to v3: https://lore.kernel.org/r/20251002-james-cs-syncfreq-v3-0-fe5df2bf91d1@lina… Changes in v3: - Move the format attr definitions to coresight-etm-perf.h we can compile on arm32 without #ifdefs - (Leo) - Convert the new #ifdefs to a single one in an is_visible() function so that the code is cleaner - (Leo) - Drop the change to remove the holes in struct etmv4_config as they were grouped by function - (Mike) - Link to v2: https://lore.kernel.org/r/20250814-james-cs-syncfreq-v2-0-c76fcb87696d@lina… Changes in v2: - Only show the attribute for ETMv4 to improve usability and fix the arm32 build error. Wrapping everything in IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) isn't ideal, but the -perf.c file is shared between ETMv3 and ETMv4, and there is already precedent for doing it this way. - Link to v1: https://lore.kernel.org/r/20250811-james-cs-syncfreq-v1-0-b001cd6e3404@lina… --- James Clark (13): coresight: Change syncfreq to be a u8 coresight: Repack struct etmv4_drvdata coresight: Refactor etm4_config_timestamp_event() coresight: Hide unused ETMv3 format attributes coresight: Define format attributes with GEN_PMU_FORMAT_ATTR() coresight: Interpret ETMv3 config with ATTR_CFG_GET_FLD() coresight: Don't reject unrecognized ETMv3 format attributes coresight: Interpret perf config with ATTR_CFG_GET_FLD() coresight: Interpret ETMv4 config with ATTR_CFG_GET_FLD() coresight: Remove misleading definitions coresight: Extend width of timestamp format attribute coresight: Allow setting the timestamp interval coresight: docs: Document etm4x timestamp interval option Documentation/trace/coresight/coresight.rst | 16 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 68 ++++----- drivers/hwtracing/coresight/coresight-etm-perf.h | 39 +++++ drivers/hwtracing/coresight/coresight-etm3x-core.c | 36 ++--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 164 +++++++++++++-------- drivers/hwtracing/coresight/coresight-etm4x.h | 92 +++++++++--- include/linux/coresight-pmu.h | 24 --- 7 files changed, 275 insertions(+), 164 deletions(-) --- base-commit: 9e9182cab5ebc3ee7544e60ef08ba19fdf216920 change-id: 20250724-james-cs-syncfreq-7c2257a38ed3 Best regards, -- James Clark <james.clark(a)linaro.org>

10 months, 3 weeks

Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()

by Leo Yan

On Thu, Nov 27, 2025 at 04:44:53PM +0800, Kuan-Wei Chiu wrote: [...] > I don't feel it is my place to say whether the etm3x driver should be > removed entirely. Sorry for confusion. Your fix patch is welcome, this is useful no matter if remove the ETMv3 driver or not. > However, if we decide to keep it, I agree that aligning cntr_val_show > with the cntr_val_store behavior (using cntr_idx) makes more sense. > > Here is my plan for v2: > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > index 762109307b86..77578885e8f3 100644 > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > @@ -717,26 +717,19 @@ static DEVICE_ATTR_RW(cntr_rld_event); > static ssize_t cntr_val_show(struct device *dev, > struct device_attribute *attr, char *buf) > { > - int i, ret = 0; > u32 val; > struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent); > struct etm_config *config = &drvdata->config; > > if (!coresight_get_mode(drvdata->csdev)) { > spin_lock(&drvdata->spinlock); > - for (i = 0; i < drvdata->nr_cntr; i++) > - ret += sprintf(buf, "counter %d: %x\n", > - i, config->cntr_val[i]); > + val = config->cntr_val[config->cntr_idx]; > spin_unlock(&drvdata->spinlock); > - return ret; > - } > - > - for (i = 0; i < drvdata->nr_cntr; i++) { > - val = etm_readl(drvdata, ETMCNTVRn(i)); > - ret += sprintf(buf, "counter %d: %x\n", i, val); > + return sprintf(buf, "%x\n", val); > } > > - return ret; > + val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx)); It is not right to read register at here (it cannot promise to read the CPU (cp14) register on the target CPU). Please refer to the same function in coresight-etm4x-sysfs.c. I think we can do the same thing at here. > + return sprintf(buf, "%x\n", val); > } > > static ssize_t cntr_val_store(struct device *dev, > > > Given the upcoming merge window, I plan to submit this v2 after -rc1 > is released. > > Alternatively, if the consensus is to drop the driver, I am happy to > submit a patch for that instead. Please continue this patch. Thanks a lot! Leo

10 months, 3 weeks

Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()

by James Clark

On 27/11/2025 8:44 am, Kuan-Wei Chiu wrote: > On Wed, Nov 26, 2025 at 10:57:23AM +0000, James Clark wrote: >> >> >> On 26/11/2025 10:49 am, Mike Leach wrote: >>> Hi, >>> >>> On Mon, 24 Nov 2025 at 16:12, James Clark <james.clark(a)linaro.org> wrote: >>>> >>>> >>>> >>>> On 21/11/2025 5:02 pm, Kuan-Wei Chiu wrote: >>>>> Hi James, >>>>> >>>>> On Fri, Nov 21, 2025 at 09:50:03AM +0000, James Clark wrote: >>>>>> >>>>>> >>>>>> On 21/11/2025 12:23 am, Kuan-Wei Chiu wrote: >>>>>>> The cntr_val_show() function is meant to display the values of all >>>>>>> available counters. However, the sprintf() call inside the loop was >>>>>>> always writing to the beginning of the buffer, causing the output of >>>>>>> previous iterations to be overwritten. As a result, only the value of >>>>>>> the last counter was actually returned to the user. >>>>>>> >>>>>>> Fix this by using the return value of sprintf() to calculate the >>>>>>> correct offset into the buffer for the next write, ensuring that all >>>>>>> counter values are appended sequentially. >>>>>>> >>>>>>> Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") >>>>>>> Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> >>>>>>> --- >>>>>>> Build tested only. I do not have the hardware to run the etm3x driver, >>>>>>> so I would be grateful if someone could verify this on actual hardware. >>>>>>> >>>>>>> I noticed this issue while browsing the coresight code after attending >>>>>>> a technical talk on the subject. This code dates back to the initial >>>>>>> driver submission over 10 years ago, so I was surprised it hadn't been >>>>>>> caught earlier. Although I cannot perform runtime testing, the logic >>>>>>> error seems obvious to me, so I still decided to submit this patch. >>>>>> >>>>>> Nice find. I think the point that it wasn't caught changes how we fix it. >>>>>> Either nobody used it ever - so we can just delete it. Or someone was using >>>>>> it and they expect it to always return a single entry with the value of the >>>>>> last counter and this is a potentially breaking change. So maybe instead of >>>>>> fixing this we should add a new cntr_vals_show() which works correctly. But >>>>>> then again if nobody is using it we shouldn't do that either. >>>>> >>>>> Thanks for your feedback. >>>>> >>>>> I agree that if any tool relies on the current behavior, this patch >>>>> would break the ABI and violate the hard rule that we must never break >>>>> userspace. >>>>> >>>>> However, I am not sure how to determine if any userspace tools are >>>>> actually using this sysfs interface. Is there a recommended way to >>>>> verify this, or a standard procedure/convention to follow in this >>>>> situation? >>>>> >>>>> Regards, >>>>> Kuan-Wei >>>>> >>>> >>>> There's no way of knowing apart from deducing that there are 0 users of >>>> the 'correct' version of the API because it never existed. This isn't >>>> even a regression, it was broken from the beginning. >>>> >>>> I suppose it does work when hardware only has one counter, but I don't >>>> know how likely that is? >>>> >>>> Looking at cntr_val_store() I think I was wrong before when I said it >>>> should be a separate file for each counter. Writing to it already writes >>>> to the counter currently selected by cntr_idx and splitting it out to >>>> separate files would have to break that too. So we can fix the display >>>> bug by making show operate on the currently selected counter in the same >>>> way as store. Then it makes a bit more sense and we can delete the >>>> "counter %d: " prefix. >>>> >>>> ETM4 already does it this way too. >>>> >>> I agree with this. >>> >>> The difficulty in having a file per counter is that different >>> implementations have different numbers of counters. Rather than >>> complicate the driver by dynamically generating the sysfs files, the >> >> It wouldn't be that hard because there is a maximum number of counters. >> You'd generate them all and then use the is_visible() thing to hide ones >> that didn't exist on that device. >> >> But it looks like we don't want to do it that way for other reasons anyway. >> > > I don't feel it is my place to say whether the etm3x driver should be > removed entirely. > > However, if we decide to keep it, I agree that aligning cntr_val_show > with the cntr_val_store behavior (using cntr_idx) makes more sense. > > Here is my plan for v2: > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > index 762109307b86..77578885e8f3 100644 > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > @@ -717,26 +717,19 @@ static DEVICE_ATTR_RW(cntr_rld_event); > static ssize_t cntr_val_show(struct device *dev, > struct device_attribute *attr, char *buf) > { > - int i, ret = 0; > u32 val; > struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent); > struct etm_config *config = &drvdata->config; > > if (!coresight_get_mode(drvdata->csdev)) { > spin_lock(&drvdata->spinlock); > - for (i = 0; i < drvdata->nr_cntr; i++) > - ret += sprintf(buf, "counter %d: %x\n", > - i, config->cntr_val[i]); > + val = config->cntr_val[config->cntr_idx]; > spin_unlock(&drvdata->spinlock); > - return ret; > - } > - > - for (i = 0; i < drvdata->nr_cntr; i++) { > - val = etm_readl(drvdata, ETMCNTVRn(i)); > - ret += sprintf(buf, "counter %d: %x\n", i, val); > + return sprintf(buf, "%x\n", val); > } > > - return ret; > + val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx)); > + return sprintf(buf, "%x\n", val); > } > > static ssize_t cntr_val_store(struct device *dev, > > > Given the upcoming merge window, I plan to submit this v2 after -rc1 > is released. > > Alternatively, if the consensus is to drop the driver, I am happy to > submit a patch for that instead. > > Regards, > Kuan-Wei > > The change looks good. I wouldn't wait for rc1, nobody else is touching these files so nothing will change, so makes sense to send it now. >>> single file + selector paradigm makes things easier. The index is >>> validated against the actual number of counters for this instance, and >>> read/write occurs for the selected one. >>> >>> Regards >>> >>> Mike >>> >>>>>> >>>>>> The interface isn't even that great, it should be a separate file per >>>>>> counter. You don't want to be parsing strings and colons to try to read a >>>>>> single value, especially in C. Separate files allows you to read it directly >>>>>> without any hassle. >>>>>> >>>>>>> >>>>>>> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>>>> index 762109307b86..312033e74b7a 100644 >>>>>>> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>>>> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>>>> @@ -725,7 +725,7 @@ static ssize_t cntr_val_show(struct device *dev, >>>>>>> if (!coresight_get_mode(drvdata->csdev)) { >>>>>>> spin_lock(&drvdata->spinlock); >>>>>>> for (i = 0; i < drvdata->nr_cntr; i++) >>>>>>> - ret += sprintf(buf, "counter %d: %x\n", >>>>>>> + ret += sprintf(buf + ret, "counter %d: %x\n", >>>>>>> i, config->cntr_val[i]); >>>>>>> spin_unlock(&drvdata->spinlock); >>>>>>> return ret; >>>>>>> @@ -733,7 +733,7 @@ static ssize_t cntr_val_show(struct device *dev, >>>>>>> for (i = 0; i < drvdata->nr_cntr; i++) { >>>>>>> val = etm_readl(drvdata, ETMCNTVRn(i)); >>>>>>> - ret += sprintf(buf, "counter %d: %x\n", i, val); >>>>>>> + ret += sprintf(buf + ret, "counter %d: %x\n", i, val); >>>>>>> } >>>>>>> return ret; >>>>>> >>>> >>> >>> >>

10 months, 3 weeks

Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()

by James Clark

On 21/11/2025 5:02 pm, Kuan-Wei Chiu wrote: > Hi James, > > On Fri, Nov 21, 2025 at 09:50:03AM +0000, James Clark wrote: >> >> >> On 21/11/2025 12:23 am, Kuan-Wei Chiu wrote: >>> The cntr_val_show() function is meant to display the values of all >>> available counters. However, the sprintf() call inside the loop was >>> always writing to the beginning of the buffer, causing the output of >>> previous iterations to be overwritten. As a result, only the value of >>> the last counter was actually returned to the user. >>> >>> Fix this by using the return value of sprintf() to calculate the >>> correct offset into the buffer for the next write, ensuring that all >>> counter values are appended sequentially. >>> >>> Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") >>> Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> >>> --- >>> Build tested only. I do not have the hardware to run the etm3x driver, >>> so I would be grateful if someone could verify this on actual hardware. >>> >>> I noticed this issue while browsing the coresight code after attending >>> a technical talk on the subject. This code dates back to the initial >>> driver submission over 10 years ago, so I was surprised it hadn't been >>> caught earlier. Although I cannot perform runtime testing, the logic >>> error seems obvious to me, so I still decided to submit this patch. >> >> Nice find. I think the point that it wasn't caught changes how we fix it. >> Either nobody used it ever - so we can just delete it. Or someone was using >> it and they expect it to always return a single entry with the value of the >> last counter and this is a potentially breaking change. So maybe instead of >> fixing this we should add a new cntr_vals_show() which works correctly. But >> then again if nobody is using it we shouldn't do that either. > > Thanks for your feedback. > > I agree that if any tool relies on the current behavior, this patch > would break the ABI and violate the hard rule that we must never break > userspace. > > However, I am not sure how to determine if any userspace tools are > actually using this sysfs interface. Is there a recommended way to > verify this, or a standard procedure/convention to follow in this > situation? > > Regards, > Kuan-Wei > There's no way of knowing apart from deducing that there are 0 users of the 'correct' version of the API because it never existed. This isn't even a regression, it was broken from the beginning. I suppose it does work when hardware only has one counter, but I don't know how likely that is? Looking at cntr_val_store() I think I was wrong before when I said it should be a separate file for each counter. Writing to it already writes to the counter currently selected by cntr_idx and splitting it out to separate files would have to break that too. So we can fix the display bug by making show operate on the currently selected counter in the same way as store. Then it makes a bit more sense and we can delete the "counter %d: " prefix. ETM4 already does it this way too. >> >> The interface isn't even that great, it should be a separate file per >> counter. You don't want to be parsing strings and colons to try to read a >> single value, especially in C. Separate files allows you to read it directly >> without any hassle. >> >>> >>> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> index 762109307b86..312033e74b7a 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> @@ -725,7 +725,7 @@ static ssize_t cntr_val_show(struct device *dev, >>> if (!coresight_get_mode(drvdata->csdev)) { >>> spin_lock(&drvdata->spinlock); >>> for (i = 0; i < drvdata->nr_cntr; i++) >>> - ret += sprintf(buf, "counter %d: %x\n", >>> + ret += sprintf(buf + ret, "counter %d: %x\n", >>> i, config->cntr_val[i]); >>> spin_unlock(&drvdata->spinlock); >>> return ret; >>> @@ -733,7 +733,7 @@ static ssize_t cntr_val_show(struct device *dev, >>> for (i = 0; i < drvdata->nr_cntr; i++) { >>> val = etm_readl(drvdata, ETMCNTVRn(i)); >>> - ret += sprintf(buf, "counter %d: %x\n", i, val); >>> + ret += sprintf(buf + ret, "counter %d: %x\n", i, val); >>> } >>> return ret; >>

10 months, 4 weeks

[PATCH v5 00/13] coresight: Update timestamp attribute to be an interval instead of bool

by James Clark

Do some cleanups then expand the timestamp format attribute from 1 bit to 4 bits for ETMv4 in Perf mode. The current interval is too high for most use cases, and particularly on the FVP the number of timestamps generated is excessive. This change not only still allows disabling or enabling timestamps, but also allows the interval to be configured. The old bit is kept deprecated and undocumented for now. There are known broken versions of Perf that don't read the format attribute positions from sysfs and instead hard code the timestamp bit. We can leave the old bit in the driver until we need the bit for another feature or enough time has passed that these old Perfs are unlikely to be used. The interval option is added as an event format attribute, rather than a Coresight config because it's something that the driver is already configuring automatically in Perf mode using any unused counter, so it's not possible to modify this with a config. Applies to coresight/next Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v5: - Add parens to interval calculation in docs (Randy) - Swap "minimum interval" and "maximum interval" in docs. (Leo) - Add TRCSYNCPR.PERIOD to docs (Leo) - Use CONFIG_ARM64 to avoid is_kernel_in_hyp_mode() (Leo) - Add a comment for hidden ETMv3 format attributes (Leo) - Hide configid for ETMv3 (Leo) - Link to v4: https://lore.kernel.org/r/20251112-james-cs-syncfreq-v4-0-165ba21401dc@lina… Changes in v4: - Add #defines for true and false resources ETM_RES_SEL_TRUE/FALSE - Reword comment about finding a counter to say if there are no resources there are no counters. - Extend existing timestamp format attribute instead of adding a new one - Refactor all the config definitions and parsing to use GEN_PMU_FORMAT_ATTR()/ATTR_CFG_GET_FLD() so we can see where the unused bits are. - Link to v3: https://lore.kernel.org/r/20251002-james-cs-syncfreq-v3-0-fe5df2bf91d1@lina… Changes in v3: - Move the format attr definitions to coresight-etm-perf.h we can compile on arm32 without #ifdefs - (Leo) - Convert the new #ifdefs to a single one in an is_visible() function so that the code is cleaner - (Leo) - Drop the change to remove the holes in struct etmv4_config as they were grouped by function - (Mike) - Link to v2: https://lore.kernel.org/r/20250814-james-cs-syncfreq-v2-0-c76fcb87696d@lina… Changes in v2: - Only show the attribute for ETMv4 to improve usability and fix the arm32 build error. Wrapping everything in IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) isn't ideal, but the -perf.c file is shared between ETMv3 and ETMv4, and there is already precedent for doing it this way. - Link to v1: https://lore.kernel.org/r/20250811-james-cs-syncfreq-v1-0-b001cd6e3404@lina… --- James Clark (13): coresight: Change syncfreq to be a u8 coresight: Repack struct etmv4_drvdata coresight: Refactor etm4_config_timestamp_event() coresight: Hide unused ETMv3 format attributes coresight: Define format attributes with GEN_PMU_FORMAT_ATTR() coresight: Interpret ETMv3 config with ATTR_CFG_GET_FLD() coresight: Don't reject unrecognized ETMv3 format attributes coresight: Interpret perf config with ATTR_CFG_GET_FLD() coresight: Interpret ETMv4 config with ATTR_CFG_GET_FLD() coresight: Remove misleading definitions coresight: Extend width of timestamp format attribute coresight: Allow setting the timestamp interval coresight: docs: Document etm4x timestamp interval option Documentation/trace/coresight/coresight.rst | 16 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 70 ++++++--- drivers/hwtracing/coresight/coresight-etm-perf.h | 39 +++++ drivers/hwtracing/coresight/coresight-etm3x-core.c | 36 ++--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 164 +++++++++++++-------- drivers/hwtracing/coresight/coresight-etm4x.h | 61 +++++--- include/linux/coresight-pmu.h | 24 --- 7 files changed, 258 insertions(+), 152 deletions(-) --- base-commit: 9e9182cab5ebc3ee7544e60ef08ba19fdf216920 change-id: 20250724-james-cs-syncfreq-7c2257a38ed3 Best regards, -- James Clark <james.clark(a)linaro.org>

11 months

[GIT PULL] coresight: Updates for Linux v6.19

by Suzuki K Poulose

Hi Greg, Please find the coresight self hosted tracing subsystem updates targeting v6.19. Kindly pull, Suzuki The following changes since commit dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa: Linux 6.18-rc3 (2025-10-26 15:59:49 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.19 for you to fetch changes up to 9e9182cab5ebc3ee7544e60ef08ba19fdf216920: coresight: etm4x: Remove the state_needs_restore flag (2025-11-12 16:53:19 +0000) ---------------------------------------------------------------- coresight: Updates for Linux v6.19 The changes for Linux v6.19 include : - Support for static TPDM - Fixes to TMC-ETR with CATU where buffer wasn't available to CATU in perf mode - Clean ups to the component operations to accept coresight_path - Fixes to the ETM4x/ETM3x driver Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Carl Worth (1): coresight: tmc: add the handle of the event to the path Jie Gan (5): dt-bindings: arm: document the static TPDM compatible coresight: tpdm: add static tpdm support coresight: tpdm: remove redundant check for drvdata coresight: change helper_ops to accept coresight_path coresight: change the sink_ops to accept coresight_path Leo Yan (8): coresight: Change device mode to atomic type coresight: etm4x: Always set tracer's device mode on target CPU coresight: etm3x: Always set tracer's device mode on target CPU coresight: etm4x: Correct polling IDLE bit coresight: etm4x: Add context synchronization before enabling trace coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF coresight: etm4x: Remove the redundant DSB coresight: etm4x: Remove the state_needs_restore flag Xiaoqi Zhuang (1): coresight: ETR: Fix ETR buffer use-after-free issue .../bindings/arm/qcom,coresight-tpdm.yaml | 23 ++- drivers/hwtracing/coresight/coresight-catu.c | 10 +- drivers/hwtracing/coresight/coresight-core.c | 30 ++-- drivers/hwtracing/coresight/coresight-ctcu-core.c | 9 +- drivers/hwtracing/coresight/coresight-cti-core.c | 5 +- drivers/hwtracing/coresight/coresight-cti.h | 5 +- drivers/hwtracing/coresight/coresight-dummy.c | 2 +- drivers/hwtracing/coresight/coresight-etb10.c | 8 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 3 +- drivers/hwtracing/coresight/coresight-etm3x-core.c | 59 ++++--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 140 +++++++++++------ drivers/hwtracing/coresight/coresight-etm4x.h | 5 - drivers/hwtracing/coresight/coresight-priv.h | 3 +- drivers/hwtracing/coresight/coresight-sysfs.c | 2 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 10 +- drivers/hwtracing/coresight/coresight-tmc-etr.c | 22 ++- drivers/hwtracing/coresight/coresight-tmc.h | 3 +- drivers/hwtracing/coresight/coresight-tpda.c | 7 - drivers/hwtracing/coresight/coresight-tpdm.c | 174 +++++++++++++++++---- drivers/hwtracing/coresight/coresight-tpdm.h | 12 ++ drivers/hwtracing/coresight/coresight-tpiu.c | 2 +- drivers/hwtracing/coresight/coresight-trbe.c | 4 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 9 +- include/linux/coresight.h | 42 ++--- 24 files changed, 402 insertions(+), 187 deletions(-)

11 months

Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()

by James Clark

On 21/11/2025 12:23 am, Kuan-Wei Chiu wrote: > The cntr_val_show() function is meant to display the values of all > available counters. However, the sprintf() call inside the loop was > always writing to the beginning of the buffer, causing the output of > previous iterations to be overwritten. As a result, only the value of > the last counter was actually returned to the user. > > Fix this by using the return value of sprintf() to calculate the > correct offset into the buffer for the next write, ensuring that all > counter values are appended sequentially. > > Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") > Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> > --- > Build tested only. I do not have the hardware to run the etm3x driver, > so I would be grateful if someone could verify this on actual hardware. > > I noticed this issue while browsing the coresight code after attending > a technical talk on the subject. This code dates back to the initial > driver submission over 10 years ago, so I was surprised it hadn't been > caught earlier. Although I cannot perform runtime testing, the logic > error seems obvious to me, so I still decided to submit this patch. Nice find. I think the point that it wasn't caught changes how we fix it. Either nobody used it ever - so we can just delete it. Or someone was using it and they expect it to always return a single entry with the value of the last counter and this is a potentially breaking change. So maybe instead of fixing this we should add a new cntr_vals_show() which works correctly. But then again if nobody is using it we shouldn't do that either. The interface isn't even that great, it should be a separate file per counter. You don't want to be parsing strings and colons to try to read a single value, especially in C. Separate files allows you to read it directly without any hassle. > > drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > index 762109307b86..312033e74b7a 100644 > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c > @@ -725,7 +725,7 @@ static ssize_t cntr_val_show(struct device *dev, > if (!coresight_get_mode(drvdata->csdev)) { > spin_lock(&drvdata->spinlock); > for (i = 0; i < drvdata->nr_cntr; i++) > - ret += sprintf(buf, "counter %d: %x\n", > + ret += sprintf(buf + ret, "counter %d: %x\n", > i, config->cntr_val[i]); > spin_unlock(&drvdata->spinlock); > return ret; > @@ -733,7 +733,7 @@ static ssize_t cntr_val_show(struct device *dev, > > for (i = 0; i < drvdata->nr_cntr; i++) { > val = etm_readl(drvdata, ETMCNTVRn(i)); > - ret += sprintf(buf, "counter %d: %x\n", i, val); > + ret += sprintf(buf + ret, "counter %d: %x\n", i, val); > } > > return ret;

11 months

Re: [PATCH -next] coresight: remove unneeded semicolon

by James Clark

On 20/11/2025 9:41 am, Jiapeng Chong wrote: > No functional modification involved. > > ./drivers/hwtracing/coresight/coresight-priv.h:238:2-3: Unneeded semicolon. > > Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=27327 > Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> > --- > drivers/hwtracing/coresight/coresight-priv.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h > index fd896ac07942..16f0cee8cad6 100644 > --- a/drivers/hwtracing/coresight/coresight-priv.h > +++ b/drivers/hwtracing/coresight/coresight-priv.h > @@ -235,7 +235,7 @@ static inline void *coresight_get_uci_data_from_amba(const struct amba_id *table > if ((pid & table->mask) == table->id) > return coresight_get_uci_data(table); > table++; > - }; > + } > return NULL; > } > Reviewed-by: James Clark <james.clark(a)linaro.org> I turned on -Wextra-semi-stmt for Coresight but it results in hundreds warnings because of the way macros like wmb() are always used with a semicolon. So I'm not really sure what the point of fixing these up is? Because they can never all be fixed without a fundamental style change so why not just ignore them? James

11 months

[PATCH v6 00/13] coresight: Update timestamp attribute to be an interval instead of bool

by James Clark

Do some cleanups then expand the timestamp format attribute from 1 bit to 4 bits for ETMv4 in Perf mode. The current interval is too high for most use cases, and particularly on the FVP the number of timestamps generated is excessive. This change not only still allows disabling or enabling timestamps, but also allows the interval to be configured. The old bit is kept deprecated and undocumented for now. There are known broken versions of Perf that don't read the format attribute positions from sysfs and instead hard code the timestamp bit. We can leave the old bit in the driver until we need the bit for another feature or enough time has passed that these old Perfs are unlikely to be used. The interval option is added as an event format attribute, rather than a Coresight config because it's something that the driver is already configuring automatically in Perf mode using any unused counter, so it's not possible to modify this with a config. Applies to coresight/next Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v6: - #ifdef out format attributes for ETMv3 instead of using is_visible(). Then the same block can be used to define format_attr_contextid_show() which avoids an awkward WARN_ONCE() and comments in arm32 for a function that's never called. - Link to v5: https://lore.kernel.org/r/20251118-james-cs-syncfreq-v5-0-82efd7b1a751@lina… Changes in v5: - Add parens to interval calculation in docs (Randy) - Swap "minimum interval" and "maximum interval" in docs. (Leo) - Add TRCSYNCPR.PERIOD to docs (Leo) - Use CONFIG_ARM64 to avoid is_kernel_in_hyp_mode() (Leo) - Add a comment for hidden ETMv3 format attributes (Leo) - Hide configid for ETMv3 (Leo) - Link to v4: https://lore.kernel.org/r/20251112-james-cs-syncfreq-v4-0-165ba21401dc@lina… Changes in v4: - Add #defines for true and false resources ETM_RES_SEL_TRUE/FALSE - Reword comment about finding a counter to say if there are no resources there are no counters. - Extend existing timestamp format attribute instead of adding a new one - Refactor all the config definitions and parsing to use GEN_PMU_FORMAT_ATTR()/ATTR_CFG_GET_FLD() so we can see where the unused bits are. - Link to v3: https://lore.kernel.org/r/20251002-james-cs-syncfreq-v3-0-fe5df2bf91d1@lina… Changes in v3: - Move the format attr definitions to coresight-etm-perf.h we can compile on arm32 without #ifdefs - (Leo) - Convert the new #ifdefs to a single one in an is_visible() function so that the code is cleaner - (Leo) - Drop the change to remove the holes in struct etmv4_config as they were grouped by function - (Mike) - Link to v2: https://lore.kernel.org/r/20250814-james-cs-syncfreq-v2-0-c76fcb87696d@lina… Changes in v2: - Only show the attribute for ETMv4 to improve usability and fix the arm32 build error. Wrapping everything in IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) isn't ideal, but the -perf.c file is shared between ETMv3 and ETMv4, and there is already precedent for doing it this way. - Link to v1: https://lore.kernel.org/r/20250811-james-cs-syncfreq-v1-0-b001cd6e3404@lina… --- James Clark (13): coresight: Change syncfreq to be a u8 coresight: Repack struct etmv4_drvdata coresight: Refactor etm4_config_timestamp_event() coresight: Hide unused ETMv3 format attributes coresight: Define format attributes with GEN_PMU_FORMAT_ATTR() coresight: Interpret ETMv3 config with ATTR_CFG_GET_FLD() coresight: Don't reject unrecognized ETMv3 format attributes coresight: Interpret perf config with ATTR_CFG_GET_FLD() coresight: Interpret ETMv4 config with ATTR_CFG_GET_FLD() coresight: Remove misleading definitions coresight: Extend width of timestamp format attribute coresight: Allow setting the timestamp interval coresight: docs: Document etm4x timestamp interval option Documentation/trace/coresight/coresight.rst | 16 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 68 ++++----- drivers/hwtracing/coresight/coresight-etm-perf.h | 39 +++++ drivers/hwtracing/coresight/coresight-etm3x-core.c | 36 ++--- drivers/hwtracing/coresight/coresight-etm4x-core.c | 164 +++++++++++++-------- drivers/hwtracing/coresight/coresight-etm4x.h | 61 +++++--- include/linux/coresight-pmu.h | 24 --- 7 files changed, 244 insertions(+), 164 deletions(-) --- base-commit: 9e9182cab5ebc3ee7544e60ef08ba19fdf216920 change-id: 20250724-james-cs-syncfreq-7c2257a38ed3 Best regards, -- James Clark <james.clark(a)linaro.org>

11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight