* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Amery Hung @ 2026-04-22 22:45 UTC (permalink / raw)
To: Eduard Zingerman
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <9237d7b35463c79863488e3f2180239aab679049.camel@gmail.com>
On Wed, Apr 22, 2026 at 2:46 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> > Assign reg->id when getting referenced kptr from read program context
> > to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> > referenced skb in qdisc programs using a new field reg->parent_id in
> > a later patch.
> >
> > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > ---
> > kernel/bpf/verifier.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 41e4ea41c72e..93003a2a96b0 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > } else {
> > mark_reg_known_zero(env, regs,
> > value_regno);
> > - if (type_may_be_null(info.reg_type))
> > - regs[value_regno].id = ++env->id_gen;
> > /* A load of ctx field could have different
> > * actual load size with the one encoded in the
> > * insn. When the dst is PTR, it is for sure not
> > @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > regs[value_regno].btf = info.btf;
> > regs[value_regno].btf_id = info.btf_id;
> > + regs[value_regno].id = info.ref_obj_id;
> > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > }
>
> Hi Amery,
>
> Could you please help me double-check my understanding of this change?
>
> It adds a new behavior, if struct_ops method parameter is annotated
> with __ref, then if a field is read from such struct_ops context
> the destination register would now have it's .id == ref_obj_id
> allocated for the parameter at the beginning of do_check().
> E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
> context and parameter corresponding to `off` has `__ref` annotation
> the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
>
Right
> This change in behavior, however, becomes visible only after the
> changes to release_reference() later in the series.
> There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
> the `rB`.
>
I probably should mention it in the commit message. The purpose of the
patch is to make the implementation consistent with the design:
parent_id tracks the id of the parent objects.
Without this patch, it should still work since in this case ref_obj_id
always equals to id. When release_reference() is called on a
KF_RELEASE kfunc, the children objects will still be invalidated
correctly.
> Are the above observations correct?
>
> > + if (type_may_be_null(info.reg_type) && !regs[value_regno].id)
> > + regs[value_regno].id = ++env->id_gen;
> > }
> > regs[value_regno].type = info.reg_type;
> > }
^ permalink raw reply
* Re: [PATCH bpf-next v3 3/9] bpf: Preserve reg->id of pointer objects after null-check
From: Eduard Zingerman @ 2026-04-22 22:46 UTC (permalink / raw)
To: bot+bpf-ci, ameryhung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, memxor, martin.lau,
mykyta.yatsenko5, kernel-team, ast, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <d5679e6f2b458bb8771f83e6985247befd68fbab894a0d2a09797f0ec3a90efe@mail.kernel.org>
On Tue, 2026-04-21 at 22:52 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 93003a2a96b0..0313b7d5f6c9 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -15886,15 +15886,10 @@ static void mark_ptr_or_null_reg(struct bpf_func_state *state,
> >
> > mark_ptr_not_null_reg(reg);
> >
> > - if (!reg_may_point_to_spin_lock(reg)) {
> > - /* For not-NULL ptr, reg->ref_obj_id will be reset
> > - * in release_reference().
> > - *
> > - * reg->id is still used by spin_lock ptr. Other
> > - * than spin_lock ptr type, reg->id can be reset.
> > - */
> > - reg->id = 0;
> > - }
> > + /*
> > + * reg->id is preserved for object relationship tracking
> > + * and spin_lock lock state tracking
> > + */
>
> How does preserving reg->id interact with reg_is_init_pkt_pointer()?
>
> In v2 review, Alexei Starovoitov raised this concern: "That pointer has
> to have id == 0". Eduard Zingerman responded that dropping the id == 0
> check should be fine, but this change was not made in v3.
>
> The function reg_is_init_pkt_pointer() still checks reg->id == 0:
>
> return reg->type == which &&
> reg->id == 0 &&
> reg->off == 0 &&
>
> With this patch, if a PTR_TO_PACKET register goes through null-checking
> in mark_ptr_or_null_reg(), it will now preserve its reg->id instead of
> resetting it to 0. Would this cause reg_is_init_pkt_pointer() to
> incorrectly return false for init packet pointers?
>
> Reference: https://lore.kernel.org/bpf/CAADnVQLCKi_QL1FeybW+6MH6FAOAoRJyW06UvtX3my3yNSH5eQ@mail.gmail.com/
>
> > }
> > }
Bot concern is bogus here, reg_is_init_pkt_pointer() is called only
for PTR_TO_PACKET. mark_ptr_or_null_reg() checks for
type_may_be_null(reg->type), meaning that for it to trigger one would
need a register of type PTR_TO_PACKET | PTR_MAYBE_NULL.
It appears there is no way to construct such type at the moment.
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Eduard Zingerman @ 2026-04-22 22:50 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <CAMB2axMzeQs3WzFd1PZFB=DgR6d2ye4qzHKhATK2895ryzAEog@mail.gmail.com>
On Wed, 2026-04-22 at 15:45 -0700, Amery Hung wrote:
> On Wed, Apr 22, 2026 at 2:46 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> >
> > On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> > > Assign reg->id when getting referenced kptr from read program context
> > > to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> > > referenced skb in qdisc programs using a new field reg->parent_id in
> > > a later patch.
> > >
> > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > ---
> > > kernel/bpf/verifier.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 41e4ea41c72e..93003a2a96b0 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > } else {
> > > mark_reg_known_zero(env, regs,
> > > value_regno);
> > > - if (type_may_be_null(info.reg_type))
> > > - regs[value_regno].id = ++env->id_gen;
> > > /* A load of ctx field could have different
> > > * actual load size with the one encoded in the
> > > * insn. When the dst is PTR, it is for sure not
> > > @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > > regs[value_regno].btf = info.btf;
> > > regs[value_regno].btf_id = info.btf_id;
> > > + regs[value_regno].id = info.ref_obj_id;
> > > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > > }
> >
> > Hi Amery,
> >
> > Could you please help me double-check my understanding of this change?
> >
> > It adds a new behavior, if struct_ops method parameter is annotated
> > with __ref, then if a field is read from such struct_ops context
> > the destination register would now have it's .id == ref_obj_id
> > allocated for the parameter at the beginning of do_check().
> > E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
> > context and parameter corresponding to `off` has `__ref` annotation
> > the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
> >
>
> Right
Ack, thank you.
> > This change in behavior, however, becomes visible only after the
> > changes to release_reference() later in the series.
> > There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
> > the `rB`.
> >
>
> I probably should mention it in the commit message. The purpose of the
> patch is to make the implementation consistent with the design:
> parent_id tracks the id of the parent objects.
>
> Without this patch, it should still work since in this case ref_obj_id
> always equals to id. When release_reference() is called on a
> KF_RELEASE kfunc, the children objects will still be invalidated
> correctly.
bpf_qdisc_fail__invalid_dynptr_cross_frame.c:invalid_dynptr_cross_frame
fails if I comment out the line `regs[value_regno].id = info.ref_obj_id;`.
The added .id link is used to propagate invalidation triggered by
`free_skb(skb);` to `hdr`.
The patch seem mandatory for the series.
^ permalink raw reply
* Re: [PATCH] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Rémi Denis-Courmont @ 2026-04-22 15:18 UTC (permalink / raw)
To: Remi Denis-Courmont, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Morduan Zang
Cc: Simon Horman, netdev, linux-kernel, syzkaller-bugs,
syzbot+706f5eb79044e686c794, Morduan Zang, zhanjun
In-Reply-To: <81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com>
Hi,
Le keskiviikkona 22. huhtikuuta 2026, 4.38.07 Itä-Euroopan kesäaika Morduan
Zang a écrit :
> syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via
> pn_socket_autobind():
>
> kernel BUG at net/phonet/socket.c:213!
> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]
> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421
> Call Trace:
> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797
> __sock_sendmsg net/socket.c:812 [inline]
> __sys_sendto+0x402/0x590 net/socket.c:2280
> ...
>
> pn_socket_autobind() calls pn_socket_bind() with port 0 and, on
> -EINVAL, assumes the socket was already bound and asserts that the
> port is non-zero:
>
> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));
> if (err != -EINVAL)
> return err;
> BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> return 0; /* socket was already bound */
>
> However pn_socket_bind() also returns -EINVAL when sk->sk_state is not
> TCP_CLOSE, even when the socket has never been bound and pn_port() is
> still 0. In that case the BUG_ON() fires and panics the kernel from a
> user-triggerable path.
>
> Treat the "bind returned -EINVAL but pn_port() is still 0" case as a
> regular error and propagate -EINVAL to the caller instead of crashing.
> Existing callers already translate a non-zero return from
> pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
> only changes behaviour from panic to a normal errno.
>
> Fixes: ba113a94b750 ("Phonet: common socket glue")
> Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
> Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
> Signed-off-by: zhanjun <zhanjun@uniontech.com>
> ---
> net/phonet/socket.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/phonet/socket.c b/net/phonet/socket.c
> index 4423d483c630..de9108adfe1c 100644
> --- a/net/phonet/socket.c
> +++ b/net/phonet/socket.c
> @@ -210,7 +210,15 @@ static int pn_socket_autobind(struct socket *sock)
> sizeof(struct sockaddr_pn));
> if (err != -EINVAL)
> return err;
> - BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> + /*
> + * pn_socket_bind() can return -EINVAL both when the socket is
> + * already bound (pn_port() != 0) and when sk_state != TCP_CLOSE
> + * without a prior bind. Only the former is an "already bound"
> + * success for autobind; otherwise propagate -EINVAL instead of
> + * crashing the kernel.
> + */
> + if (!pn_port(pn_sk(sock->sk)->sobject))
> + return -EINVAL;
This could be written as just if (err != -EINVAL || unlikely(...)) return err;
> return 0; /* socket was already bound */
> }
--
德尼-库尔蒙‧雷米
https://www.remlab.net/
^ permalink raw reply
* Re: [PATCH net v3 8/8] xsk: don't support AF_XDP on 32-bit architectures
From: Jason Xing @ 2026-04-22 23:45 UTC (permalink / raw)
To: David Laight
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <20260422212741.50deeb06@pumpkin>
On Thu, Apr 23, 2026 at 4:27 AM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Wed, 22 Apr 2026 11:36:50 +0800
> Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> > descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> > uintptr_t cast:
> >
> > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> >
> > On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> > the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> > mode the chunk offset is encoded in bits 48-63 of the descriptor
> > address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> > lost entirely. The completion queue then returns a truncated address to
> > userspace, making buffer recycling impossible.
>
> I had a look at how this is used.
>
> I suspect that XSK_UNALIGNED_BUF_OFFSET_SHIFT can just be made smaller.
> The 'addr' isn't really a normal address of any kind, it is a really
> and offset into an array made up of pages of memory.
> The actual address (kernel virtual of dma) is generated by:
> ptr->array[addr >> PAGE_SHIFT] + addr & ~PAGE_MASK
> (after removing the unaligned chunk offset from 'addr').
>
> It is actually quite likely that there are enough free high bits
> even in 32bit mode.
Interesting idea. But if everything is folded into a 32-bit area, it
means the size of umem is only 20-bit. 20-bit reflects that users only
put a max 1MB data into it. It might be too small to use?
Thanks,
Jason
>
> David
>
> >
> > Since we hear no one is using AF_XDP on 32-bit arch, we decided to
> > strictly stop supporting it at compile time.
> >
> > Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> > Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> > Suggested-by: Stanislav Fomichev <sdf@fomichev.me>
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > ---
> > net/xdp/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/xdp/Kconfig b/net/xdp/Kconfig
> > index 71af2febe72a..819aa5795f50 100644
> > --- a/net/xdp/Kconfig
> > +++ b/net/xdp/Kconfig
> > @@ -1,7 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > config XDP_SOCKETS
> > bool "XDP sockets"
> > - depends on BPF_SYSCALL
> > + depends on BPF_SYSCALL && 64BIT
> > default n
> > help
> > XDP sockets allows a channel between XDP programs and
>
^ permalink raw reply
* Re: [PATCH net v3 8/8] xsk: don't support AF_XDP on 32-bit architectures
From: Jason Xing @ 2026-04-22 23:49 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Alexander Lobakin, davem, edumazet, kuba, pabeni, bjorn,
magnus.karlsson, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <aej+JZyYwUrRXD6e@boxer>
On Thu, Apr 23, 2026 at 12:58 AM Maciej Fijalkowski
<maciej.fijalkowski@intel.com> wrote:
>
> On Thu, Apr 23, 2026 at 12:37:07AM +0800, Jason Xing wrote:
> > On Thu, Apr 23, 2026 at 12:10 AM Alexander Lobakin
> > <aleksander.lobakin@intel.com> wrote:
> > >
> > > From: Jason Xing <kerneljasonxing@gmail.com>
> > > Date: Wed, 22 Apr 2026 11:36:50 +0800
> > >
> > > > From: Jason Xing <kernelxing@tencent.com>
> > > >
> > > > In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> > > > descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> > > > uintptr_t cast:
> > > >
> > > > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> > > >
> > > > On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> > > > the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> > > > mode the chunk offset is encoded in bits 48-63 of the descriptor
> > > > address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> > > > lost entirely. The completion queue then returns a truncated address to
> > > > userspace, making buffer recycling impossible.
> > >
> > > What if we relax the restriction a bit? For example, refuse to configure
> >
> > As to the bug itself, yes, It only affects the unaligned mode.
> >
> > I wonder if we can support this after someone requires us to support
> > 32-bit arch and use it in the real world, then we can use the previous
> > patch to complete the full support (which doesn't harm the path on
> > 64-bit arch).
> >
> > The code looks like this based on your suggestion. Just for the record.
> > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> > index 58da2f4f4397..03417b04592f 100644
> > --- a/net/xdp/xdp_umem.c
> > +++ b/net/xdp/xdp_umem.c
> > @@ -177,6 +177,9 @@ static int xdp_umem_reg(struct xdp_umem *umem,
> > struct xdp_umem_reg *mr)
> > if (mr->flags & ~XDP_UMEM_FLAGS_VALID)
> > return -EINVAL;
> > + if (!IS_ENABLED(CONFIG_64BIT) && unaligned_chunks)
> > + return -EOPNOTSUPP;
> > +
> > if (!unaligned_chunks && !is_power_of_2(chunk_size))
> > return -EINVAL;
> >
> > Actually I'm fine with either of them. Right now I'm not so sure which
> > direction this patch should take :)
>
> Abstracting from discussion, that is not a patch we would want against
> -net. We should not forbid 32bit on stable kernels, maybe there is someone
> in the 'basement' using 32bit xsk on stable kernel. Plus the fixes tag vs
> patch's content looks weird ;)
Sorry, I don't follow this. Any specific suggestions on how to move forward?
Now we have three approaches w/o the fixes tag:
1. completely forbid 32-bit arch
2. only forbid unaligned mode on 32-bit arch
3. completely fix/modify the allocation logic of the first frag on
32-bit (see the v2-0008 patch)
I'm wondering how to proceed with that?
Thanks,
Jason
>
> >
> > Thanks,
> > Jason
> >
> > > an XSk socket in unaligned mode if on a 32-bit arch? Or add a check
> > > under CONFIG_32_BIT like it was done in Page Pool:
> > >
> > > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> > >
> > > #ifdef CONFIG_32BIT
> > > if (((uintptr_t)skb_shinfo(skb)->destructor_arg) & ~0x1UL) != addr)
> > > // WARN_ONCE or whatever + error path
> > > #endif
> > >
> > > I never used XSk on a 32-bit arch, but back when I was working on 32-bit
> > > MIPS 1G routers, I wanted to add native XSk support to the Eth driver.
> > > Sure, just for fun, now that we have cheap AArch64 and other 64-bit
> > > embedded chips, 32-bit embedded networking SoCs are almost dead, but
> > > OTOH, as you can see, other subsystems like PP still try to support 32 bit.
> > > Especially given that this issue applies to only to the skb XSk path,
> > > not native in-driver implementations.
> > >
> > > >
> > > > Since we hear no one is using AF_XDP on 32-bit arch, we decided to
> > > > strictly stop supporting it at compile time.
> > > >
> > > > Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> > > > Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> > > > Suggested-by: Stanislav Fomichev <sdf@fomichev.me>
> > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > ---
> > > > net/xdp/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/xdp/Kconfig b/net/xdp/Kconfig
> > > > index 71af2febe72a..819aa5795f50 100644
> > > > --- a/net/xdp/Kconfig
> > > > +++ b/net/xdp/Kconfig
> > > > @@ -1,7 +1,7 @@
> > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > config XDP_SOCKETS
> > > > bool "XDP sockets"
> > > > - depends on BPF_SYSCALL
> > > > + depends on BPF_SYSCALL && 64BIT
> > > > default n
> > > > help
> > > > XDP sockets allows a channel between XDP programs and
> > >
> > > Thanks,
> > > Olek
^ permalink raw reply
* [PATCH] mctp i2c: check packet length before marking flow active
From: William A. Kennington III @ 2026-04-23 0:15 UTC (permalink / raw)
To: Jeremy Kerr, Matt Johnston, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wolfram Sang
Cc: William A. Kennington III, netdev, linux-kernel
Currently, mctp_i2c_get_tx_flow_state() is called before the packet length
sanity check. This function marks a new flow as active in the MCTP core.
If the sanity check fails, mctp_i2c_xmit() returns early without calling
mctp_i2c_lock_nest(). This results in a mismatched locking state: the
flow is active, but the I2C bus lock was never acquired for it.
When the flow is later released, mctp_i2c_release_flow() will see the
active state and queue an unlock marker. The TX thread will then
decrement midev->i2c_lock_count from 0, causing it to underflow to -1.
This underflow permanently breaks the driver's locking logic, allowing
future transmissions to occur without holding the I2C bus lock, leading
to bus collisions and potential hardware hangs.
Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
check to ensure we only transition the flow state if we are actually
going to proceed with the transmission and locking.
Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver")
Signed-off-by: William A. Kennington III <william@wkennington.com>
---
drivers/net/mctp/mctp-i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index 15fe4d1163c1..ee2913758e54 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -496,8 +496,6 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
u8 *pecp;
int rc;
- fs = mctp_i2c_get_tx_flow_state(midev, skb);
-
hdr = (void *)skb_mac_header(skb);
/* Sanity check that packet contents matches skb length,
* and can't exceed MCTP_I2C_BUFSZ
@@ -509,6 +507,8 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
return;
}
+ fs = mctp_i2c_get_tx_flow_state(midev, skb);
+
if (skb_tailroom(skb) >= 1) {
/* Linear case with space, we can just append the PEC */
skb_put(skb, 1);
--
2.54.0.rc2.533.g4f5dca5207-goog
^ permalink raw reply related
* CL37 autonegotiation not working on amd-xgbe
From: Patrick Oppenlander @ 2026-04-23 0:18 UTC (permalink / raw)
To: netdev; +Cc: Shyam-sundar.S-k, Raju.Rangoju, kuba
Hi,
A recent change [1] stopped CL37 autonegotiation from working on
amd-xgbe hardware.
The driver thinks autonegotiation is succeeding, but no data is able
to transfer across the link. Here's an mdio/phy debug log showing the
link coming up successfully in the broken state:
amd-xgbe 0000:07:00.2 control-sfp: phy powered off
amd-xgbe 0000:07:00.2 control-sfp: CL73 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: starting PHY
amd-xgbe 0000:07:00.2 control-sfp: 10GbE SFI mode set
amd-xgbe 0000:07:00.2 control-sfp: 1GbE X mode set
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN (BaseX) initialized
amd-xgbe 0000:07:00.2 control-sfp: AN PHY configuration
amd-xgbe 0000:07:00.2 control-sfp: CL73 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN (BaseX) initialized
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN enabled/restarted
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN Complete
amd-xgbe 0000:07:00.2 control-sfp: Auto negotiation successful
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN result: Complete
amd-xgbe 0000:07:00.2 control-sfp: Link is Up - 1Gbps/Full - flow control off
I've tried SFP modules and switches from multiple vendors, and no
combination of hardware successfully autonegotiates after the change.
Unfortunately there appears to be no public documentation available
for amd-xgbe, so it's basically impossible for me to debug any
further. I've included a patch which "fixes" the issue, but given the
lack of documentation I have no idea what it really does.
If there's any more information I can provide to help diagnose the
issue, please let me know.
Patrick
[1] https://patch.msgid.link/20250630192636.3838291-1-Raju.Rangoju@amd.com
-- >8 --
From d17b2e685cc0e389f9c62b6cae735b2ef7d8c49b Mon Sep 17 00:00:00 2001
From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Date: Thu, 23 Apr 2026 09:37:51 +1000
Subject: [PATCH] amd-xgbe: fix CL37 autonegotiation
Broken after 42fd432fe6d320323215ebdf4de4d0d7e56e6792.
I can't find any documentation for this hardware, so this change really
just reverts the part of the commit which made autonegotation stop
working.
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index e4334c12b3e15..7639961db0af4 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -377,10 +377,6 @@ static void xgbe_an37_set(struct xgbe_prv_data
*pdata, bool enable,
reg |= MDIO_VEND2_CTRL1_AN_RESTART;
XMDIO_WRITE(pdata, MDIO_MMD_VEND2, MDIO_CTRL1, reg);
-
- reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_PCS_DIG_CTRL);
- reg |= XGBE_VEND2_MAC_AUTO_SW;
- XMDIO_WRITE(pdata, MDIO_MMD_VEND2, MDIO_PCS_DIG_CTRL, reg);
}
static void xgbe_an37_restart(struct xgbe_prv_data *pdata)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Morduan Zang @ 2026-04-23 0:47 UTC (permalink / raw)
To: remi
Cc: courmisch, davem, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzbot+706f5eb79044e686c794, syzkaller-bugs, zhangdandan,
zhanjun
In-Reply-To: <2466095.vKB9LnXJlr@basile.remlab.net>
Hi Remi,
On Wed, Apr 22, 2026 at 06:18:48PM +0300, Remi Denis-Courmont wrote:
> This could be written as just
> if (err != -EINVAL || unlikely(...)) return err;
Thanks, that reads much better. Folded into v2 and resending now.
Morduan
^ permalink raw reply
* [PATCH net v2] net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()
From: Morduan Zang @ 2026-04-23 0:49 UTC (permalink / raw)
To: petkan
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, andrew,
michal.pecio, linux-usb, netdev, linux-kernel, syzkaller-bugs,
Zhan Jun, syzbot+3f46c095ac0ca048cb71
In-Reply-To: <73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com>
From: Zhan Jun <zhanjun@uniontech.com>
syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()
when accessing skb->len for tx statistics after usb_submit_urb() has
been called:
BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760
drivers/net/usb/rtl8150.c:712
Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
The URB completion handler write_bulk_callback() frees the skb via
dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU
in softirq context before usb_submit_urb() returns in the submitter,
so by the time the submitter reads skb->len the skb has already been
queued to the per-CPU completion_queue and freed by net_tx_action():
CPU A (xmit) CPU B (USB completion softirq)
------------ ------------------------------
dev->tx_skb = skb;
usb_submit_urb() --+
|-------> write_bulk_callback()
| dev_kfree_skb_irq(dev->tx_skb)
| net_tx_action()
| napi_skb_cache_put() <-- free
netdev->stats.tx_bytes |
+= skb->len; <-- UAF read
Fix it by caching skb->len before submitting the URB and using the
cached value when updating the tx_bytes counter.
The pre-existing tx_bytes semantics are preserved: the counter tracks
the original frame length (skb->len), not the ETH_ZLEN/USB-alignment
padded "count" value that is handed to the device. Changing that
would be a user-visible accounting change and is out of scope for
this UAF fix.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/
Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Zhan Jun <zhanjun@uniontech.com>
---
Changes in v2:
- Drop the vague "This mirrors the fix pattern used by other USB
network drivers." claim from the changelog (Michal Pecio).
- Clarify that the patch intentionally preserves the existing
tx_bytes semantics (no ETH_ZLEN/USB padding accounted), and that
adjusting that is out of scope for this UAF fix (Michal Pecio).
- Use the correct "[PATCH net]" subject prefix per
Documentation/process/maintainer-netdev.rst (Andrew Lunn).
- Add Reviewed-by: Andrew Lunn.
- No functional changes; code diff is identical to v1.
v1: https://lore.kernel.org/all/73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com/
---
drivers/net/usb/rtl8150.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 4cda0643afb6..6fc6be0cced6 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -683,6 +683,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
+ unsigned int skb_len;
int count, res;
/* pad the frame and ensure terminating USB packet, datasheet 9.2.3 */
@@ -694,6 +695,14 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+ /*
+ * Cache skb->len before submitting the URB: the URB completion
+ * handler (write_bulk_callback) frees the skb, and it may run
+ * on another CPU before usb_submit_urb() returns, which would
+ * leave skb dangling here.
+ */
+ skb_len = skb->len;
+
netif_stop_queue(netdev);
dev->tx_skb = skb;
usb_fill_bulk_urb(dev->tx_urb, dev->udev, usb_sndbulkpipe(dev->udev, 2),
@@ -709,7 +718,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
}
} else {
netdev->stats.tx_packets++;
- netdev->stats.tx_bytes += skb->len;
+ netdev->stats.tx_bytes += skb_len;
netif_trans_update(netdev);
}
--
2.51.0
^ permalink raw reply related
* [syzbot] [net?] KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash (3)
From: syzbot @ 2026-04-23 1:06 UTC (permalink / raw)
To: davem, dsahern, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzkaller-bugs, willemdebruijn.kernel
Hello,
syzbot found the following issue on:
HEAD commit: c23719abc330 Merge tag 'x86-urgent-2026-03-08' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=141b0806580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6b32b22d8934c136
dashboard link: https://syzkaller.appspot.com/bug?extid=04905b8b3523856476c0
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c0ec3784100d/disk-c23719ab.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ff5ee751c9be/vmlinux-c23719ab.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1dda25fb6996/bzImage-c23719ab.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+04905b8b3523856476c0@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash
read-write to 0xffff88810194a9c8 of 4 bytes by task 15107 on cpu 0:
udp_lib_unhash+0x1f4/0x3e0 net/ipv4/udp.c:2261
sk_common_release+0x7a/0x230 net/core/sock.c:3990
udp_lib_close+0x15/0x20 include/net/udp.h:324
inet_release+0xcd/0xf0 net/ipv4/af_inet.c:437
__sock_release net/socket.c:662 [inline]
sock_close+0x6b/0x150 net/socket.c:1455
__fput+0x29b/0x650 fs/file_table.c:469
____fput+0x1c/0x30 fs/file_table.c:497
task_work_run+0x130/0x1a0 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x1f4/0x6f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x249/0x370 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88810194a9c8 of 4 bytes by task 15111 on cpu 1:
__udp4_lib_mcast_deliver+0x9a/0x790 net/ipv4/udp.c:2564
__udp4_lib_rcv+0x972/0x1250 net/ipv4/udp.c:2749
udp_rcv+0x4f/0x60 net/ipv4/udp.c:2936
ip_protocol_deliver_rcu+0x3f7/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:584 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:628 [inline]
ip_sublist_rcv+0x415/0x6a0 net/ipv4/ip_input.c:644
ip_list_rcv+0x261/0x290 net/ipv4/ip_input.c:678
__netif_receive_skb_list_ptype net/core/dev.c:6207 [inline]
__netif_receive_skb_list_core+0x4dc/0x500 net/core/dev.c:6254
__netif_receive_skb_list net/core/dev.c:6306 [inline]
netif_receive_skb_list_internal+0x47d/0x5f0 net/core/dev.c:6397
netif_receive_skb_list+0x35/0x220 net/core/dev.c:6449
xdp_recv_frames net/bpf/test_run.c:269 [inline]
xdp_test_run_batch net/bpf/test_run.c:350 [inline]
bpf_test_run_xdp_live+0x104c/0x1360 net/bpf/test_run.c:379
bpf_prog_test_run_xdp+0x57b/0xa10 net/bpf/test_run.c:1397
bpf_prog_test_run+0x204/0x340 kernel/bpf/syscall.c:4722
__sys_bpf+0x52e/0x7e0 kernel/bpf/syscall.c:6246
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x41/0x50 kernel/bpf/syscall.c:6339
x64_sys_call+0x10cb/0x3020 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 15111 Comm: syz.6.4060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH net v2] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Morduan Zang @ 2026-04-23 1:05 UTC (permalink / raw)
To: Remi Denis-Courmont, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, syzkaller-bugs,
syzbot+706f5eb79044e686c794, zhanjun, Morduan Zang
In-Reply-To: <81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com>
syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via
pn_socket_autobind():
kernel BUG at net/phonet/socket.c:213!
RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]
RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421
Call Trace:
sock_sendmsg_nosec+0x112/0x150 net/socket.c:797
__sock_sendmsg net/socket.c:812 [inline]
__sys_sendto+0x402/0x590 net/socket.c:2280
...
pn_socket_autobind() calls pn_socket_bind() with port 0 and, on
-EINVAL, assumes the socket was already bound and asserts that the
port is non-zero:
err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));
if (err != -EINVAL)
return err;
BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
return 0; /* socket was already bound */
However pn_socket_bind() also returns -EINVAL when sk->sk_state is not
TCP_CLOSE, even when the socket has never been bound and pn_port() is
still 0. In that case the BUG_ON() fires and panics the kernel from a
user-triggerable path.
Treat the "bind returned -EINVAL but pn_port() is still 0" case as a
regular error and propagate -EINVAL to the caller instead of crashing.
Existing callers already translate a non-zero return from
pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
only changes behaviour from panic to a normal errno.
Fixes: ba113a94b750 ("Phonet: common socket glue")
Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
Suggested-by: Remi Denis-Courmont <courmisch@gmail.com>
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
Signed-off-by: zhanjun <zhanjun@uniontech.com>
---
Changes in v2:
- Fold the extra port check into the existing -EINVAL test so that
autobind now reads as a single compact "not already bound" guard
using unlikely() (Remi Denis-Courmont).
- Reword the accompanying comment accordingly; no functional change
vs. v1 other than the code-style simplification.
v1: https://lore.kernel.org/all/81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com/
---
net/phonet/socket.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/phonet/socket.c b/net/phonet/socket.c
index 4423d483c630..bbd710d95b97 100644
--- a/net/phonet/socket.c
+++ b/net/phonet/socket.c
@@ -208,9 +208,15 @@ static int pn_socket_autobind(struct socket *sock)
sa.spn_family = AF_PHONET;
err = pn_socket_bind(sock, (struct sockaddr_unsized *)&sa,
sizeof(struct sockaddr_pn));
- if (err != -EINVAL)
+ /*
+ * pn_socket_bind() also returns -EINVAL when sk_state != TCP_CLOSE
+ * without a prior bind, so -EINVAL alone is not sufficient to infer
+ * that the socket was already bound. Only treat it as "already
+ * bound" when the port is non-zero; otherwise propagate the error
+ * instead of crashing the kernel.
+ */
+ if (err != -EINVAL || unlikely(!pn_port(pn_sk(sock->sk)->sobject)))
return err;
- BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
return 0; /* socket was already bound */
}
--
2.50.1
^ permalink raw reply related
* [PATCH v1 net] udp: Use READ_ONCE()/WRITE_ONCE() for hslot->count.
From: Kuniyuki Iwashima @ 2026-04-23 1:09 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Willem de Bruijn
Cc: Simon Horman, David Held, Kuniyuki Iwashima, Kuniyuki Iwashima,
netdev, syzbot+04905b8b3523856476c0
__udp4_lib_mcast_demux_lookup() and __udp4_lib_mcast_deliver()
reads the number of sockets in the 1-tuple hash table chain
locklessly. [0]
Let's use READ_ONCE() and WRITE_ONCE() for hslot->count.
[0]:
BUG: KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash
read-write to 0xffff88810194a9c8 of 4 bytes by task 15107 on cpu 0:
udp_lib_unhash+0x1f4/0x3e0 net/ipv4/udp.c:2261
sk_common_release+0x7a/0x230 net/core/sock.c:3990
udp_lib_close+0x15/0x20 include/net/udp.h:324
inet_release+0xcd/0xf0 net/ipv4/af_inet.c:437
__sock_release net/socket.c:662 [inline]
sock_close+0x6b/0x150 net/socket.c:1455
__fput+0x29b/0x650 fs/file_table.c:469
____fput+0x1c/0x30 fs/file_table.c:497
task_work_run+0x130/0x1a0 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x1f4/0x6f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x249/0x370 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88810194a9c8 of 4 bytes by task 15111 on cpu 1:
__udp4_lib_mcast_deliver+0x9a/0x790 net/ipv4/udp.c:2564
__udp4_lib_rcv+0x972/0x1250 net/ipv4/udp.c:2749
udp_rcv+0x4f/0x60 net/ipv4/udp.c:2936
ip_protocol_deliver_rcu+0x3f7/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:584 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:628 [inline]
ip_sublist_rcv+0x415/0x6a0 net/ipv4/ip_input.c:644
ip_list_rcv+0x261/0x290 net/ipv4/ip_input.c:678
__netif_receive_skb_list_ptype net/core/dev.c:6207 [inline]
__netif_receive_skb_list_core+0x4dc/0x500 net/core/dev.c:6254
__netif_receive_skb_list net/core/dev.c:6306 [inline]
netif_receive_skb_list_internal+0x47d/0x5f0 net/core/dev.c:6397
netif_receive_skb_list+0x35/0x220 net/core/dev.c:6449
xdp_recv_frames net/bpf/test_run.c:269 [inline]
xdp_test_run_batch net/bpf/test_run.c:350 [inline]
bpf_test_run_xdp_live+0x104c/0x1360 net/bpf/test_run.c:379
bpf_prog_test_run_xdp+0x57b/0xa10 net/bpf/test_run.c:1397
bpf_prog_test_run+0x204/0x340 kernel/bpf/syscall.c:4722
__sys_bpf+0x52e/0x7e0 kernel/bpf/syscall.c:6246
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x41/0x50 kernel/bpf/syscall.c:6339
x64_sys_call+0x10cb/0x3020 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 15111 Comm: syz.6.4060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Fixes: 2dc41cff7545 ("udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver.")
Fixes: 63c6f81cdde5 ("udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup")
Reported-by: syzbot+04905b8b3523856476c0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69e97093.050a0220.24bfd3.0048.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
net/ipv4/udp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 0ac2bf4f8759..f7e6045f5985 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -323,7 +323,7 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
sock_set_flag(sk, SOCK_RCU_FREE);
sk_add_node_rcu(sk, &hslot->head);
- hslot->count++;
+ WRITE_ONCE(hslot->count, hslot->count + 1);
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
hslot2 = udp_hashslot2(udptable, udp_sk(sk)->udp_portaddr_hash);
@@ -2200,7 +2200,7 @@ void udp_lib_unhash(struct sock *sk)
if (rcu_access_pointer(sk->sk_reuseport_cb))
reuseport_detach_sock(sk);
if (sk_del_node_init_rcu(sk)) {
- hslot->count--;
+ WRITE_ONCE(hslot->count, hslot->count - 1);
inet_sk(sk)->inet_num = 0;
sock_prot_inuse_add(net, sk->sk_prot, -1);
@@ -2471,7 +2471,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
hash2_any = 0;
hash2 = 0;
hslot = udp_hashslot(udptable, net, hnum);
- use_hash2 = hslot->count > 10;
+ use_hash2 = READ_ONCE(hslot->count) > 10;
offset = offsetof(typeof(*sk), sk_node);
if (use_hash2) {
@@ -2703,7 +2703,7 @@ static struct sock *__udp4_lib_mcast_demux_lookup(struct net *net,
hslot = &udptable->hash[slot];
/* Do not bother scanning a too big list */
- if (hslot->count > 10)
+ if (READ_ONCE(hslot->count) > 10)
return NULL;
result = NULL;
--
2.54.0.rc2.533.g4f5dca5207-goog
^ permalink raw reply related
* Re: [PATCH 19/23] cgroup/cpuset: Improve check for calling housekeeping_update()
From: Chen Ridong @ 2026-04-23 1:10 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Thomas Gleixner, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan
In-Reply-To: <20260421030351.281436-20-longman@redhat.com>
On 2026/4/21 11:03, Waiman Long wrote:
> By making sure that isolated_hk_cpus matches isolated_cpus at boot time,
> we can more accurately determine if calling housekeeping_update()
> is needed by comparing if the two cpumasks are equal. The
> update_housekeeping flag still have a use in cpuset_handle_hotplug()
> to determine if a work function should be queued to invoke
> cpuset_update_sd_hk_unlock() as it is not supposed to look at
> isolated_hk_cpus without holding cpuset_top_mutex.
>
Currently, isolated_hk_cpus is updated within the cpuset_mutex critical section
(before mutex_unlock(&cpuset_mutex)) in cpuset_update_sd_hk_unlock. Therefore, I
think update_housekeeping can now be removed.
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cgroup/cpuset.c | 36 ++++++++++++++++++++----------------
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index a4eccb0ec0d1..1b0c50b46a49 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1339,26 +1339,29 @@ static void cpuset_update_sd_hk_unlock(void)
> __releases(&cpuset_mutex)
> __releases(&cpuset_top_mutex)
> {
> + update_housekeeping = false;
> +
> /* force_sd_rebuild will be cleared in rebuild_sched_domains_locked() */
> if (force_sd_rebuild)
> rebuild_sched_domains_locked();
>
> - if (update_housekeeping) {
> - update_housekeeping = false;
> - cpumask_copy(isolated_hk_cpus, isolated_cpus);
> -
> - /*
> - * housekeeping_update() is now called without holding
> - * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> - * is still being held for mutual exclusion.
> - */
> - mutex_unlock(&cpuset_mutex);
> - cpus_read_unlock();
> - WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> - mutex_unlock(&cpuset_top_mutex);
> - } else {
> + if (cpumask_equal(isolated_hk_cpus, isolated_cpus)) {
> + /* No housekeeping cpumask update needed */
> cpuset_full_unlock();
> + return;
> }
> +
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> +
> + /*
> + * housekeeping_update() is now called without holding
> + * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> + * is still being held for mutual exclusion.
> + */
> + mutex_unlock(&cpuset_mutex);
> + cpus_read_unlock();
> + WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> + mutex_unlock(&cpuset_top_mutex);
> }
>
> /*
> @@ -3692,10 +3695,11 @@ int __init cpuset_init(void)
>
> BUG_ON(!alloc_cpumask_var(&cpus_attach, GFP_KERNEL));
>
> - if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT))
> + if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) {
> cpumask_andnot(isolated_cpus, cpu_possible_mask,
> housekeeping_cpumask(HK_TYPE_DOMAIN_BOOT));
> -
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> + }
> return 0;
> }
>
--
Best regards,
Ridong
^ permalink raw reply
* Re: [net-next v2 0/3] Add motorcomm 8531s set ds func and 8522 driver
From: Minda Chen @ 2026-04-23 1:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Frank, Andrew Lunn, Heiner Kallweit, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <eea18d2f-5294-40e4-9ea1-87aa55f8ea28@lunn.ch>
>
> On Wed, Apr 22, 2026 at 04:32:52PM +0800, Minda Chen wrote:
> > This patch is for Starfive JHB100 EVB board. JHB100 contain
> > 1 RGMII/RMII and 1 RMII synopsys GMAC cores. In the EVB board, RGMII
> > interface connect with YT8531s Ethernet PHY. RMII interface connect
> > with YT8522 ethernet PHY. So patch 1-2 is for RGMII interface patch 3
> > is RMII is for RMII interface.
> >
> > JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
> > Managent Controller). Similar with Aspeed 27x0.
> >
> > The JHB100 minimal system upstream is in progress:
> > https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.
> > 467700-1-changhuang.liang@starfivetech.com/
>
> Please take a read of sections 1.3 and 1.4 of:
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> Andrew
>
> ---
> pw-bot: cr
I am sorry about the "net-next" in merge window
^ permalink raw reply
* Re: [PATCH net-next v7 0/5] TLS read_sock performance scalability
From: Jakub Kicinski @ 2026-04-23 2:08 UTC (permalink / raw)
To: Chuck Lever
Cc: john.fastabend, Sabrina Dubroca, netdev, kernel-tls-handshake,
Chuck Lever, Hannes Reinecke, Alistair Francis
In-Reply-To: <3fc31ab1-23de-4381-b85c-5faa39169ad9@app.fastmail.com>
On Wed, 22 Apr 2026 12:41:43 -0400 Chuck Lever wrote:
> I see that this series is currently not in v7.1. What is left to do?
It's marked as Changes requested in patchwork, possibly due to
mis-reading of the discussion on patch 4. We process patches within
few days (well, we used to before the AI swarm) so if in doubt you
should ask sooner :S
^ permalink raw reply
* RE: [PATCH net v2 03/15] drivers: net: 3com: 3c574: Remove this driver
From: Wei Fang @ 2026-04-23 2:14 UTC (permalink / raw)
To: Andrew Lunn, Andrew Lunn
Cc: Geert Uytterhoeven, Michael Fritscher, Byron Stanoszek,
Daniel Palmer, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260422-v7-0-0-net-next-driver-removal-v1-v2-3-08a5b59784d5@lunn.ch>
> The 3c574 was written by Donald Becker between 19973-1998. It is an
Nit: 19973 --> 1993
> PCMCIA device, so unlikely to be used with modern kernels.
>
^ permalink raw reply
* Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer
From: Jakub Kicinski @ 2026-04-23 2:20 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, Sabrina Dubroca, Ralf Lici, Paolo Abeni, Andrew Lunn,
David S. Miller, Eric Dumazet, Hyunwoo Kim
In-Reply-To: <20260422123242.530882-2-antonio@openvpn.net>
On Wed, 22 Apr 2026 14:32:42 +0200 Antonio Quartulli wrote:
> + /* Prevent adding new peers while destroying the ovpn interface.
> + * Failing to do so would end up holding the device reference
> + * endlessly hostage of the new peer object with no chance of
> + * release..
> + */
> + if (ovpn->dev->reg_state >= NETREG_UNREGISTERING)
> + return -ENODEV;
AI review suggests wrapping reg_state read in READ_ONCE(), I think
that's legit. Also nit: I think > or != REGISTERED would be more
idiomatic than comparing >= UNREGSITERING ?
If you agree make sure Sashiko doesn't complain about anything else
once it's public:
https://sashiko.dev/#/patchset/20260422123242.530882-2-antonio@openvpn.net
^ permalink raw reply
* Re: [PATCH net v2 03/15] drivers: net: 3com: 3c574: Remove this driver
From: Jakub Kicinski @ 2026-04-23 2:21 UTC (permalink / raw)
To: Wei Fang
Cc: Andrew Lunn, Andrew Lunn, Geert Uytterhoeven, Michael Fritscher,
Byron Stanoszek, Daniel Palmer, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan
In-Reply-To: <AM8PR04MB7284CF79628FB99F7A7F20D5882A2@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Thu, 23 Apr 2026 02:14:22 +0000 Wei Fang wrote:
> > The 3c574 was written by Donald Becker between 19973-1998. It is an
>
> Nit: 19973 --> 1993
Will fix when applying FWIW
^ permalink raw reply
* [PATCH net v3] ipv6: addrconf: skip ERRDAD transition when address already DEAD
From: Linmao Li @ 2026-04-23 2:32 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni
Cc: horms, stephen, netdev, linux-kernel, Linmao Li
In-Reply-To: <20260421075033.1110816-1-lilinmao@kylinos.cn>
addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD
via addrconf_dad_end(), which drops ifp->lock on return. The lock
is re-acquired after net_info_ratelimited(). A concurrent
ipv6_del_addr() can take the lock in that window, set ifp->state
to DEAD and run list_del_rcu(&ifp->if_list).
addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:
and schedules a new dad_work. The work calls ipv6_del_addr()
again, hitting the already-poisoned list entry:
general protection fault: 0000 [#1] SMP NOPTI
CPU: 4 PID: 217 Comm: kworker/4:1
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:ipv6_del_addr+0xe9/0x280
RAX: dead000000000122
Call Trace:
addrconf_dad_stop+0x113/0x140
addrconf_dad_work+0x28c/0x430
process_one_work+0x1eb/0x3b0
worker_thread+0x4d/0x400
kthread+0x104/0x140
ret_from_fork+0x35/0x40
Fold the addrconf_dad_end() logic into addrconf_dad_failure()
under a single ifp->lock critical section. The STABLE_PRIVACY
branch temporarily drops ifp->lock, so keep a state-is-DEAD
bail-out at errdad: for that remaining window.
Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
net/ipv6/addrconf.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5476b6536eb7..c9ea0d5042d0 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2166,16 +2166,18 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp)
struct net *net = dev_net(idev->dev);
int max_addresses;
- if (addrconf_dad_end(ifp)) {
+ spin_lock_bh(&ifp->lock);
+
+ if (ifp->state != INET6_IFADDR_STATE_DAD) {
+ spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
return;
}
+ ifp->state = INET6_IFADDR_STATE_POSTDAD;
net_info_ratelimited("%s: IPv6 duplicate address %pI6c used by %pM detected!\n",
ifp->idev->dev->name, &ifp->addr, eth_hdr(skb)->h_source);
- spin_lock_bh(&ifp->lock);
-
if (ifp->flags & IFA_F_STABLE_PRIVACY) {
struct in6_addr new_addr;
struct inet6_ifaddr *ifp2;
@@ -2227,6 +2229,11 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp)
errdad:
/* transition from _POSTDAD to _ERRDAD */
+ if (ifp->state == INET6_IFADDR_STATE_DEAD) {
+ spin_unlock_bh(&ifp->lock);
+ in6_ifa_put(ifp);
+ return;
+ }
ifp->state = INET6_IFADDR_STATE_ERRDAD;
spin_unlock_bh(&ifp->lock);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Jakub Kicinski @ 2026-04-23 2:38 UTC (permalink / raw)
To: David Woodhouse
Cc: davem, openwrt-devel, Guy Ellis, netdev, edumazet, pabeni,
andrew+netdev, horms, corbet, skhan, linux, tsbogend, maddy, mpe,
npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
mchehab+huawei, tytso, herbert, geert, ebiggers, johannes.berg,
jonathan.cameron, kees, kuniyu, fourier.thomas, andriy.shevchenko,
rdunlap, akpm, linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <accbbcdf0ec14ae4d3f21ef5da7091bdcbd6574f.camel@infradead.org>
On Wed, 22 Apr 2026 14:05:31 +0100 David Woodhouse wrote:
> On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
> > I'm still deleting the solos driver, chances are nobody uses it.
> > Easy enough to revert back in since core is still around.
> > The guiding principle is to keep USB modems and delete
> > the rest as USB ADSL2+ CPEs were most popular historically.
>
> Still not entirely convinced; I worked on both USB ATM modems and on
> Solos, and the Solos is both the most modern and the only one I still
> actually have. And the only one we have native support for that could
> ever do full 24Mb/s ADSL2+, I believe.
>
> If we drop it, OpenWrt will need to drop support for these, which I
> think were quite popular at the time; there were a few UK resellers:
> https://openwrt.org/toh/traverse/geos1_1
>
> I still don't actually care *enough* to try to find an ADSL line I
> could plug one into for testing though... :)
I'm inversely unconvinced. The argument has the ring of "I still have
this HW lying around somewhere", which is usually what prevents us from
shedding all this dead weight code. I don't want to argue, so I'll keep it.
But if one "fix" arrives for this driver - it's going :(
^ permalink raw reply
* Re: [PATCH net 00/18] Remove a number of ISA and PCMCIA Ethernet drivers
From: Jakub Kicinski @ 2026-04-23 2:44 UTC (permalink / raw)
To: Daniel Palmer
Cc: David Laight, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-doc
In-Reply-To: <CAFr9PXnuyb0jTAhRgJGRmdzUMxP-0HrHHHN3YpQnOn8-nBBC1g@mail.gmail.com>
On Wed, 22 Apr 2026 18:33:15 +0900 Daniel Palmer wrote:
> Seriously though, I think we should have something to mark stuff in
> MAINTAINERS and elsewhere that is in the kernel but only because a few
> people are having fun with it.
IMHO that's not a great use of upstream maintainers' time.
We support loadable modules, perfect fit for retro computing
and drivers which aren't up to the standards.
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Philip Prindeville @ 2026-04-23 2:41 UTC (permalink / raw)
To: David Woodhouse
Cc: Jakub Kicinski, davem, openwrt-devel, Guy Ellis, netdev, edumazet,
pabeni, andrew+netdev, horms, corbet, skhan, linux, tsbogend,
maddy, mpe, npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
mchehab+huawei, tytso, herbert, geert, ebiggers, johannes.berg,
jonathan.cameron, kees, kuniyu, fourier.thomas, andriy.shevchenko,
rdunlap, akpm, linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <accbbcdf0ec14ae4d3f21ef5da7091bdcbd6574f.camel@infradead.org>
> On Apr 22, 2026, at 7:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
>>
>> I'm still deleting the solos driver, chances are nobody uses it.
>> Easy enough to revert back in since core is still around.
>> The guiding principle is to keep USB modems and delete
>> the rest as USB ADSL2+ CPEs were most popular historically.
>
> Still not entirely convinced; I worked on both USB ATM modems and on
> Solos, and the Solos is both the most modern and the only one I still
> actually have. And the only one we have native support for that could
> ever do full 24Mb/s ADSL2+, I believe.
>
> If we drop it, OpenWrt will need to drop support for these, which I
> think were quite popular at the time; there were a few UK resellers:
> https://openwrt.org/toh/traverse/geos1_1
>
> I still don't actually care *enough* to try to find an ADSL line I
> could plug one into for testing though... :)
I have 3 boards lying around if anyone wants them.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Jakub Kicinski @ 2026-04-23 2:48 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: andrew+netdev, davem, edumazet, pabeni, netdev, linux-kernel
In-Reply-To: <20260421082005.74a3efb4@kernel.org>
On Tue, 21 Apr 2026 08:20:05 -0700 Jakub Kicinski wrote:
> On Tue, 21 Apr 2026 10:37:38 +0300 Nikola Z. Ivanov wrote:
> > Additionally remove the now redundant zero assignments
> > and reorder the remaining ones so that they more closely
> > match the order of the fields as they appear in the ip header.
>
> Doesn't matter, now that the whole thing is zero-initialized.
> I don't think it's worth the noise in the git history.
I don't see a v2, so just to be clear -- the patch looks good,
just don't reorder the assignments please.
^ permalink raw reply
* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-23 2:59 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Boris Pismenny, willemdebruijn.kernel@gmail.com,
andrew+netdev@lunn.ch, daniel.zahka@gmail.com,
davem@davemloft.net, leon@kernel.org,
linux-kernel@vger.kernel.org, edumazet@google.com,
linux-rdma@vger.kernel.org, Rahul Rameshbabu, Raed Salem,
Dragos Tatulea, kees@kernel.org, Mark Bloch, pabeni@redhat.com,
Tariq Toukan, Saeed Mahameed, netdev@vger.kernel.org,
Gal Pressman
In-Reply-To: <5167f0714e3ddf750f80740bf2ab18a7bb567b16.camel@nvidia.com>
On Wed, 22 Apr 2026 15:13:04 +0000 Cosmin Ratiu wrote:
> > > Can you call mlx5e_psp_cleanup() when register fails for now?
> >
> > Done for the next version, currently undergoing testing.
>
> There's a snag: priv->psp may be accessed concurrently from
> mlx5e_get_stats() -> mlx5e_fold_sw_stats64() so we'd need to play
> tricks with RCU and that goes beyond what a net fix should be: It's a
> redesign of how priv->psp is handled in the driver. There's a risk we
> are missing things, or it becomes more intrusive that what a fix should
> be.
Questionable.
> I would like to ask you: let's please not do this redesign of priv->psp
> in a rush, and leave it for the net-next series I mentioned...
>
> To reiterate, would you like to take patch 2?
Sure, whatever. But it has to be reposted, of course.
^ 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