* [PATCH net-next 00/10] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw multiplexer that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.
┌─────────────────────────────────┐
│ │ ┌──────┐
│ P1 GDM1 ├────►MT7530│
│ │ └──────┘
│ │ ETH0 (DSA conduit)
│ │
│ PSE/FE │
│ │
│ │
│ │ ┌─────┐
│ P0 CDM1 ├────►QDMA0│
│ P4 P9 GDM4 │ └─────┘
└──┬─────────────────────────┬────┘
│ │
┌──▼──┐ ┌────▼────┐
│ PPE │ │ MUX │
└─────┘ └─┬─────┬─┘
│ │
┌──▼──┐┌─▼───┐
│ ETH ││ USB │
└─────┘└─────┘
ETH1 ETH2
This series introduces support for multiple net_devices connected to the
same Frame Engine (FE) GDM port (GDM3 or GDM4) via an external hw
multiplexer. Please note GDM1 or GDM2 does not support the connection with
the external multiplexer.
---
Lorenzo Bianconi (10):
dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
net: airoha: Rely on net_device pointer in HTB callbacks
net: airoha: Rely on net_device pointer in ETS callbacks
net: airoha: Introduce airoha_gdm_dev struct
net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
net: airoha: Rely on airoha_gdm_dev pointer in airhoa_is_lan_gdm_port()
net: airoha: Support multiple net_devices for a single FE GDM port
net: airoha: Do not stop GDM port if it is shared
net: airoha: Rename get_src_port_id callback in get_sport
.../devicetree/bindings/net/airoha,en7581-eth.yaml | 44 +-
drivers/net/ethernet/airoha/airoha_eth.c | 626 +++++++++++++--------
drivers/net/ethernet/airoha/airoha_eth.h | 30 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 42 +-
4 files changed, 497 insertions(+), 245 deletions(-)
---
base-commit: 68bb4adb58e114336826e2ecc15ecf62e2890d3e
change-id: 20260324-airoha-eth-multi-serdes-fb4b556ee756
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH] selftests/bpf: Reject malformed IPv4/IPv6 skb test input
From: Sun Jian @ 2026-03-29 12:50 UTC (permalink / raw)
To: ast, daniel, andrii
Cc: martin.lau, eddyz87, song, yonghong.song, john.fastabend, kpsingh,
sdf, haoluo, jolsa, davem, edumazet, kuba, pabeni, horms, bpf,
netdev, linux-kernel, Sun Jian, syzbot+619b9ef527f510a57cfc
bpf_prog_test_run_skb() derives skb->protocol from the Ethernet header
through eth_type_trans(), but it does not verify that the provided
linear input is long enough to contain the corresponding L3 base
header.
This can construct an inconsistent skb for test_run: the packet can be
recognized as IPv6 while skb_headlen() still only covers ETH_HLEN
bytes. In that case, helpers such as bpf_skb_adjust_room() may compute
offsets based on the inferred protocol and operate on bytes beyond the
initialized linear data, which can trigger KMSAN.
Reject such malformed IPv4/IPv6 skb test input early by checking that
the linear head covers both the Ethernet header and the corresponding
IPv4/IPv6 base header before running the program.
Reported-by: syzbot+619b9ef527f510a57cfc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=619b9ef527f510a57cfc
Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
---
net/bpf/test_run.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 178c4738e63b..65cfb408f52b 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -1118,6 +1118,25 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
skb->protocol = eth_type_trans(skb, dev);
skb_reset_network_header(skb);
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ if (skb_headlen(skb) < ETH_HLEN + sizeof(struct iphdr)) {
+ ret = -EINVAL;
+ goto out;
+ }
+ break;
+#if IS_ENABLED(CONFIG_IPV6)
+ case htons(ETH_P_IPV6):
+ if (skb_headlen(skb) < ETH_HLEN + sizeof(struct ipv6hdr)) {
+ ret = -EINVAL;
+ goto out;
+ }
+ break;
+#endif
+ default:
+ break;
+ }
+
switch (skb->protocol) {
case htons(ETH_P_IP):
sk->sk_family = AF_INET;
base-commit: cbfffcca2bf0622b601b7eaf477aa29035169184
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 2/2] declance: Include the offending address with DMA errors
From: Maciej W. Rozycki @ 2026-03-29 12:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.21.2603291259140.60268@angie.orcam.me.uk>
The address latched in the I/O ASIC LANCE DMA Pointer Register uses the
TURBOchannel bus address encoding and therefore bits 33:29 of location
referred occupy bits 4:0, bits 28:2 are left-shifted by 3, and bits 1:0
are hardwired to zero. In reality no TURBOchannel system exceeds 1GiB
of RAM though, so the address reported will always fit in 16 hex digits.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
drivers/net/ethernet/amd/declance.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
linux-declance-dma-merr-addr.diff
Index: linux-macro/drivers/net/ethernet/amd/declance.c
===================================================================
--- linux-macro.orig/drivers/net/ethernet/amd/declance.c
+++ linux-macro/drivers/net/ethernet/amd/declance.c
@@ -726,8 +726,10 @@ static void lance_tx(struct net_device *
static irqreturn_t lance_dma_merr_int(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
+ u64 ldp = ioasic_read(IO_REG_LANCE_DMA_P);
- pr_err_ratelimited("%s: DMA error\n", dev->name);
+ pr_err_ratelimited("%s: DMA error at %#010llx\n", dev->name,
+ (ldp & 0x1f) << 29 | (ldp & 0xffffffe0) >> 3);
return IRQ_HANDLED;
}
^ permalink raw reply
* [PATCH net-next 1/2] declance: Rate-limit DMA errors
From: Maciej W. Rozycki @ 2026-03-29 12:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.21.2603291259140.60268@angie.orcam.me.uk>
Prevent the system from becoming unusable due to a flood of DMA error
messages.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
drivers/net/ethernet/amd/declance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
linux-declance-ratelimit.diff
Index: linux-macro/drivers/net/ethernet/amd/declance.c
===================================================================
--- linux-macro.orig/drivers/net/ethernet/amd/declance.c
+++ linux-macro/drivers/net/ethernet/amd/declance.c
@@ -727,7 +727,7 @@ static irqreturn_t lance_dma_merr_int(in
{
struct net_device *dev = dev_id;
- printk(KERN_ERR "%s: DMA error\n", dev->name);
+ pr_err_ratelimited("%s: DMA error\n", dev->name);
return IRQ_HANDLED;
}
^ permalink raw reply
* [PATCH net-next 0/2] declance: Improve DMA error reporting
From: Maciej W. Rozycki @ 2026-03-29 12:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
Hi,
Inspired by a recent discussion[1] I have come up with this pair of
small improvements to DMA error reporting with declance. Please apply.
References:
[1] Sebastian Andrzej Siewior, "declance: Remove IRQF_ONESHOT",
<https://lore.kernel.org/r/20260127135334.qUEaYP9G@linutronix.de/>
Maciej
^ permalink raw reply
* [PATCH net-next] FDDI: defza: Rate-limit memory allocation errors
From: Maciej W. Rozycki @ 2026-03-29 12:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
drivers/net/fddi/defza.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
linux-defza-ratelimit.diff
Index: linux-macro/drivers/net/fddi/defza.c
===================================================================
--- linux-macro.orig/drivers/net/fddi/defza.c
+++ linux-macro/drivers/net/fddi/defza.c
@@ -767,8 +767,9 @@ static void fza_rx(struct net_device *de
fp->rx_dma[i] = dma;
} else {
fp->stats.rx_dropped++;
- pr_notice("%s: memory squeeze, dropping packet\n",
- fp->name);
+ pr_notice_ratelimited(
+ "%s: memory squeeze, dropping packet\n",
+ fp->name);
}
err_rx:
^ permalink raw reply
* [PATCH net-next] FDDI: defxx: Rate-limit memory allocation errors
From: Maciej W. Rozycki @ 2026-03-29 12:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel
Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure, e.g.:
[...]
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 0-...!: (332 ticks this GP) idle=255c/1/0x40000000 softirq=16420123/16420123 fqs=0
rcu: (t=2103 jiffies g=35680089 q=4 ncpus=1)
rcu: rcu_sched kthread timer wakeup didn't happen for 2102 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=0 timer-softirq=12779658
rcu: rcu_sched kthread starved for 2103 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_sched state:I stack:0 pid:14 tgid:14 ppid:2 flags:0x00004000
Call Trace:
__schedule+0x258/0x580
schedule+0x19/0xa0
schedule_timeout+0x4a/0xb0
? hrtimers_cpu_dying+0x1b0/0x1b0
rcu_gp_fqs_loop+0xb1/0x450
rcu_gp_kthread+0x9d/0x130
kthread+0xb2/0xe0
? rcu_gp_init+0x4a0/0x4a0
? kthread_park+0x90/0x90
ret_from_fork+0x2d/0x50
? kthread_park+0x90/0x90
ret_from_fork_asm+0x12/0x20
entry_INT80_32+0x10d/0x10d
CPU: 0 UID: 500 PID: 21895 Comm: 31370.exe Not tainted 6.13.0-dirty #2
(here running the libstdc++-v3 testsuite).
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
drivers/net/fddi/defxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
linux-defxx-ratelimit.diff
Index: linux-macro/drivers/net/fddi/defxx.c
===================================================================
--- linux-macro.orig/drivers/net/fddi/defxx.c
+++ linux-macro/drivers/net/fddi/defxx.c
@@ -3182,7 +3182,7 @@ static void dfx_rcv_queue_process(
pkt_len + 3);
if (skb == NULL)
{
- printk("%s: Could not allocate receive buffer. Dropping packet.\n", bp->dev->name);
+ printk_ratelimited("%s: Could not allocate receive buffer. Dropping packet.\n", bp->dev->name);
bp->rcv_discards++;
break;
}
^ permalink raw reply
* Re: [PATCH] net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak
From: Jamal Hadi Salim @ 2026-03-29 12:16 UTC (permalink / raw)
To: Yochai Eisenrich; +Cc: David S . Miller, Jiri Pirko, security, netdev
In-Reply-To: <20260328211436.1010152-1-echelonh@gmail.com>
On Sat, Mar 28, 2026 at 5:14 PM Yochai Eisenrich <echelonh@gmail.com> wrote:
>
> When building netlink messages, tc_chain_fill_node() never initializes
> the tcm_info field of struct tcmsg. Since the allocation is not zeroed,
> kernel heap memory is leaked to userspace through this 4-byte field.
>
> The fix simply zeroes tcm_info alongside the other fields that are
> already initialized.
>
> Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
> Signed-off-by: Yochai Eisenrich <echelonh@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
> ---
> net/sched/cls_api.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 4829c27446e3..20f7f9ee0b35 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -2969,6 +2969,7 @@ static int tc_chain_fill_node(const struct tcf_proto_ops *tmplt_ops,
> tcm->tcm__pad1 = 0;
> tcm->tcm__pad2 = 0;
> tcm->tcm_handle = 0;
> + tcm->tcm_info = 0;
> if (block->q) {
> tcm->tcm_ifindex = qdisc_dev(block->q)->ifindex;
> tcm->tcm_parent = block->q->handle;
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH net 1/3] net/sched: cls_fw: fix NULL pointer dereference on shared blocks
From: Jamal Hadi Salim @ 2026-03-29 12:15 UTC (permalink / raw)
To: Xiang Mei; +Cc: netdev, jiri, davem, edumazet, kuba, horms, shuah, bestswngs
In-Reply-To: <CAM0EoMkspiNjXpdwnG2HaPK3n+BJkjTRbA8k4TsV4fcVk7g_Zg@mail.gmail.com>
On Fri, Mar 27, 2026 at 10:11 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On Fri, Mar 27, 2026 at 2:13 AM Xiang Mei <xmei5@asu.edu> wrote:
> >
> > The old-method path in fw_classify() calls tcf_block_q() and
> > dereferences q->handle. Shared blocks leave block->q NULL, causing a
> > NULL deref when an empty cls_fw filter is attached to a shared block
> > and a packet with a nonzero major skb mark is classified.
> >
> > Check tcf_block_shared() before accessing block->q and return -1 (no
> > match) for shared blocks, consistent with cls_u32's tc_u_common_ptr().
> >
> > The fixed null-ptr-deref calling stack:
> > KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> > RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
> > Call Trace:
> > tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
> > tc_run (net/core/dev.c:4401)
> > __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
> >
> > Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc")
> > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > Signed-off-by: Xiang Mei <xmei5@asu.edu>
>
> Thanks for also providing the tdc tests. Looks like a bizarre bug—and
> in my mind the question is does fw or flow even factor into tc blocks?
> Please give me time to review if the approach makes sense - perhaps
> this weekend.
>
Since the fix is exactly as what u32 does - why not move
tc_u_common_ptr() to a header file (pkt_cls.h)? then reuse it in u32,
fw, and flow.
I am still questioning the value of using blocks with these two
classifiers and unfortunately the commit message of 1abf272022cf was
not helpful.
The testcases look good. Please add a letter head, perhaps quote the
comment in tc_u_common_ptr() since it gives a good description of this
whole dance.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH iproute2-next v2] dpll: Send object per event in JSON monitor mode
From: Petr Oros @ 2026-03-29 11:47 UTC (permalink / raw)
To: Vitaly Grinberg, netdev; +Cc: stephen
In-Reply-To: <20260329-dpll-mon-j-v2-1-c8170a80e6d8@redhat.com>
> Previously, monitor mode wrapped all events in a single JSON array
> inside a top-level object, which made piping the output to external
> tools (such as `jq`) impossible.
> Send a separate JSON object for each event in monitor mode,
> making the output suitable for line-by-line consumers. Skip the
> global JSON wrapper for monitor mode.
>
> Signed-off-by: Vitaly Grinberg <vgrinber@redhat.com>
> ---
> v2:
> - Fixed indentation
> ---
> dpll/dpll.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/dpll/dpll.c b/dpll/dpll.c
> index 9893ca8c..49576d23 100644
> --- a/dpll/dpll.c
> +++ b/dpll/dpll.c
> @@ -571,8 +571,15 @@ int main(int argc, char **argv)
> argc -= optind;
> argv += optind;
>
> - new_json_obj_plain(json);
> - open_json_object(NULL);
> + /* Monitor emits one JSON object per event for streaming;
> + * other commands use a single JSON wrapper object.
> + */
> + bool is_monitor = argc > 0 && strcmp(argv[0], "monitor") == 0;
> +
> + if (!is_monitor) {
> + new_json_obj_plain(json);
> + open_json_object(NULL);
> + }
>
> /* Skip netlink init for help commands */
> bool need_nl = true;
> @@ -602,8 +609,10 @@ dpll_fini:
> if (need_nl)
> dpll_fini(dpll);
> json_cleanup:
> - close_json_object();
> - delete_json_obj_plain();
> + if (!is_monitor) {
> + close_json_object();
> + delete_json_obj_plain();
> + }
> dpll_free:
> dpll_free(dpll);
> return ret;
> @@ -2173,6 +2182,7 @@ static int cmd_monitor_cb(const struct nlmsghdr *nlh, void *data)
>
> mnl_attr_parse(nlh, sizeof(struct genlmsghdr), attr_cb, tb);
>
> + new_json_obj_plain(json);
> open_json_object(NULL);
> print_string(PRINT_JSON, "name", NULL, json_name);
> open_json_object("msg");
> @@ -2182,6 +2192,7 @@ static int cmd_monitor_cb(const struct nlmsghdr *nlh, void *data)
>
> close_json_object();
> close_json_object();
> + delete_json_obj_plain();
> break;
> }
> case DPLL_CMD_PIN_CREATE_NTF:
> @@ -2200,6 +2211,7 @@ static int cmd_monitor_cb(const struct nlmsghdr *nlh, void *data)
> json_name = "pin-delete-ntf";
> }
>
> + new_json_obj_plain(json);
> open_json_object(NULL);
> print_string(PRINT_JSON, "name", NULL, json_name);
> open_json_object("msg");
> @@ -2209,6 +2221,7 @@ static int cmd_monitor_cb(const struct nlmsghdr *nlh, void *data)
>
> close_json_object();
> close_json_object();
> + delete_json_obj_plain();
> break;
> }
> default:
> @@ -2273,8 +2286,6 @@ static int cmd_monitor(struct dpll *dpll)
> goto err_signalfd;
> }
>
> - open_json_array(PRINT_JSON, "monitor");
> -
> pfds[0].fd = signal_fd;
> pfds[0].events = POLLIN;
> pfds[1].fd = netlink_fd;
> @@ -2307,8 +2318,6 @@ static int cmd_monitor(struct dpll *dpll)
> }
> }
>
> - close_json_array(PRINT_JSON, NULL);
> -
> err_signalfd:
> if (signal_fd >= 0)
> close(signal_fd);
>
> ---
> base-commit: 36252727bfc653905bb39bec115a32869452beb1
> change-id: 20260328-dpll-mon-j-d88eb48c1f09
>
> Best regards,
> --
> Vitaly Grinberg <vgrinber@redhat.com>
>
>
Good idea, Thanks
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* [PATCH RFC net-next] usb: gadget: u_ether: fix eth_get_drvinfo() oops
From: Russell King (Oracle) @ 2026-03-29 11:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guilherme G. Piccoli, Kees Cook, linux-usb, netdev, Tony Luck
The following oops was observed on the nVidia Jetson Xavier NX1
platform with 7.0.0-rc5, which is caused by dev->gadget becoming NULL
while the u_ether device is still visible to userspace. Adding some
debug reveals that we see this sequence:
net usb1: gadget detached
tegra-xudc 3550000.usb: ep 0 disabled
net usb1: no gadget for drvinfo
usb1 (unregistering): left allmulticast mode
usb1 (unregistering): left promiscuous mode
l4tbr0: port 2(usb1) entered disabled state
Put a sticky plaster over this (it's racy!) I suspect
gether_detach_gadget() needs to at least take the RTNL as well to
prevent ethtool ops running concurrently with the gadget being
detached.
Unable to handle kernel NULL pointer dereference at virtual address 000000000000
00d0
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000001086b1000
[00000000000000d0] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: snd_soc_tegra210_mvc snd_soc_tegra186_asrc snd_soc_tegra210_m
ixer snd_soc_tegra210_admaif snd_soc_tegra_pcm snd_soc_tegra210_ope snd_soc_tegr
a186_dspk snd_soc_tegra210_i2s snd_soc_simple_card_utils snd_soc_tegra210_dmic s
nd_soc_tegra210_amx snd_soc_tegra210_adx snd_soc_tegra210_sfc rtw88_8822ce rtw88
_8822c rtw88_pci rtw88_core mac80211 libarc4 sha256 cfg80211 snd_soc_tegra210_ah
ub snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer tegra210_adma zram tegra_drm
zsmalloc usb_f_ncm syscopyarea usb_f_mass_storage drm_client_lib sysfillrect sy
simgblt ramoops fb_sys_fops reed_solomon nls_iso8859_1 drm_display_helper nls_cp437 vfat drm_kms_helper fb fat cec drm_dp_aux_bus tegra_aconnect usb_f_acm u_serial usb_f_rndis u_ether max77620_wdt realtek tegra_xudc phy_package snd phy_tegra194_p2u dwmac_dwc_qos_eth soundcore stmmac_platform pwm_tegra rtc_efi tegra186_gpc_dma virt_dma tegra_bpmp_thermal host1x pcie_tegra194 libcomposite udc_core drm drm_panel_orientation_quirks backlight efivarfs ip_tables
x_tables
CPU: 1 UID: 0 PID: 4181 Comm: systemd-udevd Not tainted 7.0.0-rc5-net-next+ #640 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : eth_get_drvinfo+0x4c/0x80 [u_ether]
lr : eth_get_drvinfo+0x40/0x80 [u_ether]
sp : ffff80008484bb60
x29: ffff80008484bb60 x28: ffff000083de18c0 x27: 0000000000000000
x26: 0000000000000000 x25: ffff0000947da0a8 x24: 0000000000004000
x23: ffff0000a38a5600 x22: 0000000000000000 x21: ffff80007a3a5558
x20: ffff0000947da000 x19: ffff0000a38a5608 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe09af760
x14: 0000000000000000 x13: 0000000000000020 x12: 0101010101010101
x11: 7f7f7f7f7f7f7f7f x10: 00007ffff0071c50 x9 : 0000000000000020
x8 : 0101010101010101 x7 : ffff0000a38a5634 x6 : fefefefefefefeff
x5 : ffff0000a38a562c x4 : 0000000000383030 x3 : 0000000000383030
x2 : 0000000000000020 x1 : 0000000000000000 x0 : ffff0000a38a564c
Call trace:
eth_get_drvinfo+0x4c/0x80 [u_ether] (P)
ethtool_get_drvinfo+0x54/0x1e0
__dev_ethtool+0x698/0x2000
dev_ethtool+0x90/0x1a0
dev_ioctl+0x37c/0x594
sock_ioctl+0x390/0x5bc
__arm64_sys_ioctl+0x408/0xeb4
invoke_syscall.constprop.0+0x50/0xe0
do_el0_svc+0x40/0xc0
el0_svc+0x48/0x2a0
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x19c/0x1a0
Code: 95a68811 f9468a81 d2800402 91011260 (f9406821)
---[ end trace 0000000000000000 ]---
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
1. get_maintainers.pl is picking up on the PSTORE folk because of the
mention of "ramoops" in the commit message... even though this has
nothing to do with them.
2. I think there's more bugs here as mentioned in the commit message,
since setting dev->gadget to NULL without taking any locking while
the u_ether device is still published to userspace looks mightily
dangerous. Seems to be another kernel driver that fails to obey the
basics discussed in OLS some twenty years ago concerning the order
of setup/publish/unpublish/teardown... and we still don't seem to
be able to get it right. :(
3. Patch generated against the net-next tree, because that's what I'm
working with being focussed on stmmac at the moment - but I would like
my test platform not to oops and reboot itself when I instead want it
to power off.
drivers/usb/gadget/function/u_ether.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
index 1a9e7c495e2e..d1ae91889537 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -113,6 +113,10 @@ static void eth_get_drvinfo(struct net_device *net, struct ethtool_drvinfo *p)
strscpy(p->driver, "g_ether", sizeof(p->driver));
strscpy(p->version, UETH__VERSION, sizeof(p->version));
+
+ if (!dev->gadget)
+ return;
+
strscpy(p->fw_version, dev->gadget->name, sizeof(p->fw_version));
strscpy(p->bus_info, dev_name(&dev->gadget->dev), sizeof(p->bus_info));
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 net-next 3/8] dpll: extend pin notifier and netlink events with notification source ID
From: Jiri Pirko @ 2026-03-29 11:24 UTC (permalink / raw)
To: Grzegorz Nitka
Cc: netdev, linux-kernel, intel-wired-lan, poros, richardcochran,
andrew+netdev, przemyslaw.kitszel, anthony.l.nguyen,
Prathosh.Satish, ivecera, arkadiusz.kubalewski, vadim.fedorenko,
donald.hunter, horms, pabeni, kuba, davem, edumazet,
Aleksandr Loktionov
In-Reply-To: <20260326162832.3135857-4-grzegorz.nitka@intel.com>
Thu, Mar 26, 2026 at 05:28:27PM +0100, grzegorz.nitka@intel.com wrote:
>Extend the DPLL pin notification API to include a source identifier
>indicating where the notification originates. This allows notifier
>consumers and netlink listeners to distinguish between notifications
>coming from an associated DPLL instance, a parent pin, or the pin
>itself.
>
>A new field, src_id, is added to struct dpll_pin_notifier_info and is
>passed through all pin-related notification paths. Callers of
>dpll_pin_notify() are updated to provide a meaningful source identifier
>based on their context:
> - pin registration/unregistration uses the DPLL's clock_id,
> - pin-on-pin operations use the parent pin's clock_id,
> - pin changes use the pin's own clock_id.
>
>As introduced in the commit ("dpll: allow registering FW-identified pin
>with a different DPLL"), it is possible to share the same physical pin
>via firmware description (fwnode) with DPLL objects from different
>kernel modules. This means that a given pin can be registered multiple
>times.
>
>Driver such as ICE (E825 devices) rely on this mechanism when listening
>for the event where a shared-fwnode pin appears, while avoiding reacting
>to events triggered by their own registration logic.
>
>This change only extends the notification metadata and does not alter
>existing semantics for drivers that do not use the new field.
>
>Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
>---
> drivers/dpll/dpll_core.c | 14 ++++++++------
> drivers/dpll/dpll_core.h | 2 +-
> drivers/dpll/dpll_netlink.c | 10 +++++-----
> drivers/dpll/dpll_netlink.h | 4 ++--
> include/linux/dpll.h | 1 +
> 5 files changed, 17 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c
>index 55ad03977d6d..c7fcae76c3f5 100644
>--- a/drivers/dpll/dpll_core.c
>+++ b/drivers/dpll/dpll_core.c
>@@ -71,7 +71,8 @@ void dpll_device_notify(struct dpll_device *dpll, unsigned long action)
> call_dpll_notifiers(action, &info);
> }
>
>-void dpll_pin_notify(struct dpll_pin *pin, unsigned long action)
>+void dpll_pin_notify(struct dpll_pin *pin, u64 ntfy_src,
I don't see the reason for "ntfy_" prefix here. Also. It's src_clock_id.
Could you perhaps consistently name this "src_clock_id" here and in the
info struct as well?
Thanks!
[..]
^ permalink raw reply
* [PATCH net-next v3 4/4] net: hsr: reject unresolved interlink ifindex
From: luka.gejak @ 2026-03-29 11:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: horms, fmaurer, liuhangbin, linux-kernel, luka.gejak
In-Reply-To: <20260329112313.17164-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
In hsr_newlink(), a provided but invalid IFLA_HSR_INTERLINK attribute
was silently ignored if __dev_get_by_index() returned NULL. This leads
to incorrect RedBox topology creation without notifying the user.
Fix this by returning -EINVAL and an extack message when the
interlink attribute is present but cannot be resolved.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_netlink.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index db0b0af7a692..f0ca23da3ab9 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -76,9 +76,14 @@ static int hsr_newlink(struct net_device *dev,
return -EINVAL;
}
- if (data[IFLA_HSR_INTERLINK])
+ if (data[IFLA_HSR_INTERLINK]) {
interlink = __dev_get_by_index(link_net,
nla_get_u32(data[IFLA_HSR_INTERLINK]));
+ if (!interlink) {
+ NL_SET_ERR_MSG_MOD(extack, "Interlink does not exist");
+ return -EINVAL;
+ }
+ }
if (interlink && interlink == link[0]) {
NL_SET_ERR_MSG_MOD(extack, "Interlink and Slave1 are the same");
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 3/4] net: hsr: require valid EOT supervision TLV
From: luka.gejak @ 2026-03-29 11:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: horms, fmaurer, liuhangbin, linux-kernel, luka.gejak
In-Reply-To: <20260329112313.17164-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
Supervision frames are only valid if terminated with a zero-length EOT
TLV. The current check fails to reject non-EOT entries as the terminal
TLV, potentially allowing malformed supervision traffic.
Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
with a length of zero.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_forward.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index aefc9b6936ba..d26c7d0e8109 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -110,7 +110,7 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
}
/* end of tlvs must follow at the end */
- if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
+ if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
hsr_sup_tlv->HSR_TLV_length != 0)
return false;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 2/4] net: hsr: fix VLAN add unwind on slave errors
From: luka.gejak @ 2026-03-29 11:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: horms, fmaurer, liuhangbin, linux-kernel, luka.gejak
In-Reply-To: <20260329112313.17164-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
When vlan_vid_add() fails for a secondary slave, the error path calls
vlan_vid_del() on the failing port instead of the peer slave that had
already succeeded. This results in asymmetric VLAN state across the HSR
pair.
Fix this by switching to a centralized unwind path that removes the VID
from any slave device that was already programmed.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_device.c | 32 +++++++++++++++++---------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 5c3eca2235ce..8ee30fc32612 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -532,8 +532,8 @@ static void hsr_change_rx_flags(struct net_device *dev, int change)
static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
__be16 proto, u16 vid)
{
- bool is_slave_a_added = false;
- bool is_slave_b_added = false;
+ struct net_device *slave_a_dev = NULL;
+ struct net_device *slave_b_dev = NULL;
struct hsr_port *port;
struct hsr_priv *hsr;
int ret = 0;
@@ -549,33 +549,35 @@ static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
switch (port->type) {
case HSR_PT_SLAVE_A:
if (ret) {
- /* clean up Slave-B */
netdev_err(dev, "add vid failed for Slave-A\n");
- if (is_slave_b_added)
- vlan_vid_del(port->dev, proto, vid);
- return ret;
+ goto unwind;
}
-
- is_slave_a_added = true;
+ slave_a_dev = port->dev;
break;
-
case HSR_PT_SLAVE_B:
if (ret) {
- /* clean up Slave-A */
netdev_err(dev, "add vid failed for Slave-B\n");
- if (is_slave_a_added)
- vlan_vid_del(port->dev, proto, vid);
- return ret;
+ goto unwind;
}
-
- is_slave_b_added = true;
+ slave_b_dev = port->dev;
break;
default:
+ if (ret)
+ goto unwind;
break;
}
}
return 0;
+
+unwind:
+ if (slave_a_dev)
+ vlan_vid_del(slave_a_dev, proto, vid);
+
+ if (slave_b_dev)
+ vlan_vid_del(slave_b_dev, proto, vid);
+
+ return ret;
}
static int hsr_ndo_vlan_rx_kill_vid(struct net_device *dev,
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 1/4] net: hsr: serialize seq_blocks merge across nodes
From: luka.gejak @ 2026-03-29 11:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: horms, fmaurer, liuhangbin, linux-kernel, luka.gejak
In-Reply-To: <20260329112313.17164-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
During node merging, hsr_handle_sup_frame() walks node_curr->seq_blocks
to update node_real without holding node_curr->seq_out_lock. This
allows concurrent mutations from duplicate registration paths, risking
inconsistent state or XArray/bitmap corruption.
Fix this by locking both nodes' seq_out_lock during the merge.
To prevent ABBA deadlocks, locks are acquired in order of memory
address.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_framereg.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
index 577fb588bc2f..d09875b33588 100644
--- a/net/hsr/hsr_framereg.c
+++ b/net/hsr/hsr_framereg.c
@@ -123,6 +123,40 @@ static void hsr_free_node_rcu(struct rcu_head *rn)
hsr_free_node(node);
}
+static void hsr_lock_seq_out_pair(struct hsr_node *node_a,
+ struct hsr_node *node_b)
+{
+ if (node_a == node_b) {
+ spin_lock_bh(&node_a->seq_out_lock);
+ return;
+ }
+
+ if (node_a < node_b) {
+ spin_lock_bh(&node_a->seq_out_lock);
+ spin_lock_nested(&node_b->seq_out_lock, SINGLE_DEPTH_NESTING);
+ } else {
+ spin_lock_bh(&node_b->seq_out_lock);
+ spin_lock_nested(&node_a->seq_out_lock, SINGLE_DEPTH_NESTING);
+ }
+}
+
+static void hsr_unlock_seq_out_pair(struct hsr_node *node_a,
+ struct hsr_node *node_b)
+{
+ if (node_a == node_b) {
+ spin_unlock_bh(&node_a->seq_out_lock);
+ return;
+ }
+
+ if (node_a < node_b) {
+ spin_unlock(&node_b->seq_out_lock);
+ spin_unlock_bh(&node_a->seq_out_lock);
+ } else {
+ spin_unlock(&node_a->seq_out_lock);
+ spin_unlock_bh(&node_b->seq_out_lock);
+ }
+}
+
void hsr_del_nodes(struct list_head *node_db)
{
struct hsr_node *node;
@@ -432,7 +466,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame)
}
ether_addr_copy(node_real->macaddress_B, ethhdr->h_source);
- spin_lock_bh(&node_real->seq_out_lock);
+ hsr_lock_seq_out_pair(node_real, node_curr);
for (i = 0; i < HSR_PT_PORTS; i++) {
if (!node_curr->time_in_stale[i] &&
time_after(node_curr->time_in[i], node_real->time_in[i])) {
@@ -455,7 +489,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame)
src_blk->seq_nrs[i], HSR_SEQ_BLOCK_SIZE);
}
}
- spin_unlock_bh(&node_real->seq_out_lock);
+ hsr_unlock_seq_out_pair(node_real, node_curr);
node_real->addr_B_port = port_rcv->type;
spin_lock_bh(&hsr->list_lock);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 0/4] net: hsr: address functional and concurrency bugs
From: luka.gejak @ 2026-03-29 11:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: horms, fmaurer, liuhangbin, linux-kernel, luka.gejak
From: Luka Gejak <luka.gejak@linux.dev>
Changes in v3:
- addressed Felix review feedback in the VLAN add unwind fix
- removed the superfluous empty line
Changes in v2:
- picked up Reviewed-by tags on patches 1, 3 and 4
- changes in patch 2 per advice of Felix Maurer
This series addresses four logic bugs in the HSR/PRP implementation
identified during a protocol audit.
The primary change resolves a race condition in the node merging path by
implementing address-based lock ordering. This ensures that concurrent
mutations of sequence blocks do not lead to state corruption or
deadlocks.
Additional fixes include correcting asymmetric VLAN error unwinding,
enforcing strict supervision frame TLV validation, and improving Netlink
error reporting for invalid interlink attributes.
Luka Gejak (4):
net: hsr: serialize seq_blocks merge across nodes
net: hsr: fix VLAN add unwind on slave errors
net: hsr: require valid EOT supervision TLV
net: hsr: reject unresolved interlink ifindex
net/hsr/hsr_device.c | 32 +++++++++++++++++---------------
net/hsr/hsr_forward.c | 2 +-
net/hsr/hsr_framereg.c | 38 ++++++++++++++++++++++++++++++++++++--
net/hsr/hsr_netlink.c | 7 ++++++-
4 files changed, 60 insertions(+), 19 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH net-next 2/2] devlink: unregister shared devlink resources on destroy
From: Jiri Pirko @ 2026-03-29 11:17 UTC (permalink / raw)
To: Przemek Kitszel
Cc: netdev, Jakub Kicinski, Tony Nguyen, intel-wired-lan,
Aleksandr Loktionov, edumazet, horms, pabeni, davem,
Michal Schmidt
In-Reply-To: <b78d4c11-e20b-4a84-b8da-2638df46c46c@intel.com>
Thu, Mar 26, 2026 at 06:44:49AM +0100, przemyslaw.kitszel@intel.com wrote:
>On 3/26/26 06:20, Jiri Pirko wrote:
>> Wed, Mar 25, 2026 at 07:26:53AM +0100, przemyslaw.kitszel@intel.com wrote:
>> > Since shared devlink acts as a normal devlink instance, capable of all
>> > usual devlink operations, it must unregister its resources.
>> >
>> > I plan to make use of devlink resources on a shared instance for ice
>> > driver by separate series, coming soon.
>> >
>> > Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> > ---
>> > net/devlink/sh_dev.c | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/net/devlink/sh_dev.c b/net/devlink/sh_dev.c
>> > index b85e5cb1edbe..5de138bf3630 100644
>> > --- a/net/devlink/sh_dev.c
>> > +++ b/net/devlink/sh_dev.c
>> > @@ -71,6 +71,7 @@ static void devlink_shd_destroy(struct devlink_shd *shd)
>> >
>> > list_del(&shd->list);
>> > devl_lock(devlink);
>> > + devl_resources_unregister(devlink);
>>
>> Hmm. It is driver's responsibility to call this on appropriate place,
>> symmetric to resource register. Why to have this in code for sh?
>>
>> The idea I had was to have callbacks to driver to do things like this
>> and more eventually. Would it work for you?
>
>for driver stuff that could be useful (say, someone wants to have
>an additional data structure to iterate and free), OTOH, each
>entity that is sharing should "unplug" from shared devlink, so
>those structures should be emptied anyway
>for my stuff in ice I managed to do without destructor
>
>coming back to devlink stuff - all things (resources, health)
>would need same cleaning in all drives, so putting that in
>devlink_shd_destroy() will simply take the burden off devs
>(at the expense of less symmetric code for normal/shared
>devlinks)
I think that devs can handle the burden for the sake of symmetricity.
>
>in short: I'm ok with any of
>a. callback for all cleanup
>b. callback for driver-specific cleanup
>c. no callback and no driver-specific cleanup (until someone needs
> that very much)
>
>thanks!
>
>>
>>
>> > devl_unregister(devlink);
>> > devl_unlock(devlink);
>> > kfree(shd->id);
>> > --
>> > 2.51.1
>> >
>
^ permalink raw reply
* Re: [PATCH v1 net-next] tun: Ignore tun in netdev_lock_pos().
From: kernel test robot @ 2026-03-29 11:10 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Willem de Bruijn, Jason Wang, Andrew Lunn
Cc: oe-kbuild-all, netdev, Simon Horman, Kuniyuki Iwashima
In-Reply-To: <20260327213441.3781433-1-kuniyu@google.com>
Hi Kuniyuki,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/tun-Ignore-tun-in-netdev_lock_pos/20260328-220059
base: net-next/main
patch link: https://lore.kernel.org/r/20260327213441.3781433-1-kuniyu%40google.com
patch subject: [PATCH v1 net-next] tun: Ignore tun in netdev_lock_pos().
config: x86_64-rhel-9.4-kselftests (https://download.01.org/0day-ci/archive/20260329/202603291907.vWkbcfS4-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260329/202603291907.vWkbcfS4-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603291907.vWkbcfS4-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: vmlinux.o: in function `netdev_lock_pos':
>> net/core/dev.c:540:(.text+0x24fe910): undefined reference to `tun_link_ops'
>> ld: net/core/dev.c:540:(.text+0x254084c): undefined reference to `tun_link_ops'
vim +540 net/core/dev.c
529
530 static inline unsigned short netdev_lock_pos(const struct net_device *dev)
531 {
532 unsigned short dev_type = dev->type;
533 int i;
534
535 for (i = 0; i < ARRAY_SIZE(netdev_lock_type); i++)
536 if (netdev_lock_type[i] == dev_type)
537 return i;
538
539 /* the last key is used by default */
> 540 WARN_ONCE(!netdev_is_tun(dev),
541 "netdev_lock_pos() could not find dev_type=%u\n", dev_type);
542 return ARRAY_SIZE(netdev_lock_type) - 1;
543 }
544
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next v2] net: airoha: Delay offloading until all net_devices are fully registered
From: Lorenzo Bianconi @ 2026-03-29 10:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
Netfilter flowtable can theoretically try to offload flower rules as soon
as a net_device is registered while all the other ones are not
registered or initialized, triggering a possible NULL pointer dereferencing
of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
register_netdev() fails for a particular net_device, there is a small
race if Netfilter tries to offload flowtable rules before all the
net_devices are properly unregistered in airoha_probe() error patch,
triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
routine. In order to avoid any possible race, delay offloading until
all net_devices are registered in the networking subsystem.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v2:
- Do not grab flow_offload_mutex in airoha_register_gdm_devices() since
it can trigger a deadlock. Add DEV_STATE_REGISTERED flag instead to
mark when all net_devices are fully registered.
- Link to v1: https://lore.kernel.org/r/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 ++
drivers/net/ethernet/airoha/airoha_eth.h | 1 +
drivers/net/ethernet/airoha/airoha_ppe.c | 7 +++++++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..743ef0db30980ce74059dfb63553030ef3bf735f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2957,6 +2957,8 @@ static int airoha_register_gdm_devices(struct airoha_eth *eth)
return err;
}
+ set_bit(DEV_STATE_REGISTERED, ð->state);
+
return 0;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 7df4dbcd8861856c54c2a38bc89c69180ac2f6dc..af29fc74165b8fffb59f45b4725dbd963f1b876d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -88,6 +88,7 @@ enum {
enum {
DEV_STATE_INITIALIZED,
+ DEV_STATE_REGISTERED,
};
enum {
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 58b14aea7c2f33ebce11c51d892eefff692378ca..c057bb2d105d92947bb8c421d89ee94fc0c10f2f 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1389,6 +1389,13 @@ int airoha_ppe_setup_tc_block_cb(struct airoha_ppe_dev *dev, void *type_data)
struct airoha_eth *eth = ppe->eth;
int err = 0;
+ /* Netfilter flowtable can try to offload flower rules while not all
+ * the net_devices are registered or initialized. Delay offloading
+ * until all net_devices are registered in the system.
+ */
+ if (!test_bit(DEV_STATE_REGISTERED, ð->state))
+ return -EBUSY;
+
mutex_lock(&flow_offload_mutex);
if (!eth->npu)
---
base-commit: ced629dc8e5c51ff2b5d847adeeb1035cd655d58
change-id: 20260321-airoha-regiser-race-fix-fe854f61d760
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH] net/ipv6: repeat route lookup with saddr set for ECMP
From: Maximilian Moehl @ 2026-03-29 9:12 UTC (permalink / raw)
To: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, Maximilian Moehl
When the routing decision involves ECMP, the initial hash is calculated
with saddr being :: and the decision which interface to select from an
ECMP group is based on that hash. If the route lookup has to be
repeated, e.g. because a route was updated, the hash is calculated with
saddr set to the previously selected address. This can cause the
selected interface to change, breaking ongoing connections.
To ensure the initial interface selection is based on an actual saddr
the route lookup is repeated after the source address selection if a
hash was calculated.
Signed-off-by: Maximilian Moehl <maximilian@moehl.eu>
Link: https://lore.kernel.org/all/aOYLRyIlc7XU7-7n@shredder/
---
I've created a write-up of what I've done, including the steps taken
to test the patch: https://moehl.eu/blog/linux-ipv6-ecmp-instability.html
net/ipv6/ip6_output.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8e2a6b28cea7..465fce51d017 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1148,6 +1148,18 @@ static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
*dst = NULL;
}
+ /* If ECMP was involved the initial hash was calculted
+ * with saddr=:: which can result in instability
+ * when it is later re-calculated with the selected
+ * saddr. Lookup the route again with the chosen
+ * saddr to get a stable result.
+ */
+ if (fl6->mp_hash) {
+ fl6->mp_hash = 0;
+ dst_release(*dst);
+ *dst = NULL;
+ }
+
if (fl6->flowi6_oif)
flags |= RT6_LOOKUP_F_IFACE;
}
base-commit: dc9e9d61e301c087bcd990dbf2fa18ad3e2e1429
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v2] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Arend van Spriel @ 2026-03-29 10:21 UTC (permalink / raw)
To: Ronald Claveau, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, van Spriel
Cc: linux-wireless, devicetree, linux-kernel, netdev, Conor Dooley
In-Reply-To: <20260327-add-bcm43752-compatible-v2-1-5b28e6637101@aliel.fr>
On 27/03/2026 10:36, Ronald Claveau wrote:
> Add bcm43752 compatible with its bcm4329 compatible fallback.
Hi Johannes,
I moved this patch to you in patchwork. In response by Neil Armstrong to
earlier proposed patch it seems he prefers this to go through the
wireless or networking tree.
Regards,
Arend
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> The Khadas VIM4 board based on Amlogic A311D2 aka T7 features an AP6275s Wi-Fi/Bluetooth module with a BCM43752 chipset.
> This patch aims to add this chipset with its fallback to bcm4329 compatible.
>
> The original patch series is here:
> https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr
> ---
> Changes in v2:
> - Add netdev in CC.
> - Link to v1: https://lore.kernel.org/r/20260326-add-bcm43752-compatible-v1-1-b3b9a58ab38b@aliel.fr
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
^ permalink raw reply
* [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Andreas Haarmann-Thiemann @ 2026-03-29 10:11 UTC (permalink / raw)
To: linusw; +Cc: ulli.kroll, netdev, linux-arm-kernel
Hello,
I am writing to report an SKB memory leak in the Cortina Gemini Ethernet
driver (drivers/net/ethernet/cortina/gemini.c) that causes the device to
lock up under sustained receive load.
Hardware affected: Raidsonic IB-NAS4220-B (Storlink/Cortina Gemini SL3516,
ARM FA526), running OpenWrt 6.12.67.
--- Observed Behaviour ---
Under sustained RX load (e.g. large file transfers over the network), the
device freezes completely and requires a hard power cycle. No kernel panic
or oops is produced; the system simply stops responding.
--- Root Cause Analysis ---
In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when
gmac_get_queue_page() returns NULL for the second page of a multi-page
fragment, the driver logs an error and continues - but does not free the
in-progress skb that was already being assembled via napi_build_skb() /
napi_get_frags():
gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
/* BUG: skb leaked here */
port->stats.rx_dropped++;
continue;
}
This path is distinct from the similar block in gmac_cleanup_rxq(), which
correctly only logs "could not find page" without an skb in flight.
Each occurrence of this error path leaks one skb. Under sustained traffic
the leak exhausts kernel memory, causing the observed lockup.
Note: this analysis is based on code review only. The fix below has not
yet been verified on hardware due to the driver being compiled into the
kernel (CONFIG_GEMINI_ETHERNET=y) on the affected device, which prevents
loading a patched module at runtime.
--- Proposed Fix ---
Free the in-progress skb via napi_free_frags() before continuing, matching
the pattern already used elsewhere in the driver:
diff --git a/drivers/net/ethernet/cortina/gemini.c
b/drivers/net/ethernet/cortina/gemini.c
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int
budget)
gpage = gmac_get_queue_page(geth, port, mapping +
PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
+ if (skb) {
+ napi_free_frags(&port->napi);
+ skb = NULL;
+ }
port->stats.rx_dropped++;
continue;
}
--- Additional Notes ---
A similar "could not find page" error path exists in gmac_cleanup_rxq().
That path does not have an skb in flight at that point and does not require
the same fix.
I would be happy to submit this as a formal patch if the analysis looks
correct to you.
Thank you for your time.
Best regards,
Andreas Haarmann-Thiemann
eitschman@nebelreich.de
^ permalink raw reply
* [PATCH 1/1] rxrpc: reject undecryptable rxkad response tickets
From: Ren Wei @ 2026-03-29 9:54 UTC (permalink / raw)
To: security
Cc: dhowells, marc.dionne, davem, edumazet, kuba, pabeni, horms,
yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z, xuyuqiabc,
n05ec, linux-afs, netdev, linux-kernel
In-Reply-To: <cover.1774627789.git.xuyuqiabc@gmail.com>
From: Yuqi Xu <xuyuqiabc@gmail.com>
rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then
parses the buffer as plaintext without checking whether
crypto_skcipher_decrypt() succeeded.
A malformed RESPONSE can therefore use a non-block-aligned ticket
length, make the decrypt operation fail, and still drive the ticket
parser with attacker-controlled bytes.
Check the decrypt result and abort the connection with RXKADBADTICKET
when ticket decryption fails.
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/rxrpc/rxkad.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index e923d6829008..0f79d694cb08 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -958,6 +958,7 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
struct in_addr addr;
unsigned int life;
time64_t issue, now;
+ int ret;
bool little_endian;
u8 *p, *q, *name, *end;
@@ -977,8 +978,11 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
sg_init_one(&sg[0], ticket, ticket_len);
skcipher_request_set_callback(req, 0, NULL, NULL);
skcipher_request_set_crypt(req, sg, sg, ticket_len, iv.x);
- crypto_skcipher_decrypt(req);
+ ret = crypto_skcipher_decrypt(req);
skcipher_request_free(req);
+ if (ret < 0)
+ return rxrpc_abort_conn(conn, skb, RXKADBADTICKET, -EPROTO,
+ rxkad_abort_resp_tkt_short);
p = ticket;
end = p + ticket_len;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
From: Russell King (Oracle) @ 2026-03-29 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bKj-0000000ELtf-3md9@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:41PM +0000, Russell King (Oracle) wrote:
> According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time
> based scheduling) is not permitted for channels which have hardware
> TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
> TBS feature enabling during driver open") concurs with this, but it
> is incomplete.
>
> This commit avoids enabling TSO support on the channels which have
> TBS available, which, as far as the hardware is concerned, means we
> do not set the TSE bit in the DMA channel's transmit control register.
>
> However, the net device's features apply to all queues(channels), which
> means these channels may still be handed TSO skbs to transmit, and the
> driver will pass them to stmmac_tso_xmit(). This will generate the
> descriptors for TSO, even though the channel has the TSE bit clear.
>
> Fix this by checking whether the queue(channel) has TBS available,
> and if it does, fall back to software GSO support.
This is sufficient for the immediate issue of fixing the patch below,
but I think there's another issue that also needs fixing here.
TSO requires the hardware to support checksum offload, and there is
a comment in the driver:
/* DWMAC IPs can be synthesized to support tx coe only for a few tx
* queues. In that case, checksum offloading for those queues that don't
* support tx coe needs to fallback to software checksum calculation.
*
* Packets that won't trigger the COE e.g. most DSA-tagged packets will
* also have to be checksummed in software.
*/
So, it seems at the very least we need to add a check (in a subsequent
patch) for priv->plat->tx_queues_cfg[queue].coe_unsupported to
stmmac_channel_tso_permitted().
I'm also wondering about the stmmac_has_ip_ethertype() thing, which
checks whether the skb can be checksummed by the hardware, and how that
interacts with TSO, and whether that's yet another hole that needs
plugging.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox