--- /dev/null
+From 50f813e57601c22b6f26ced3193b9b94d70a2640 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:47 +0100
+Subject: arm64: probes: Fix simulate_ldr*_literal()
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-3-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:48 +0100
+Subject: arm64: probes: Fix uprobes for big-endian kernels
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <stdio.h>
+| #include <stdbool.h>
+|
+| #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 <adrp_self>:
+| 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 <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-4-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <asm/insn.h>
+ #include <asm/probes.h>
+
+-#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)
--- /dev/null
+From acc450aa07099d071b18174c22a1119c57da8227 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:46 +0100
+Subject: arm64: probes: Remove broken LDR (literal) uprobe support
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-2-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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))
--- /dev/null
+From 80e9963fb3b5509dfcabe9652d56bf4b35542055 Mon Sep 17 00:00:00 2001
+From: Nianyao Tang <tangnianyao@huawei.com>
+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 <tangnianyao@huawei.com>
+
+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 <tangnianyao@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
+Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Fri, 11 Oct 2024 11:01:03 +0800
+Subject: net: enetc: add missing static descriptor and inline keyword
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202410102136.jQHZOcS4-lkp@intel.com/
+Signed-off-by: Wei Fang <wei.fang@nxp.com>
+Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241011030103.392362-1-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From c728a95ccf2a8ba544facfc30a4418d4c68c39f0 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 10 Oct 2024 17:20:54 +0800
+Subject: net: enetc: block concurrent XDP transmissions during ring reconfiguration
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241010092056.298128-3-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 6b58fadd44aafbbd6af5f0b965063e1fd2063992 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 10 Oct 2024 17:20:56 +0800
+Subject: net: enetc: disable NAPI after all rings are disabled
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241010092056.298128-5-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 0a93f2ca4be6c4616d371f18a3fabad2df7f8d55 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 10 Oct 2024 17:20:55 +0800
+Subject: net: enetc: disable Tx BD rings after they are empty
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241010092056.298128-4-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 412950d5746f7aa139e14fe95338694c1f09b595 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 10 Oct 2024 17:20:53 +0800
+Subject: net: enetc: remove xdp_drops statistic from enetc_xdp_drop()
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241010092056.298128-2-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+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 <o.rempel@pengutronix.de>
+
+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 <o.rempel@pengutronix.de>
+Cc: stable@vger.kernel.org
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://patch.msgid.link/20241013052916.3115142-1-o.rempel@pengutronix.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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));
+
--- /dev/null
+From 217a3d98d1e9891a8b1438a27dfbc64ddf01f691 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+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 <ruanjinjie@huawei.com>
+
+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 <horms@kernel.org>
+Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Link: https://patch.msgid.link/20241014121922.1280583-1-ruanjinjie@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From d8794ac20a299b647ba9958f6d657051fc51a540 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Wed, 9 Oct 2024 15:23:01 +0800
+Subject: posix-clock: Fix missing timespec64 check in pc_clock_settime()
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+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 <richardcochran@gmail.com>
+Suggested-by: Andrew Lunn <andrew@lunn.ch>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Link: https://patch.msgid.link/20241009072302.1754567-2-ruanjinjie@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
