On Thu, Jun 30, 2022 at 05:13:17PM +0700, Bagas Sanjaya wrote:
> Stephen Rothwell reported htmldocs warning:
>
> Documentation/trace/coresight/coresight.rst:133: WARNING: Inline emphasis start-string without end-string.
>
> The warning above is due to unescaped wildcard asterisk (*) on CoreSight
> devicetree binding filename, which confuses Sphinx as emphasis instead.
>
> Escape the wildcard to fix the warning.
>
> Link: https://lore.kernel.org/linux-next/20220630173801.41bf22a2@canb.auug.org.au/
> Fixes: 3c15fddf312120 ("dt-bindings: arm: Convert CoreSight bindings to DT schema")
> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Cc: Mike Leach <mike.leach(a)linaro.org>
> Cc: Leo Yan <leo.yan(a)linaro.org>
> Cc: Jonathan Corbet <corbet(a)lwn.net>
> Cc: Rob Herring <robh(a)kernel.org>
> Cc: coresight(a)lists.linaro.org
> Cc: linux-arm-kernel(a)lists.infradead.org
> Cc: linux-next(a)vger.kernel.org
> Cc: linux-kernel(a)vger.kernel.org
> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
> Signed-off-by: Bagas Sanjaya <bagasdotme(a)gmail.com>
> ---
> Documentation/trace/coresight/coresight.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
> index 529b7c80e6f353..1644a0244ad10a 100644
> --- a/Documentation/trace/coresight/coresight.rst
> +++ b/Documentation/trace/coresight/coresight.rst
> @@ -130,7 +130,7 @@ Misc:
> Device Tree Bindings
> --------------------
>
> -See Documentation/devicetree/bindings/arm/arm,coresight-*.yaml for details.
> +See Documentation/devicetree/bindings/arm/arm,coresight-\*.yaml for details.
>
> As of this writing drivers for ITM, STMs and CTIs are not provided but are
> expected to be added as the solution matures.
>
> base-commit: 6cc11d2a1759275b856e464265823d94aabd5eaf
> --
> An old man doll... just what I always wanted! - Clara
>
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v4:
No functional change - fixed comment in patch header 1/2 and error string format to
remove checkpatch warning as requested by Mathieu.
Changes since v3:
Addressed minor issues raised by Suzuki.
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 298 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 261 insertions(+), 52 deletions(-)
--
2.17.1
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v3:
Addressed minor issues raised by Suzuki.
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 299 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 262 insertions(+), 52 deletions(-)
--
2.17.1
Hi Nick,
Thanks for the rework.
On 23/06/2022 18:41, Nick Desaulniers wrote:
> When the following configs are enabled:
> * CORESIGHT
> * CORESIGHT_SOURCE_ETM4X
> * UBSAN
> * UBSAN_TRAP
>
> Clang fails assemble the kernel with the error:
> <instantiation>:1:7: error: expected constant expression in '.inst' directive
> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
> ^
> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in
> macro instantiation
> etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from
> macro 'etm4x_relaxed_read32'
> read_etm4x_sysreg_offset((offset), false)))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded
> from macro 'read_etm4x_sysreg_offset'
> __val = read_etm4x_sysreg_const_offset((offset)); \
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from
> macro 'read_etm4x_sysreg_const_offset'
> READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from
> macro 'READ_ETM4x_REG'
> read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
> ^
> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro
> 'read_sysreg_s'
> asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
> ^
> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> " mrs_s " v ", " __stringify(r) "\n" \
> ^
>
> Consider the definitions of TRCSSCSRn and TRCCNTVRn:
> drivers/hwtracing/coresight/coresight-etm4x.h:56
> #define TRCCNTVRn(n) (0x160 + (n * 4))
> drivers/hwtracing/coresight/coresight-etm4x.h:81
> #define TRCSSCSRn(n) (0x2A0 + (n * 4))
>
> Where the macro parameter is expanded to i; a loop induction variable
> from etm4_disable_hw.
>
> When any compiler can determine that loops may be unrolled, then the
> __builtin_constant_p check in read_etm4x_sysreg_offset() defined in
> drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
> can lead to the expression `(0x160 + (i * 4))` being passed to
> read_etm4x_sysreg_const_offset. Via the trace above, this is passed
> through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
> is string-ified and used directly in inline asm.
>
> Regardless of which compiler or compiler options determine whether a
> loop can or can't be unrolled, which determines whether
> __builtin_constant_p evaluates to true when passed an expression using a
> loop induction variable, it is NEVER safe to allow the preprocessor to
> construct inline asm like:
> asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
> ^ expected constant expression
>
> Replace unsafe uses of calls to etm4x_relaxed_read32 with
> csdev_access_relaxed_read32 when the parameter is an expression that
> would be invalid inline asm so that it does not depend on the ability of
> the compiler to optimize __builtin_constant_p of the expression to true.
> Only when the second parameter of etm4x_relaxed_read32 expands to an
> expression dependent on a loop induction variable do we need to fix
> this.
>
> For such cases where the induction variable is used in an expression,
> perform the following function call replacements:
> * etm4x_relaxed_write32 -> csdev_access_relaxed_write32
> * etm4x_relaxed_write64 -> csdev_access_relaxed_write64
> * etm4x_relaxed_read32 -> csdev_access_relaxed_read32
> * etm4x_read32 -> csdev_access_read32
> * etm4x_read64 -> csdev_access_read64
>
> This is not a bug in clang; it's a potentially unsafe use of the macro
> arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1310
> Reported-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Tao Zhang <quic_taozha(a)quicinc.com>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Hi Nick
Thanks for resending the patch. Unfortunately, this one still doesn't
address my comments in the v3 [0].
On 14/06/2022 23:02, Nick Desaulniers wrote:
> When the following configs are enabled:
> * CORESIGHT
> * CORESIGHT_SOURCE_ETM4X
> * UBSAN
> * UBSAN_TRAP
>
> Clang fails assemble the kernel with the error:
> <instantiation>:1:7: error: expected constant expression in '.inst' directive
> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
> ^
> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
> etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
> read_etm4x_sysreg_offset((offset), false)))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
> __val = read_etm4x_sysreg_const_offset((offset)); \
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
> READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
> read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
> ^
> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
> asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
> ^
> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> " mrs_s " v ", " __stringify(r) "\n" \
> ^
>
> Consider the definitions of TRCSSCSRn and TRCCNTVRn:
> drivers/hwtracing/coresight/coresight-etm4x.h:56
> #define TRCCNTVRn(n) (0x160 + (n * 4))
> drivers/hwtracing/coresight/coresight-etm4x.h:81
> #define TRCSSCSRn(n) (0x2A0 + (n * 4))
>
> Where the macro parameter is expanded to i; a loop induction variable
> from etm4_disable_hw.
>
> When any compiler can determine that loops may be unrolled, then the
> __builtin_constant_p check in read_etm4x_sysreg_offset() defined in
> drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
> can lead to the expression `(0x160 + (i * 4))` being passed to
> read_etm4x_sysreg_const_offset. Via the trace above, this is passed
> through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
> is string-ified and used directly in inline asm.
>
> Regardless of compiler or compiler options determine whether a loop can
> or can't be unrolled, which determines whether __builtin_constant_p
> evaluates to true when passed an expression using a loop induction
> variable, it is NEVER safe to allow the preprocessor to construction
> inline asm like:
> asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
> ^ expected constant expression
>
> Replace unsafe uses of calls to etm4x_relaxed_read32 with
> csdev_access_read32 when the parameter is an expression that would be
> invalid inline asm so that it does not depend on the ability of the
> compiler to optimize __builtin_constant_p of the expression to true.
> Only when the second parameter of etm4x_relaxed_read32 expands to an
> expression dependent on a loop induction variable do we need to fix
> this.
>
> This is not a bug in clang; it's a potentially unsafe use of the macro
> arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1310
> Suggested-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Tao Zhang <quic_taozha(a)quicinc.com>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
> ---
> V1 (Arnd):
> https://lore.kernel.org/lkml/20210225094324.3542511-1-arnd@kernel.org/
>
> V2 (Arnd):
> https://lore.kernel.org/lkml/20210429145752.3218324-1-arnd@kernel.org/
>
> V3 (Tao):
> https://lore.kernel.org/lkml/1632652550-26048-1-git-send-email-quic_taozha@…
Even with this patch applied, we have many more instances left
to convert. Please could you update the patch to convert all of these ?
$ grep "(i)" coresight-etm4x* | grep -v csdev_
coresight-etm4x-core.c: * Check if TRCSSPCICRn(i) is implemented for a
given instance.
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->seq_ctrl[i], TRCSEQEVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntrldvr[i], TRCCNTRLDVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntr_ctrl[i], TRCCNTCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntr_val[i], TRCCNTVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->res_ctrl[i], TRCRSCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_ctrl[i], TRCSSCCRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_status[i], TRCSSCSRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_pe_cmp[i], TRCSSPCICRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->addr_val[i], TRCACVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->addr_acc[i], TRCACATRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->ctxid_pid[i], TRCCIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->vmid_val[i], TRCVMIDCVRn(i));
coresight-etm4x-core.c: state->trcseqevr[i] = etm4x_read32(csa,
TRCSEQEVRn(i));
coresight-etm4x-core.c: state->trccntrldvr[i] =
etm4x_read32(csa, TRCCNTRLDVRn(i));
coresight-etm4x-core.c: state->trccntctlr[i] = etm4x_read32(csa,
TRCCNTCTLRn(i));
coresight-etm4x-core.c: state->trccntvr[i] = etm4x_read32(csa,
TRCCNTVRn(i));
coresight-etm4x-core.c: state->trcrsctlr[i] = etm4x_read32(csa,
TRCRSCTLRn(i));
coresight-etm4x-core.c: state->trcssccr[i] = etm4x_read32(csa,
TRCSSCCRn(i));
coresight-etm4x-core.c: state->trcsscsr[i] = etm4x_read32(csa,
TRCSSCSRn(i));
coresight-etm4x-core.c: state->trcsspcicr[i] =
etm4x_read32(csa, TRCSSPCICRn(i));
coresight-etm4x-core.c: state->trcacvr[i] = etm4x_read64(csa,
TRCACVRn(i));
coresight-etm4x-core.c: state->trcacatr[i] = etm4x_read64(csa,
TRCACATRn(i));
coresight-etm4x-core.c: state->trccidcvr[i] = etm4x_read64(csa,
TRCCIDCVRn(i));
coresight-etm4x-core.c: state->trcvmidcvr[i] = etm4x_read64(csa,
TRCVMIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcseqevr[i], TRCSEQEVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntrldvr[i], TRCCNTRLDVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntctlr[i], TRCCNTCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntvr[i], TRCCNTVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcrsctlr[i], TRCRSCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcssccr[i], TRCSSCCRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcsscsr[i], TRCSSCSRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcsspcicr[i], TRCSSPCICRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcacvr[i], TRCACVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcacatr[i], TRCACATRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trccidcvr[i], TRCCIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcvmidcvr[i], TRCVMIDCVRn(i));
[0]
https://lore.kernel.org/lkml/48162555-2a67-60bc-ea4b-8720e7b98a22@arm.com/
Kind regards
Suzuki
>
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 87299e99dabb..7c6bd85e36d4 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -836,13 +836,13 @@ static void etm4_disable_hw(void *info)
> /* read the status of the single shot comparators */
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> config->ss_status[i] =
> - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> + csdev_access_read32(csa, TRCSSCSRn(i));
> }
>
> /* read back the current counter values */
> for (i = 0; i < drvdata->nr_cntr; i++) {
> config->cntr_val[i] =
> - etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> + csdev_access_read32(csa, TRCCNTVRn(i));
> }
>
> coresight_disclaim_device_unlocked(csdev);
> @@ -1177,7 +1177,7 @@ static void etm4_init_arch_data(void *info)
> drvdata->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4);
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> drvdata->config.ss_status[i] =
> - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> + csdev_access_read32(csa, TRCSSCSRn(i));
> }
> /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> drvdata->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4);
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 297 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 263 insertions(+), 49 deletions(-)
--
2.17.1
coresight devices track their connections (output connections) and
hold a reference to the fwnode. When a device goes away, we walk through
the devices on the coresight bus and make sure that the references
are dropped. This happens both ways:
a) For all output connections from the device, drop the reference to
the target device via coresight_release_platform_data()
b) Iterate over all the devices on the coresight bus and drop the
reference to fwnode if *this* device is the target of the output
connection, via coresight_remove_conns()->coresight_remove_match().
However, the coresight_remove_match() doesn't clear the fwnode field,
after dropping the reference, this causes use-after-free and
additional refcount drops on the fwnode.
e.g., if we have two devices, A and B, with a connection, A -> B.
If we remove B first, B would clear the reference on B, from A
via coresight_remove_match(). But when A is removed, it still has
a connection with fwnode still pointing to B. Thus it tries to drops
the reference in coresight_release_platform_data(), raising the bells
like :
[ 91.990153] ------------[ cut here ]------------
[ 91.990163] refcount_t: addition on 0; use-after-free.
[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)
crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]
[ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53
[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019
[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144
[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144
[ 91.990496] sp : ffff80000c843640
[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8
[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8
[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2
[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40
[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0
[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375
[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28
[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572
[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027
[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00
[ 91.991000] Call trace:
[ 91.991012] refcount_warn_saturate+0xa0/0x144
[ 91.991034] kobject_get+0xac/0xb0
[ 91.991055] of_node_get+0x2c/0x40
[ 91.991076] of_fwnode_get+0x40/0x60
[ 91.991094] fwnode_handle_get+0x3c/0x60
[ 91.991116] fwnode_get_nth_parent+0xf4/0x110
[ 91.991137] fwnode_full_name_string+0x48/0xc0
[ 91.991158] device_node_string+0x41c/0x530
[ 91.991178] pointer+0x320/0x3ec
[ 91.991198] vsnprintf+0x23c/0x750
[ 91.991217] vprintk_store+0x104/0x4b0
[ 91.991238] vprintk_emit+0x8c/0x360
[ 91.991257] vprintk_default+0x44/0x50
[ 91.991276] vprintk+0xcc/0xf0
[ 91.991295] _printk+0x68/0x90
[ 91.991315] of_node_release+0x13c/0x14c
[ 91.991334] kobject_put+0x98/0x114
[ 91.991354] of_node_put+0x24/0x34
[ 91.991372] of_fwnode_put+0x40/0x5c
[ 91.991390] fwnode_handle_put+0x38/0x50
[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight]
[ 91.991472] coresight_unregister+0x64/0xcc [coresight]
[ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x]
[ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x]
[ 91.991598] amba_remove+0x3c/0x19c
Reproducible by: (Build all coresight components as modules):
#!/bin/sh
while true
do
for m in tmc stm cpu_debug etm4x replicator funnel
do
modprobe coresight_${m}
done
for m in tmc stm cpu_debug etm4x replicator funnel
do
rmmode coresight_${m}
done
done
Cc: stable(a)vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Mike Leach <mike.leach(a)linaro.org>
Cc: Leo Yan <leo.yan(a)linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index ee6ce92ab4c3..1edfec1e9d18 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1424,6 +1424,7 @@ static int coresight_remove_match(struct device *dev, void *data)
* platform data.
*/
fwnode_handle_put(conn->child_fwnode);
+ conn->child_fwnode = NULL;
/* No need to continue */
break;
}
--
2.35.3
[Adding James]
Hi Jiapeng,
On Fri, May 06, 2022 at 05:17:18PM +0800, Jiapeng Chong wrote:
> Clean the following coccicheck warning:
>
> ./tools/perf/util/cs-etm.c:418:34-35: WARNING opportunity for swap().
>
> Reported-by: Abaci Robot <abaci(a)linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com>
> ---
> tools/perf/util/cs-etm.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 8b95fb3c4d7b..0cb555cc766f 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -406,18 +406,13 @@ struct cs_etm_packet_queue
> static void cs_etm__packet_swap(struct cs_etm_auxtrace *etm,
> struct cs_etm_traceid_queue *tidq)
> {
> - struct cs_etm_packet *tmp;
> -
> if (etm->synth_opts.branches || etm->synth_opts.last_branch ||
> - etm->synth_opts.instructions) {
> + etm->synth_opts.instructions)
> /*
> * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
> * the next incoming packet.
> */
> - tmp = tidq->packet;
> - tidq->packet = tidq->prev_packet;
> - tidq->prev_packet = tmp;
Those 3 lines have burned a lot of eyes... As far as I can remember the idea is
simply to make sure that after that point, ->prev_packet is now set to ->packet
in preparation for the next iteration. There is no point in setting ->packet to
->prev_packet. As such the following would work just fine:
tidq->prev_packet = tidq->packet;
... but I will let James and Leo have a final say on that.
> - }
> + swap(tidq->packet, tidq->prev_packet);
If we absolutely need to keep swapping the packets please add the header file
where swap() is found.
Thanks,
Mathieu
> }
>
> static void cs_etm__packet_dump(const char *pkt_string)
> --
> 2.20.1.7.g153144c
>
Any loaded configurations must be correctly unloaded on coresight module
exit, or issues can arise with nested locking in the configfs directory
code if built with CONFIG_LOCKDEP.
Prior to this patch, the preloaded configuration configfs directory entries
were being unloaded by the recursive code in
configfs_unregister_subsystem().
However, when built with CONFIG_LOCKDEP, this caused a nested lock warning,
which was not mitigated by the LOCKDEP dependent code in fs/configfs/dir.c
designed to prevent this, due to the different directory levels for the
root of the directory being removed.
As the preloaded (and all other) configurations are registered after
configfs_register_subsystem(), we now explicitly unload them before the
call to configfs_unregister_subsystem().
The new routine cscfg_unload_cfgs_on_exit() iterates through the load
owner list to unload any remaining configurations that were not unloaded
by the user before the module exits. This covers both the
CSCFG_OWNER_PRELOAD and CSCFG_OWNER_MODULE owner types, and will be
extended to cover future load owner types for CoreSight configurations.
Applies to coresight/next
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
---
Changes since v1:
Altered ordering of init of cscfg_mgr to ensure lists valid for
potential exit path on error.
---
.../hwtracing/coresight/coresight-syscfg.c | 72 ++++++++++++++++---
1 file changed, 61 insertions(+), 11 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 11850fd8c3b5..050a32f7e439 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -1042,6 +1042,13 @@ static int cscfg_create_device(void)
if (!cscfg_mgr)
goto create_dev_exit_unlock;
+ /* initialise the cscfg_mgr structure */
+ INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
+ INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
+ INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
+ INIT_LIST_HEAD(&cscfg_mgr->load_order_list);
+ atomic_set(&cscfg_mgr->sys_active_cnt, 0);
+
/* setup the device */
dev = cscfg_device();
dev->release = cscfg_dev_release;
@@ -1056,14 +1063,61 @@ static int cscfg_create_device(void)
return err;
}
-static void cscfg_clear_device(void)
+/*
+ * Loading and unloading is generally on user discretion.
+ * If exiting due to coresight module unload, we need to unload any configurations that remain,
+ * before we unregister the configfs intrastructure.
+ *
+ * Do this by walking the load_owner list and taking appropriate action, depending on the load
+ * owner type.
+ *
+ * called with the cscfg_mutex held
+ */
+
+#define LOADABLE_MOD_ERR "cscfg: ERROR - a loadable module failed to unload configs on exit\n"
+
+static void cscfg_unload_cfgs_on_exit(void)
{
- struct cscfg_config_desc *cfg_desc;
+ struct cscfg_load_owner_info *owner_info = NULL;
- mutex_lock(&cscfg_mutex);
- list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
- etm_perf_del_symlink_cscfg(cfg_desc);
+ while (!list_empty(&cscfg_mgr->load_order_list)) {
+
+ /* remove in reverse order of loading */
+ owner_info = list_last_entry(&cscfg_mgr->load_order_list,
+ struct cscfg_load_owner_info, item);
+
+ /* action according to type */
+ switch (owner_info->type) {
+ case CSCFG_OWNER_PRELOAD:
+ /*
+ * preloaded descriptors are statically allocated in
+ * this module - just need to unload dynamic items from
+ * csdev lists, and remove from configfs directories.
+ */
+ pr_info("cscfg: unloading preloaded configurations\n");
+ cscfg_unload_owned_cfgs_feats(owner_info);
+ break;
+
+ case CSCFG_OWNER_MODULE:
+ /*
+ * this is an error - the loadable module must have been unloaded prior
+ * to the coresight module unload. Therefore that module has not
+ * correctly unloaded configs in its own exit code.
+ * Nothing to do other than emit an error string.
+ */
+ pr_err(LOADABLE_MOD_ERR);
+ break;
+ }
+
+ /* remove from load order list */
+ list_del(&owner_info->item);
}
+}
+
+static void cscfg_clear_device(void)
+{
+ mutex_lock(&cscfg_mutex);
+ cscfg_unload_cfgs_on_exit();
cscfg_configfs_release(cscfg_mgr);
device_unregister(cscfg_device());
mutex_unlock(&cscfg_mutex);
@@ -1074,20 +1128,16 @@ int __init cscfg_init(void)
{
int err = 0;
+ /* create the device and init cscfg_mgr */
err = cscfg_create_device();
if (err)
return err;
+ /* initialise configfs subsystem */
err = cscfg_configfs_init(cscfg_mgr);
if (err)
goto exit_err;
- INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
- INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
- INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
- INIT_LIST_HEAD(&cscfg_mgr->load_order_list);
- atomic_set(&cscfg_mgr->sys_active_cnt, 0);
-
/* preload built-in configurations */
err = cscfg_preload(THIS_MODULE);
if (err)
--
2.17.1