July 2025 - Linux-stable-mirror

[PATCH v1] arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on

by Francesco Dolcini

From: Francesco Dolcini <francesco.dolcini(a)toradex.com> LDO5 regulator is used to power the i.MX8MM NVCC_SD2 I/O supply, that is used for the SD2 card interface and also for some GPIOs. When the SD card interface is not enabled the regulator subsystem could turn off this supply, since it is not used anywhere else, however this will also remove the power to some other GPIOs, for example one I/O that is used to power the ethernet phy, leading to a non working ethernet interface. [ 31.820515] On-module +V3.3_1.8_SD (LDO5): disabling [ 31.821761] PMIC_USDHC_VSELECT: disabling [ 32.764949] fec 30be0000.ethernet end0: Link is Down Fix this keeping the LDO5 supply always on. Cc: stable(a)vger.kernel.org Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Fixes: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> --- arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi index d29710772569..1594ce9182a5 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi @@ -464,6 +464,7 @@ reg_vdd_phy: LDO4 { }; reg_nvcc_sd: LDO5 { + regulator-always-on; regulator-max-microvolt = <3300000>; regulator-min-microvolt = <1800000>; regulator-name = "On-module +V3.3_1.8_SD (LDO5)"; -- 2.39.5

5 months, 3 weeks

3
2
0 0

[PATCH] crypto: s390/sha - Fix uninitialized variable in SHA-1 and SHA-2

by Eric Biggers

Commit 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements") added the field s390_sha_ctx::first_message_part and made it be used by s390_sha_update_blocks(). At the time, s390_sha_update_blocks() was used by all the s390 SHA-1, SHA-2, and SHA-3 algorithms. However, only the initialization functions for SHA-3 were updated, leaving SHA-1 and SHA-2 using first_message_part uninitialized. This could cause e.g. CPACF_KIMD_SHA_512 | CPACF_KIMD_NIP to be used instead of just CPACF_KIMD_NIP. It's unclear why this didn't cause a problem earlier; this bug was found only when UBSAN detected the uninitialized boolean. Perhaps the CPU ignores CPACF_KIMD_NIP for SHA-1 and SHA-2. Regardless, let's fix this. For now just initialize to false, i.e. don't try to "optimize" the SHA state initialization. Note: in 6.16, we need to patch SHA-1, SHA-384, and SHA-512. In 6.15 and earlier, we'll also need to patch SHA-224 and SHA-256, as they hadn't yet been librarified (which incidentally fixed this bug). Fixes: 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements") Cc: stable(a)vger.kernel.org Reported-by: Ingo Franzki <ifranzki(a)linux.ibm.com> Closes: https://lore.kernel.org/r/12740696-595c-4604-873e-aefe8b405fbf@linux.ibm.com Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- This is targeting 6.16. I'd prefer to take this through libcrypto-fixes, since the librarification work is also touching this area. But let me know if there's a preference for the crypto tree or the s390 tree instead. arch/s390/crypto/sha1_s390.c | 1 + arch/s390/crypto/sha512_s390.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/s390/crypto/sha1_s390.c b/arch/s390/crypto/sha1_s390.c index d229cbd2ba229..73672e76a88f9 100644 --- a/arch/s390/crypto/sha1_s390.c +++ b/arch/s390/crypto/sha1_s390.c @@ -36,10 +36,11 @@ static int s390_sha1_init(struct shash_desc *desc) sctx->state[2] = SHA1_H2; sctx->state[3] = SHA1_H3; sctx->state[4] = SHA1_H4; sctx->count = 0; sctx->func = CPACF_KIMD_SHA_1; + sctx->first_message_part = false; return 0; } static int s390_sha1_export(struct shash_desc *desc, void *out) diff --git a/arch/s390/crypto/sha512_s390.c b/arch/s390/crypto/sha512_s390.c index 33711a29618c3..e9e112025ff22 100644 --- a/arch/s390/crypto/sha512_s390.c +++ b/arch/s390/crypto/sha512_s390.c @@ -30,10 +30,11 @@ static int sha512_init(struct shash_desc *desc) ctx->sha512.state[6] = SHA512_H6; ctx->sha512.state[7] = SHA512_H7; ctx->count = 0; ctx->sha512.count_hi = 0; ctx->func = CPACF_KIMD_SHA_512; + ctx->first_message_part = false; return 0; } static int sha512_export(struct shash_desc *desc, void *out) @@ -95,10 +96,11 @@ static int sha384_init(struct shash_desc *desc) ctx->sha512.state[6] = SHA384_H6; ctx->sha512.state[7] = SHA384_H7; ctx->count = 0; ctx->sha512.count_hi = 0; ctx->func = CPACF_KIMD_SHA_512; + ctx->first_message_part = false; return 0; } static struct shash_alg sha384_alg = { base-commit: e540341508ce2f6e27810106253d5de194b66750 -- 2.50.0

5 months, 3 weeks

3
8
0 0

[PATCH 5/5] lib/crypto: x86/poly1305: Fix performance regression on short messages

by Eric Biggers

Restore the len >= 288 condition on using the AVX implementation, which was incidentally removed by commit 318c53ae02f2 ("crypto: x86/poly1305 - Add block-only interface"). This check took into account the overhead in key power computation, kernel-mode "FPU", and tail handling associated with the AVX code. Indeed, restoring this check slightly improves performance for len < 256 as measured using poly1305_kunit on an "AMD Ryzen AI 9 365" (Zen 5) CPU: Length Before After ====== ========== ========== 1 30 MB/s 36 MB/s 16 516 MB/s 598 MB/s 64 1700 MB/s 1882 MB/s 127 2265 MB/s 2651 MB/s 128 2457 MB/s 2827 MB/s 200 2702 MB/s 3238 MB/s 256 3841 MB/s 3768 MB/s 511 4580 MB/s 4585 MB/s 512 5430 MB/s 5398 MB/s 1024 7268 MB/s 7305 MB/s 3173 8999 MB/s 8948 MB/s 4096 9942 MB/s 9921 MB/s 16384 10557 MB/s 10545 MB/s While the optimal threshold for this CPU might be slightly lower than 288 (see the len == 256 case), other CPUs would need to be tested too, and these sorts of benchmarks can underestimate the true cost of kernel-mode "FPU". Therefore, for now just restore the 288 threshold. Fixes: 318c53ae02f2 ("crypto: x86/poly1305 - Add block-only interface") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- lib/crypto/x86/poly1305_glue.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/crypto/x86/poly1305_glue.c b/lib/crypto/x86/poly1305_glue.c index 968d84677631..856d48fd422b 100644 --- a/lib/crypto/x86/poly1305_glue.c +++ b/lib/crypto/x86/poly1305_glue.c @@ -96,11 +96,19 @@ void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *inp, /* SIMD disables preemption, so relax after processing each page. */ BUILD_BUG_ON(SZ_4K < POLY1305_BLOCK_SIZE || SZ_4K % POLY1305_BLOCK_SIZE); + /* + * The AVX implementations have significant setup overhead (e.g. key + * power computation, kernel FPU enabling) which makes them slower for + * short messages. Fall back to the scalar implementation for messages + * shorter than 288 bytes, unless the AVX-specific key setup has already + * been performed (indicated by ctx->is_base2_26). + */ if (!static_branch_likely(&poly1305_use_avx) || + (len < POLY1305_BLOCK_SIZE * 18 && !ctx->is_base2_26) || unlikely(!irq_fpu_usable())) { convert_to_base2_64(ctx); poly1305_blocks_x86_64(ctx, inp, len, padbit); return; } -- 2.50.0

5 months, 3 weeks

1
0
0 0

[PATCH 4/5] lib/crypto: x86/poly1305: Fix register corruption in no-SIMD contexts

by Eric Biggers

Restore the SIMD usability check and base conversion that were removed by commit 318c53ae02f2 ("crypto: x86/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions *should* be called only where SIMD registers are usable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use irq_fpu_usable() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: 318c53ae02f2 ("crypto: x86/poly1305 - Add block-only interface") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- lib/crypto/x86/poly1305_glue.c | 40 +++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/lib/crypto/x86/poly1305_glue.c b/lib/crypto/x86/poly1305_glue.c index b7e78a583e07..968d84677631 100644 --- a/lib/crypto/x86/poly1305_glue.c +++ b/lib/crypto/x86/poly1305_glue.c @@ -23,10 +23,46 @@ struct poly1305_arch_internal { u64 r[2]; u64 pad; struct { u32 r2, r1, r4, r3; } rn[9]; }; +/* + * The AVX code uses base 2^26, while the scalar code uses base 2^64. If we hit + * the unfortunate situation of using AVX and then having to go back to scalar + * -- because the user is silly and has called the update function from two + * separate contexts -- then we need to convert back to the original base before + * proceeding. It is possible to reason that the initial reduction below is + * sufficient given the implementation invariants. However, for an avoidance of + * doubt and because this is not performance critical, we do the full reduction + * anyway. Z3 proof of below function: https://xn--4db.cc/ltPtHCKN/py + */ +static void convert_to_base2_64(void *ctx) +{ + struct poly1305_arch_internal *state = ctx; + u32 cy; + + if (!state->is_base2_26) + return; + + cy = state->h[0] >> 26; state->h[0] &= 0x3ffffff; state->h[1] += cy; + cy = state->h[1] >> 26; state->h[1] &= 0x3ffffff; state->h[2] += cy; + cy = state->h[2] >> 26; state->h[2] &= 0x3ffffff; state->h[3] += cy; + cy = state->h[3] >> 26; state->h[3] &= 0x3ffffff; state->h[4] += cy; + state->hs[0] = ((u64)state->h[2] << 52) | ((u64)state->h[1] << 26) | state->h[0]; + state->hs[1] = ((u64)state->h[4] << 40) | ((u64)state->h[3] << 14) | (state->h[2] >> 12); + state->hs[2] = state->h[4] >> 24; + /* Unsigned Less Than: branchlessly produces 1 if a < b, else 0. */ +#define ULT(a, b) ((a ^ ((a ^ b) | ((a - b) ^ b))) >> (sizeof(a) * 8 - 1)) + cy = (state->hs[2] >> 2) + (state->hs[2] & ~3ULL); + state->hs[2] &= 3; + state->hs[0] += cy; + state->hs[1] += (cy = ULT(state->hs[0], cy)); + state->hs[2] += ULT(state->hs[1], cy); +#undef ULT + state->is_base2_26 = 0; +} + asmlinkage void poly1305_block_init_arch( struct poly1305_block_state *state, const u8 raw_key[POLY1305_BLOCK_SIZE]); EXPORT_SYMBOL_GPL(poly1305_block_init_arch); asmlinkage void poly1305_blocks_x86_64(struct poly1305_arch_internal *ctx, @@ -60,11 +96,13 @@ void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *inp, /* SIMD disables preemption, so relax after processing each page. */ BUILD_BUG_ON(SZ_4K < POLY1305_BLOCK_SIZE || SZ_4K % POLY1305_BLOCK_SIZE); - if (!static_branch_likely(&poly1305_use_avx)) { + if (!static_branch_likely(&poly1305_use_avx) || + unlikely(!irq_fpu_usable())) { + convert_to_base2_64(ctx); poly1305_blocks_x86_64(ctx, inp, len, padbit); return; } do { -- 2.50.0

5 months, 3 weeks

1
0
0 0

[PATCH 3/5] lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts

by Eric Biggers

Restore the SIMD usability check that was removed by commit a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions *should* be called only where SIMD registers are usable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- lib/crypto/arm64/poly1305-glue.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/crypto/arm64/poly1305-glue.c b/lib/crypto/arm64/poly1305-glue.c index c9a74766785b..31aea21ce42f 100644 --- a/lib/crypto/arm64/poly1305-glue.c +++ b/lib/crypto/arm64/poly1305-glue.c @@ -5,10 +5,11 @@ * Copyright (C) 2019 Linaro Ltd. <ard.biesheuvel(a)linaro.org> */ #include <asm/hwcap.h> #include <asm/neon.h> +#include <asm/simd.h> #include <crypto/internal/poly1305.h> #include <linux/cpufeature.h> #include <linux/jump_label.h> #include <linux/kernel.h> #include <linux/module.h> @@ -31,11 +32,11 @@ static __ro_after_init DEFINE_STATIC_KEY_FALSE(have_neon); void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src, unsigned int len, u32 padbit) { len = round_down(len, POLY1305_BLOCK_SIZE); - if (static_branch_likely(&have_neon)) { + if (static_branch_likely(&have_neon) && likely(may_use_simd())) { do { unsigned int todo = min_t(unsigned int, len, SZ_4K); kernel_neon_begin(); poly1305_blocks_neon(state, src, todo, padbit); -- 2.50.0

5 months, 3 weeks

1
0
0 0

[PATCH 2/5] lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts

by Eric Biggers

Restore the SIMD usability check that was removed by commit 773426f4771b ("crypto: arm/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions *should* be called only where SIMD registers are usable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: 773426f4771b ("crypto: arm/poly1305 - Add block-only interface") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- lib/crypto/arm/poly1305-glue.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/crypto/arm/poly1305-glue.c b/lib/crypto/arm/poly1305-glue.c index 5b65b840c166..2d86c78af883 100644 --- a/lib/crypto/arm/poly1305-glue.c +++ b/lib/crypto/arm/poly1305-glue.c @@ -5,10 +5,11 @@ * Copyright (C) 2019 Linaro Ltd. <ard.biesheuvel(a)linaro.org> */ #include <asm/hwcap.h> #include <asm/neon.h> +#include <asm/simd.h> #include <crypto/internal/poly1305.h> #include <linux/cpufeature.h> #include <linux/jump_label.h> #include <linux/kernel.h> #include <linux/module.h> @@ -32,11 +33,11 @@ static __ro_after_init DEFINE_STATIC_KEY_FALSE(have_neon); void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src, unsigned int len, u32 padbit) { len = round_down(len, POLY1305_BLOCK_SIZE); if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON) && - static_branch_likely(&have_neon)) { + static_branch_likely(&have_neon) && likely(may_use_simd())) { do { unsigned int todo = min_t(unsigned int, len, SZ_4K); kernel_neon_begin(); poly1305_blocks_neon(state, src, todo, padbit); -- 2.50.0

5 months, 3 weeks

1
0
0 0

[REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"

by Matthew Schwartz

Hello, I installed kernel 6.15.4 to find that my battery estimate on my handheld gaming device was completely inaccurate, instead giving negative values and an unknown estimated battery life in multiple places. After bisecting, I landed on "ACPI: battery: negate current when discharging” as the bad commit. This commit breaks not one but several userspace implementations of battery monitoring: Steam and MangoHud. Perhaps it breaks more, but those are the two I have noticed so far. Thanks, Matthew Schwartz

5 months, 3 weeks

5
6
0 0

+ samples-damon-mtier-support-boot-time-enable-setup.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: samples/damon/mtier: support boot time enable setup has been added to the -mm mm-new branch. Its filename is samples-damon-mtier-support-boot-time-enable-setup.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: samples/damon/mtier: support boot time enable setup Date: Sun, 6 Jul 2025 12:32:04 -0700 If 'enable' parameter of the 'mtier' DAMON sample module is set at boot time via the kernel command line, memory allocation is tried before the slab is initialized. As a result kernel NULL pointer dereference BUG can happen. Fix it by checking the initialization status. Link: https://lkml.kernel.org/r/20250706193207.39810-4-sj@kernel.org Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- samples/damon/mtier.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/samples/damon/mtier.c~samples-damon-mtier-support-boot-time-enable-setup +++ a/samples/damon/mtier.c @@ -157,6 +157,8 @@ static void damon_sample_mtier_stop(void damon_destroy_ctx(ctxs[1]); } +static bool init_called; + static int damon_sample_mtier_enable_store( const char *val, const struct kernel_param *kp) { @@ -170,6 +172,9 @@ static int damon_sample_mtier_enable_sto if (enable == enabled) return 0; + if (!init_called) + return 0; + if (enable) { err = damon_sample_mtier_start(); if (err) @@ -182,6 +187,14 @@ static int damon_sample_mtier_enable_sto static int __init damon_sample_mtier_init(void) { + int err = 0; + + init_called = true; + if (enable) { + err = damon_sample_mtier_start(); + if (err) + enable = false; + } return 0; } _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-core-handle-damon_call_control-as-normal-under-kdmond-deactivation.patch mm-damon-introduce-damon_stat-module.patch mm-damon-introduce-damon_stat-module-fix.patch mm-damon-stat-calculate-and-expose-estimated-memory-bandwidth.patch mm-damon-stat-calculate-and-expose-idle-time-percentiles.patch docs-admin-guide-mm-damon-add-damon_stat-usage-document.patch mm-damon-paddr-use-alloc_migartion_target-with-no-migration-fallback-nodemask.patch revert-mm-rename-alloc_demote_folio-to-alloc_migrate_folio.patch revert-mm-make-alloc_demote_folio-externally-invokable-for-migration.patch selftets-damon-add-a-test-for-memcg_path-leak.patch mm-damon-sysfs-schemes-decouple-from-damos_quota_goal_metric.patch mm-damon-sysfs-schemes-decouple-from-damos_action.patch mm-damon-sysfs-schemes-decouple-from-damos_wmark_metric.patch mm-damon-sysfs-schemes-decouple-from-damos_filter_type.patch mm-damon-sysfs-decouple-from-damon_ops_id.patch selftests-damon-add-drgn-script-for-extracting-damon-status.patch selftests-damon-_damon_sysfs-set-kdamondpid-in-start.patch selftests-damon-add-python-and-drgn-based-damon-sysfs-test.patch selftests-damon-sysfspy-test-monitoring-attribute-parameters.patch selftests-damon-sysfspy-test-adaptive-targets-parameter.patch selftests-damon-sysfspy-test-damos-schemes-parameters-setup.patch mm-damon-add-trace-event-for-auto-tuned-monitoring-intervals.patch mm-damon-add-trace-event-for-effective-size-quota.patch samples-damon-wsse-fix-boot-time-enable-handling.patch samples-damon-prcl-fix-boot-time-enable-crash.patch samples-damon-mtier-support-boot-time-enable-setup.patch mm-damon-reclaim-reset-enabled-when-damon-start-failed.patch mm-damon-lru_sort-reset-enabled-when-damon-start-failed.patch mm-damon-reclaim-use-parameter-context-correctly.patch

5 months, 3 weeks

1
0
0 0

+ samples-damon-wsse-fix-boot-time-enable-handling.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: samples/damon/wsse: fix boot time enable handling has been added to the -mm mm-new branch. Its filename is samples-damon-wsse-fix-boot-time-enable-handling.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: samples/damon/wsse: fix boot time enable handling Date: Sun, 6 Jul 2025 12:32:02 -0700 Patch series "mm/damon: fix misc bugs in DAMON modules". From manual code review, I found below bugs in DAMON modules. DAMON sample modules crash if those are enabled at boot time, via kernel command line. A similar issue was found and fixed on DAMON non-sample modules in the past, but we didn't check that for sample modules. DAMON non-sample modules are not setting 'enabled' parameters accordingly when real enabling is failed. Honggyu found and fixed[1] this type of bugs in DAMON sample modules, and my inspection was motivated by the great work. Kudos to Honggyu. Finally, DAMON_RECLIAM is mistakenly losing scheme internal status due to misuse of damon_commit_ctx(). DAMON_LRU_SORT has a similar misuse, but fortunately it is not causing real status loss. Fix the bugs. Since these are similar patterns of bugs that were found in the past, it would be better to add tests or refactor the code, in future. This patch (of 6): If 'enable' parameter of the 'wsse' DAMON sample module is set at boot time via the kernel command line, memory allocation is tried before the slab is initialized. As a result kernel NULL pointer dereference BUG can happen. Fix it by checking the initialization status. Link: https://lkml.kernel.org/r/20250706193207.39810-1-sj@kernel.org Link: https://lkml.kernel.org/r/20250706193207.39810-2-sj@kernel.org Link: https://lore.kernel.org/20250702000205.1921-1-honggyu.kim@sk.com [1] Fixes: b757c6cfc696 ("samples/damon/wsse: start and stop DAMON as the user requests") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- samples/damon/wsse.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) --- a/samples/damon/wsse.c~samples-damon-wsse-fix-boot-time-enable-handling +++ a/samples/damon/wsse.c @@ -89,6 +89,8 @@ static void damon_sample_wsse_stop(void) put_pid(target_pidp); } +static bool init_called; + static int damon_sample_wsse_enable_store( const char *val, const struct kernel_param *kp) { @@ -103,6 +105,9 @@ static int damon_sample_wsse_enable_stor return 0; if (enable) { + if (!init_called) + return 0; + err = damon_sample_wsse_start(); if (err) enable = false; @@ -114,7 +119,15 @@ static int damon_sample_wsse_enable_stor static int __init damon_sample_wsse_init(void) { - return 0; + int err = 0; + + init_called = true; + if (enable) { + err = damon_sample_wsse_start(); + if (err) + enable = false; + } + return err; } module_init(damon_sample_wsse_init); _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-core-handle-damon_call_control-as-normal-under-kdmond-deactivation.patch mm-damon-introduce-damon_stat-module.patch mm-damon-introduce-damon_stat-module-fix.patch mm-damon-stat-calculate-and-expose-estimated-memory-bandwidth.patch mm-damon-stat-calculate-and-expose-idle-time-percentiles.patch docs-admin-guide-mm-damon-add-damon_stat-usage-document.patch mm-damon-paddr-use-alloc_migartion_target-with-no-migration-fallback-nodemask.patch revert-mm-rename-alloc_demote_folio-to-alloc_migrate_folio.patch revert-mm-make-alloc_demote_folio-externally-invokable-for-migration.patch selftets-damon-add-a-test-for-memcg_path-leak.patch mm-damon-sysfs-schemes-decouple-from-damos_quota_goal_metric.patch mm-damon-sysfs-schemes-decouple-from-damos_action.patch mm-damon-sysfs-schemes-decouple-from-damos_wmark_metric.patch mm-damon-sysfs-schemes-decouple-from-damos_filter_type.patch mm-damon-sysfs-decouple-from-damon_ops_id.patch selftests-damon-add-drgn-script-for-extracting-damon-status.patch selftests-damon-_damon_sysfs-set-kdamondpid-in-start.patch selftests-damon-add-python-and-drgn-based-damon-sysfs-test.patch selftests-damon-sysfspy-test-monitoring-attribute-parameters.patch selftests-damon-sysfspy-test-adaptive-targets-parameter.patch selftests-damon-sysfspy-test-damos-schemes-parameters-setup.patch mm-damon-add-trace-event-for-auto-tuned-monitoring-intervals.patch mm-damon-add-trace-event-for-effective-size-quota.patch samples-damon-wsse-fix-boot-time-enable-handling.patch samples-damon-prcl-fix-boot-time-enable-crash.patch samples-damon-mtier-support-boot-time-enable-setup.patch mm-damon-reclaim-reset-enabled-when-damon-start-failed.patch mm-damon-lru_sort-reset-enabled-when-damon-start-failed.patch mm-damon-reclaim-use-parameter-context-correctly.patch

5 months, 3 weeks

1
0
0 0

[PATCH 0/6] mm/damon: fix misc bugs in DAMON modules

by SeongJae Park

From manual code review, I found below bugs in DAMON modules. DAMON sample modules crash if those are enabled at boot time, via kernel command line. A similar issue was found and fixed on DAMON non-sample modules in the past, but we didn't check that for sample modules. DAMON non-sample modules are not setting 'enabled' parameters accordingly when real enabling is failed. Honggyu found and fixed[1] this type of bugs in DAMON sample modules, and my inspection was motivated by the great work. Kudos to Honggyu. Finally, DAMON_RECLIAM is mistakenly losing scheme internal status due to misuse of damon_commit_ctx(). DAMON_LRU_SORT has a similar misuse, but fortunately it is not causing real status loss. Fix the bugs. Since these are similar patterns of bugs that were found in the past, it would be better to add tests or refactor the code, in future. Note that the fix of the second bug for DAMON_STAT is sent separately[2], since it is a fix for a bug in mm-unstable tree at the moment. Also as mentioned above, DAMON_LRU_SORT also has a misuse of damon_commit_ctx(), but it is not causing a real issue, hence the fix is not included in this series. I will post it later. [1] https://lore.kernel.org/20250702000205.1921-1-honggyu.kim@sk.com [2] https://lore.kernel.org/20250706184750.36588-1-sj@kernel.org SeongJae Park (6): samples/damon/wsse: fix boot time enable handling samples/damon/prcl: fix boot time enable crash samples/damon/mtier: support boot time enable setup mm/damon/reclaim: reset enabled when DAMON start failed mm/damon/lru_sort: reset enabled when DAMON start failed mm/damon/reclaim: use parameter context correctly mm/damon/lru_sort.c | 5 ++++- mm/damon/reclaim.c | 9 ++++++--- samples/damon/mtier.c | 13 +++++++++++++ samples/damon/prcl.c | 13 +++++++++++++ samples/damon/wsse.c | 15 ++++++++++++++- 5 files changed, 50 insertions(+), 5 deletions(-) base-commit: a555ad24c884e9f4ee2f2a0184f5b7b89c8d4a6e -- 2.39.5

5 months, 3 weeks

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025