* Re: [net-next PATCH 01/10] net: dsa: tag_rtl8_4: update format description
From: Linus Walleij @ 2026-04-07 7:33 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-1-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Document the updated tag layout fields (EFID, VSEL/VIDX) and clarify
> which bits are set/cleared when emitting tags.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH 03/10] net: dsa: realtek: rtl8365mb: prepare for multiple source files
From: Linus Walleij @ 2026-04-07 7:35 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-3-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Rename rtl8365mb.c to rtl8365mb_main.c in preparation for subsequent
> commits which add additional source files to the driver.
>
> The trailing backslash in the Makefile is deliberate. It allows for new
> files to be added without clobbering git history.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
I can't really see from the patch if the line below the backslash is empty and
that is why this bisects fine, but if this compiles fine then OK.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v8 00/11] net: tunnel: introduce noref xmit flows for tunnels
From: Paolo Abeni @ 2026-04-07 7:39 UTC (permalink / raw)
To: Marek Mietus, netdev, sd, kuba; +Cc: Jason
In-Reply-To: <bbb2b833-a9a9-4558-8d4b-1b041f6706d7@yahoo.com>
On 4/6/26 9:58 AM, Marek Mietus wrote:
> W dniu 17.03.2026 o 12:37, Paolo Abeni pisze:
>> On 3/12/26 4:56 PM, Marek Mietus wrote:
>>> Currently, tunnel xmit flows always take a reference on the dst_entry
>>> for each xmitted packet. These atomic operations are redundant in some
>>> flows.
>>>
>>> This patchset introduces the infrastructure required for converting
>>> the tunnel xmit flows to noref, and converts them where possible.
>>>
>>> These changes improve tunnel performance, since less atomic operations
>>> are used.
>>>
>>> There are already noref optimizations in both ipv4 and ip6.
>>> (See __ip_queue_xmit, inet6_csk_xmit)
>>> This patchset implements similar optimizations in ip and udp tunnels.
>>>
>>> Benchmarks:
>>> I used a vxlan tunnel over a pair of veth peers and measured the average
>>> throughput over multiple samples.
>>>
>>> I ran 100 samples on a clean build, and another 100 on a patched
>>> build. Each sample ran for 120 seconds. These were my results:
>>>
>>> clean: 72.52 gb/sec, stddev = 1.39
>>> patched: 75.39 gb/sec, stddev = 0.94
>>>
>>> TL;DR - This patchset results in a 4% improvement in throughput for
>>> vxlan. It's safe to assume that we might see similar results when testing
>>> other tunnels.
>>
>> Sabrina noted I wrongly replied on an old revision. Reporting my
>> statements here for completeness.
>>
>> IMHO this performance delta is not enough to justify this amount of changes.
>>
>> Additionally, the measured impact of removing the dst_hold/dst_release
>> does not fit with my direct experience on the same matter: it should be
>> below noise level in practice, as dst are per-cpu and and no
>> contention/false sharing is expected in a good setup.
>>
>> I think you are observing larger impact because in the veth test
>> dst_release can happen on a remote CPU. Note that this setup (vxlan over
>> veth) is not very relevant in practice.
>>
>> I'm sorry I'm not applying this series.
>>
>> Side note: if you are interested into improving (UDP) tunnel
>> performances have a look to big TCP support work from Alice Mikityanska:
>>
>> https://lore.kernel.org/netdev/20260226201600.222044-1-alice.kernel@fastmail.im/
>>
>> /P
>>
>>
>
> Hi Paolo,
>
> Could you clarify what would be a more realistic test setup? I'm assuming using physical interfaces would yield more realistic results.
> Also, what performance benefit would be worth this kind of "code churn"? What kind of margins were you looking for?
veth devices hides a significant part of the memory buffer lifecycles,
as there is a single allocation/free for both sender and receiver. Using
reasonably fast/recent H/W NICs would make the figures much more relevant.
Given the amount of changes included in this series, I think that a
performance improvement well above the noise range in a relevant test
case would be needed to justify it. If you really want a figure, I would
say 5%. Note that the main difference WRT your testing is the setup itself.
To be completely open, I don't see how the refcount change could come
near such figure, as in my testing on H/W NICs the total reference
counting cost is usually well below noise level.
/P
^ permalink raw reply
* Re: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Russell King (Oracle) @ 2026-04-07 7:40 UTC (permalink / raw)
To: Jiawen Wu
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable
In-Reply-To: <096d01dcc657$9ee42b00$dcac8100$@trustnetic.com>
On Tue, Apr 07, 2026 at 02:27:34PM +0800, Jiawen Wu wrote:
> On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> > On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > > For the copper NIC with external PHY, the driver called
> > > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during
> > > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> > > > > upon module remove.
> > > > >
> > > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
> > > >
> > > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > > remove function with rtnl_lock()..rtnl_unlock() ?
> > >
> > > This is also a solution. But I think it would be nice to unify with other drivers
> > > that call the functions in ndo_open/close.
> >
> > Both approaches are equally valid. Some network drivers attach the PHY
> > at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> > but not present). Others attach in .ndo_open which can only fail in this
> > circumstance with no retry without userspace manually implementing that.
> >
> > There are other advantages and disadvantages to each approach.
>
> Hi,
>
> So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
The reaosn phylink_disconnect_phy() requires the RTNL lock is because it
_can_ be called while the netdev is published, and the RTNL lock
protects the networking core from the PHY being removed from the netdev,
preventing ethtool ops into the PHY driver from running concurrently
with the PHY's disconnection and potential later destruction.
Offering two APIs, one which requires the lock to provide that
protection and one which doesn't would over-complicate the phylink code
and make reviews way more difficult, as we'd now have to spot the
wrong function being used in the wrong code path.
It's simpler for drivers that want to connect and disconnect the PHY
at probe/remove time for them to just take the RTNL lock briefly over
the call to phylink_disconnect_phy().
There is no "recommendation" for connecting and disconnecting the
PHY at probe/remove time vs ndo_open/ndo_release. That's entirely up
to the driver author. As I've already said, there are advantages and
disadvantages of either way and that's a matter for the driver author
to consider and select the most appropriate choice for their driver.
--
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
* Re: [net-next PATCH 05/10] net: dsa: realtek: rtl8365mb: add table lookup interface
From: Linus Walleij @ 2026-04-07 7:43 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-5-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Add a generic table lookup interface to centralize access to
> the RTL8365MB internal tables.
>
> This interface abstracts the low-level table access logic and
> will be used by subsequent commits to implement FDB and VLAN
> operations.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-07 7:43 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <CAL+tcoAvVBN7juJEBt5-FYQ4eGTe7dYrFbR3CMOwguw=_X=btA@mail.gmail.com>
On Tue, Apr 7, 2026 at 11:33 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> On Mon, Apr 6, 2026 at 10:37 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
> > > <willemdebruijn.kernel@gmail.com> wrote:
> > > >
> > > > Jason Xing wrote:
> > > > > From: Jason Xing <kernelxing@tencent.com>
> > > > >
> > > > > The patch is the 1/2 part of push-level granularity feature.
> > > > >
> > > > > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > > > > though it might not carry the last byte of the sendmsg.
> > > > >
> > > > > Prior to the patch, BPF timestamping cannot cover this case:
> > > > > The following steps reproduce this:
> > > > > 1) skb A is the current last skb before entering wait_for_space process
> > > > > 2) tcp_push() pushes A without any tag
> > > > > 3) A is transmitted from TCP to driver without putting any skb carrying
> > > > > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > > > > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > > > > error code. Note that the socket lock is released.
> > > > > 5) skb A finally gets acked and removed from the rtx queue.
> > > > > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > > > > 'do_error' label and then 'out' label.
> > > > > 7) at this moment, skb A turns out to be the last one in this send
> > > > > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > > > > before the final tcp_push()
> > > > > 8) BPF script fails to see any timestamps this time
> > > > >
> > > > > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > > ---
> > > > > net/ipv4/tcp.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > > > index c603b90057f6..7d030a11d004 100644
> > > > > --- a/net/ipv4/tcp.c
> > > > > +++ b/net/ipv4/tcp.c
> > > > > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > > > > wait_for_space:
> > > > > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > > > > tcp_remove_empty_skb(sk);
> > > > > - if (copied)
> > > > > + if (copied) {
> > > > > + tcp_bpf_tx_timestamp(sk);
> > > > > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > > > > TCP_NAGLE_PUSH, size_goal);
> > > >
> > > > Now the number of skbs that will be tracked will be unpredictable,
> > > > varying based on memory pressure.
> > >
> > > Right, I put some effort into writing a selftests to check how many
> > > push functions get called at one time and failed to do so.
> > >
> > > >
> > > > That sounds hard to use to me. Especially if these extra pushes
> > > > cannot be identified as such.
> > > >
> > > > Perhaps if all skbs from the same sendmsg call can be identified,
> > > > that would help explain pattern in data resulting from these
> > > > uncommon extra data points.
> > >
> > > You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
> > > close to packet basis without considering fragmentation of skb :)
> >
> > No, I meant somehow in the notification having a way to identify all
> > the skbs belonging to the same sendmsg call, to allow filtering on
> > that. But I also don't immediately see how to do that (without adding
> > yet another counter say).
>
> If we don't build the relationship between skb and sendmsg (just like
> the SENDMSG sock option), we will have no clue on how to calculate. If
> we only take care of the skb from the view of the syscall layer, it's
> fine by moving tcp_bpf_tx_timestamp() before tcp_skb_entail(). But in
> terms of per skb even generated beneath TCP due to gso/tso, there is
> only one way to correlate: adding an additional member in the skb
> structure to store its sendmsg time. This discussion is only suitable
> for use cases like net_timestamping.
>
> Well, my key point is that, I have to admit, the above (including
> existing bpf script net_timestamping) is a less effective way which
> definitely harms the performance because of the extremely frequent
> look-up process. It's not suitable for 7x24 observability in
> production. What we've done internally is make the kernel layer as
> lightweight/easy as possible and let the timestamping feature throw
> each record into a ring buffer that the application can read, sort and
> calculate. This arch survives the performance. But that's simply what
> the design of the kernel module is, given the fast deployment in
> production. I suppose in the future we could build a userspace tool
> like blktrace to monitor efficiently instead of the selftest sample.
> Honestly I don't like look-up action.
>
> Since we're modifying the kernel, how about adding a new member to
> record sendmsg time which bpf script is able to read. The whole
> scenario looks like this:
> 1) in tcp_sendmsg_locked(), record the sendmsg time for each skb
> 2) in either tso_fragment() or tcp_gso_tstamp(), each new skb will get
> a copy of its original skb
> 3) in each stage, bpf script reads the skb's sendmsg time and the
> current time, and then effortlessly do the math.
>
> At this point, what I had in mind is we have two options:
> 1) only handle the skb from the view of the send syscall layer, which
> is, for sure, very simple but not thorough.
> 2) stick to a pure authentic packet basis, then adding a new member
> seems inevitable. so the question would be where to add? The space of
> the skb structure is very precious :(
Finding a suitable place to put this timestamp is really hard. IIRC,
we can't expand the size of struct skb_shared_info so easily since
it's a global effect.
I'm wondering if we can turn the per-packet mode into a non-compatible
feature by reusing 'u32 tskey' to store a microsecond timestamp of
sendmsg.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Allison Henderson @ 2026-04-07 7:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, pabeni, edumazet, rds-devel, horms, linux-rdma
In-Reply-To: <20260406181957.4bba8580@kernel.org>
On Mon, 2026-04-06 at 18:19 -0700, Jakub Kicinski wrote:
> On Sat, 4 Apr 2026 21:16:12 -0700 Allison Henderson wrote:
> > From: Håkon Bugge <haakon.bugge@oracle.com>
>
> > Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
> > Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
> > Signed-off-by: Allison Henderson <achender@kernel.org>
>
> Author's sign-off missing on this patch (I sent out the AI reviews
> as well, without looking, take them with a grain of salt).
Yes, Håkon's sob should be here, I will add it.
Thanks!
Allison
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Allison Henderson @ 2026-04-07 7:55 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: rds-devel, edumazet, linux-rdma, horms, pabeni, netdev
In-Reply-To: <20260407011900.3596320-1-kuba@kernel.org>
On Mon, 2026-04-06 at 18:19 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> net/rds: Optimize rds_ib_laddr_check
>
> This patch optimizes rds_ib_laddr_check() to avoid excessive
> rdma_bind_addr() calls by checking if an address has been used before.
> It renames the original function to rds_ib_laddr_check_cm() and
> introduces a new wrapper that first checks rds_ib_get_device() before
> falling back to the CM-based check.
>
> > diff --git a/net/rds/ib.c b/net/rds/ib.c
> > index ac6affa33ce7..73e01984ee9a 100644
> > --- a/net/rds/ib.c
> > +++ b/net/rds/ib.c
> > @@ -401,8 +401,8 @@ static void rds6_ib_ic_info(struct socket *sock, unsigned int len,
> > * allowed to influence which paths have priority. We could call userspace
> > * asserting this policy "routing".
> > */
> > -static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > - __u32 scope_id)
> > +static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
> > + __u32 scope_id)
> > {
> > int ret;
> > struct rdma_cm_id *cm_id;
>
> [ ... ]
>
> > @@ -487,6 +487,20 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > return ret;
> > }
> >
> > +static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > + __u32 scope_id)
> > +{
> > + struct rds_ib_device *rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> > +
> > + if (rds_ibdev) {
> > + rds_ib_dev_put(rds_ibdev);
> > +
> > + return 0;
> > + }
> > +
> > + return rds_ib_laddr_check_cm(net, addr, scope_id);
> > +}
> > +
>
> Can this code handle pure IPv6 addresses correctly? The function extracts
> addr->s6_addr32[3] and passes it to rds_ib_get_device(), which looks up
> devices by IPv4 address.
>
> For IPv4-mapped IPv6 addresses, addr->s6_addr32[3] contains the IPv4
> address. But for pure IPv6 addresses (when CONFIG_IPV6 is enabled),
> addr->s6_addr32[3] contains the last 32 bits of the IPv6 address, which
> could accidentally match a stored IPv4 address.
>
> When this collision occurs, the function returns 0 (success) without
> calling rds_ib_laddr_check_cm(), which performs the full validation
> including rdma_bind_addr() and IPv6 link-local scope_id checks. This
> means a pure IPv6 address could be incorrectly accepted as valid for IB
> transport.
>
> Should this be guarded with an ipv6_addr_v4mapped(addr) check? For
> example:
>
> if (ipv6_addr_v4mapped(addr)) {
> rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> ...
> }
>
> The existing callers of rds_ib_get_device (rds_ib_get_mr,
> rds_ib_update_ipaddr) operate in post-connection contexts where the
> address type is already validated, but rds_ib_laddr_check is the
> validation gate called during bind/transport-selection for any address
> type.
Ok I think the correct ports to fix this would be these two commits:
https://github.com/oracle/linux-uek/commit/caffdcae6593
caffdcae6593 ("rds: Enable RDS IPv6 support")
https://github.com/oracle/linux-uek/commit/cb82f22bbff5
cb82f22bbff5 ("rds: Changed IP address internal representation to struct in6_addr")
But that is starting to snowball quite a bit outside the scope of the syzbot bug, and a lot of rds port patches tend to
domino like this if we don't find a way to contain it. So for the syzbot report, I think the ai suggestion is
reasonable. So, if folks agree, I am fine to add that check in v2.
Thank you!
Allison
>
> > static void rds_ib_unregister_client(void)
> > {
> > ib_unregister_client(&rds_ib_client);
>
> [ ... ]
^ permalink raw reply
* Re: [PATCH 1/2] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
From: Paolo Abeni @ 2026-04-07 7:55 UTC (permalink / raw)
To: Konstantin Khorenko, David S . Miller, Eric Dumazet,
Jakub Kicinski
Cc: Simon Horman, Thomas Weißschuh, Arnd Bergmann,
Peter Oberparleiter, Mikhail Zaslonko, netdev, linux-kernel,
Pavel Tikhomirov, Vasileios Almpanis
In-Reply-To: <20260402140558.1437002-2-khorenko@virtuozzo.com>
On 4/2/26 4:05 PM, Konstantin Khorenko wrote:
> When CONFIG_GCOV_PROFILE_ALL=y is enabled, the kernel fails to build:
>
> In file included from <command-line>:
> In function 'skb_extensions_init',
> inlined from 'skb_init' at net/core/skbuff.c:5214:2:
> ././include/linux/compiler_types.h:706:45: error: call to
> '__compiletime_assert_1490' declared with attribute error:
> BUILD_BUG_ON failed: skb_ext_total_length() > 255
>
> CONFIG_GCOV_PROFILE_ALL adds -fprofile-arcs -ftest-coverage
> -fno-tree-loop-im to CFLAGS globally. GCC inserts branch profiling
> counters into the skb_ext_total_length() loop and, combined with
> -fno-tree-loop-im (which disables loop invariant motion), cannot
> constant-fold the result.
> BUILD_BUG_ON requires a compile-time constant and fails.
>
> The issue manifests in kernels with 5+ SKB extension types enabled
> (e.g., after addition of SKB_EXT_CAN, SKB_EXT_PSP). With 4 extensions
> GCC can still unroll and fold the loop despite GCOV instrumentation;
> with 5+ it gives up.
>
> Mark skb_ext_total_length() with __no_profile to prevent GCOV from
> inserting counters into this function. Without counters the loop is
> "clean" and GCC can constant-fold it even with -fno-tree-loop-im active.
> This allows BUILD_BUG_ON to work correctly while keeping GCOV profiling
> for the rest of the kernel.
>
> This also removes the CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard
> introduced by d6e5794b06c0, as __no_profile handles both GCOV and KCOV
> instrumentation at the root cause level rather than just disabling the
> check.
>
> Fixes: 5d21d0a65b57 ("net: generalize calculation of skb extensions length")
> Fixes: d6e5794b06c0 ("net: avoid build bug in skb extension length calculation")
>
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
No empty lines in the tags area.
Also given the commit description, isn't the introduction of the 5th skb
extension a better fixes tag?
> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> net/core/skbuff.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0e217041958a..47c7f0ab6e84 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5145,7 +5145,7 @@ static const u8 skb_ext_type_len[] = {
> #endif
> };
>
> -static __always_inline unsigned int skb_ext_total_length(void)
> +static __always_inline __no_profile unsigned int skb_ext_total_length(void)
> {
> unsigned int l = SKB_EXT_CHUNKSIZEOF(struct skb_ext);
> int i;
> @@ -5159,9 +5159,7 @@ static __always_inline unsigned int skb_ext_total_length(void)
> static void skb_extensions_init(void)
> {
> BUILD_BUG_ON(SKB_EXT_NUM > 8);
> -#if !IS_ENABLED(CONFIG_KCOV_INSTRUMENT_ALL)
> BUILD_BUG_ON(skb_ext_total_length() > 255);
> -#endif
Sashiko notes that there could be still build breakage:
https://sashiko.dev/#/patchset/20260402140558.1437002-1-khorenko%40virtuozzo.com
Could you please double check the above?
I think a 'noinline' in skb_extensions_init() would address any
complains on patch 2/2
/P
>
> skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
> SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),
^ permalink raw reply
* Re: [net-next PATCH 06/10] net: dsa: realtek: rtl8365mb: add VLAN support
From: Linus Walleij @ 2026-04-07 7:59 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-6-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
> structures for VLANs:
>
> - VLAN4K: A full table with 4096 entries defining port membership and
> tagging.
> - VLANMC: A smaller table with 32 entries used primarily for PVID
> assignment.
>
> In this hardware, a port's PVID must point to an index in the VLANMC
> table rather than a VID directly. Since the VLANMC table is limited to
> 32 entries, the driver implements a dynamic allocation scheme to
> maximize resource usage:
>
> - VLAN4K is treated by the driver as the source of truth for membership.
> - A VLANMC entry is only allocated when a port is configured to use a
> specific VID as its PVID.
> - VLANMC entries are deleted when no longer needed as a PVID by any port.
>
> Although VLANMC has a members field, the switch only checks membership
> in the VLAN4K table. However, when a corresponding VLAN entry also exists
> in VLANMC, this driver keeps both membership configurations in sync.
>
> VLANMC index 0, although a valid entry, is reserved in this driver as a
> neutral PVID value for ports not using a specific PVID.
>
> In the subsequent RTL8367D switch family, VLANMC table was
> removed and PVID assignment was delegated to a dedicated set of
> registers.
>
> All ports start isolated, forwarding exclusively to CPU ports, and
> with VLAN transparent, ignoring VLAN membership. Once a member in a
> bridge, the port isolation is expanded to include the bridge members.
> When that bridge enables VLAN filtering, the VLAN transparent feature is
> disabled, letting the switch filter based on VLAN setup.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
This patch ignores the existing abstractions for generic RTL8366 VLAN
handling in rtl8366-core.c and realtek.h, which is actually compiled
and bundled into the same object with the RTL8365MB driver.
It provides rtl8366_vlan_add(), rtl8366_vlan_del(), rtl8366_enable_vlan(),
rtl8366_enable_vlan4k(), rtl8366_set_pvid(), rtl8366_set_vlan().
The RTL8366RB notably has the same 32 PVID thing and the
same 4K VLAN table.
I understand that it is always easier to develop and test something
for "just this one chip", but I predictably have to be the one to ask
if this can be done in the shared code.
You need to either:
- Take a second sweep and refactor to share the existing VLAN
handling with RTL8366RB (preferred).
- Explain why RTL8365MB is so very different that it cannot share
code with RTL8366RB, then proceed to move all code from
rtl8366-core.c into the RTL8366RB driver, change prefix of functions
and generally make it local so it doesn't bloat the
RTL8365MB code before adding this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net v2 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Ren Wei @ 2026-04-07 8:00 UTC (permalink / raw)
To: netdev
Cc: kuniyu, davem, edumazet, kuba, pabeni, horms, xemul, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, wangjiexun2025, n05ec
In-Reply-To: <cover.1775207252.git.wangjiexun2025@gmail.com>
From: Jiexun Wang <wangjiexun2025@gmail.com>
Exact UNIX diag lookups hold a reference to the socket, but not to
u->path. Meanwhile, unix_release_sock() clears u->path under
unix_state_lock() and drops the path reference after unlocking.
Read the inode and device numbers for UNIX_DIAG_VFS while holding
unix_state_lock(), then emit the netlink attribute after dropping the
lock.
This keeps the VFS data stable while the reply is being built.
Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
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: Jiexun Wang <wangjiexun2025@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
Changes in v2:
- reorder local variables in reverse xmas tree order
net/unix/diag.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/unix/diag.c b/net/unix/diag.c
index ca3473026151..c9c1e51c4419 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -28,18 +28,23 @@ static int sk_diag_dump_name(struct sock *sk, struct sk_buff *nlskb)
static int sk_diag_dump_vfs(struct sock *sk, struct sk_buff *nlskb)
{
- struct dentry *dentry = unix_sk(sk)->path.dentry;
+ struct unix_diag_vfs uv;
+ struct dentry *dentry;
+ bool have_vfs = false;
+ unix_state_lock(sk);
+ dentry = unix_sk(sk)->path.dentry;
if (dentry) {
- struct unix_diag_vfs uv = {
- .udiag_vfs_ino = d_backing_inode(dentry)->i_ino,
- .udiag_vfs_dev = dentry->d_sb->s_dev,
- };
-
- return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
+ uv.udiag_vfs_ino = d_backing_inode(dentry)->i_ino;
+ uv.udiag_vfs_dev = dentry->d_sb->s_dev;
+ have_vfs = true;
}
+ unix_state_unlock(sk);
- return 0;
+ if (!have_vfs)
+ return 0;
+
+ return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
}
static int sk_diag_dump_peer(struct sock *sk, struct sk_buff *nlskb)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net v2 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: Ido Schimmel @ 2026-04-07 8:02 UTC (permalink / raw)
To: David Ahern
Cc: Ao Zhou, netdev, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, Jiri Pirko, Yifan Wu,
Juefei Pu, Yuan Tan, Xin Liu, Haoze Xie
In-Reply-To: <b6cc7bc1-f18b-43d2-a21a-c964466fa882@kernel.org>
On Mon, Apr 06, 2026 at 12:14:15PM -0600, David Ahern wrote:
> On 4/6/26 9:48 AM, Ido Schimmel wrote:
> >
> > Don't we have the same problem in l3mdev_l3_rcv() and l3mdev_l3_out()?
> > If so, please check if I missed more places and include them in v3.
> >
> > And I think that the part that I was missing earlier is that we don't
> > have RCU synchronization in the unslaving path, so an RCU reader can
> > either see the original master, NULL or a new master (e.g., bridge
> > instead of the original VRF master).
>
> synchronize_rcu after the unlink (control path) seems like a better,
> more robust option than adding more checks to the datapath.
IMO it would be better to proceed with the original approach and look
into adding RCU synchronization in net-next. The original approach is
more surgical and the pattern of first checking netif_is_l3_master()
already exists in other places.
^ permalink raw reply
* Re: [net-next PATCH 07/10] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
From: Linus Walleij @ 2026-04-07 8:11 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-7-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> static int rtl8365mb_port_set_isolation(struct realtek_priv *priv, int port,
> u32 mask)
> +static int rtl8365mb_port_add_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
> +static int rtl8365mb_port_remove_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
This is smart!
> +static int rtl8365mb_port_bridge_join(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge,
> + bool *tx_forward_offload,
> + struct netlink_ext_ack *extack)
> +static void rtl8365mb_port_bridge_leave(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge)
The content of these functions are very similar to
rtl8366rb_port_bridge_join() and rtl8366rb_port_bridge_leave().
What about moving this code to the shared library rtl8366-core as
rtl8366_port_bridge_join() and rtl8366_port_bridge_leave()
and add per-variant callbacks for ->port_set_isolation()
->port_add_isolation() and ->port_remove_isolation() to
struct realtek_ops and share this with rtl8366rb by refactoring
rtl8366rb.c to use the same callbacks.
Using shared code will help us to avoid having to fix the same
bugs in more than one place.
I don't know about this EFID stuff in rtl8365mb_port_set_efid()
(maybe RTL8366RB needs something like that too) but certainly that
can be an optional callback in struct realtek_ops for now.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Jiawen Wu @ 2026-04-07 8:07 UTC (permalink / raw)
To: 'Russell King (Oracle)'
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable, netdev, 'Mengyuan Lou',
'Andrew Lunn', 'David S. Miller',
'Eric Dumazet', 'Jakub Kicinski',
'Paolo Abeni', 'Simon Horman',
'Jacob Keller', 'Abdun Nihaal', stable
In-Reply-To: <adS0_I_2HBH-gM19@shell.armlinux.org.uk>
On Tue, Apr 7, 2026 3:41 PM, Russell King (Oracle) wrote:
> On Tue, Apr 07, 2026 at 02:27:34PM +0800, Jiawen Wu wrote:
> > On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> > > On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > > > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > > > For the copper NIC with external PHY, the driver called
> > > > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during
> > > > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> > > > > > upon module remove.
> > > > > >
> > > > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
> > > > >
> > > > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > > > remove function with rtnl_lock()..rtnl_unlock() ?
> > > >
> > > > This is also a solution. But I think it would be nice to unify with other drivers
> > > > that call the functions in ndo_open/close.
> > >
> > > Both approaches are equally valid. Some network drivers attach the PHY
> > > at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> > > but not present). Others attach in .ndo_open which can only fail in this
> > > circumstance with no retry without userspace manually implementing that.
> > >
> > > There are other advantages and disadvantages to each approach.
> >
> > Hi,
> >
> > So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
>
> The reaosn phylink_disconnect_phy() requires the RTNL lock is because it
> _can_ be called while the netdev is published, and the RTNL lock
> protects the networking core from the PHY being removed from the netdev,
> preventing ethtool ops into the PHY driver from running concurrently
> with the PHY's disconnection and potential later destruction.
>
> Offering two APIs, one which requires the lock to provide that
> protection and one which doesn't would over-complicate the phylink code
> and make reviews way more difficult, as we'd now have to spot the
> wrong function being used in the wrong code path.
>
> It's simpler for drivers that want to connect and disconnect the PHY
> at probe/remove time for them to just take the RTNL lock briefly over
> the call to phylink_disconnect_phy().
>
> There is no "recommendation" for connecting and disconnecting the
> PHY at probe/remove time vs ndo_open/ndo_release. That's entirely up
> to the driver author. As I've already said, there are advantages and
> disadvantages of either way and that's a matter for the driver author
> to consider and select the most appropriate choice for their driver.
OK. I'll change it at v2 patch.
^ permalink raw reply
* Re: [PATCH v2] xfrm6: fix slab-out-of-bounds write in xfrm6_input_addr()
From: Steffen Klassert @ 2026-04-07 8:15 UTC (permalink / raw)
To: I Viswanath; +Cc: nicholas, netdev, Herbert Xu, David S . Miller, Milad Nasr
In-Reply-To: <CAPrAcgNbbcLrJDBs03=CQU0VzbqaEGi_h4gsrWY693ERsuTE1A@mail.gmail.com>
On Wed, Apr 01, 2026 at 09:56:40PM +0530, I Viswanath wrote:
> On Wed, 1 Apr 2026 at 10:26, <nicholas@carlini.com> wrote:
>
> > - if (1 + sp->len == XFRM_MAX_DEPTH) {
> > + if (1 + sp->len >= XFRM_MAX_DEPTH) {
> > XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
> > goto drop;
> > }
>
> If you look at other places where sp->len is incremented, you will
> notice the guard condition is always (sp->len == XFRM_MAX_DEPTH). This
> bug exists because in xfrm6_input.c, the greatest valid index is taken
> to be XFRM_MAX_DEPTH - 2 when it should be XFRM_MAX_DEPTH - 1.
> Therefore, The correct fix should be using the common guard not
> changing the guard to use >=
>
> On a tangential note, There is no guard present before the increment
> in xfrm_output.c which is probably another OOB bug
Nicholas, please have a look if you can update your patch based
on these comments.
Thanks!
^ permalink raw reply
* Re: [PATCH ipsec 1/2] xfrm: Wait for RCU readers during policy netns exit
From: Steffen Klassert @ 2026-04-07 8:16 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <ac5YaN5EJQwokOq6@strlen.de>
On Thu, Apr 02, 2026 at 01:52:08PM +0200, Florian Westphal wrote:
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > xfrm_policy_fini() frees the policy_bydst hash tables after flushing the
> > policy work items and deleting all policies, but it does not wait for
> > concurrent RCU readers to leave their read-side critical sections first.
> >
> > The policy_bydst tables are published via rcu_assign_pointer() and are
> > looked up through rcu_dereference_check(), so netns teardown must also
> > wait for an RCU grace period before freeing the table memory.
> >
> > Fix this by adding synchronize_rcu() before freeing the policy hash tables.
> >
> > Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups")
>
> Reviewed-by: Florian Westphal <fw@strlen.de>
This is now applied to the ipsec tree.
^ permalink raw reply
* Re: [PATCH v3] xfrm: hold dev ref until after transport_finish NF_HOOK
From: Steffen Klassert @ 2026-04-07 8:18 UTC (permalink / raw)
To: Qi Tang
Cc: Herbert Xu, Florian Westphal, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern, netdev,
stable
In-Reply-To: <20260402114401.62212-1-tpluszz77@gmail.com>
On Thu, Apr 02, 2026 at 07:44:01PM +0800, Qi Tang wrote:
> After async crypto completes, xfrm_input_resume() calls dev_put()
> immediately on re-entry before the skb reaches transport_finish.
> The skb->dev pointer is then used inside NF_HOOK and its okfn,
> which can race with device teardown.
>
> Remove the dev_put from the async resumption entry and instead
> drop the reference after the NF_HOOK call in transport_finish,
> using a saved device pointer since NF_HOOK may consume the skb.
> This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip
> the okfn.
>
> For non-transport exits (decaps, gro, drop) and secondary
> async return points, release the reference inline when
> async is set.
>
> Suggested-by: Florian Westphal <fw@strlen.de>
> Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet")
> Cc: stable@vger.kernel.org
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
Applied to the ipsec tree, thanks a lot!
^ permalink raw reply
* Re: [PATCH v2] net: sfp: add quirks for GPON ONT SFP sticks
From: Russell King (Oracle) @ 2026-04-07 8:18 UTC (permalink / raw)
To: John Pavlick
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, Marcin Nita
In-Reply-To: <20260406121716.69854-1-jspavlick@posteo.net>
On Mon, Apr 06, 2026 at 12:17:21PM +0000, John Pavlick wrote:
> Several GPON ONT SFP sticks based on Realtek RTL960x report
> 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
> On hosts with serdes fixed at 2.5Gbase-X (e.g. Banana Pi R3 / MT7986),
> the kernel rejects them with 'no common interface modes'.
>
> Add quirks for:
> - Hisense-Leox LXT-010S-H
> - Hisense ZNID-GPON-2311NA
> - HSGQ HSGQ-XPON-Stick
>
> Each quirk advertises 2500base-X and ignores TX_FAULT during the
> module's ~40s Linux boot time.
>
> Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed
> 2.5Gbps link and full throughput with flow offloading.
>
> Suggested-by: Marcin Nita <marcin.nita@leolabs.pl>
> Signed-off-by: John Pavlick <jspavlick@posteo.net>
> ---
> Changes in v2:
> - Add Suggested-by tag for Marcin Nita <marcin.nita@leolabs.pl>, who
> suggested investigating sfp.c quirks as a solution rather than
> attempting to edit the EEPROM data directly on the module.
Please read the maintainer-netdev documentation, particularly on
submisison of patches. You need to specify the tree and also avoid
resending within 24 ours.
Patch looks fine.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks!
--
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
* Re: [PATCH net v2 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Jason Xing @ 2026-04-07 8:21 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, kuniyu, davem, edumazet, kuba, pabeni, horms, xemul,
yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
wangjiexun2025
In-Reply-To: <20260407080015.1744197-1-n05ec@lzu.edu.cn>
On Tue, Apr 7, 2026 at 4:01 PM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Jiexun Wang <wangjiexun2025@gmail.com>
>
> Exact UNIX diag lookups hold a reference to the socket, but not to
> u->path. Meanwhile, unix_release_sock() clears u->path under
> unix_state_lock() and drops the path reference after unlocking.
>
> Read the inode and device numbers for UNIX_DIAG_VFS while holding
> unix_state_lock(), then emit the netlink attribute after dropping the
> lock.
>
> This keeps the VFS data stable while the reply is being built.
>
> Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
> 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: Jiexun Wang <wangjiexun2025@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Next time, please, you should obey the submission rules. One of them
is to at least wait ~24 hours before posting a new version, which
makes reviewers from all over the world have a chance to take a look
at your patch.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics
From: Jens Emil Schulz Ostergaard @ 2026-04-07 8:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195639.2789284-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: lan9645x: add port statistics
>
> Add statistics support for the port counters. Chip registers are 32 bit,
> so this unit is responsible maintaining a 64bit software cache, and
> updating it frequently to handle overflows in hardware.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 24a60f40f6b8..9a46c08dad59 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > @@ -262,6 +264,12 @@ static int lan9645x_setup(struct dsa_switch *ds)
> > if (!lan9645x->owq)
> > return -ENOMEM;
> >
> > + err = lan9645x_stats_init(lan9645x);
> > + if (err) {
> > + dev_err(dev, "Failed to init stats.\n");
> > + goto owq_destroy;
> > + }
> > +
> [ ... ]
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> > index 000000000000..3e82a859f173
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> [ ... ]
> > +static const struct lan9645x_ethtool_stat lan9645x_port_ethtool_stats[] = {
> > + { "rx_uc", SCNT_RX_UC },
> > + { "rx_cat_drop", SCNT_RX_CAT_DROP },
> [ ... ]
> > + { "tx_uc", SCNT_TX_UC },
> > + { "tx_drop", SCNT_TX_DROP },
> [ ... ]
> > +};
>
> Is it necessary to duplicate standard networking statistics in the driver
> private ethtool output?
>
> The networking subsystem guidelines state that stats possessing a standard UAPI
> representation, such as tx_dropped and rx_packets in struct rtnl_link_stats64,
> should not be duplicated in the ethtool -S output.
>
> Could these redundant strings be removed since the driver natively supports
> them via lan9645x_stats_get_stats64?
>
I do not think they are redundant. They are only available in an aggregated form
via rtnl_link_stats64, not directly. Information is lost if they are removed.
> [ ... ]
> > +static const struct lan9645x_view_stats lan9645x_view_stat_cfgs[] = {
> > + [LAN9645X_STAT_PORTS] = {
> > + .name = "ports",
> > + .type = LAN9645X_STAT_PORTS,
> > + .layout = lan9645x_port_stats_layout,
> > + .num_cnts = ARRAY_SIZE(lan9645x_port_stats_layout),
> > + .num_indexes = NUM_PHYS_PORTS,
> > + },
> > +};
> [ ... ]
> > +static u64 *lan9645x_stats_view_idx_update(struct lan9645x *lan9645x,
> > + enum lan9645x_view_stat_type vtype,
> > + int idx)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > +
> > + mutex_lock(&s->hw_lock);
> > + __lan9645x_stats_view_idx_update(lan9645x, vtype, idx);
> > + mutex_unlock(&s->hw_lock);
> > +
> > + return STAT_COUNTERS(lan9645x, vtype, idx);
> > +}
>
> Does this code overflow the allocated buffer when called for the CPU port?
>
> The stats buffer cnts is allocated using num_indexes, which is NUM_PHYS_PORTS
> (9). This covers ports 0 to 8. However, the CPU port is defined as index 9
> (CPU_PORT = 9).
>
> When the DSA core invokes stat callbacks like get_ethtool_stats or get_stats64
> for the CPU port, the idx argument is 9. While the helper
> __lan9645x_stats_view_idx_update skips the hardware read for out-of-bounds
> indices, lan9645x_stats_view_idx_update ignores that failure and returns the
> result of STAT_COUNTERS(lan9645x, vtype, idx).
>
> This computes a pointer past the end of the cnts array, which the callers then
> blindly dereference, potentially leaking kernel memory or causing a crash. Can
> bounds checking be added to the callers, or should the buffer be sized to
> include the CPU port?
>
No this is not called for the CPU port index 9.
> [ ... ]
> > +void lan9645x_stats_get_ethtool_stats(struct lan9645x *lan9645x, int port,
> > + u64 *data)
> > +{
> > + struct lan9645x_stats *stats = lan9645x->stats;
> > + u64 *c;
> > + int i;
> > +
> > + c = lan9645x_stats_view_idx_update(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&stats->sw_lock);
> > + for (i = 0; i < ARRAY_SIZE(lan9645x_port_ethtool_stats); i++)
> > + *data++ = c[lan9645x_port_ethtool_stats[i].idx];
> > + spin_unlock(&stats->sw_lock);
> > +}
> [ ... ]
> > +/* Called in atomic context */
> > +void lan9645x_stats_get_stats64(struct lan9645x *lan9645x, int port,
> > + struct rtnl_link_stats64 *stats)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > + u64 *c;
> > +
> > + c = STAT_COUNTERS(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&s->sw_lock);
>
> Can this code deadlock when a softirq interrupts a process holding the lock?
>
> The sw_lock spinlock protects the 64-bit software stats counters. In
> lan9645x_stats_get_stats64, which acts as the ndo_get_stats64 callback, this
> lock is acquired using a plain spin_lock. The code comment notes this function
> is called in atomic context (such as from NET_RX_SOFTIRQ via dev_get_stats).
>
> Concurrently, process context paths like lan9645x_stats_get_ethtool_stats and
> lan9645x_check_stats_work also acquire sw_lock using plain spin_lock. Because
> plain spin_lock does not disable softirqs, if a softirq preempts the execution
> on a CPU while process context holds sw_lock, the softirq will spin
> indefinitely waiting for the lock.
>
> Should the process-context acquisitions use spin_lock_bh instead?
>
As far as I can tell ndo_get_stats64 is not called from softirq. Ocelot also uses
a plain spin_lock here. Since no softirq path touches this lock, there is no
deadlock.
> [ ... ]
> > +int lan9645x_stats_init(struct lan9645x *lan9645x)
> > +{
> > + const struct lan9645x_view_stats *vs;
> > + struct lan9645x_stats *stats;
> > + int err, i;
> > +
> > + lan9645x->stats = devm_kzalloc(lan9645x->dev, sizeof(*stats),
> > + GFP_KERNEL);
>
> Will this memory be leaked when the DSA switch unbinds and rebinds?
>
> The lan9645x_stats_init function allocates lan9645x->stats, vstat->cnts, and
> vstat->buf using devm_kzalloc and devm_kcalloc. This function is called from
> lan9645x_setup, which is the DSA .setup callback.
>
> The DSA tree lifecycle is independent of the platform device lifecycle. If the
> master netdevice is unbound and bound again, the DSA switch's .teardown and
> .setup callbacks will be invoked multiple times. Because .teardown cannot free
> devres-managed memory, the memory tied to the platform device will be leaked
> on every setup cycle until the switch's platform device itself is destroyed.
>
> Could this use standard kzalloc allocations paired with kfree in teardown?
Similar comment as the devm_* comment for the .setup function. I do not think
this is a problem, since there can not be multiple setup/teardown cycles
during the device lifetime. dsa_tree_teardown is only called from
dsa_switch_remove which is called by the switch drivers .remove.
As far as I can tell both felix and ksz use device managed allocations in their
setup callback.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Thomas Richard @ 2026-04-07 8:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260405-smoky-spectacular-koel-dbfcda@quoll>
Hello Krzysztof,
On 4/5/26 10:06 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
>> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
>> driver only supports LAN7500 and LAN7505 devices.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>
> Rather microchip,lan7500.yaml. Wildcards don't really scale when you
> have 75yy coming which does not fit into this binding.
>
>
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description:
>> + Device tree properties for LAN75XX compatible USB Ethernet controller.
>> +
>> +allOf:
>> + - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>
> Drop items, that's enum directly.
>
>> + - enum:
>> + - usb424,7500
>> + - usb424,7505
>
> But you should notice that this is exactly the same as 95xx, so why it
> cannot go there? Because of the wildcard 95xx naming? That's not a
> reason.
Yes I noticed. I did not put them in 95xx because it is not the same
driver. Isn't that a valid reason?
Best Regards,
Thomas
^ permalink raw reply
* [PATCH net] atm: mpoa: fix mpc->dev refcount across mpoad restart
From: Shuvam Pandey @ 2026-04-07 8:35 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev
Cc: linux-kernel, syzbot+5ec223ccb83b24ef982f
atm: mpoa: fix mpc->dev refcount across mpoad restart
mpoad_close() drops the reference held in mpc->dev with dev_put(), but
the mpoa_client stays alive and keeps the same device pointer.
A later mpoad attach reuses the existing mpoa_client without
reacquiring that reference, so the next close can hit the netdevice
refcount warning. Keep the LEC device reference with the mpoa_client
until the device unregisters or the client is torn down.
Reported-by: syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.com
Link: https://groups.google.com/g/syzkaller-bugs/c/qhZ5MJfLBOE/m/UnotmgRdAQAJ
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
---
net/atm/mpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/atm/mpc.c b/net/atm/mpc.c
index ce8e9780373b..1e9b9c633e8b 100644
--- a/net/atm/mpc.c
+++ b/net/atm/mpc.c
@@ -886,7 +886,6 @@ static void mpoad_close(struct atm_vcc *vcc)
struct lec_priv *priv = netdev_priv(mpc->dev);
priv->lane2_ops->associate_indicator = NULL;
stop_mpc(mpc);
- dev_put(mpc->dev);
}
mpc->in_ops->destroy_cache(mpc);
@@ -1508,6 +1507,8 @@ static void __exit atm_mpoa_cleanup(void)
priv = netdev_priv(mpc->dev);
if (priv->lane2_ops != NULL)
priv->lane2_ops->associate_indicator = NULL;
+ dev_put(mpc->dev);
+ mpc->dev = NULL;
}
ddprintk("about to clear caches\n");
mpc->in_ops->destroy_cache(mpc);
--
2.50.0
^ permalink raw reply related
* Re: [PATCH 1/1] net: hsr: avoid learning nodes from ordinary PRP SAN traffic
From: Paolo Abeni @ 2026-04-07 8:40 UTC (permalink / raw)
To: Ao Zhou, netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Felix Maurer, Murali Karicheri, Shaurya Rane,
Sebastian Andrzej Siewior, Ingo Molnar, Kees Cook, Yifan Wu,
Juefei Pu, Yuan Tan, Xin Liu, Yuqi Xu
In-Reply-To: <9c88b4b7844f867d065e7a7aba28b2c026386168.1775056603.git.royenheart@outlook.com>
On 4/2/26 4:18 PM, Ao Zhou wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> PRP slave ports accept ordinary SAN traffic and forward it to the
> master device without needing a persistent node entry. Creating one
> node per previously unseen SAN source lets arbitrary source MAC floods
> grow node_db until the prune timer catches up.
>
> Keep the receive path for ordinary PRP SAN traffic, but stop learning a
> new node when the frame is untagged and does not carry a PRP trailer.
> Continue to deliver the frame locally and only keep node state for
> actual HSR/PRP senders or nodes that have already been learned.
It's not clear to me what prevents the rouge sender from always
including a valid PRP trailer, thus still causing the issue addressed
here. Some rationale needs to be included, or possibly limit the amount
of newly created nodes to some configurable maximum.
> Fixes: 451d8123f897 ("net: prp: add packet handling support")
> 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: Yuqi Xu <xuyuqiabc@gmail.com>
> Signed-off-by: Haoze Xie <royenheart@gmail.com>
> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> ---
> net/hsr/hsr_forward.c | 14 ++++++++++----
> net/hsr/hsr_framereg.c | 16 +++++++++++++---
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index aefc9b6936ba..5fbfc42997d2 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -403,7 +403,8 @@ static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
> int res, recv_len;
>
> was_multicast_frame = (skb->pkt_type == PACKET_MULTICAST);
> - hsr_addr_subst_source(node_src, skb);
> + if (node_src)
> + hsr_addr_subst_source(node_src, skb);
> skb_pull(skb, ETH_HLEN);
> recv_len = skb->len;
> res = netif_rx(skb);
> @@ -699,8 +700,12 @@ static int fill_frame_info(struct hsr_frame_info *frame,
>
> frame->node_src = hsr_get_node(port, n_db, skb,
> frame->is_supervision, port->type);
> - if (!frame->node_src)
> - return -1; /* Unknown node and !is_supervision, or no mem */
> + if (IS_ERR(frame->node_src)) {
> + ret = PTR_ERR(frame->node_src);
> + if (ret != -ENOENT)
> + return ret;
> + frame->node_src = NULL;
> + }
>
> ethhdr = (struct ethhdr *)skb_mac_header(skb);
> frame->is_vlan = false;
> @@ -739,7 +744,8 @@ void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port)
> if (fill_frame_info(&frame, skb, port) < 0)
> goto out_drop;
>
> - hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> + if (frame.node_src)
> + hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> hsr_forward_do(&frame);
I *think* the hsr_forward_do() could unconditionally dereference
node_src in:
hsr->proto_ops->register_frame_out -> {prp,hsr}_register_frame_out ->
hsr_check_duplicate:
node = frame->node_src;
if (WARN_ON_ONCE(port_type >= node->seq_port_cnt))
/P
^ permalink raw reply
* [PATCH net v2] Revert "mptcp: add needs_id for netlink appending addr"
From: Matthieu Baerts (NGI0) @ 2026-04-07 8:41 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, stable, Matthieu Baerts (NGI0)
This commit was originally adding the ability to add MPTCP endpoints
with ID 0 by accident. The in-kernel PM, handling MPTCP endpoints at the
net namespace level, is not supposed to handle endpoints with such ID,
because this ID 0 is reserved to the initial subflow, as mentioned in
the MPTCPv1 protocol [1], a per-connection setting.
Note that 'ip mptcp endpoint add id 0' stops early with an error, but
other tools might still request the in-kernel PM to create MPTCP
endpoints with this restricted ID 0.
In other words, it was wrong to call the mptcp_pm_has_addr_attr_id
helper to check whether the address ID attribute is set: if it was set
to 0, a new MPTCP endpoint would be created with ID 0, which is not
expected, and might cause various issues later.
Fixes: 584f38942626 ("mptcp: add needs_id for netlink appending addr")
Cc: stable@vger.kernel.org
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.2-9 [1]
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
v2:
- The v1 has been sent to net-next with a different commit message:
https://lore.kernel.org/20260403-net-next-mptcp-msg_eor-misc-v1-4-b0b33bea3fed@kernel.org
---
net/mptcp/pm_kernel.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index 82e59f9c6dd9..0ebf43be9939 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -720,7 +720,7 @@ static void __mptcp_pm_release_addr_entry(struct mptcp_pm_addr_entry *entry)
static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
struct mptcp_pm_addr_entry *entry,
- bool needs_id, bool replace)
+ bool replace)
{
struct mptcp_pm_addr_entry *cur, *del_entry = NULL;
int ret = -EINVAL;
@@ -779,7 +779,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id) {
+ if (!entry->addr.id) {
find_next:
entry->addr.id = find_next_zero_bit(pernet->id_bitmap,
MPTCP_PM_MAX_ADDR_ID + 1,
@@ -790,7 +790,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id)
+ if (!entry->addr.id)
goto out;
__set_bit(entry->addr.id, pernet->id_bitmap);
@@ -923,7 +923,7 @@ int mptcp_pm_nl_get_local_id(struct mptcp_sock *msk,
return -ENOMEM;
entry->addr.port = 0;
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true, false);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, false);
if (ret < 0)
kfree(entry);
@@ -977,18 +977,6 @@ static int mptcp_nl_add_subflow_or_signal_addr(struct net *net,
return 0;
}
-static bool mptcp_pm_has_addr_attr_id(const struct nlattr *attr,
- struct genl_info *info)
-{
- struct nlattr *tb[MPTCP_PM_ADDR_ATTR_MAX + 1];
-
- if (!nla_parse_nested_deprecated(tb, MPTCP_PM_ADDR_ATTR_MAX, attr,
- mptcp_pm_address_nl_policy, info->extack) &&
- tb[MPTCP_PM_ADDR_ATTR_ID])
- return true;
- return false;
-}
-
/* Add an MPTCP endpoint */
int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
{
@@ -1037,9 +1025,7 @@ int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
goto out_free;
}
}
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry,
- !mptcp_pm_has_addr_attr_id(attr, info),
- true);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true);
if (ret < 0) {
GENL_SET_ERR_MSG_FMT(info, "too many addresses or duplicate one: %d", ret);
goto out_free;
---
base-commit: a9d4f4f6e65e0bf9bbddedecc84d67249991979c
change-id: 20260406-net-mptcp-revert-pm-needs-id-f1cbb7021f9e
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply related
* [PATCH net] net: initialize sk_rx_queue_mapping in sk_clone()
From: Jiayuan Chen @ 2026-04-07 8:42 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, David S. Miller, Jakub Kicinski, Simon Horman,
Soheil Hassas Yeganeh, linux-kernel
sk_clone() initializes sk_tx_queue_mapping via sk_tx_queue_clear()
but does not initialize sk_rx_queue_mapping. Since this field is in
the sk_dontcopy region, it is neither copied from the parent socket
by sock_copy() nor zeroed by sk_prot_alloc() (called without
__GFP_ZERO from sk_clone).
Commit 03cfda4fa6ea ("tcp: fix another uninit-value
(sk_rx_queue_mapping)") attempted to fix this by introducing
sk_mark_napi_id_set() with force_set=true in tcp_child_process().
However, sk_mark_napi_id_set() -> sk_rx_queue_set() only writes
when skb_rx_queue_recorded(skb) is true. If the 3-way handshake
ACK arrives through a device that does not record rx_queue (e.g.
loopback or veth), sk_rx_queue_mapping remains uninitialized.
When a subsequent data packet arrives with a recorded rx_queue,
sk_mark_napi_id() -> sk_rx_queue_update() reads the uninitialized
field for comparison (force_set=false path), triggering KMSAN.
This was reproduced by establishing a TCP connection over loopback
(which does not call skb_record_rx_queue), then attaching a BPF TC
program on lo ingress to set skb->queue_mapping on data packets:
BUG: KMSAN: uninit-value in tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2287)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)
ip_local_deliver_finish (net/ipv4/ip_input.c:242)
ip_local_deliver (net/ipv4/ip_input.c:262)
ip_rcv (net/ipv4/ip_input.c:573)
__netif_receive_skb (net/core/dev.c:6294)
process_backlog (net/core/dev.c:6646)
__napi_poll (net/core/dev.c:7710)
net_rx_action (net/core/dev.c:7929)
handle_softirqs (kernel/softirq.c:623)
do_softirq (kernel/softirq.c:523)
__local_bh_enable_ip (kernel/softirq.c:?)
__dev_queue_xmit (net/core/dev.c:?)
ip_finish_output2 (net/ipv4/ip_output.c:237)
ip_output (net/ipv4/ip_output.c:438)
__ip_queue_xmit (net/ipv4/ip_output.c:534)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1693)
tcp_write_xmit (net/ipv4/tcp_output.c:3064)
tcp_sendmsg_locked (net/ipv4/tcp.c:?)
tcp_sendmsg (net/ipv4/tcp.c:1465)
inet_sendmsg (net/ipv4/af_inet.c:865)
sock_write_iter (net/socket.c:1195)
vfs_write (fs/read_write.c:688)
...
Uninit was created at:
kmem_cache_alloc_noprof (mm/slub.c:4873)
sk_prot_alloc (net/core/sock.c:2239)
sk_alloc (net/core/sock.c:2301)
inet_create (net/ipv4/af_inet.c:334)
__sock_create (net/socket.c:1605)
__sys_socket (net/socket.c:1747)
Fix this at the root by adding sk_rx_queue_clear() alongside
sk_tx_queue_clear() in sk_clone().
Fixes: 342159ee394d ("net: avoid dirtying sk->sk_rx_queue_mapping")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
net/core/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5976100a9d55..a12c5eca88f2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2583,6 +2583,7 @@ struct sock *sk_clone(const struct sock *sk, const gfp_t priority,
sk_set_socket(newsk, NULL);
sk_tx_queue_clear(newsk);
+ sk_rx_queue_clear(newsk);
RCU_INIT_POINTER(newsk->sk_wq, NULL);
if (newsk->sk_prot->sockets_allocated)
--
2.43.0
^ permalink raw reply related
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