From: Greg Kroah-Hartman Date: Fri, 18 Oct 2024 07:45:50 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v5.10.228~74 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6b32ffab24bba09336d0b1d9993804803b764cdd;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: arm64-probes-fix-simulate_ldr-_literal.patch arm64-probes-fix-uprobes-for-big-endian-kernels.patch arm64-probes-remove-broken-ldr-literal-uprobe-support.patch irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch net-enetc-add-missing-static-descriptor-and-inline-keyword.patch net-enetc-block-concurrent-xdp-transmissions-during-ring-reconfiguration.patch net-enetc-disable-napi-after-all-rings-are-disabled.patch net-enetc-disable-tx-bd-rings-after-they-are-empty.patch net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch net-microchip-vcap-api-fix-memory-leaks-in-vcap_api_encode_rule_test.patch posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch --- diff --git a/queue-6.6/arm64-probes-fix-simulate_ldr-_literal.patch b/queue-6.6/arm64-probes-fix-simulate_ldr-_literal.patch new file mode 100644 index 00000000000..16c997865ed --- /dev/null +++ b/queue-6.6/arm64-probes-fix-simulate_ldr-_literal.patch @@ -0,0 +1,79 @@ +From 50f813e57601c22b6f26ced3193b9b94d70a2640 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 8 Oct 2024 16:58:47 +0100 +Subject: arm64: probes: Fix simulate_ldr*_literal() + +From: Mark Rutland + +commit 50f813e57601c22b6f26ced3193b9b94d70a2640 upstream. + +The simulate_ldr_literal() code always loads a 64-bit quantity, and when +simulating a 32-bit load into a 'W' register, it discards the most +significant 32 bits. For big-endian kernels this means that the relevant +bits are discarded, and the value returned is the the subsequent 32 bits +in memory (i.e. the value at addr + 4). + +Additionally, simulate_ldr_literal() and simulate_ldrsw_literal() use a +plain C load, which the compiler may tear or elide (e.g. if the target +is the zero register). Today this doesn't happen to matter, but it may +matter in future if trampoline code uses a LDR (literal) or LDRSW +(literal). + +Update simulate_ldr_literal() and simulate_ldrsw_literal() to use an +appropriately-sized READ_ONCE() to perform the access, which avoids +these problems. + +Fixes: 39a67d49ba35 ("arm64: kprobes instruction simulation support") +Cc: stable@vger.kernel.org +Signed-off-by: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20241008155851.801546-3-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/probes/simulate-insn.c | 18 +++++++----------- + 1 file changed, 7 insertions(+), 11 deletions(-) + +--- a/arch/arm64/kernel/probes/simulate-insn.c ++++ b/arch/arm64/kernel/probes/simulate-insn.c +@@ -171,17 +171,15 @@ simulate_tbz_tbnz(u32 opcode, long addr, + void __kprobes + simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs) + { +- u64 *load_addr; ++ unsigned long load_addr; + int xn = opcode & 0x1f; +- int disp; + +- disp = ldr_displacement(opcode); +- load_addr = (u64 *) (addr + disp); ++ load_addr = addr + ldr_displacement(opcode); + + if (opcode & (1 << 30)) /* x0-x30 */ +- set_x_reg(regs, xn, *load_addr); ++ set_x_reg(regs, xn, READ_ONCE(*(u64 *)load_addr)); + else /* w0-w30 */ +- set_w_reg(regs, xn, *load_addr); ++ set_w_reg(regs, xn, READ_ONCE(*(u32 *)load_addr)); + + instruction_pointer_set(regs, instruction_pointer(regs) + 4); + } +@@ -189,14 +187,12 @@ simulate_ldr_literal(u32 opcode, long ad + void __kprobes + simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs) + { +- s32 *load_addr; ++ unsigned long load_addr; + int xn = opcode & 0x1f; +- int disp; + +- disp = ldr_displacement(opcode); +- load_addr = (s32 *) (addr + disp); ++ load_addr = addr + ldr_displacement(opcode); + +- set_x_reg(regs, xn, *load_addr); ++ set_x_reg(regs, xn, READ_ONCE(*(s32 *)load_addr)); + + instruction_pointer_set(regs, instruction_pointer(regs) + 4); + } diff --git a/queue-6.6/arm64-probes-fix-uprobes-for-big-endian-kernels.patch b/queue-6.6/arm64-probes-fix-uprobes-for-big-endian-kernels.patch new file mode 100644 index 00000000000..bb56390f97e --- /dev/null +++ b/queue-6.6/arm64-probes-fix-uprobes-for-big-endian-kernels.patch @@ -0,0 +1,169 @@ +From 13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 8 Oct 2024 16:58:48 +0100 +Subject: arm64: probes: Fix uprobes for big-endian kernels + +From: Mark Rutland + +commit 13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7 upstream. + +The arm64 uprobes code is broken for big-endian kernels as it doesn't +convert the in-memory instruction encoding (which is always +little-endian) into the kernel's native endianness before analyzing and +simulating instructions. This may result in a few distinct problems: + +* The kernel may may erroneously reject probing an instruction which can + safely be probed. + +* The kernel may erroneously erroneously permit stepping an + instruction out-of-line when that instruction cannot be stepped + out-of-line safely. + +* The kernel may erroneously simulate instruction incorrectly dur to + interpretting the byte-swapped encoding. + +The endianness mismatch isn't caught by the compiler or sparse because: + +* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so + the compiler and sparse have no idea these contain a little-endian + 32-bit value. The core uprobes code populates these with a memcpy() + which similarly does not handle endianness. + +* While the uprobe_opcode_t type is an alias for __le32, both + arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] + to the similarly-named probe_opcode_t, which is an alias for u32. + Hence there is no endianness conversion warning. + +Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and +adding the appropriate __le32_to_cpu() conversions prior to consuming +the instruction encoding. The core uprobes copies these fields as opaque +ranges of bytes, and so is unaffected by this change. + +At the same time, remove MAX_UINSN_BYTES and consistently use +AARCH64_INSN_SIZE for clarity. + +Tested with the following: + +| #include +| #include +| +| #define noinline __attribute__((noinline)) +| +| static noinline void *adrp_self(void) +| { +| void *addr; +| +| asm volatile( +| " adrp %x0, adrp_self\n" +| " add %x0, %x0, :lo12:adrp_self\n" +| : "=r" (addr)); +| } +| +| +| int main(int argc, char *argv) +| { +| void *ptr = adrp_self(); +| bool equal = (ptr == adrp_self); +| +| printf("adrp_self => %p\n" +| "adrp_self() => %p\n" +| "%s\n", +| adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); +| +| return 0; +| } + +.... where the adrp_self() function was compiled to: + +| 00000000004007e0 : +| 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> +| 4007e4: 911f8000 add x0, x0, #0x7e0 +| 4007e8: d65f03c0 ret + +Before this patch, the ADRP is not recognized, and is assumed to be +steppable, resulting in corruption of the result: + +| # ./adrp-self +| adrp_self => 0x4007e0 +| adrp_self() => 0x4007e0 +| EQUAL +| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events +| # echo 1 > /sys/kernel/tracing/events/uprobes/enable +| # ./adrp-self +| adrp_self => 0x4007e0 +| adrp_self() => 0xffffffffff7e0 +| NOT EQUAL + +After this patch, the ADRP is correctly recognized and simulated: + +| # ./adrp-self +| adrp_self => 0x4007e0 +| adrp_self() => 0x4007e0 +| EQUAL +| # +| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events +| # echo 1 > /sys/kernel/tracing/events/uprobes/enable +| # ./adrp-self +| adrp_self => 0x4007e0 +| adrp_self() => 0x4007e0 +| EQUAL + +Fixes: 9842ceae9fa8 ("arm64: Add uprobe support") +Cc: stable@vger.kernel.org +Signed-off-by: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20241008155851.801546-4-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/uprobes.h | 8 +++----- + arch/arm64/kernel/probes/uprobes.c | 4 ++-- + 2 files changed, 5 insertions(+), 7 deletions(-) + +--- a/arch/arm64/include/asm/uprobes.h ++++ b/arch/arm64/include/asm/uprobes.h +@@ -10,11 +10,9 @@ + #include + #include + +-#define MAX_UINSN_BYTES AARCH64_INSN_SIZE +- + #define UPROBE_SWBP_INSN cpu_to_le32(BRK64_OPCODE_UPROBES) + #define UPROBE_SWBP_INSN_SIZE AARCH64_INSN_SIZE +-#define UPROBE_XOL_SLOT_BYTES MAX_UINSN_BYTES ++#define UPROBE_XOL_SLOT_BYTES AARCH64_INSN_SIZE + + typedef __le32 uprobe_opcode_t; + +@@ -23,8 +21,8 @@ struct arch_uprobe_task { + + struct arch_uprobe { + union { +- u8 insn[MAX_UINSN_BYTES]; +- u8 ixol[MAX_UINSN_BYTES]; ++ __le32 insn; ++ __le32 ixol; + }; + struct arch_probe_insn api; + bool simulate; +--- a/arch/arm64/kernel/probes/uprobes.c ++++ b/arch/arm64/kernel/probes/uprobes.c +@@ -42,7 +42,7 @@ int arch_uprobe_analyze_insn(struct arch + else if (!IS_ALIGNED(addr, AARCH64_INSN_SIZE)) + return -EINVAL; + +- insn = *(probe_opcode_t *)(&auprobe->insn[0]); ++ insn = le32_to_cpu(auprobe->insn); + + switch (arm_probe_decode_insn(insn, &auprobe->api)) { + case INSN_REJECTED: +@@ -108,7 +108,7 @@ bool arch_uprobe_skip_sstep(struct arch_ + if (!auprobe->simulate) + return false; + +- insn = *(probe_opcode_t *)(&auprobe->insn[0]); ++ insn = le32_to_cpu(auprobe->insn); + addr = instruction_pointer(regs); + + if (auprobe->api.handler) diff --git a/queue-6.6/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch b/queue-6.6/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch new file mode 100644 index 00000000000..eb3ae6f314c --- /dev/null +++ b/queue-6.6/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch @@ -0,0 +1,121 @@ +From acc450aa07099d071b18174c22a1119c57da8227 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 8 Oct 2024 16:58:46 +0100 +Subject: arm64: probes: Remove broken LDR (literal) uprobe support + +From: Mark Rutland + +commit acc450aa07099d071b18174c22a1119c57da8227 upstream. + +The simulate_ldr_literal() and simulate_ldrsw_literal() functions are +unsafe to use for uprobes. Both functions were originally written for +use with kprobes, and access memory with plain C accesses. When uprobes +was added, these were reused unmodified even though they cannot safely +access user memory. + +There are three key problems: + +1) The plain C accesses do not have corresponding extable entries, and + thus if they encounter a fault the kernel will treat these as + unintentional accesses to user memory, resulting in a BUG() which + will kill the kernel thread, and likely lead to further issues (e.g. + lockup or panic()). + +2) The plain C accesses are subject to HW PAN and SW PAN, and so when + either is in use, any attempt to simulate an access to user memory + will fault. Thus neither simulate_ldr_literal() nor + simulate_ldrsw_literal() can do anything useful when simulating a + user instruction on any system with HW PAN or SW PAN. + +3) The plain C accesses are privileged, as they run in kernel context, + and in practice can access a small range of kernel virtual addresses. + The instructions they simulate have a range of +/-1MiB, and since the + simulated instructions must itself be a user instructions in the + TTBR0 address range, these can address the final 1MiB of the TTBR1 + acddress range by wrapping downwards from an address in the first + 1MiB of the TTBR0 address range. + + In contemporary kernels the last 8MiB of TTBR1 address range is + reserved, and accesses to this will always fault, meaning this is no + worse than (1). + + Historically, it was theoretically possible for the linear map or + vmemmap to spill into the final 8MiB of the TTBR1 address range, but + in practice this is extremely unlikely to occur as this would + require either: + + * Having enough physical memory to fill the entire linear map all the + way to the final 1MiB of the TTBR1 address range. + + * Getting unlucky with KASLR randomization of the linear map such + that the populated region happens to overlap with the last 1MiB of + the TTBR address range. + + ... and in either case if we were to spill into the final page there + would be larger problems as the final page would alias with error + pointers. + +Practically speaking, (1) and (2) are the big issues. Given there have +been no reports of problems since the broken code was introduced, it +appears that no-one is relying on probing these instructions with +uprobes. + +Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW +(literal), limiting the use of simulate_ldr_literal() and +simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR +(literal) and LDRSW (literal) will be rejected as +arm_probe_decode_insn() will return INSN_REJECTED. In future we can +consider introducing working uprobes support for these instructions, but +this will require more significant work. + +Fixes: 9842ceae9fa8 ("arm64: Add uprobe support") +Cc: stable@vger.kernel.org +Signed-off-by: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20241008155851.801546-2-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/probes/decode-insn.c | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +--- a/arch/arm64/kernel/probes/decode-insn.c ++++ b/arch/arm64/kernel/probes/decode-insn.c +@@ -99,10 +99,6 @@ arm_probe_decode_insn(probe_opcode_t ins + aarch64_insn_is_blr(insn) || + aarch64_insn_is_ret(insn)) { + api->handler = simulate_br_blr_ret; +- } else if (aarch64_insn_is_ldr_lit(insn)) { +- api->handler = simulate_ldr_literal; +- } else if (aarch64_insn_is_ldrsw_lit(insn)) { +- api->handler = simulate_ldrsw_literal; + } else { + /* + * Instruction cannot be stepped out-of-line and we don't +@@ -140,6 +136,17 @@ arm_kprobe_decode_insn(kprobe_opcode_t * + probe_opcode_t insn = le32_to_cpu(*addr); + probe_opcode_t *scan_end = NULL; + unsigned long size = 0, offset = 0; ++ struct arch_probe_insn *api = &asi->api; ++ ++ if (aarch64_insn_is_ldr_lit(insn)) { ++ api->handler = simulate_ldr_literal; ++ decoded = INSN_GOOD_NO_SLOT; ++ } else if (aarch64_insn_is_ldrsw_lit(insn)) { ++ api->handler = simulate_ldrsw_literal; ++ decoded = INSN_GOOD_NO_SLOT; ++ } else { ++ decoded = arm_probe_decode_insn(insn, &asi->api); ++ } + + /* + * If there's a symbol defined in front of and near enough to +@@ -157,7 +164,6 @@ arm_kprobe_decode_insn(kprobe_opcode_t * + else + scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE; + } +- decoded = arm_probe_decode_insn(insn, &asi->api); + + if (decoded != INSN_REJECTED && scan_end) + if (is_probed_address_atomic(addr - 1, scan_end)) diff --git a/queue-6.6/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch b/queue-6.6/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch new file mode 100644 index 00000000000..ea3a88b5a4c --- /dev/null +++ b/queue-6.6/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch @@ -0,0 +1,65 @@ +From 80e9963fb3b5509dfcabe9652d56bf4b35542055 Mon Sep 17 00:00:00 2001 +From: Nianyao Tang +Date: Sat, 6 Apr 2024 02:27:37 +0000 +Subject: irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1 + +From: Nianyao Tang + +commit 80e9963fb3b5509dfcabe9652d56bf4b35542055 upstream. + +As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19): + + "A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS + command queue does not show the command as consumed until all of its + effects are completed." + +Furthermore, VSYNC is allowed to deliver an SError when referencing a +non existent VPE. + +By these definitions, a VMAPP followed by a VSYNC is a bug, as the +later references a VPE that has been unmapped by the former. + +Fix it by eliding the VSYNC in this scenario. + +Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") +Signed-off-by: Nianyao Tang +Signed-off-by: Thomas Gleixner +Reviewed-by: Marc Zyngier +Reviewed-by: Zenghui Yu +Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-gic-v3-its.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-gic-v3-its.c ++++ b/drivers/irqchip/irq-gic-v3-its.c +@@ -786,6 +786,7 @@ static struct its_vpe *its_build_vmapp_c + struct its_cmd_block *cmd, + struct its_cmd_desc *desc) + { ++ struct its_vpe *vpe = valid_vpe(its, desc->its_vmapp_cmd.vpe); + unsigned long vpt_addr, vconf_addr; + u64 target; + bool alloc; +@@ -798,6 +799,11 @@ static struct its_vpe *its_build_vmapp_c + if (is_v4_1(its)) { + alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); + its_encode_alloc(cmd, alloc); ++ /* ++ * Unmapping a VPE is self-synchronizing on GICv4.1, ++ * no need to issue a VSYNC. ++ */ ++ vpe = NULL; + } + + goto out; +@@ -832,7 +838,7 @@ static struct its_vpe *its_build_vmapp_c + out: + its_fixup_cmd(cmd); + +- return valid_vpe(its, desc->its_vmapp_cmd.vpe); ++ return vpe; + } + + static struct its_vpe *its_build_vmapti_cmd(struct its_node *its, diff --git a/queue-6.6/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch b/queue-6.6/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch new file mode 100644 index 00000000000..8095c96648a --- /dev/null +++ b/queue-6.6/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch @@ -0,0 +1,47 @@ +From 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Fri, 11 Oct 2024 11:01:03 +0800 +Subject: net: enetc: add missing static descriptor and inline keyword + +From: Wei Fang + +commit 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 upstream. + +Fix the build warnings when CONFIG_FSL_ENETC_MDIO is not enabled. +The detailed warnings are shown as follows. + +include/linux/fsl/enetc_mdio.h:62:18: warning: no previous prototype for function 'enetc_hw_alloc' [-Wmissing-prototypes] + 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) + | ^ +include/linux/fsl/enetc_mdio.h:62:1: note: declare 'static' if the function is not intended to be used outside of this translation unit + 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) + | ^ + | static +8 warnings generated. + +Fixes: 6517798dd343 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl") +Cc: stable@vger.kernel.org +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202410102136.jQHZOcS4-lkp@intel.com/ +Signed-off-by: Wei Fang +Reviewed-by: Claudiu Manoil +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241011030103.392362-1-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/fsl/enetc_mdio.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/include/linux/fsl/enetc_mdio.h ++++ b/include/linux/fsl/enetc_mdio.h +@@ -59,7 +59,8 @@ static inline int enetc_mdio_read_c45(st + static inline int enetc_mdio_write_c45(struct mii_bus *bus, int phy_id, + int devad, int regnum, u16 value) + { return -EINVAL; } +-struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) ++static inline struct enetc_hw *enetc_hw_alloc(struct device *dev, ++ void __iomem *port_regs) + { return ERR_PTR(-EINVAL); } + + #endif diff --git a/queue-6.6/net-enetc-block-concurrent-xdp-transmissions-during-ring-reconfiguration.patch b/queue-6.6/net-enetc-block-concurrent-xdp-transmissions-during-ring-reconfiguration.patch new file mode 100644 index 00000000000..ab38d2506fc --- /dev/null +++ b/queue-6.6/net-enetc-block-concurrent-xdp-transmissions-during-ring-reconfiguration.patch @@ -0,0 +1,109 @@ +From c728a95ccf2a8ba544facfc30a4418d4c68c39f0 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Thu, 10 Oct 2024 17:20:54 +0800 +Subject: net: enetc: block concurrent XDP transmissions during ring reconfiguration + +From: Wei Fang + +commit c728a95ccf2a8ba544facfc30a4418d4c68c39f0 upstream. + +When testing the XDP_REDIRECT function on the LS1028A platform, we +found a very reproducible issue that the Tx frames can no longer be +sent out even if XDP_REDIRECT is turned off. Specifically, if there +is a lot of traffic on Rx direction, when XDP_REDIRECT is turned on, +the console may display some warnings like "timeout for tx ring #6 +clear", and all redirected frames will be dropped, the detailed log +is as follows. + +root@ls1028ardb:~# ./xdp-bench redirect eno0 eno2 +Redirecting from eno0 (ifindex 3; driver fsl_enetc) to eno2 (ifindex 4; driver fsl_enetc) +[203.849809] fsl_enetc 0000:00:00.2 eno2: timeout for tx ring #5 clear +[204.006051] fsl_enetc 0000:00:00.2 eno2: timeout for tx ring #6 clear +[204.161944] fsl_enetc 0000:00:00.2 eno2: timeout for tx ring #7 clear +eno0->eno2 1420505 rx/s 1420590 err,drop/s 0 xmit/s + xmit eno0->eno2 0 xmit/s 1420590 drop/s 0 drv_err/s 15.71 bulk-avg +eno0->eno2 1420484 rx/s 1420485 err,drop/s 0 xmit/s + xmit eno0->eno2 0 xmit/s 1420485 drop/s 0 drv_err/s 15.71 bulk-avg + +By analyzing the XDP_REDIRECT implementation of enetc driver, the +driver will reconfigure Tx and Rx BD rings when a bpf program is +installed or uninstalled, but there is no mechanisms to block the +redirected frames when enetc driver reconfigures rings. Similarly, +XDP_TX verdicts on received frames can also lead to frames being +enqueued in the Tx rings. Because XDP ignores the state set by the +netif_tx_wake_queue() API, so introduce the ENETC_TX_DOWN flag to +suppress transmission of XDP frames. + +Fixes: c33bfaf91c4c ("net: enetc: set up XDP program under enetc_reconfigure()") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241010092056.298128-3-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 14 ++++++++++++++ + drivers/net/ethernet/freescale/enetc/enetc.h | 1 + + 2 files changed, 15 insertions(+) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -902,6 +902,7 @@ static bool enetc_clean_tx_ring(struct e + + if (unlikely(tx_frm_cnt && netif_carrier_ok(ndev) && + __netif_subqueue_stopped(ndev, tx_ring->index) && ++ !test_bit(ENETC_TX_DOWN, &priv->flags) && + (enetc_bd_unused(tx_ring) >= ENETC_TXBDS_MAX_NEEDED))) { + netif_wake_subqueue(ndev, tx_ring->index); + } +@@ -1380,6 +1381,9 @@ int enetc_xdp_xmit(struct net_device *nd + int xdp_tx_bd_cnt, i, k; + int xdp_tx_frm_cnt = 0; + ++ if (unlikely(test_bit(ENETC_TX_DOWN, &priv->flags))) ++ return -ENETDOWN; ++ + enetc_lock_mdio(); + + tx_ring = priv->xdp_tx_ring[smp_processor_id()]; +@@ -1605,6 +1609,12 @@ static int enetc_clean_rx_ring_xdp(struc + break; + case XDP_TX: + tx_ring = priv->xdp_tx_ring[rx_ring->index]; ++ if (unlikely(test_bit(ENETC_TX_DOWN, &priv->flags))) { ++ enetc_xdp_drop(rx_ring, orig_i, i); ++ tx_ring->stats.xdp_tx_drops++; ++ break; ++ } ++ + xdp_tx_bd_cnt = enetc_rx_swbd_to_xdp_tx_swbd(xdp_tx_arr, + rx_ring, + orig_i, i); +@@ -2466,6 +2476,8 @@ void enetc_start(struct net_device *ndev + enetc_enable_bdrs(priv); + + netif_tx_start_all_queues(ndev); ++ ++ clear_bit(ENETC_TX_DOWN, &priv->flags); + } + EXPORT_SYMBOL_GPL(enetc_start); + +@@ -2523,6 +2535,8 @@ void enetc_stop(struct net_device *ndev) + struct enetc_ndev_priv *priv = netdev_priv(ndev); + int i; + ++ set_bit(ENETC_TX_DOWN, &priv->flags); ++ + netif_tx_stop_all_queues(ndev); + + enetc_disable_bdrs(priv); +--- a/drivers/net/ethernet/freescale/enetc/enetc.h ++++ b/drivers/net/ethernet/freescale/enetc/enetc.h +@@ -328,6 +328,7 @@ enum enetc_active_offloads { + + enum enetc_flags_bit { + ENETC_TX_ONESTEP_TSTAMP_IN_PROGRESS = 0, ++ ENETC_TX_DOWN, + }; + + /* interrupt coalescing modes */ diff --git a/queue-6.6/net-enetc-disable-napi-after-all-rings-are-disabled.patch b/queue-6.6/net-enetc-disable-napi-after-all-rings-are-disabled.patch new file mode 100644 index 00000000000..8bc968391c6 --- /dev/null +++ b/queue-6.6/net-enetc-disable-napi-after-all-rings-are-disabled.patch @@ -0,0 +1,115 @@ +From 6b58fadd44aafbbd6af5f0b965063e1fd2063992 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Thu, 10 Oct 2024 17:20:56 +0800 +Subject: net: enetc: disable NAPI after all rings are disabled + +From: Wei Fang + +commit 6b58fadd44aafbbd6af5f0b965063e1fd2063992 upstream. + +When running "xdp-bench tx eno0" to test the XDP_TX feature of ENETC +on LS1028A, it was found that if the command was re-run multiple times, +Rx could not receive the frames, and the result of xdp-bench showed +that the rx rate was 0. + +root@ls1028ardb:~# ./xdp-bench tx eno0 +Hairpinning (XDP_TX) packets on eno0 (ifindex 3; driver fsl_enetc) +Summary 2046 rx/s 0 err,drop/s +Summary 0 rx/s 0 err,drop/s +Summary 0 rx/s 0 err,drop/s +Summary 0 rx/s 0 err,drop/s + +By observing the Rx PIR and CIR registers, CIR is always 0x7FF and +PIR is always 0x7FE, which means that the Rx ring is full and can no +longer accommodate other Rx frames. Therefore, the problem is caused +by the Rx BD ring not being cleaned up. + +Further analysis of the code revealed that the Rx BD ring will only +be cleaned if the "cleaned_cnt > xdp_tx_in_flight" condition is met. +Therefore, some debug logs were added to the driver and the current +values of cleaned_cnt and xdp_tx_in_flight were printed when the Rx +BD ring was full. The logs are as follows. + +[ 178.762419] [XDP TX] >> cleaned_cnt:1728, xdp_tx_in_flight:2140 +[ 178.771387] [XDP TX] >> cleaned_cnt:1941, xdp_tx_in_flight:2110 +[ 178.776058] [XDP TX] >> cleaned_cnt:1792, xdp_tx_in_flight:2110 + +From the results, the max value of xdp_tx_in_flight has reached 2140. +However, the size of the Rx BD ring is only 2048. So xdp_tx_in_flight +did not drop to 0 after enetc_stop() is called and the driver does not +clear it. The root cause is that NAPI is disabled too aggressively, +without having waited for the pending XDP_TX frames to be transmitted, +and their buffers recycled, so that xdp_tx_in_flight cannot naturally +drop to 0. Later, enetc_free_tx_ring() does free those stale, unsent +XDP_TX packets, but it is not coded up to also reset xdp_tx_in_flight, +hence the manifestation of the bug. + +One option would be to cover this extra condition in enetc_free_tx_ring(), +but now that the ENETC_TX_DOWN exists, we have created a window at +the beginning of enetc_stop() where NAPI can still be scheduled, but +any concurrent enqueue will be blocked. Therefore, enetc_wait_bdrs() +and enetc_disable_tx_bdrs() can be called with NAPI still scheduled, +and it is guaranteed that this will not wait indefinitely, but instead +give us an indication that the pending TX frames have orderly dropped +to zero. Only then should we call napi_disable(). + +This way, enetc_free_tx_ring() becomes entirely redundant and can be +dropped as part of subsequent cleanup. + +The change also refactors enetc_start() so that it looks like the +mirror opposite procedure of enetc_stop(). + +Fixes: ff58fda09096 ("net: enetc: prioritize ability to go down over packet processing") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Tested-by: Vladimir Oltean +Link: https://patch.msgid.link/20241010092056.298128-5-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -2477,8 +2477,6 @@ void enetc_start(struct net_device *ndev + + enetc_setup_interrupts(priv); + +- enetc_enable_tx_bdrs(priv); +- + for (i = 0; i < priv->bdr_int_num; i++) { + int irq = pci_irq_vector(priv->si->pdev, + ENETC_BDR_INT_BASE_IDX + i); +@@ -2487,6 +2485,8 @@ void enetc_start(struct net_device *ndev + enable_irq(irq); + } + ++ enetc_enable_tx_bdrs(priv); ++ + enetc_enable_rx_bdrs(priv); + + netif_tx_start_all_queues(ndev); +@@ -2555,6 +2555,10 @@ void enetc_stop(struct net_device *ndev) + + enetc_disable_rx_bdrs(priv); + ++ enetc_wait_bdrs(priv); ++ ++ enetc_disable_tx_bdrs(priv); ++ + for (i = 0; i < priv->bdr_int_num; i++) { + int irq = pci_irq_vector(priv->si->pdev, + ENETC_BDR_INT_BASE_IDX + i); +@@ -2564,10 +2568,6 @@ void enetc_stop(struct net_device *ndev) + napi_disable(&priv->int_vector[i]->napi); + } + +- enetc_wait_bdrs(priv); +- +- enetc_disable_tx_bdrs(priv); +- + enetc_clear_interrupts(priv); + } + EXPORT_SYMBOL_GPL(enetc_stop); diff --git a/queue-6.6/net-enetc-disable-tx-bd-rings-after-they-are-empty.patch b/queue-6.6/net-enetc-disable-tx-bd-rings-after-they-are-empty.patch new file mode 100644 index 00000000000..75253f263b1 --- /dev/null +++ b/queue-6.6/net-enetc-disable-tx-bd-rings-after-they-are-empty.patch @@ -0,0 +1,141 @@ +From 0a93f2ca4be6c4616d371f18a3fabad2df7f8d55 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Thu, 10 Oct 2024 17:20:55 +0800 +Subject: net: enetc: disable Tx BD rings after they are empty + +From: Wei Fang + +commit 0a93f2ca4be6c4616d371f18a3fabad2df7f8d55 upstream. + +The Tx BD rings are disabled first in enetc_stop() and the driver +waits for them to become empty. This operation is not safe while +the ring is actively transmitting frames, and will cause the ring +to not be empty and hardware exception. As described in the NETC +block guide, software should only disable an active Tx ring after +all pending ring entries have been consumed (i.e. when PI = CI). +Disabling a transmit ring that is actively processing BDs risks +a HW-SW race hazard whereby a hardware resource becomes assigned +to work on one or more ring entries only to have those entries be +removed due to the ring becoming disabled. + +When testing XDP_REDIRECT feautre, although all frames were blocked +from being put into Tx rings during ring reconfiguration, the similar +warning log was still encountered: + +fsl_enetc 0000:00:00.2 eno2: timeout for tx ring #6 clear +fsl_enetc 0000:00:00.2 eno2: timeout for tx ring #7 clear + +The reason is that when there are still unsent frames in the Tx ring, +disabling the Tx ring causes the remaining frames to be unable to be +sent out. And the Tx ring cannot be restored, which means that even +if the xdp program is uninstalled, the Tx frames cannot be sent out +anymore. Therefore, correct the operation order in enect_start() and +enect_stop(). + +Fixes: ff58fda09096 ("net: enetc: prioritize ability to go down over packet processing") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241010092056.298128-4-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 36 +++++++++++++++++++-------- + 1 file changed, 26 insertions(+), 10 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -2236,18 +2236,24 @@ static void enetc_enable_rxbdr(struct en + enetc_rxbdr_wr(hw, idx, ENETC_RBMR, rbmr); + } + +-static void enetc_enable_bdrs(struct enetc_ndev_priv *priv) ++static void enetc_enable_rx_bdrs(struct enetc_ndev_priv *priv) + { + struct enetc_hw *hw = &priv->si->hw; + int i; + +- for (i = 0; i < priv->num_tx_rings; i++) +- enetc_enable_txbdr(hw, priv->tx_ring[i]); +- + for (i = 0; i < priv->num_rx_rings; i++) + enetc_enable_rxbdr(hw, priv->rx_ring[i]); + } + ++static void enetc_enable_tx_bdrs(struct enetc_ndev_priv *priv) ++{ ++ struct enetc_hw *hw = &priv->si->hw; ++ int i; ++ ++ for (i = 0; i < priv->num_tx_rings; i++) ++ enetc_enable_txbdr(hw, priv->tx_ring[i]); ++} ++ + static void enetc_disable_rxbdr(struct enetc_hw *hw, struct enetc_bdr *rx_ring) + { + int idx = rx_ring->index; +@@ -2264,18 +2270,24 @@ static void enetc_disable_txbdr(struct e + enetc_txbdr_wr(hw, idx, ENETC_TBMR, 0); + } + +-static void enetc_disable_bdrs(struct enetc_ndev_priv *priv) ++static void enetc_disable_rx_bdrs(struct enetc_ndev_priv *priv) + { + struct enetc_hw *hw = &priv->si->hw; + int i; + +- for (i = 0; i < priv->num_tx_rings; i++) +- enetc_disable_txbdr(hw, priv->tx_ring[i]); +- + for (i = 0; i < priv->num_rx_rings; i++) + enetc_disable_rxbdr(hw, priv->rx_ring[i]); + } + ++static void enetc_disable_tx_bdrs(struct enetc_ndev_priv *priv) ++{ ++ struct enetc_hw *hw = &priv->si->hw; ++ int i; ++ ++ for (i = 0; i < priv->num_tx_rings; i++) ++ enetc_disable_txbdr(hw, priv->tx_ring[i]); ++} ++ + static void enetc_wait_txbdr(struct enetc_hw *hw, struct enetc_bdr *tx_ring) + { + int delay = 8, timeout = 100; +@@ -2465,6 +2477,8 @@ void enetc_start(struct net_device *ndev + + enetc_setup_interrupts(priv); + ++ enetc_enable_tx_bdrs(priv); ++ + for (i = 0; i < priv->bdr_int_num; i++) { + int irq = pci_irq_vector(priv->si->pdev, + ENETC_BDR_INT_BASE_IDX + i); +@@ -2473,7 +2487,7 @@ void enetc_start(struct net_device *ndev + enable_irq(irq); + } + +- enetc_enable_bdrs(priv); ++ enetc_enable_rx_bdrs(priv); + + netif_tx_start_all_queues(ndev); + +@@ -2539,7 +2553,7 @@ void enetc_stop(struct net_device *ndev) + + netif_tx_stop_all_queues(ndev); + +- enetc_disable_bdrs(priv); ++ enetc_disable_rx_bdrs(priv); + + for (i = 0; i < priv->bdr_int_num; i++) { + int irq = pci_irq_vector(priv->si->pdev, +@@ -2552,6 +2566,8 @@ void enetc_stop(struct net_device *ndev) + + enetc_wait_bdrs(priv); + ++ enetc_disable_tx_bdrs(priv); ++ + enetc_clear_interrupts(priv); + } + EXPORT_SYMBOL_GPL(enetc_stop); diff --git a/queue-6.6/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch b/queue-6.6/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch new file mode 100644 index 00000000000..194a79283b6 --- /dev/null +++ b/queue-6.6/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch @@ -0,0 +1,47 @@ +From 412950d5746f7aa139e14fe95338694c1f09b595 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Thu, 10 Oct 2024 17:20:53 +0800 +Subject: net: enetc: remove xdp_drops statistic from enetc_xdp_drop() + +From: Wei Fang + +commit 412950d5746f7aa139e14fe95338694c1f09b595 upstream. + +The xdp_drops statistic indicates the number of XDP frames dropped in +the Rx direction. However, enetc_xdp_drop() is also used in XDP_TX and +XDP_REDIRECT actions. If frame loss occurs in these two actions, the +frames loss count should not be included in xdp_drops, because there +are already xdp_tx_drops and xdp_redirect_failures to count the frame +loss of these two actions, so it's better to remove xdp_drops statistic +from enetc_xdp_drop() and increase xdp_drops in XDP_DROP action. + +Fixes: 7ed2bc80074e ("net: enetc: add support for XDP_TX") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Maciej Fijalkowski +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241010092056.298128-2-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -1524,7 +1524,6 @@ static void enetc_xdp_drop(struct enetc_ + &rx_ring->rx_swbd[rx_ring_first]); + enetc_bdr_idx_inc(rx_ring, &rx_ring_first); + } +- rx_ring->stats.xdp_drops++; + } + + static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring, +@@ -1589,6 +1588,7 @@ static int enetc_clean_rx_ring_xdp(struc + fallthrough; + case XDP_DROP: + enetc_xdp_drop(rx_ring, orig_i, i); ++ rx_ring->stats.xdp_drops++; + break; + case XDP_PASS: + rxbd = orig_rxbd; diff --git a/queue-6.6/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch b/queue-6.6/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch new file mode 100644 index 00000000000..ba2b954a2ed --- /dev/null +++ b/queue-6.6/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch @@ -0,0 +1,81 @@ +From d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 Mon Sep 17 00:00:00 2001 +From: Oleksij Rempel +Date: Sun, 13 Oct 2024 07:29:16 +0200 +Subject: net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY + +From: Oleksij Rempel + +commit d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 upstream. + +A boot delay was introduced by commit 79540d133ed6 ("net: macb: Fix +handling of fixed-link node"). This delay was caused by the call to +`mdiobus_register()` in cases where a fixed-link PHY was present. The +MDIO bus registration triggered unnecessary PHY address scans, leading +to a 20-second delay due to attempts to detect Clause 45 (C45) +compatible PHYs, despite no MDIO bus being attached. + +The commit 79540d133ed6 ("net: macb: Fix handling of fixed-link node") +was originally introduced to fix a regression caused by commit +7897b071ac3b4 ("net: macb: convert to phylink"), which caused the driver +to misinterpret fixed-link nodes as PHY nodes. This resulted in warnings +like: +mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address +mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0 +... +mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31 + +This patch reworks the logic to avoid registering and allocation of the +MDIO bus when: + - The device tree contains a fixed-link node. + - There is no "mdio" child node in the device tree. + +If a child node named "mdio" exists, the MDIO bus will be registered to +support PHYs attached to the MACB's MDIO bus. Otherwise, with only a +fixed-link, the MDIO bus is skipped. + +Tested on a sama5d35 based system with a ksz8863 switch attached to +macb0. + +Fixes: 79540d133ed6 ("net: macb: Fix handling of fixed-link node") +Signed-off-by: Oleksij Rempel +Cc: stable@vger.kernel.org +Reviewed-by: Andrew Lunn +Link: https://patch.msgid.link/20241013052916.3115142-1-o.rempel@pengutronix.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cadence/macb_main.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/cadence/macb_main.c ++++ b/drivers/net/ethernet/cadence/macb_main.c +@@ -930,9 +930,6 @@ static int macb_mdiobus_register(struct + return ret; + } + +- if (of_phy_is_fixed_link(np)) +- return mdiobus_register(bp->mii_bus); +- + /* Only create the PHY from the device tree if at least one PHY is + * described. Otherwise scan the entire MDIO bus. We do this to support + * old device tree that did not follow the best practices and did not +@@ -953,8 +950,19 @@ static int macb_mdiobus_register(struct + + static int macb_mii_init(struct macb *bp) + { ++ struct device_node *child, *np = bp->pdev->dev.of_node; + int err = -ENXIO; + ++ /* With fixed-link, we don't need to register the MDIO bus, ++ * except if we have a child named "mdio" in the device tree. ++ * In that case, some devices may be attached to the MACB's MDIO bus. ++ */ ++ child = of_get_child_by_name(np, "mdio"); ++ if (child) ++ of_node_put(child); ++ else if (of_phy_is_fixed_link(np)) ++ return macb_mii_probe(bp->dev); ++ + /* Enable management port */ + macb_writel(bp, NCR, MACB_BIT(MPE)); + diff --git a/queue-6.6/net-microchip-vcap-api-fix-memory-leaks-in-vcap_api_encode_rule_test.patch b/queue-6.6/net-microchip-vcap-api-fix-memory-leaks-in-vcap_api_encode_rule_test.patch new file mode 100644 index 00000000000..1d6c638dd7b --- /dev/null +++ b/queue-6.6/net-microchip-vcap-api-fix-memory-leaks-in-vcap_api_encode_rule_test.patch @@ -0,0 +1,119 @@ +From 217a3d98d1e9891a8b1438a27dfbc64ddf01f691 Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Mon, 14 Oct 2024 20:19:22 +0800 +Subject: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jinjie Ruan + +commit 217a3d98d1e9891a8b1438a27dfbc64ddf01f691 upstream. + +Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in +kunit test") fixed the use-after-free error, but introduced below +memory leaks by removing necessary vcap_free_rule(), add it to fix it. + + unreferenced object 0xffffff80ca58b700 (size 192): + comm "kunit_try_catch", pid 1215, jiffies 4294898264 + hex dump (first 32 bytes): + 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... + 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ + backtrace (crc 9c09c3fe): + [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 + [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 + [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 + [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 + [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac + [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec + [<00000000c5d82c9a>] kthread+0x2e8/0x374 + [<00000000f4287308>] ret_from_fork+0x10/0x20 + unreferenced object 0xffffff80cc0b0400 (size 64): + comm "kunit_try_catch", pid 1215, jiffies 4294898265 + hex dump (first 32 bytes): + 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... + 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... + backtrace (crc daf014e9): + [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 + [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 + [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 + [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 + [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac + [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec + [<00000000c5d82c9a>] kthread+0x2e8/0x374 + [<00000000f4287308>] ret_from_fork+0x10/0x20 + unreferenced object 0xffffff80cc0b0700 (size 64): + comm "kunit_try_catch", pid 1215, jiffies 4294898265 + hex dump (first 32 bytes): + 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... + 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... + backtrace (crc 8d877792): + [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 + [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 + [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c + [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 + [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac + [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec + [<00000000c5d82c9a>] kthread+0x2e8/0x374 + [<00000000f4287308>] ret_from_fork+0x10/0x20 + unreferenced object 0xffffff80cc0b0900 (size 64): + comm "kunit_try_catch", pid 1215, jiffies 4294898266 + hex dump (first 32 bytes): + 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ + 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... + backtrace (crc 34181e56): + [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 + [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 + [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 + [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 + [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 + [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac + [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec + [<00000000c5d82c9a>] kthread+0x2e8/0x374 + [<00000000f4287308>] ret_from_fork+0x10/0x20 + unreferenced object 0xffffff80cc0b0980 (size 64): + comm "kunit_try_catch", pid 1215, jiffies 4294898266 + hex dump (first 32 bytes): + 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. + 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... + backtrace (crc 275fd9be): + [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 + [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 + [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 + [<000000001396a1a2>] test_add_def_fields+0xb0/0x100 + [<000000006e7621f0>] vcap_val_rule+0xa98/0x13e8 + [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 + [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac + [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec + [<00000000c5d82c9a>] kthread+0x2e8/0x374 + [<00000000f4287308>] ret_from_fork+0x10/0x20 + ...... + +Cc: stable@vger.kernel.org +Fixes: a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") +Reviewed-by: Simon Horman +Reviewed-by: Jens Emil Schulz Østergaard +Signed-off-by: Jinjie Ruan +Link: https://patch.msgid.link/20241014121922.1280583-1-ruanjinjie@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c b/drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c +index f2a5a36fdacd..7251121ab196 100644 +--- a/drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c ++++ b/drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c +@@ -1444,6 +1444,8 @@ static void vcap_api_encode_rule_test(struct kunit *test) + + ret = vcap_del_rule(&test_vctrl, &test_netdev, id); + KUNIT_EXPECT_EQ(test, 0, ret); ++ ++ vcap_free_rule(rule); + } + + static void vcap_api_set_rule_counter_test(struct kunit *test) +-- +2.47.0 + diff --git a/queue-6.6/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch b/queue-6.6/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch new file mode 100644 index 00000000000..b39e716da04 --- /dev/null +++ b/queue-6.6/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch @@ -0,0 +1,52 @@ +From d8794ac20a299b647ba9958f6d657051fc51a540 Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Wed, 9 Oct 2024 15:23:01 +0800 +Subject: posix-clock: Fix missing timespec64 check in pc_clock_settime() + +From: Jinjie Ruan + +commit d8794ac20a299b647ba9958f6d657051fc51a540 upstream. + +As Andrew pointed out, it will make sense that the PTP core +checked timespec64 struct's tv_sec and tv_nsec range before calling +ptp->info->settime64(). + +As the man manual of clock_settime() said, if tp.tv_sec is negative or +tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, +which include dynamic clocks which handles PTP clock, and the condition is +consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() +only check the timespec is valid, but not ensure that the time is +in a valid range, so check it ahead using timespec64_valid_strict() +in pc_clock_settime() and return -EINVAL if not valid. + +There are some drivers that use tp->tv_sec and tp->tv_nsec directly to +write registers without validity checks and assume that the higher layer +has checked it, which is dangerous and will benefit from this, such as +hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), +and some drivers can remove the checks of itself. + +Cc: stable@vger.kernel.org +Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks") +Acked-by: Richard Cochran +Suggested-by: Andrew Lunn +Suggested-by: Thomas Gleixner +Signed-off-by: Jinjie Ruan +Link: https://patch.msgid.link/20241009072302.1754567-2-ruanjinjie@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/posix-clock.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/time/posix-clock.c ++++ b/kernel/time/posix-clock.c +@@ -299,6 +299,9 @@ static int pc_clock_settime(clockid_t id + goto out; + } + ++ if (!timespec64_valid_strict(ts)) ++ return -EINVAL; ++ + if (cd.clk->ops.clock_settime) + err = cd.clk->ops.clock_settime(cd.clk, ts); + else diff --git a/queue-6.6/series b/queue-6.6/series index b2b2936c99c..5b6fb7a1d53 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -3,3 +3,15 @@ btrfs-fix-uninitialized-pointer-free-on-read_alloc_one_name-error.patch ksmbd-fix-user-after-free-from-session-log-off.patch alsa-hda-conexant-fix-audio-routing-for-hp-eliteone-1000-g2.patch mptcp-pm-fix-uaf-read-in-mptcp_pm_nl_rm_addr_or_subflow.patch +net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch +net-enetc-block-concurrent-xdp-transmissions-during-ring-reconfiguration.patch +net-enetc-disable-tx-bd-rings-after-they-are-empty.patch +net-enetc-disable-napi-after-all-rings-are-disabled.patch +net-enetc-add-missing-static-descriptor-and-inline-keyword.patch +posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch +arm64-probes-remove-broken-ldr-literal-uprobe-support.patch +arm64-probes-fix-simulate_ldr-_literal.patch +arm64-probes-fix-uprobes-for-big-endian-kernels.patch +net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch +net-microchip-vcap-api-fix-memory-leaks-in-vcap_api_encode_rule_test.patch +irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch