From: Greg Kroah-Hartman Date: Sat, 9 Nov 2024 15:41:07 +0000 (+0100) Subject: 6.11-stable patches X-Git-Tag: v5.15.172~47 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2c95bff4f8444003a6fec425f8f6de708b750e6d;p=thirdparty%2Fkernel%2Fstable-queue.git 6.11-stable patches added patches: arm64-kconfig-make-sme-depend-on-broken-for-now.patch arm64-smccc-remove-broken-support-for-smcccv1.3-sve-discard-hint.patch arm64-sve-discard-stale-cpu-state-when-handling-sve-traps.patch btrfs-fix-per-subvolume-ro-rw-flags-with-new-mount-api.patch btrfs-fix-the-length-of-reserved-qgroup-to-free.patch btrfs-reinitialize-delayed-ref-list-after-deleting-it-from-the-list.patch idpf-avoid-vport-access-in-idpf_get_link_ksettings.patch idpf-fix-idpf_vc_core_init-error-path.patch kvm-ppc-book3s-hv-mask-off-lpcr_mer-for-a-vcpu-before-running-it-to-avoid-spurious-interrupts.patch mm-slab-fix-warning-caused-by-duplicate-kmem_cache-creation-in-kmem_buckets_create.patch mptcp-use-sock_kfree_s-instead-of-kfree.patch net-vertexcom-mse102x-fix-possible-double-free-of-tx-skb.patch net-wwan-t7xx-fix-off-by-one-error-in-t7xx_dpmaif_rx_buf_alloc.patch nfs-fix-kmsan-warning-in-decode_getfattr_attrs.patch scsi-ufs-core-start-the-rtc-update-work-later.patch tracing-fix-tracefs-mount-options.patch --- diff --git a/queue-6.11/arm64-kconfig-make-sme-depend-on-broken-for-now.patch b/queue-6.11/arm64-kconfig-make-sme-depend-on-broken-for-now.patch new file mode 100644 index 00000000000..4c8ad97f9c8 --- /dev/null +++ b/queue-6.11/arm64-kconfig-make-sme-depend-on-broken-for-now.patch @@ -0,0 +1,46 @@ +From 81235ae0c846e1fb46a2c6fe9283fe2b2b24f7dc Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Wed, 6 Nov 2024 16:42:20 +0000 +Subject: arm64: Kconfig: Make SME depend on BROKEN for now + +From: Mark Rutland + +commit 81235ae0c846e1fb46a2c6fe9283fe2b2b24f7dc upstream. + +Although support for SME was merged in v5.19, we've since uncovered a +number of issues with the implementation, including issues which might +corrupt the FPSIMD/SVE/SME state of arbitrary tasks. While there are +patches to address some of these issues, ongoing review has highlighted +additional functional problems, and more time is necessary to analyse +and fix these. + +For now, mark SME as BROKEN in the hope that we can fix things properly +in the near future. As SME is an OPTIONAL part of ARMv9.2+, and there is +very little extant hardware, this should not adversely affect the vast +majority of users. + +Signed-off-by: Mark Rutland +Cc: Ard Biesheuvel +Cc: Catalin Marinas +Cc: Marc Zyngier +Cc: Mark Brown +Cc: Will Deacon +Cc: stable@vger.kernel.org # 5.19 +Acked-by: Catalin Marinas +Link: https://lore.kernel.org/r/20241106164220.2789279-1-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/Kconfig ++++ b/arch/arm64/Kconfig +@@ -2173,6 +2173,7 @@ config ARM64_SME + bool "ARM Scalable Matrix Extension support" + default y + depends on ARM64_SVE ++ depends on BROKEN + help + The Scalable Matrix Extension (SME) is an extension to the AArch64 + execution state which utilises a substantial subset of the SVE diff --git a/queue-6.11/arm64-smccc-remove-broken-support-for-smcccv1.3-sve-discard-hint.patch b/queue-6.11/arm64-smccc-remove-broken-support-for-smcccv1.3-sve-discard-hint.patch new file mode 100644 index 00000000000..d5f939ba3bd --- /dev/null +++ b/queue-6.11/arm64-smccc-remove-broken-support-for-smcccv1.3-sve-discard-hint.patch @@ -0,0 +1,227 @@ +From 8c462d56487e3abdbf8a61cedfe7c795a54f4a78 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Wed, 6 Nov 2024 16:04:48 +0000 +Subject: arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint + +From: Mark Rutland + +commit 8c462d56487e3abdbf8a61cedfe7c795a54f4a78 upstream. + +SMCCCv1.3 added a hint bit which callers can set in an SMCCC function ID +(AKA "FID") to indicate that it is acceptable for the SMCCC +implementation to discard SVE and/or SME state over a specific SMCCC +call. The kernel support for using this hint is broken and SMCCC calls +may clobber the SVE and/or SME state of arbitrary tasks, though FPSIMD +state is unaffected. + +The kernel support is intended to use the hint when there is no SVE or +SME state to save, and to do this it checks whether TIF_FOREIGN_FPSTATE +is set or TIF_SVE is clear in assembly code: + +| ldr , [, #TSK_TI_FLAGS] +| tbnz , #TIF_FOREIGN_FPSTATE, 1f // Any live FP state? +| tbnz , #TIF_SVE, 2f // Does that state include SVE? +| +| 1: orr , , ARM_SMCCC_1_3_SVE_HINT +| 2: +| << SMCCC call using FID >> + +This is not safe as-is: + +(1) SMCCC calls can be made in a preemptible context and preemption can + result in TIF_FOREIGN_FPSTATE being set or cleared at arbitrary + points in time. Thus checking for TIF_FOREIGN_FPSTATE provides no + guarantee. + +(2) TIF_FOREIGN_FPSTATE only indicates that the live FP/SVE/SME state in + the CPU does not belong to the current task, and does not indicate + that clobbering this state is acceptable. + + When the live CPU state is clobbered it is necessary to update + fpsimd_last_state.st to ensure that a subsequent context switch will + reload FP/SVE/SME state from memory rather than consuming the + clobbered state. This and the SMCCC call itself must happen in a + critical section with preemption disabled to avoid races. + +(3) Live SVE/SME state can exist with TIF_SVE clear (e.g. with only + TIF_SME set), and checking TIF_SVE alone is insufficient. + +Remove the broken support for the SMCCCv1.3 SVE saving hint. This is +effectively a revert of commits: + +* cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint") +* a7c3acca5380 ("arm64: smccc: Save lr before calling __arm_smccc_sve_check()") + +... leaving behind the ARM_SMCCC_VERSION_1_3 and ARM_SMCCC_1_3_SVE_HINT +definitions, since these are simply definitions from the SMCCC +specification, and the latter is used in KVM via ARM_SMCCC_CALL_HINTS. + +If we want to bring this back in future, we'll probably want to handle +this logic in C where we can use all the usual FPSIMD/SVE/SME helper +functions, and that'll likely require some rework of the SMCCC code +and/or its callers. + +Fixes: cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint") +Signed-off-by: Mark Rutland +Cc: Ard Biesheuvel +Cc: Catalin Marinas +Cc: Marc Zyngier +Cc: Mark Brown +Cc: Will Deacon +Cc: stable@vger.kernel.org +Reviewed-by: Mark Brown +Link: https://lore.kernel.org/r/20241106160448.2712997-1-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/smccc-call.S | 35 +++-------------------------------- + drivers/firmware/smccc/smccc.c | 4 ---- + include/linux/arm-smccc.h | 32 +++----------------------------- + 3 files changed, 6 insertions(+), 65 deletions(-) + +--- a/arch/arm64/kernel/smccc-call.S ++++ b/arch/arm64/kernel/smccc-call.S +@@ -7,48 +7,19 @@ + + #include + #include +-#include +- +-/* +- * If we have SMCCC v1.3 and (as is likely) no SVE state in +- * the registers then set the SMCCC hint bit to say there's no +- * need to preserve it. Do this by directly adjusting the SMCCC +- * function value which is already stored in x0 ready to be called. +- */ +-SYM_FUNC_START(__arm_smccc_sve_check) +- +- ldr_l x16, smccc_has_sve_hint +- cbz x16, 2f +- +- get_current_task x16 +- ldr x16, [x16, #TSK_TI_FLAGS] +- tbnz x16, #TIF_FOREIGN_FPSTATE, 1f // Any live FP state? +- tbnz x16, #TIF_SVE, 2f // Does that state include SVE? +- +-1: orr x0, x0, ARM_SMCCC_1_3_SVE_HINT +- +-2: ret +-SYM_FUNC_END(__arm_smccc_sve_check) +-EXPORT_SYMBOL(__arm_smccc_sve_check) + + .macro SMCCC instr +- stp x29, x30, [sp, #-16]! +- mov x29, sp +-alternative_if ARM64_SVE +- bl __arm_smccc_sve_check +-alternative_else_nop_endif + \instr #0 +- ldr x4, [sp, #16] ++ ldr x4, [sp] + stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS] + stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS] +- ldr x4, [sp, #24] ++ ldr x4, [sp, #8] + cbz x4, 1f /* no quirk structure */ + ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS] + cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6 + b.ne 1f + str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS] +-1: ldp x29, x30, [sp], #16 +- ret ++1: ret + .endm + + /* +--- a/drivers/firmware/smccc/smccc.c ++++ b/drivers/firmware/smccc/smccc.c +@@ -16,7 +16,6 @@ static u32 smccc_version = ARM_SMCCC_VER + static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE; + + bool __ro_after_init smccc_trng_available = false; +-u64 __ro_after_init smccc_has_sve_hint = false; + s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED; + s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED; + +@@ -28,9 +27,6 @@ void __init arm_smccc_version_init(u32 v + smccc_conduit = conduit; + + smccc_trng_available = smccc_probe_trng(); +- if (IS_ENABLED(CONFIG_ARM64_SVE) && +- smccc_version >= ARM_SMCCC_VERSION_1_3) +- smccc_has_sve_hint = true; + + if ((smccc_version >= ARM_SMCCC_VERSION_1_2) && + (smccc_conduit != SMCCC_CONDUIT_NONE)) { +--- a/include/linux/arm-smccc.h ++++ b/include/linux/arm-smccc.h +@@ -227,8 +227,6 @@ u32 arm_smccc_get_version(void); + + void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit); + +-extern u64 smccc_has_sve_hint; +- + /** + * arm_smccc_get_soc_id_version() + * +@@ -327,15 +325,6 @@ struct arm_smccc_quirk { + }; + + /** +- * __arm_smccc_sve_check() - Set the SVE hint bit when doing SMC calls +- * +- * Sets the SMCCC hint bit to indicate if there is live state in the SVE +- * registers, this modifies x0 in place and should never be called from C +- * code. +- */ +-asmlinkage unsigned long __arm_smccc_sve_check(unsigned long x0); +- +-/** + * __arm_smccc_smc() - make SMC calls + * @a0-a7: arguments passed in registers 0 to 7 + * @res: result values from registers 0 to 3 +@@ -402,20 +391,6 @@ asmlinkage void __arm_smccc_hvc(unsigned + + #endif + +-/* nVHE hypervisor doesn't have a current thread so needs separate checks */ +-#if defined(CONFIG_ARM64_SVE) && !defined(__KVM_NVHE_HYPERVISOR__) +- +-#define SMCCC_SVE_CHECK ALTERNATIVE("nop \n", "bl __arm_smccc_sve_check \n", \ +- ARM64_SVE) +-#define smccc_sve_clobbers "x16", "x30", "cc", +- +-#else +- +-#define SMCCC_SVE_CHECK +-#define smccc_sve_clobbers +- +-#endif +- + #define __constraint_read_2 "r" (arg0) + #define __constraint_read_3 __constraint_read_2, "r" (arg1) + #define __constraint_read_4 __constraint_read_3, "r" (arg2) +@@ -486,12 +461,11 @@ asmlinkage void __arm_smccc_hvc(unsigned + register unsigned long r3 asm("r3"); \ + CONCATENATE(__declare_arg_, \ + COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__); \ +- asm volatile(SMCCC_SVE_CHECK \ +- inst "\n" : \ ++ asm volatile(inst "\n" : \ + "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3) \ + : CONCATENATE(__constraint_read_, \ + COUNT_ARGS(__VA_ARGS__)) \ +- : smccc_sve_clobbers "memory"); \ ++ : "memory"); \ + if (___res) \ + *___res = (typeof(*___res)){r0, r1, r2, r3}; \ + } while (0) +@@ -540,7 +514,7 @@ asmlinkage void __arm_smccc_hvc(unsigned + asm ("" : \ + : CONCATENATE(__constraint_read_, \ + COUNT_ARGS(__VA_ARGS__)) \ +- : smccc_sve_clobbers "memory"); \ ++ : "memory"); \ + if (___res) \ + ___res->a0 = SMCCC_RET_NOT_SUPPORTED; \ + } while (0) diff --git a/queue-6.11/arm64-sve-discard-stale-cpu-state-when-handling-sve-traps.patch b/queue-6.11/arm64-sve-discard-stale-cpu-state-when-handling-sve-traps.patch new file mode 100644 index 00000000000..6d9666f4379 --- /dev/null +++ b/queue-6.11/arm64-sve-discard-stale-cpu-state-when-handling-sve-traps.patch @@ -0,0 +1,91 @@ +From 751ecf6afd6568adc98f2a6052315552c0483d18 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Wed, 30 Oct 2024 20:23:50 +0000 +Subject: arm64/sve: Discard stale CPU state when handling SVE traps + +From: Mark Brown + +commit 751ecf6afd6568adc98f2a6052315552c0483d18 upstream. + +The logic for handling SVE traps manipulates saved FPSIMD/SVE state +incorrectly, and a race with preemption can result in a task having +TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state +is stale (e.g. with SVE traps enabled). This has been observed to result +in warnings from do_sve_acc() where SVE traps are not expected while +TIF_SVE is set: + +| if (test_and_set_thread_flag(TIF_SVE)) +| WARN_ON(1); /* SVE access shouldn't have trapped */ + +Warnings of this form have been reported intermittently, e.g. + + https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ + https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ + +The race can occur when the SVE trap handler is preempted before and +after manipulating the saved FPSIMD/SVE state, starting and ending on +the same CPU, e.g. + +| void do_sve_acc(unsigned long esr, struct pt_regs *regs) +| { +| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled +| // task->fpsimd_cpu is 0. +| // per_cpu_ptr(&fpsimd_last_state, 0) is task. +| +| ... +| +| // Preempted; migrated from CPU 0 to CPU 1. +| // TIF_FOREIGN_FPSTATE is set. +| +| get_cpu_fpsimd_context(); +| +| if (test_and_set_thread_flag(TIF_SVE)) +| WARN_ON(1); /* SVE access shouldn't have trapped */ +| +| sve_init_regs() { +| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { +| ... +| } else { +| fpsimd_to_sve(current); +| current->thread.fp_type = FP_STATE_SVE; +| } +| } +| +| put_cpu_fpsimd_context(); +| +| // Preempted; migrated from CPU 1 to CPU 0. +| // task->fpsimd_cpu is still 0 +| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: +| // - Stale HW state is reused (with SVE traps enabled) +| // - TIF_FOREIGN_FPSTATE is cleared +| // - A return to userspace skips HW state restore +| } + +Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set +by calling fpsimd_flush_task_state() to detach from the saved CPU +state. This ensures that a subsequent context switch will not reuse the +stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the +new state to be reloaded from memory prior to a return to userspace. + +Fixes: cccb78ce89c4 ("arm64/sve: Rework SVE access trap to convert state in registers") +Reported-by: Mark Rutland +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Reviewed-by: Mark Rutland +Link: https://lore.kernel.org/r/20241030-arm64-fpsimd-foreign-flush-v1-1-bd7bd66905a2@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/fpsimd.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/kernel/fpsimd.c ++++ b/arch/arm64/kernel/fpsimd.c +@@ -1367,6 +1367,7 @@ static void sve_init_regs(void) + } else { + fpsimd_to_sve(current); + current->thread.fp_type = FP_STATE_SVE; ++ fpsimd_flush_task_state(current); + } + } + diff --git a/queue-6.11/btrfs-fix-per-subvolume-ro-rw-flags-with-new-mount-api.patch b/queue-6.11/btrfs-fix-per-subvolume-ro-rw-flags-with-new-mount-api.patch new file mode 100644 index 00000000000..4b956a8eec1 --- /dev/null +++ b/queue-6.11/btrfs-fix-per-subvolume-ro-rw-flags-with-new-mount-api.patch @@ -0,0 +1,117 @@ +From cda7163d4e3d99db93aa38f0e825b8433c7a8452 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Wed, 30 Oct 2024 11:25:47 +1030 +Subject: btrfs: fix per-subvolume RO/RW flags with new mount API + +From: Qu Wenruo + +commit cda7163d4e3d99db93aa38f0e825b8433c7a8452 upstream. + +[BUG] +With util-linux 2.40.2, the 'mount' utility is already utilizing the new +mount API. e.g: + + # strace mount -o subvol=subv1,ro /dev/test/scratch1 /mnt/test/ + ... + fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/mapper/test-scratch1", 0) = 0 + fsconfig(3, FSCONFIG_SET_STRING, "subvol", "subv1", 0) = 0 + fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0 + fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0 + fsmount(3, FSMOUNT_CLOEXEC, 0) = 4 + mount_setattr(4, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_RDONLY, attr_clr=0, propagation=0 /* MS_??? */, userns_fd=0}, 32) = 0 + move_mount(4, "", AT_FDCWD, "/mnt/test", MOVE_MOUNT_F_EMPTY_PATH) = 0 + +But this leads to a new problem, that per-subvolume RO/RW mount no +longer works, if the initial mount is RO: + + # mount -o subvol=subv1,ro /dev/test/scratch1 /mnt/test + # mount -o rw,subvol=subv2 /dev/test/scratch1 /mnt/scratch + # mount | grep mnt + /dev/mapper/test-scratch1 on /mnt/test type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/subv1) + /dev/mapper/test-scratch1 on /mnt/scratch type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/subv2) + # touch /mnt/scratch/foobar + touch: cannot touch '/mnt/scratch/foobar': Read-only file system + +This is a common use cases on distros. + +[CAUSE] +We have a workaround for remount to handle the RO->RW change, but if the +mount is using the new mount API, we do not do that, and rely on the +mount tool NOT to set the ro flag. + +But that's not how the mount tool is doing for the new API: + + fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/mapper/test-scratch1", 0) = 0 + fsconfig(3, FSCONFIG_SET_STRING, "subvol", "subv1", 0) = 0 + fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0 <<<< Setting RO flag for super block + fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0 + fsmount(3, FSMOUNT_CLOEXEC, 0) = 4 + mount_setattr(4, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_RDONLY, attr_clr=0, propagation=0 /* MS_??? */, userns_fd=0}, 32) = 0 + move_mount(4, "", AT_FDCWD, "/mnt/test", MOVE_MOUNT_F_EMPTY_PATH) = 0 + +This means we will set the super block RO at the first mount. + +Later RW mount will not try to reconfigure the fs to RW because the +mount tool is already using the new API. + +This totally breaks the per-subvolume RO/RW mount behavior. + +[FIX] +Do not skip the reconfiguration even if using the new API. The old +comments are just expecting any mount tool to properly skip the RO flag +set even if we specify "ro", which is not the reality. + +Update the comments regarding the backward compatibility on the kernel +level so it works with old and new mount utilities. + +CC: stable@vger.kernel.org # 6.8+ +Fixes: f044b318675f ("btrfs: handle the ro->rw transition for mounting different subvolumes") +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/super.c | 25 +++++-------------------- + 1 file changed, 5 insertions(+), 20 deletions(-) + +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -1979,25 +1979,10 @@ error: + * fsconfig(FSCONFIG_SET_FLAG, "ro"). This option is seen by the filesystem + * in fc->sb_flags. + * +- * This disambiguation has rather positive consequences. Mounting a subvolume +- * ro will not also turn the superblock ro. Only the mount for the subvolume +- * will become ro. +- * +- * So, if the superblock creation request comes from the new mount API the +- * caller must have explicitly done: +- * +- * fsconfig(FSCONFIG_SET_FLAG, "ro") +- * fsmount/mount_setattr(MOUNT_ATTR_RDONLY) +- * +- * IOW, at some point the caller must have explicitly turned the whole +- * superblock ro and we shouldn't just undo it like we did for the old mount +- * API. In any case, it lets us avoid the hack in the new mount API. +- * +- * Consequently, the remounting hack must only be used for requests originating +- * from the old mount API and should be marked for full deprecation so it can be +- * turned off in a couple of years. +- * +- * The new mount API has no reason to support this hack. ++ * But, currently the util-linux mount command already utilizes the new mount ++ * API and is still setting fsconfig(FSCONFIG_SET_FLAG, "ro") no matter if it's ++ * btrfs or not, setting the whole super block RO. To make per-subvolume mounting ++ * work with different options work we need to keep backward compatibility. + */ + static struct vfsmount *btrfs_reconfigure_for_mount(struct fs_context *fc) + { +@@ -2019,7 +2004,7 @@ static struct vfsmount *btrfs_reconfigur + if (IS_ERR(mnt)) + return mnt; + +- if (!fc->oldapi || !ro2rw) ++ if (!ro2rw) + return mnt; + + /* We need to convert to rw, call reconfigure. */ diff --git a/queue-6.11/btrfs-fix-the-length-of-reserved-qgroup-to-free.patch b/queue-6.11/btrfs-fix-the-length-of-reserved-qgroup-to-free.patch new file mode 100644 index 00000000000..9a894c85357 --- /dev/null +++ b/queue-6.11/btrfs-fix-the-length-of-reserved-qgroup-to-free.patch @@ -0,0 +1,38 @@ +From 2b084d8205949dd804e279df8e68531da78be1e8 Mon Sep 17 00:00:00 2001 +From: Haisu Wang +Date: Fri, 25 Oct 2024 14:54:40 +0800 +Subject: btrfs: fix the length of reserved qgroup to free + +From: Haisu Wang + +commit 2b084d8205949dd804e279df8e68531da78be1e8 upstream. + +The dealloc flag may be cleared and the extent won't reach the disk in +cow_file_range when errors path. The reserved qgroup space is freed in +commit 30479f31d44d ("btrfs: fix qgroup reserve leaks in +cow_file_range"). However, the length of untouched region to free needs +to be adjusted with the correct remaining region size. + +Fixes: 30479f31d44d ("btrfs: fix qgroup reserve leaks in cow_file_range") +CC: stable@vger.kernel.org # 6.11+ +Reviewed-by: Qu Wenruo +Reviewed-by: Boris Burkov +Signed-off-by: Haisu Wang +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -1599,7 +1599,7 @@ out_unlock: + clear_bits |= EXTENT_CLEAR_DATA_RESV; + extent_clear_unlock_delalloc(inode, start, end, locked_page, + &cached, clear_bits, page_ops); +- btrfs_qgroup_free_data(inode, NULL, start, cur_alloc_size, NULL); ++ btrfs_qgroup_free_data(inode, NULL, start, end - start + 1, NULL); + } + return ret; + } diff --git a/queue-6.11/btrfs-reinitialize-delayed-ref-list-after-deleting-it-from-the-list.patch b/queue-6.11/btrfs-reinitialize-delayed-ref-list-after-deleting-it-from-the-list.patch new file mode 100644 index 00000000000..404eadd016c --- /dev/null +++ b/queue-6.11/btrfs-reinitialize-delayed-ref-list-after-deleting-it-from-the-list.patch @@ -0,0 +1,50 @@ +From c9a75ec45f1111ef530ab186c2a7684d0a0c9245 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 4 Nov 2024 12:11:15 +0000 +Subject: btrfs: reinitialize delayed ref list after deleting it from the list + +From: Filipe Manana + +commit c9a75ec45f1111ef530ab186c2a7684d0a0c9245 upstream. + +At insert_delayed_ref() if we need to update the action of an existing +ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's +ref_add_list using list_del(), which leaves the ref's add_list member +not reinitialized, as list_del() sets the next and prev members of the +list to LIST_POISON1 and LIST_POISON2, respectively. + +If later we end up calling drop_delayed_ref() against the ref, which can +happen during merging or when destroying delayed refs due to a transaction +abort, we can trigger a crash since at drop_delayed_ref() we call +list_empty() against the ref's add_list, which returns false since +the list was not reinitialized after the list_del() and as a consequence +we call list_del() again at drop_delayed_ref(). This results in an +invalid list access since the next and prev members are set to poison +pointers, resulting in a splat if CONFIG_LIST_HARDENED and +CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences +otherwise. + +So fix this by deleting from the list with list_del_init() instead. + +Fixes: 1d57ee941692 ("btrfs: improve delayed refs iterations") +CC: stable@vger.kernel.org # 4.19+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/delayed-ref.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/delayed-ref.c ++++ b/fs/btrfs/delayed-ref.c +@@ -649,7 +649,7 @@ static bool insert_delayed_ref(struct bt + &href->ref_add_list); + else if (ref->action == BTRFS_DROP_DELAYED_REF) { + ASSERT(!list_empty(&exist->add_list)); +- list_del(&exist->add_list); ++ list_del_init(&exist->add_list); + } else { + ASSERT(0); + } diff --git a/queue-6.11/idpf-avoid-vport-access-in-idpf_get_link_ksettings.patch b/queue-6.11/idpf-avoid-vport-access-in-idpf_get_link_ksettings.patch new file mode 100644 index 00000000000..dfab8558584 --- /dev/null +++ b/queue-6.11/idpf-avoid-vport-access-in-idpf_get_link_ksettings.patch @@ -0,0 +1,132 @@ +From 81d2fb4c7c18a3b36ba3e00b9d5b753107472d75 Mon Sep 17 00:00:00 2001 +From: Pavan Kumar Linga +Date: Fri, 25 Oct 2024 11:38:42 -0700 +Subject: idpf: avoid vport access in idpf_get_link_ksettings + +From: Pavan Kumar Linga + +commit 81d2fb4c7c18a3b36ba3e00b9d5b753107472d75 upstream. + +When the device control plane is removed or the platform +running device control plane is rebooted, a reset is detected +on the driver. On driver reset, it releases the resources and +waits for the reset to complete. If the reset fails, it takes +the error path and releases the vport lock. At this time if the +monitoring tools tries to access link settings, it call traces +for accessing released vport pointer. + +To avoid it, move link_speed_mbps to netdev_priv structure +which removes the dependency on vport pointer and the vport lock +in idpf_get_link_ksettings. Also use netif_carrier_ok() +to check the link status and adjust the offsetof to use link_up +instead of link_speed_mbps. + +Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks") +Cc: stable@vger.kernel.org # 6.7+ +Reviewed-by: Tarun K Singh +Signed-off-by: Pavan Kumar Linga +Tested-by: Krishneil Singh +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/idpf/idpf.h | 4 ++-- + drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 11 +++-------- + drivers/net/ethernet/intel/idpf/idpf_lib.c | 4 ++-- + drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 +- + 4 files changed, 8 insertions(+), 13 deletions(-) + +--- a/drivers/net/ethernet/intel/idpf/idpf.h ++++ b/drivers/net/ethernet/intel/idpf/idpf.h +@@ -141,6 +141,7 @@ enum idpf_vport_state { + * @adapter: Adapter back pointer + * @vport: Vport back pointer + * @vport_id: Vport identifier ++ * @link_speed_mbps: Link speed in mbps + * @vport_idx: Relative vport index + * @state: See enum idpf_vport_state + * @netstats: Packet and byte stats +@@ -150,6 +151,7 @@ struct idpf_netdev_priv { + struct idpf_adapter *adapter; + struct idpf_vport *vport; + u32 vport_id; ++ u32 link_speed_mbps; + u16 vport_idx; + enum idpf_vport_state state; + struct rtnl_link_stats64 netstats; +@@ -287,7 +289,6 @@ struct idpf_port_stats { + * @tx_itr_profile: TX profiles for Dynamic Interrupt Moderation + * @port_stats: per port csum, header split, and other offload stats + * @link_up: True if link is up +- * @link_speed_mbps: Link speed in mbps + * @sw_marker_wq: workqueue for marker packets + */ + struct idpf_vport { +@@ -331,7 +332,6 @@ struct idpf_vport { + struct idpf_port_stats port_stats; + + bool link_up; +- u32 link_speed_mbps; + + wait_queue_head_t sw_marker_wq; + }; +--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c +@@ -1296,24 +1296,19 @@ static void idpf_set_msglevel(struct net + static int idpf_get_link_ksettings(struct net_device *netdev, + struct ethtool_link_ksettings *cmd) + { +- struct idpf_vport *vport; +- +- idpf_vport_ctrl_lock(netdev); +- vport = idpf_netdev_to_vport(netdev); ++ struct idpf_netdev_priv *np = netdev_priv(netdev); + + ethtool_link_ksettings_zero_link_mode(cmd, supported); + cmd->base.autoneg = AUTONEG_DISABLE; + cmd->base.port = PORT_NONE; +- if (vport->link_up) { ++ if (netif_carrier_ok(netdev)) { + cmd->base.duplex = DUPLEX_FULL; +- cmd->base.speed = vport->link_speed_mbps; ++ cmd->base.speed = np->link_speed_mbps; + } else { + cmd->base.duplex = DUPLEX_UNKNOWN; + cmd->base.speed = SPEED_UNKNOWN; + } + +- idpf_vport_ctrl_unlock(netdev); +- + return 0; + } + +--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c +@@ -1873,7 +1873,7 @@ int idpf_initiate_soft_reset(struct idpf + * mess with. Nothing below should use those variables from new_vport + * and should instead always refer to them in vport if they need to. + */ +- memcpy(new_vport, vport, offsetof(struct idpf_vport, link_speed_mbps)); ++ memcpy(new_vport, vport, offsetof(struct idpf_vport, link_up)); + + /* Adjust resource parameters prior to reallocating resources */ + switch (reset_cause) { +@@ -1919,7 +1919,7 @@ int idpf_initiate_soft_reset(struct idpf + /* Same comment as above regarding avoiding copying the wait_queues and + * mutexes applies here. We do not want to mess with those if possible. + */ +- memcpy(vport, new_vport, offsetof(struct idpf_vport, link_speed_mbps)); ++ memcpy(vport, new_vport, offsetof(struct idpf_vport, link_up)); + + if (reset_cause == IDPF_SR_Q_CHANGE) + idpf_vport_alloc_vec_indexes(vport); +--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +@@ -141,7 +141,7 @@ static void idpf_handle_event_link(struc + } + np = netdev_priv(vport->netdev); + +- vport->link_speed_mbps = le32_to_cpu(v2e->link_speed); ++ np->link_speed_mbps = le32_to_cpu(v2e->link_speed); + + if (vport->link_up == v2e->link_status) + return; diff --git a/queue-6.11/idpf-fix-idpf_vc_core_init-error-path.patch b/queue-6.11/idpf-fix-idpf_vc_core_init-error-path.patch new file mode 100644 index 00000000000..9699a41a341 --- /dev/null +++ b/queue-6.11/idpf-fix-idpf_vc_core_init-error-path.patch @@ -0,0 +1,57 @@ +From 9b58031ff96b84a38d7b73b23c7ecfb2e0557f43 Mon Sep 17 00:00:00 2001 +From: Pavan Kumar Linga +Date: Fri, 25 Oct 2024 11:38:43 -0700 +Subject: idpf: fix idpf_vc_core_init error path + +From: Pavan Kumar Linga + +commit 9b58031ff96b84a38d7b73b23c7ecfb2e0557f43 upstream. + +In an event where the platform running the device control plane +is rebooted, reset is detected on the driver. It releases +all the resources and waits for the reset to complete. Once the +reset is done, it tries to build the resources back. At this +time if the device control plane is not yet started, then +the driver timeouts on the virtchnl message and retries to +establish the mailbox again. + +In the retry flow, mailbox is deinitialized but the mailbox +workqueue is still alive and polling for the mailbox message. +This results in accessing the released control queue leading to +null-ptr-deref. Fix it by unrolling the work queue cancellation +and mailbox deinitialization in the reverse order which they got +initialized. + +Fixes: 4930fbf419a7 ("idpf: add core init and interrupt request") +Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") +Cc: stable@vger.kernel.org # 6.9+ +Reviewed-by: Tarun K Singh +Signed-off-by: Pavan Kumar Linga +Tested-by: Krishneil Singh +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/idpf/idpf_lib.c | 1 + + drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 1 - + 2 files changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c +@@ -1799,6 +1799,7 @@ static int idpf_init_hard_reset(struct i + */ + err = idpf_vc_core_init(adapter); + if (err) { ++ cancel_delayed_work_sync(&adapter->mbx_task); + idpf_deinit_dflt_mbx(adapter); + goto unlock_mutex; + } +--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +@@ -3063,7 +3063,6 @@ init_failed: + adapter->state = __IDPF_VER_CHECK; + if (adapter->vcxn_mngr) + idpf_vc_xn_shutdown(adapter->vcxn_mngr); +- idpf_deinit_dflt_mbx(adapter); + set_bit(IDPF_HR_DRV_LOAD, adapter->flags); + queue_delayed_work(adapter->vc_event_wq, &adapter->vc_event_task, + msecs_to_jiffies(task_delay)); diff --git a/queue-6.11/kvm-ppc-book3s-hv-mask-off-lpcr_mer-for-a-vcpu-before-running-it-to-avoid-spurious-interrupts.patch b/queue-6.11/kvm-ppc-book3s-hv-mask-off-lpcr_mer-for-a-vcpu-before-running-it-to-avoid-spurious-interrupts.patch new file mode 100644 index 00000000000..760ae8c55a8 --- /dev/null +++ b/queue-6.11/kvm-ppc-book3s-hv-mask-off-lpcr_mer-for-a-vcpu-before-running-it-to-avoid-spurious-interrupts.patch @@ -0,0 +1,77 @@ +From a373830f96db288a3eb43a8692b6bcd0bd88dfe1 Mon Sep 17 00:00:00 2001 +From: Gautam Menghani +Date: Mon, 28 Oct 2024 14:34:09 +0530 +Subject: KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid spurious interrupts + +From: Gautam Menghani + +commit a373830f96db288a3eb43a8692b6bcd0bd88dfe1 upstream. + +Running a L2 vCPU (see [1] for terminology) with LPCR_MER bit set and no +pending interrupts results in that L2 vCPU getting an infinite flood of +spurious interrupts. The 'if check' in kvmhv_run_single_vcpu() sets the +LPCR_MER bit if there are pending interrupts. + +The spurious flood problem can be observed in 2 cases: +1. Crashing the guest while interrupt heavy workload is running + a. Start a L2 guest and run an interrupt heavy workload (eg: ipistorm) + b. While the workload is running, crash the guest (make sure kdump + is configured) + c. Any one of the vCPUs of the guest will start getting an infinite + flood of spurious interrupts. + +2. Running LTP stress tests in multiple guests at the same time + a. Start 4 L2 guests. + b. Start running LTP stress tests on all 4 guests at same time. + c. In some time, any one/more of the vCPUs of any of the guests will + start getting an infinite flood of spurious interrupts. + +The root cause of both the above issues is the same: +1. A NMI is sent to a running vCPU that has LPCR_MER bit set. +2. In the NMI path, all registers are refreshed, i.e, H_GUEST_GET_STATE + is called for all the registers. +3. When H_GUEST_GET_STATE is called for LPCR, the vcpu->arch.vcore->lpcr + of that vCPU at L1 level gets updated with LPCR_MER set to 1, and this + new value is always used whenever that vCPU runs, regardless of whether + there was a pending interrupt. +4. Since LPCR_MER is set, the vCPU in L2 always jumps to the external + interrupt handler, and this cycle never ends. + +Fix the spurious flood by masking off the LPCR_MER bit before running a +L2 vCPU to ensure that it is not set if there are no pending interrupts. + +[1] Terminology: +1. L0 : PAPR hypervisor running in HV mode +2. L1 : Linux guest (logical partition) running on top of L0 +3. L2 : KVM guest running on top of L1 + +Fixes: ec0f6639fa88 ("KVM: PPC: Book3S HV nestedv2: Ensure LPCR_MER bit is passed to the L0") +Cc: stable@vger.kernel.org # v6.8+ +Signed-off-by: Gautam Menghani +Signed-off-by: Madhavan Srinivasan +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kvm/book3s_hv.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/arch/powerpc/kvm/book3s_hv.c ++++ b/arch/powerpc/kvm/book3s_hv.c +@@ -4892,6 +4892,18 @@ int kvmhv_run_single_vcpu(struct kvm_vcp + BOOK3S_INTERRUPT_EXTERNAL, 0); + else + lpcr |= LPCR_MER; ++ } else { ++ /* ++ * L1's copy of L2's LPCR (vcpu->arch.vcore->lpcr) can get its MER bit ++ * unexpectedly set - for e.g. during NMI handling when all register ++ * states are synchronized from L0 to L1. L1 needs to inform L0 about ++ * MER=1 only when there are pending external interrupts. ++ * In the above if check, MER bit is set if there are pending ++ * external interrupts. Hence, explicity mask off MER bit ++ * here as otherwise it may generate spurious interrupts in L2 KVM ++ * causing an endless loop, which results in L2 guest getting hung. ++ */ ++ lpcr &= ~LPCR_MER; + } + } else if (vcpu->arch.pending_exceptions || + vcpu->arch.doorbell_request || diff --git a/queue-6.11/mm-slab-fix-warning-caused-by-duplicate-kmem_cache-creation-in-kmem_buckets_create.patch b/queue-6.11/mm-slab-fix-warning-caused-by-duplicate-kmem_cache-creation-in-kmem_buckets_create.patch new file mode 100644 index 00000000000..ce98caf533d --- /dev/null +++ b/queue-6.11/mm-slab-fix-warning-caused-by-duplicate-kmem_cache-creation-in-kmem_buckets_create.patch @@ -0,0 +1,161 @@ +From 9c9201afebea1efc7ea4b8f721ee18a05bb8aca1 Mon Sep 17 00:00:00 2001 +From: Koichiro Den +Date: Tue, 5 Nov 2024 11:27:47 +0900 +Subject: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create + +From: Koichiro Den + +commit 9c9201afebea1efc7ea4b8f721ee18a05bb8aca1 upstream. + +Commit b035f5a6d852 ("mm: slab: reduce the kmalloc() minimum alignment +if DMA bouncing possible") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. +However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. +This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], +resulting in kmem_buckets_create() attempting to create a kmem_cache for +size 16 twice. This duplication triggers warnings on boot: + +[ 2.325108] ------------[ cut here ]------------ +[ 2.325135] kmem_cache of name 'memdup_user-16' already exists +[ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 +[ 2.327957] Modules linked in: +[ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 +[ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 +[ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) +[ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 +[ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 +[ 2.328942] sp : ffff800083d6fc50 +[ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 +[ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 +[ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 +[ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 +[ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 +[ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 +[ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 +[ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 +[ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 +[ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 +[ 2.329291] Call trace: +[ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 +[ 2.329499] kmem_buckets_create+0xfc/0x320 +[ 2.329526] init_user_buckets+0x34/0x78 +[ 2.329540] do_one_initcall+0x64/0x3c8 +[ 2.329550] kernel_init_freeable+0x26c/0x578 +[ 2.329562] kernel_init+0x3c/0x258 +[ 2.329574] ret_from_fork+0x10/0x20 +[ 2.329698] ---[ end trace 0000000000000000 ]--- + +[ 2.403704] ------------[ cut here ]------------ +[ 2.404716] kmem_cache of name 'msg_msg-16' already exists +[ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 +[ 2.404842] Modules linked in: +[ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 +[ 2.405026] Tainted: [W]=WARN +[ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 +[ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 +[ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 +[ 2.405111] sp : ffff800083d6fc50 +[ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 +[ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 +[ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 +[ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 +[ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 +[ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 +[ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 +[ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 +[ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 +[ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 +[ 2.405287] Call trace: +[ 2.405293] __kmem_cache_create_args+0xb8/0x3b0 +[ 2.405305] kmem_buckets_create+0xfc/0x320 +[ 2.405315] init_msg_buckets+0x34/0x78 +[ 2.405326] do_one_initcall+0x64/0x3c8 +[ 2.405337] kernel_init_freeable+0x26c/0x578 +[ 2.405348] kernel_init+0x3c/0x258 +[ 2.405360] ret_from_fork+0x10/0x20 +[ 2.405370] ---[ end trace 0000000000000000 ]--- + +To address this, alias kmem_cache for sizes smaller than min alignment +to the aligned sized kmem_cache, as done with the default system kmalloc +bucket. + +Fixes: b32801d1255b ("mm/slab: Introduce kmem_buckets_create() and family") +Cc: # v6.11+ +Signed-off-by: Koichiro Den +Reviewed-by: Catalin Marinas +Tested-by: Catalin Marinas +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slab_common.c | 31 ++++++++++++++++++++----------- + 1 file changed, 20 insertions(+), 11 deletions(-) + +--- a/mm/slab_common.c ++++ b/mm/slab_common.c +@@ -418,8 +418,11 @@ kmem_buckets *kmem_buckets_create(const + unsigned int usersize, + void (*ctor)(void *)) + { ++ unsigned long mask = 0; ++ unsigned int idx; + kmem_buckets *b; +- int idx; ++ ++ BUILD_BUG_ON(ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]) > BITS_PER_LONG); + + /* + * When the separate buckets API is not built in, just return +@@ -441,7 +444,7 @@ kmem_buckets *kmem_buckets_create(const + for (idx = 0; idx < ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]); idx++) { + char *short_size, *cache_name; + unsigned int cache_useroffset, cache_usersize; +- unsigned int size; ++ unsigned int size, aligned_idx; + + if (!kmalloc_caches[KMALLOC_NORMAL][idx]) + continue; +@@ -454,10 +457,6 @@ kmem_buckets *kmem_buckets_create(const + if (WARN_ON(!short_size)) + goto fail; + +- cache_name = kasprintf(GFP_KERNEL, "%s-%s", name, short_size + 1); +- if (WARN_ON(!cache_name)) +- goto fail; +- + if (useroffset >= size) { + cache_useroffset = 0; + cache_usersize = 0; +@@ -465,18 +464,28 @@ kmem_buckets *kmem_buckets_create(const + cache_useroffset = useroffset; + cache_usersize = min(size - cache_useroffset, usersize); + } +- (*b)[idx] = kmem_cache_create_usercopy(cache_name, size, ++ ++ aligned_idx = __kmalloc_index(size, false); ++ if (!(*b)[aligned_idx]) { ++ cache_name = kasprintf(GFP_KERNEL, "%s-%s", name, short_size + 1); ++ if (WARN_ON(!cache_name)) ++ goto fail; ++ (*b)[aligned_idx] = kmem_cache_create_usercopy(cache_name, size, + 0, flags, cache_useroffset, + cache_usersize, ctor); +- kfree(cache_name); +- if (WARN_ON(!(*b)[idx])) +- goto fail; ++ kfree(cache_name); ++ if (WARN_ON(!(*b)[aligned_idx])) ++ goto fail; ++ set_bit(aligned_idx, &mask); ++ } ++ if (idx != aligned_idx) ++ (*b)[idx] = (*b)[aligned_idx]; + } + + return b; + + fail: +- for (idx = 0; idx < ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]); idx++) ++ for_each_set_bit(idx, &mask, ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL])) + kmem_cache_destroy((*b)[idx]); + kfree(b); + diff --git a/queue-6.11/mptcp-use-sock_kfree_s-instead-of-kfree.patch b/queue-6.11/mptcp-use-sock_kfree_s-instead-of-kfree.patch new file mode 100644 index 00000000000..3121b95eeb4 --- /dev/null +++ b/queue-6.11/mptcp-use-sock_kfree_s-instead-of-kfree.patch @@ -0,0 +1,46 @@ +From 99635c91fb8b860a6404b9bc8b769df7bdaa2ae3 Mon Sep 17 00:00:00 2001 +From: Geliang Tang +Date: Mon, 4 Nov 2024 13:31:42 +0100 +Subject: mptcp: use sock_kfree_s instead of kfree + +From: Geliang Tang + +commit 99635c91fb8b860a6404b9bc8b769df7bdaa2ae3 upstream. + +The local address entries on userspace_pm_local_addr_list are allocated +by sock_kmalloc(). + +It's then required to use sock_kfree_s() instead of kfree() to free +these entries in order to adjust the allocated size on the sk side. + +Fixes: 24430f8bf516 ("mptcp: add address into userspace pm list") +Cc: stable@vger.kernel.org +Signed-off-by: Geliang Tang +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20241104-net-mptcp-misc-6-12-v1-2-c13f2ff1656f@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_userspace.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/mptcp/pm_userspace.c ++++ b/net/mptcp/pm_userspace.c +@@ -91,6 +91,7 @@ static int mptcp_userspace_pm_delete_loc + struct mptcp_pm_addr_entry *addr) + { + struct mptcp_pm_addr_entry *entry, *tmp; ++ struct sock *sk = (struct sock *)msk; + + list_for_each_entry_safe(entry, tmp, &msk->pm.userspace_pm_local_addr_list, list) { + if (mptcp_addresses_equal(&entry->addr, &addr->addr, false)) { +@@ -98,7 +99,7 @@ static int mptcp_userspace_pm_delete_loc + * be used multiple times (e.g. fullmesh mode). + */ + list_del_rcu(&entry->list); +- kfree(entry); ++ sock_kfree_s(sk, entry, sizeof(*entry)); + msk->pm.local_addr_used--; + return 0; + } diff --git a/queue-6.11/net-vertexcom-mse102x-fix-possible-double-free-of-tx-skb.patch b/queue-6.11/net-vertexcom-mse102x-fix-possible-double-free-of-tx-skb.patch new file mode 100644 index 00000000000..18bb0002234 --- /dev/null +++ b/queue-6.11/net-vertexcom-mse102x-fix-possible-double-free-of-tx-skb.patch @@ -0,0 +1,82 @@ +From 1f26339b2ed63d1e8e18a18674fb73a392f3660e Mon Sep 17 00:00:00 2001 +From: Stefan Wahren +Date: Tue, 5 Nov 2024 17:31:01 +0100 +Subject: net: vertexcom: mse102x: Fix possible double free of TX skb + +From: Stefan Wahren + +commit 1f26339b2ed63d1e8e18a18674fb73a392f3660e upstream. + +The scope of the TX skb is wider than just mse102x_tx_frame_spi(), +so in case the TX skb room needs to be expanded, we should free the +the temporary skb instead of the original skb. Otherwise the original +TX skb pointer would be freed again in mse102x_tx_work(), which leads +to crashes: + + Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP + CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 + Hardware name: chargebyte Charge SOM DC-ONE (DT) + Workqueue: events mse102x_tx_work [mse102x] + pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) + pc : skb_release_data+0xb8/0x1d8 + lr : skb_release_data+0x1ac/0x1d8 + sp : ffff8000819a3cc0 + x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 + x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff + x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 + x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc + x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 + x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 + x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 + x8 : fffffc00001bc008 + x7 : 0000000000000000 x6 : 0000000000000008 + x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 + x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 + Call trace: + skb_release_data+0xb8/0x1d8 + kfree_skb_reason+0x48/0xb0 + mse102x_tx_work+0x164/0x35c [mse102x] + process_one_work+0x138/0x260 + worker_thread+0x32c/0x438 + kthread+0x118/0x11c + ret_from_fork+0x10/0x20 + Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660) + +Cc: stable@vger.kernel.org +Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") +Signed-off-by: Stefan Wahren +Link: https://patch.msgid.link/20241105163101.33216-1-wahrenst@gmx.net +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/vertexcom/mse102x.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/vertexcom/mse102x.c ++++ b/drivers/net/ethernet/vertexcom/mse102x.c +@@ -222,7 +222,7 @@ static int mse102x_tx_frame_spi(struct m + struct mse102x_net_spi *mses = to_mse102x_spi(mse); + struct spi_transfer *xfer = &mses->spi_xfer; + struct spi_message *msg = &mses->spi_msg; +- struct sk_buff *tskb; ++ struct sk_buff *tskb = NULL; + int ret; + + netif_dbg(mse, tx_queued, mse->ndev, "%s: skb %p, %d@%p\n", +@@ -235,7 +235,6 @@ static int mse102x_tx_frame_spi(struct m + if (!tskb) + return -ENOMEM; + +- dev_kfree_skb(txp); + txp = tskb; + } + +@@ -257,6 +256,8 @@ static int mse102x_tx_frame_spi(struct m + mse->stats.xfer_err++; + } + ++ dev_kfree_skb(tskb); ++ + return ret; + } + diff --git a/queue-6.11/net-wwan-t7xx-fix-off-by-one-error-in-t7xx_dpmaif_rx_buf_alloc.patch b/queue-6.11/net-wwan-t7xx-fix-off-by-one-error-in-t7xx_dpmaif_rx_buf_alloc.patch new file mode 100644 index 00000000000..f91e5cbecb9 --- /dev/null +++ b/queue-6.11/net-wwan-t7xx-fix-off-by-one-error-in-t7xx_dpmaif_rx_buf_alloc.patch @@ -0,0 +1,42 @@ +From 3b557be89fc688dbd9ccf704a70f7600a094f13a Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Fri, 1 Nov 2024 10:53:16 +0800 +Subject: net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jinjie Ruan + +commit 3b557be89fc688dbd9ccf704a70f7600a094f13a upstream. + +The error path in t7xx_dpmaif_rx_buf_alloc(), free and unmap the already +allocated and mapped skb in a loop, but the loop condition terminates when +the index reaches zero, which fails to free the first allocated skb at +index zero. + +Check with i-- so that skb at index 0 is freed as well. + +Cc: stable@vger.kernel.org +Fixes: d642b012df70 ("net: wwan: t7xx: Add data path interface") +Acked-by: Sergey Ryazanov +Signed-off-by: Jinjie Ruan +Reviewed-by: Ilpo Järvinen +Link: https://patch.msgid.link/20241101025316.3234023-1-ruanjinjie@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c ++++ b/drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c +@@ -226,7 +226,7 @@ int t7xx_dpmaif_rx_buf_alloc(struct dpma + return 0; + + err_unmap_skbs: +- while (--i > 0) ++ while (i--) + t7xx_unmap_bat_skb(dpmaif_ctrl->dev, bat_req->bat_skb, i); + + return ret; diff --git a/queue-6.11/nfs-fix-kmsan-warning-in-decode_getfattr_attrs.patch b/queue-6.11/nfs-fix-kmsan-warning-in-decode_getfattr_attrs.patch new file mode 100644 index 00000000000..465049ae52f --- /dev/null +++ b/queue-6.11/nfs-fix-kmsan-warning-in-decode_getfattr_attrs.patch @@ -0,0 +1,69 @@ +From dc270d7159699ad6d11decadfce9633f0f71c1db Mon Sep 17 00:00:00 2001 +From: Roberto Sassu +Date: Fri, 25 Oct 2024 16:03:27 +0200 +Subject: nfs: Fix KMSAN warning in decode_getfattr_attrs() + +From: Roberto Sassu + +commit dc270d7159699ad6d11decadfce9633f0f71c1db upstream. + +Fix the following KMSAN warning: + +CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B +Tainted: [B]=BAD_PAGE +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) +===================================================== +===================================================== +BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 + decode_getfattr_attrs+0x2d6d/0x2f90 + decode_getfattr_generic+0x806/0xb00 + nfs4_xdr_dec_getattr+0x1de/0x240 + rpcauth_unwrap_resp_decode+0xab/0x100 + rpcauth_unwrap_resp+0x95/0xc0 + call_decode+0x4ff/0xb50 + __rpc_execute+0x57b/0x19d0 + rpc_execute+0x368/0x5e0 + rpc_run_task+0xcfe/0xee0 + nfs4_proc_getattr+0x5b5/0x990 + __nfs_revalidate_inode+0x477/0xd00 + nfs_access_get_cached+0x1021/0x1cc0 + nfs_do_access+0x9f/0xae0 + nfs_permission+0x1e4/0x8c0 + inode_permission+0x356/0x6c0 + link_path_walk+0x958/0x1330 + path_lookupat+0xce/0x6b0 + filename_lookup+0x23e/0x770 + vfs_statx+0xe7/0x970 + vfs_fstatat+0x1f2/0x2c0 + __se_sys_newfstatat+0x67/0x880 + __x64_sys_newfstatat+0xbd/0x120 + x64_sys_call+0x1826/0x3cf0 + do_syscall_64+0xd0/0x1b0 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +The KMSAN warning is triggered in decode_getfattr_attrs(), when calling +decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not +initialized. + +Fix the issue by initializing fattr->mdsthreshold to NULL in +nfs_fattr_init(). + +Cc: stable@vger.kernel.org # v3.5.x +Fixes: 88034c3d88c2 ("NFSv4.1 mdsthreshold attribute xdr") +Signed-off-by: Roberto Sassu +Signed-off-by: Anna Schumaker +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfs/inode.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/nfs/inode.c ++++ b/fs/nfs/inode.c +@@ -1656,6 +1656,7 @@ void nfs_fattr_init(struct nfs_fattr *fa + fattr->gencount = nfs_inc_attr_generation_counter(); + fattr->owner_name = NULL; + fattr->group_name = NULL; ++ fattr->mdsthreshold = NULL; + } + EXPORT_SYMBOL_GPL(nfs_fattr_init); + diff --git a/queue-6.11/scsi-ufs-core-start-the-rtc-update-work-later.patch b/queue-6.11/scsi-ufs-core-start-the-rtc-update-work-later.patch new file mode 100644 index 00000000000..16e8d230a85 --- /dev/null +++ b/queue-6.11/scsi-ufs-core-start-the-rtc-update-work-later.patch @@ -0,0 +1,68 @@ +From 54c814c8b23bc7617be3d46abdb896937695dbfa Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Thu, 31 Oct 2024 14:26:24 -0700 +Subject: scsi: ufs: core: Start the RTC update work later + +From: Bart Van Assche + +commit 54c814c8b23bc7617be3d46abdb896937695dbfa upstream. + +The RTC update work involves runtime resuming the UFS controller. Hence, +only start the RTC update work after runtime power management in the UFS +driver has been fully initialized. This patch fixes the following kernel +crash: + +Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP +Workqueue: events ufshcd_rtc_work +Call trace: + _raw_spin_lock_irqsave+0x34/0x8c (P) + pm_runtime_get_if_active+0x24/0x9c (L) + pm_runtime_get_if_active+0x24/0x9c + ufshcd_rtc_work+0x138/0x1b4 + process_one_work+0x148/0x288 + worker_thread+0x2cc/0x3d4 + kthread+0x110/0x114 + ret_from_fork+0x10/0x20 + +Reported-by: Neil Armstrong +Closes: https://lore.kernel.org/linux-scsi/0c0bc528-fdc2-4106-bc99-f23ae377f6f5@linaro.org/ +Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") +Cc: Bean Huo +Cc: stable@vger.kernel.org +Signed-off-by: Bart Van Assche +Link: https://lore.kernel.org/r/20241031212632.2799127-1-bvanassche@acm.org +Reviewed-by: Peter Wang +Reviewed-by: Bean Huo +Tested-by: Neil Armstrong # on SM8650-HDK +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ufs/core/ufshcd.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/drivers/ufs/core/ufshcd.c ++++ b/drivers/ufs/core/ufshcd.c +@@ -8641,6 +8641,14 @@ static int ufshcd_add_lus(struct ufs_hba + ufshcd_init_clk_scaling_sysfs(hba); + } + ++ /* ++ * The RTC update code accesses the hba->ufs_device_wlun->sdev_gendev ++ * pointer and hence must only be started after the WLUN pointer has ++ * been initialized by ufshcd_scsi_add_wlus(). ++ */ ++ schedule_delayed_work(&hba->ufs_rtc_update_work, ++ msecs_to_jiffies(UFS_RTC_UPDATE_INTERVAL_MS)); ++ + ufs_bsg_probe(hba); + scsi_scan_host(hba->host); + +@@ -8800,8 +8808,6 @@ static int ufshcd_device_init(struct ufs + ufshcd_force_reset_auto_bkops(hba); + + ufshcd_set_timestamp_attr(hba); +- schedule_delayed_work(&hba->ufs_rtc_update_work, +- msecs_to_jiffies(UFS_RTC_UPDATE_INTERVAL_MS)); + + /* Gear up to HS gear if supported */ + if (hba->max_pwr_info.is_valid) { diff --git a/queue-6.11/series b/queue-6.11/series index 424a4cd280b..b26196f66ca 100644 --- a/queue-6.11/series +++ b/queue-6.11/series @@ -120,3 +120,19 @@ dm-unstriped-cast-an-operand-to-sector_t-to-prevent-potential-uint32_t-overflow. dm-fix-a-crash-if-blk_alloc_disk-fails.patch mptcp-no-admin-perm-to-list-endpoints.patch alsa-usb-audio-add-quirk-for-hp-320-fhd-webcam.patch +scsi-ufs-core-start-the-rtc-update-work-later.patch +nfs-fix-kmsan-warning-in-decode_getfattr_attrs.patch +tracing-fix-tracefs-mount-options.patch +net-wwan-t7xx-fix-off-by-one-error-in-t7xx_dpmaif_rx_buf_alloc.patch +net-vertexcom-mse102x-fix-possible-double-free-of-tx-skb.patch +mptcp-use-sock_kfree_s-instead-of-kfree.patch +arm64-sve-discard-stale-cpu-state-when-handling-sve-traps.patch +arm64-kconfig-make-sme-depend-on-broken-for-now.patch +arm64-smccc-remove-broken-support-for-smcccv1.3-sve-discard-hint.patch +mm-slab-fix-warning-caused-by-duplicate-kmem_cache-creation-in-kmem_buckets_create.patch +kvm-ppc-book3s-hv-mask-off-lpcr_mer-for-a-vcpu-before-running-it-to-avoid-spurious-interrupts.patch +idpf-avoid-vport-access-in-idpf_get_link_ksettings.patch +idpf-fix-idpf_vc_core_init-error-path.patch +btrfs-fix-the-length-of-reserved-qgroup-to-free.patch +btrfs-fix-per-subvolume-ro-rw-flags-with-new-mount-api.patch +btrfs-reinitialize-delayed-ref-list-after-deleting-it-from-the-list.patch diff --git a/queue-6.11/tracing-fix-tracefs-mount-options.patch b/queue-6.11/tracing-fix-tracefs-mount-options.patch new file mode 100644 index 00000000000..0218cbf9789 --- /dev/null +++ b/queue-6.11/tracing-fix-tracefs-mount-options.patch @@ -0,0 +1,126 @@ +From e4d32142d1de8bcafd90ea5f4f557104f0969c41 Mon Sep 17 00:00:00 2001 +From: Kalesh Singh +Date: Wed, 30 Oct 2024 10:17:48 -0700 +Subject: tracing: Fix tracefs mount options + +From: Kalesh Singh + +commit e4d32142d1de8bcafd90ea5f4f557104f0969c41 upstream. + +Commit 78ff64081949 ("vfs: Convert tracefs to use the new mount API") +converted tracefs to use the new mount APIs caused mount options +(e.g. gid=) to not take effect. + +The tracefs superblock can be updated from multiple paths: + - on fs_initcall() to init_trace_printk_function_export() + - from a work queue to initialize eventfs + tracer_init_tracefs_work_func() + - fsconfig() syscall to mount or remount of tracefs + +The tracefs superblock root inode gets created early on in +init_trace_printk_function_export(). + +With the new mount API, tracefs effectively uses get_tree_single() instead +of the old API mount_single(). + +Previously, mount_single() ensured that the options are always applied to +the superblock root inode: + (1) If the root inode didn't exist, call fill_super() to create it + and apply the options. + (2) If the root inode exists, call reconfigure_single() which + effectively calls tracefs_apply_options() to parse and apply + options to the subperblock's fs_info and inode and remount + eventfs (if necessary) + +On the other hand, get_tree_single() effectively calls vfs_get_super() +which: + (3) If the root inode doesn't exists, calls fill_super() to create it + and apply the options. + (4) If the root inode already exists, updates the fs_context root + with the superblock's root inode. + +(4) above is always the case for tracefs mounts, since the super block's +root inode will already be created by init_trace_printk_function_export(). + +This means that the mount options get ignored: + - Since it isn't applied to the superblock's root inode, it doesn't + get inherited by the children. + - Since eventfs is initialized from a separate work queue and + before call to mount with the options, and it doesn't get remounted + for mount. + +Ensure that the mount options are applied to the super block and eventfs +is remounted to respect the mount options. + +To understand this better, if fstab has the following: + + tracefs /sys/kernel/tracing tracefs nosuid,nodev,noexec,gid=tracing 0 0 + +On boot up, permissions look like: + + # ls -l /sys/kernel/tracing/trace + -rw-r----- 1 root root 0 Nov 1 08:37 /sys/kernel/tracing/trace + +When it should look like: + + # ls -l /sys/kernel/tracing/trace + -rw-r----- 1 root tracing 0 Nov 1 08:37 /sys/kernel/tracing/trace + +Link: https://lore.kernel.org/r/536e99d3-345c-448b-adee-a21389d7ab4b@redhat.com/ + +Cc: Eric Sandeen +Cc: Mathieu Desnoyers +Cc: Shuah Khan +Cc: Ali Zahraee +Cc: Christian Brauner +Cc: David Howells +Cc: Steven Rostedt +Cc: Masami Hiramatsu +Cc: stable@vger.kernel.org +Fixes: 78ff64081949 ("vfs: Convert tracefs to use the new mount API") +Link: https://lore.kernel.org/20241030171928.4168869-2-kaleshsingh@google.com +Signed-off-by: Kalesh Singh +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + fs/tracefs/inode.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c +index 1748dff58c3b..cfc614c638da 100644 +--- a/fs/tracefs/inode.c ++++ b/fs/tracefs/inode.c +@@ -392,6 +392,9 @@ static int tracefs_reconfigure(struct fs_context *fc) + struct tracefs_fs_info *sb_opts = sb->s_fs_info; + struct tracefs_fs_info *new_opts = fc->s_fs_info; + ++ if (!new_opts) ++ return 0; ++ + sync_filesystem(sb); + /* structure copy of new mount options to sb */ + *sb_opts = *new_opts; +@@ -478,14 +481,17 @@ static int tracefs_fill_super(struct super_block *sb, struct fs_context *fc) + sb->s_op = &tracefs_super_operations; + sb->s_d_op = &tracefs_dentry_operations; + +- tracefs_apply_options(sb, false); +- + return 0; + } + + static int tracefs_get_tree(struct fs_context *fc) + { +- return get_tree_single(fc, tracefs_fill_super); ++ int err = get_tree_single(fc, tracefs_fill_super); ++ ++ if (err) ++ return err; ++ ++ return tracefs_reconfigure(fc); + } + + static void tracefs_free_fc(struct fs_context *fc) +-- +2.47.0 +