* Re: [PATCH net] vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting
From: Bobby Eshleman @ 2026-04-20 18:34 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, Eric Dumazet, Simon Horman, kvm, Arseniy Krasnov,
David S. Miller, Paolo Abeni, Jakub Kicinski, Michael S. Tsirkin,
Jason Wang, virtualization, linux-kernel, Eugenio Pérez,
Xuan Zhuo, Stefan Hajnoczi, Yiming Qian
In-Reply-To: <20260420132051.217589-1-sgarzare@redhat.com>
On Mon, Apr 20, 2026 at 03:20:51PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> virtio_transport_init_zcopy_skb() uses iter->count as the size argument
> for msg_zerocopy_realloc(), which in turn passes it to
> mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this
> function is called after virtio_transport_fill_skb() has already consumed
> the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count
> will be 0, skipping the RLIMIT_MEMLOCK enforcement.
>
> Pass pkt_len (the total bytes being sent) as an explicit parameter to
> virtio_transport_init_zcopy_skb() instead of reading the already-consumed
> iter->count.
>
> This matches TCP and UDP, which both call msg_zerocopy_realloc() with
> the original message size.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 0742091beae7..416d533f493d 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -73,6 +73,7 @@ static bool virtio_transport_can_zcopy(const struct virtio_transport *t_ops,
> static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
> struct sk_buff *skb,
> struct msghdr *msg,
> + size_t pkt_len,
> bool zerocopy)
> {
> struct ubuf_info *uarg;
> @@ -81,12 +82,10 @@ static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
> uarg = msg->msg_ubuf;
> net_zcopy_get(uarg);
> } else {
> - struct iov_iter *iter = &msg->msg_iter;
> struct ubuf_info_msgzc *uarg_zc;
>
> uarg = msg_zerocopy_realloc(sk_vsock(vsk),
> - iter->count,
> - NULL, false);
> + pkt_len, NULL, false);
> if (!uarg)
> return -1;
>
> @@ -398,11 +397,17 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> * each iteration. If this is last skb for this buffer
> * and MSG_ZEROCOPY mode is in use - we must allocate
> * completion for the current syscall.
> + *
> + * Pass pkt_len because msg iter is already consumed
> + * by virtio_transport_fill_skb(), so iter->count
> + * can not be used for RLIMIT_MEMLOCK pinned-pages
> + * accounting done by msg_zerocopy_realloc().
> */
> if (info->msg && info->msg->msg_flags & MSG_ZEROCOPY &&
> skb_len == rest_len && info->op == VIRTIO_VSOCK_OP_RW) {
> if (virtio_transport_init_zcopy_skb(vsk, skb,
> info->msg,
> + pkt_len,
> can_zcopy)) {
> kfree_skb(skb);
> ret = -ENOMEM;
> --
> 2.53.0
>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
^ permalink raw reply
* Re: [PATCH net] tcp: make probe0 timer handle expired user timeout
From: Jakub Kicinski @ 2026-04-20 18:33 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell
Cc: Altan Hacigumus, Kuniyuki Iwashima, David S . Miller, David Ahern,
Paolo Abeni, Simon Horman, netdev, Enke Chen
In-Reply-To: <20260414013634.43997-1-ahacigu.linux@gmail.com>
On Mon, 13 Apr 2026 18:36:34 -0700 Altan Hacigumus wrote:
> tcp_clamp_probe0_to_user_timeout() computes remaining time in jiffies
> using subtraction with an unsigned lvalue. If elapsed probing time
> already exceeds the configured TCP_USER_TIMEOUT, the subtraction
> underflows and yields a large value.
>
> Handle this expiration case similarly to tcp_clamp_rto_to_user_timeout().
>
> Fixes: 344db93ae3ee ("tcp: make TCP_USER_TIMEOUT accurate for zero window probes")
> Signed-off-by: Altan Hacigumus <ahacigu.linux@gmail.com>
Hi Eric, Neal, does this makes sense?
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 5a14a53a3c9e..4a43356a4e06 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -50,7 +50,8 @@ static u32 tcp_clamp_rto_to_user_timeout(const struct sock *sk)
> u32 tcp_clamp_probe0_to_user_timeout(const struct sock *sk, u32 when)
> {
> const struct inet_connection_sock *icsk = inet_csk(sk);
> - u32 remaining, user_timeout;
> + u32 user_timeout;
> + s32 remaining;
> s32 elapsed;
>
> user_timeout = READ_ONCE(icsk->icsk_user_timeout);
> @@ -61,6 +62,8 @@ u32 tcp_clamp_probe0_to_user_timeout(const struct sock *sk, u32 when)
> if (unlikely(elapsed < 0))
> elapsed = 0;
> remaining = msecs_to_jiffies(user_timeout) - elapsed;
> + if (remaining <= 0)
> + return 1;
> remaining = max_t(u32, remaining, TCP_TIMEOUT_MIN);
>
> return min_t(u32, remaining, when);
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers
From: Ido Schimmel @ 2026-04-20 18:26 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, idosch, dsahern, davem, edumazet, kuba, pabeni, horms,
jiri, yifanwucs, tomapufckgml, yuantan098, bird, royenheart
In-Reply-To: <20260420113208.GA972415@shredder>
On Mon, Apr 20, 2026 at 02:32:08PM +0300, Ido Schimmel wrote:
> On Sun, Apr 19, 2026 at 10:53:32PM +0800, Ren Wei wrote:
> > From: Haoze Xie <royenheart@gmail.com>
> >
> > Several l3mdev slave-side helpers resolve an upper device and then use
> > l3mdev_ops without first proving that the resolved device is still a
> > valid L3 master.
> >
> > During slave transition, an RCU reader can transiently observe an upper
> > that is not an L3 master. Guard the affected slave-resolved paths by
> > requiring the resolved upper to still be an L3 master before using
> > l3mdev_ops, while keeping existing L3 RX handler providers intact.
> >
> > Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
> > Cc: stable@kernel.org
> > 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: Haoze Xie <royenheart@gmail.com>
> > Signed-off-by: Haoze Xie <royenheart@gmail.com>
> > Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
>
> I think it's fine for net:
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Thought about this again. I would like to check another approach
(synchronize_net() after clearing IFF_L3MDEV_SLAVE). Will update
tomorrow.
^ permalink raw reply
* Re: [net-next,v9,09/10] test: Add ext_hdr.py in networking selftests
From: Tom Herbert @ 2026-04-20 18:25 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, justin.iurman, willemdebruijn.kernel, pabeni, willemb,
davem, kuba, justin.iurman
In-Reply-To: <20260317152456.1742468-3-horms@kernel.org>
On Tue, Mar 17, 2026 at 8:26 AM Simon Horman <horms@kernel.org> 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
>
> Simon says: pylint also has quite a lot to say about this patch. I'm
> assuming it is all minor stuff. But could you look into addressing the
> issues it flags?
Yes, it's all minor and score is good.
>
> ---
> test: Add ext_hdr.py in networking selftests
>
> This commit adds a new Python helper file that contains Extension Header
> format definitions and related functions for building IPv6 extension
> header chains in networking selftests.
>
> > diff --git a/tools/testing/selftests/net/ext_hdr.py b/tools/testing/selftests/net/ext_hdr.py
> > new file mode 100755
> > index 000000000000..bfb7da4a7c88
> > --- /dev/null
> > +++ b/tools/testing/selftests/net/ext_hdr.py
> > @@ -0,0 +1,385 @@
> > +#!/usr/bin/env python3
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +# Helper functions for creating extension headers using scapy
> > +
> > +import ctypes
> > +import shlex
> > +import socket
> > +import sys
> > +import subprocess
> > +import scapy
> > +import proto_nums
> > +
> > +
> > +# Read a sysctl
> > +def sysctl_read(name):
> > + try:
> > + # shlex.split helps handle arguments correctly
> > + command = shlex.split(f"sysctl -n {name}")
> > + # Use check=True to raise an exception if the command fails
> > + result = subprocess.run(command, check=True,
> > + capture_output=True, text=True)
> > + value = result.stdout.strip()
> > + except subprocess.CalledProcessError as ex:
> > + print(f"Error reading sysctl: {ex.stderr}")
> > + except FileNotFoundError:
> > + print("The 'sysctl' command was not found. "
> > + "Check your system's PATH.")
> > +
> > + return int(value)
>
> What happens when an exception is caught here? When either
> subprocess.CalledProcessError or FileNotFoundError occurs, the exception
> handlers print an error message but don't set 'value'. The function then
> reaches the 'return int(value)' statement, which will raise
> UnboundLocalError.
>
> This will crash the test in several places:
>
> tools/testing/selftests/net/ext_hdr.py:check_eh_order() uses the return:
> do_check = sysctl_read("net.ipv6.enforce_ext_hdr_order")
>
> tools/testing/selftests/net/ext_hdr.py:make_eh_chain() uses the return:
> pair = make_full_hbh_dst_options_list(nnext_hdr, args,
> sysctl_read("net.ipv6.max_hbh_opts_number"),
> sysctl_read("net.ipv6.max_hbh_length"))
>
> and:
> pair = make_full_hbh_dst_options_list(nnext_hdr, args,
> sysctl_read("net.ipv6.max_dst_opts_number"),
> sysctl_read("net.ipv6.max_dst_opts_length"))
>
> Should the exception handlers return a default value or re-raise to let
> callers handle it?
>
> > +
> > +# Common definitions for Destination and Hop-by-Hop options
>
> [ ... ]
>
> Should ext_hdr.py be added to TEST_FILES in the Makefile? The selftests
> build system documentation requires that any file imported by test scripts
> must be added to TEST_FILES. Without this, tests will work in the source
> tree but fail after 'make install' with ModuleNotFoundError.
Yes, I will add missing files
>
> The file is imported at line 12 ('import proto_nums'), and appears to be
> a library meant for import rather than direct execution. Both ext_hdr.py
> and proto_nums.py need to be added to TEST_FILES in
> tools/testing/selftests/net/Makefile.
Yes, will do
^ permalink raw reply
* Re: [PATCH net-next v9 10/10] test: Add networking selftest for eh limits
From: Tom Herbert @ 2026-04-20 18:23 UTC (permalink / raw)
To: Simon Horman
Cc: davem, kuba, netdev, justin.iurman, willemdebruijn.kernel, pabeni
In-Reply-To: <20260317153222.GD1710951@horms.kernel.org>
On Tue, Mar 17, 2026 at 8:32 AM Simon Horman <horms@kernel.org> wrote:
>
> On Sat, Mar 14, 2026 at 10:51:24AM -0700, Tom Herbert wrote:
> > Add a networking selftest for Extension Header limits. The
> > limits to test are in systcls:
> >
> > net.ipv6.enforce_ext_hdr_order
> > net.ipv6.max_dst_opts_number
> > net.ipv6.max_hbh_opts_number
> > net.ipv6.max_hbh_length
> > net.ipv6.max_dst_opts_length
> >
> > The basic idea of the test is to fabricate ICMPv6 Echo Request
> > packets with various combinations of Extension Headers. The packets
> > are sent to a host in another namespace. If a an ICMPv6 Echo Reply
> > is received then the packet wasn't dropped due to a limit being
> > exceeded, and if it was dropped then we assume that a limit was
> > exceeded. For each test packet we derive an expectation as to
> > whether the packet will be dropped or not. Test success depends
> > on whether our expectation is matched. i.e. if we expect a reply
> > then the test succeeds if we see a reply, and if we don't expect a
> > reply then the test succeeds if we don't see a reply.
> >
> > The test is divided into a frontend bash script (eh_limits.sh) and a
> > backend Python script (eh_limits.py).
> >
> > The frontend sets up two network namespaces with IPv6 addresses
> > configured on veth's. We then invoke the backend to send the
> > test packets. This first pass is done with default sysctl settings.
> > On a second pass we change the various sysctl settings and run
> > again.
> >
> > The backend runs through the various test cases described in the
> > Make_Test_Packets function. This function calls Make_Packet for
> > a test case where arguments provide the Extension Header chain to
> > be tested. The Run_Test function loops through the various packets
> > and tests if a reply is received versus the expectation. If a test
> > case fails then an error status is returned by the backend.
> >
> > The backend script can also be run with the "-w <pcap_file>" to
> > write the created packets to a pcap file instead of running the
> > test.
> >
> > Signed-off-by: Tom Herbert <tom@herbertland.com>
> > ---
> > tools/testing/selftests/net/Makefile | 1 +
> > tools/testing/selftests/net/eh_limits.py | 349 +++++++++++++++++++++++
> > tools/testing/selftests/net/eh_limits.sh | 205 +++++++++++++
> > 3 files changed, 555 insertions(+)
> > create mode 100755 tools/testing/selftests/net/eh_limits.py
> > create mode 100755 tools/testing/selftests/net/eh_limits.sh
>
> Hi Tom,
>
> Shellcheck flags several instances of the following:
>
> - https://www.shellcheck.net/wiki/SC2154 -- ns1 is referenced but not assigned.
> - https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
>
> In the case of SC2086 I think this can be trivially addressed by adding
> double quotes.
>
> While I think SC2154 should probably be ignored using
>
> # shellcheck disable=SC2154
>
> We're trying to make new scripts shellcheck clean, so I'd appreciate it if
> you could look into this.
Okay, I'll fix the double quotes.
>
>
> Also, pylint has also something to say about this patch.
I don't believe those warnings aren't critical, and the score is a
high as other python files in the directory.
Tom
>
> ...
^ permalink raw reply
* Re: [PATCH-next v2 0/2] ipvs: Fix incorrect use of HK_TYPE_KTHREAD housekeeping cpumask
From: Julian Anastasov @ 2026-04-20 18:13 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Waiman Long, Simon Horman, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Florian Westphal,
Phil Sutter, Frederic Weisbecker, Chen Ridong, Phil Auld,
linux-kernel, netdev, lvs-devel, netfilter-devel, coreteam,
sheviks
In-Reply-To: <aeZmVMaMymU6ZS5S@chamomile>
Hello,
On Mon, 20 Apr 2026, Pablo Neira Ayuso wrote:
> On Mon, Apr 20, 2026 at 08:24:56PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Fri, 3 Apr 2026, Pablo Neira Ayuso wrote:
> >
> > > On Fri, Apr 03, 2026 at 05:15:50PM +0300, Julian Anastasov wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Tue, 31 Mar 2026, Waiman Long wrote:
> > > >
> > > > > v2:
> > > > > - Rebased on top of linux-next
> > > > >
> > > > > Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for preferred
> > > > > affinity management"), the HK_TYPE_KTHREAD housekeeping cpumask may no
> > > > > longer be correct in showing the actual CPU affinity of kthreads that
> > > > > have no predefined CPU affinity. As the ipvs networking code is still
> > > > > using HK_TYPE_KTHREAD, we need to make HK_TYPE_KTHREAD reflect the
> > > > > reality.
> > > > >
> > > > > This patch series makes HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > > > and uses RCU to protect access to the HK_TYPE_KTHREAD housekeeping
> > > > > cpumask.
> > > > >
> > > > > Waiman Long (2):
> > > > > sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > > > ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
> > > >
> > > > The patchset looks good to me for nf-next, thanks!
> > > >
> > > > Acked-by: Julian Anastasov <ja@ssi.bg>
> > > >
> > > > Pablo, Florian, as a bugfix this patchset missed
> > > > the chance to be applied before the changes that are in
> > > > nf-next in ip_vs.h, there is little fuzz there. If there
> > > > is no chance to resolve it somehow, we can apply it
> > > > on top of nf-next where it now applies successfully.
> > >
> > > One way to handle this is to follow up with nf-next as you suggest,
> > > then send a backport that applies cleanly for -stable once it is
> > > released.
> > >
> > > Else, let me know if I am misunderstanding.
> >
> > This patchset is now material for the net tree. To help it,
> > I just posted patch "ipvs: fix races around est_mutex and est_cpulist"
> > that can be applied before this patchset to the net tree.
> > Can we get this patchset for the net tree?
>
> Yes, I am preparing a PR.
>
> BTW, did you get look at the report provided by the AI assistant?
>
> https://sashiko.dev/#/?list=org.kernel.vger.netfilter-devel
Yes, I monitor it. I'm waiting the review for
my 3+1 patches from today. And I hope the review for
this HK_TYPE_KTHREAD patchset is addressed too with
"ipvs: fix races around est_mutex and est_cpulist".
> If not, please repost to get initial feedback from it.
>
> Thanks.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [ANN] netdev call - Apr 21st
From: Jakub Kicinski @ 2026-04-20 18:02 UTC (permalink / raw)
To: netdev
Hi!
The bi-weekly call is scheduled for tomorrow at 8:30 am (PT) /
5:30 pm (~EU), at https://bbb.lwn.net/rooms/ldm-chf-zxx-we7/join
I'd like to discuss evolution of the process which would prepare
us for the "AI age" (read: influx of plausibly looking yet entirely
computer generated patches).
^ permalink raw reply
* Re: [PATCH 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-20 17:59 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Richard Cochran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexandre Belloni, Yury Norov,
Rasmus Villemoes, Hans de Goede, Linus Walleij, Sakari Ailus,
Salah Triki, Achim Gratz, Ben Collins,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-rtc@vger.kernel.org
In-Reply-To: <5fea4ea146404b55919037594ab85f1a@realtek.com>
On Mon, Apr 20, 2026 at 07:49:19AM +0000, Ping-Ke Shih wrote:
> Yury Norov <ynorov@nvidia.com> wrote:
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852b_common.c
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852b_common.c
> > @@ -206,9 +206,9 @@ static void rtw8852bx_efuse_parsing_tssi(struct rtw89_dev *rtwdev,
> > static bool _decode_efuse_gain(u8 data, s8 *high, s8 *low)
> > {
> > if (high)
> > - *high = sign_extend32(FIELD_GET(GENMASK(7, 4), data), 3);
> > + *high = FIELD_GET_SIGNED(GENMASK(7, 4), data);
> > if (low)
> > - *low = sign_extend32(FIELD_GET(GENMASK(3, 0), data), 3);
> > + *low = FIELD_GET(GENMASK(3, 0), data);
>
> FIELD_GET_SIGNED()?
>
> >
> > return data != 0xff;
> > }
Ah sorry. Will fix in v2
^ permalink raw reply
* Re: pre-boot plugged SFP autoneg advertisement
From: Andrew Lunn @ 2026-04-20 17:57 UTC (permalink / raw)
To: markus.stockhausen
Cc: linux, hkallweit1, netdev, 'Jonas Jelonek', jan, nbd,
'Daniel Golle'
In-Reply-To: <007701dcd0e1$11c45210$354cf630$@gmx.de>
On Mon, Apr 20, 2026 at 06:16:34PM +0200, markus.stockhausen@gmx.de wrote:
> > Von: markus.stockhausen@gmx.de <markus.stockhausen@gmx.de>
> > Gesendet: Sonntag, 19. April 2026 10:49
> > An: 'Andrew Lunn' <andrew@lunn.ch>
> > Betreff: AW: pre-boot plugged SFP autoneg advertisement
> >
> > Took that hint/question and digged deeper. Added further debug
> > to each and every linkmode_copy. I think I found the culprit in
> > a userspace ethtool call. For now I assume OpenWrt netifd.
>
> Hi Andrew,
>
> once again thanks for your help. After further investigation I hopefully can
> add
> more details. I think I got the whole picture now. So some additional
> background
> information about the environment.
>
> - Realtek RTL930x devices with SFP+ module slots
> - These are driven directly by a SerDes (controlled by downstream PCS
> driver)
> - The DTS reads
>
> port11: port@11 {
> reg = <11>;
> label = "lan12" ;
> pcs-handle = <&serdes8>;
> phy-mode = "1000base-x";
> sfp = <&sfp1>;
> managed = "in-band-status";
> };
>
> Sequence of events during boot is as follows:
>
> - SFP module is already inserted (in my case 1G)
> - phylink_sfp_config_phy() runs long before any network config starts
> - OpenWrt netifd daemon starts and wants to configure the network interfaces
> - It reads current settings via ethtool ioctl and gets autoneg=off
> - It writes basic config values via ethtool ioctl including autneg=off
> - Later on it starts the interface and phylink_start() is issued
I would say netifd is not optimal. I'm not sure we every agree to
return the full ksetting on an interface which is admin down. Many
driver don't even connect to the PHY until open is called, and so are
likely to return -ENODEV. See phy_ethtool_set_link_ksettings().
Could you look into the behaviour of netifd, especially if it gets
-ENODEV during the first read. Does it try again after setting the
interface up?
Could you disable netifd and manually configure the interface up. Does
it get autoneg correct then?
Now, i think it is useful to be able to configure an interface when it
is admin down. So if ksetting_get does not return -ENODEV it probably
should return the full and correct information. However, im not sure
your change is sufficient to do that, since what an interface can
actually do is the common subset of what the MAC, PCS and SFP can
do. So just taking the value from the SFP does not feel correct to me,
at least not without having a deeper understanding of what phylink is
doing. And Russell King is busy with other things are the moment.
So i think we are looking at multiple problems/solutions here:
netifd should does a second ksettings_get after setting the interface
admin up, and reevaluates how the interface should be configured.
If we know phylink is going to return a subset of the correct
information when the interface is admin down, maybe it should return
-ENODEV?
Is it possible in general to make phylink return the full correct
ksetting when start() has not been called. We need to think about
multiple use cases here, not just an SFP, but also a PHY, a fixed link
and a BASE-T PHY inside an SFP module. Maybe it needs to sometimes
return -ENODEV, other times it can return correct information?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] netlink: clean up failed initial dump-start state
From: Michael Bommarito @ 2026-04-20 17:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, netdev, Simon Horman,
Kuniyuki Iwashima, Kees Cook, Feng Yang, linux-kernel
In-Reply-To: <20260420103715.347fbd4a@kernel.org>
On Mon, Apr 20, 2026 at 1:37 PM Jakub Kicinski <kuba@kernel.org> wrote:
> On a quick look I can't see which path clears the dump state in case we
> keep failing to allocate an skb. Could you add more info on that?
> ...
> This should be part of the commit message, it's useful to understanding
> the problem. Actually more than the current commit msg TBH.
> ...
> If you're planning to repost - please wait until tomorrow, we ask that
> revisions are at least 24h apart so that people across the timezones
> have a chance to chime in.
Thanks, good points. I'll set a reminder and follow up tomorrow with
your ideas if we don't hear from others.
Thanks,
Mike Bommarito
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-20 17:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260420111940.GE3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 01:19:40PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 17, 2026 at 01:36:12PM -0400, Yury Norov wrote:
> > The bitfields are designed in assumption that fields contain unsigned
> > integer values, thus extracting the values from the field implies
> > zero-extending.
> >
> > Some drivers need to sign-extend their fields, and currently do it like:
> >
> > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> >
> > It's error-prone because it relies on user to provide the correct
> > index of the most significant bit and proper 32 vs 64 function flavor.
> >
> > Thus, introduce a FIELD_GET_SIGNED() macro, which is the more
> > convenient and compiles (on x86_64) to just a couple instructions:
> > shl and sar.
> >
> > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > ---
> > include/linux/bitfield.h | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > index 54aeeef1f0ec..35ef63972810 100644
> > --- a/include/linux/bitfield.h
> > +++ b/include/linux/bitfield.h
> > @@ -178,6 +178,22 @@
> > __FIELD_GET(_mask, _reg, "FIELD_GET: "); \
> > })
> >
> > +/**
> > + * FIELD_GET_SIGNED() - extract a signed bitfield element
> > + * @mask: shifted mask defining the field's length and position
> > + * @reg: value of entire bitfield
> > + *
> > + * Returns the sign-extended field specified by @_mask from the
> > + * bitfield passed in as @_reg by masking and shifting it down.
> > + */
> > +#define FIELD_GET_SIGNED(mask, reg) \
> > + ({ \
> > + __BF_FIELD_CHECK(mask, reg, 0U, "FIELD_GET_SIGNED: "); \
> > + ((__signed_scalar_typeof(mask))((long long)(reg) << \
> > + __builtin_clzll(mask) >> (__builtin_clzll(mask) + \
> > + __builtin_ctzll(mask))));\
> > + })
>
> IIRC clz is count-leading-zeros and ctz is count-trailing-zeros. Most of
> the other FIELD things use __bf_shf() which is defined in terms of ffs -
> 1 (which is another way of writing ctz).
>
> So how about you start by redefining __bf_shf() in ctz, and then add
> another helper for the clz and write the thing something like:
>
> ((long long)(reg) << __bf_clz(mask)) >> (__bf_clz(mask) + __bf_shf(mask));
So...
I like the shorter form, but whatever we add in the bitfield.h - we'll
have to support it.
For example, __bf_shf() wasn't intended to be used outsize of the
header, thus double underscored. But there's over 100 external users
now. And to make it worse, it's broken for GCC 14 and earlier:
https://lore.kernel.org/all/20260409-field-prep-fix-v1-1-f0e9ae64f63c@imgtec.com/
So needs to get fixed.
The bitfield.h has two __bf macros: __bf_shf() and __bf_cast_unsigned().
They are thin wrappers, but after all do something with the corresponding
builtins output. The __bf_cls() would be a pure renaming. I'm OK with
that, but some people don't:
https://lore.kernel.org/all/20260303182845.250bb2de@kernel.org/
That's why I didn't make FIELD_GET_SIGNED() implementation looking nicer.
If you strongly prefer the shorter version, I can do that in v2.
> Also, since the order of the shifts is rather important, I think it
> makes sense to add this extra pair of (), even when not strictly needed,
> just to make it easier to read.
Sure, will do.
^ permalink raw reply
* Re: [PATCH-next v2 0/2] ipvs: Fix incorrect use of HK_TYPE_KTHREAD housekeeping cpumask
From: Pablo Neira Ayuso @ 2026-04-20 17:45 UTC (permalink / raw)
To: Julian Anastasov
Cc: Waiman Long, Simon Horman, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Florian Westphal,
Phil Sutter, Frederic Weisbecker, Chen Ridong, Phil Auld,
linux-kernel, netdev, lvs-devel, netfilter-devel, coreteam,
sheviks
In-Reply-To: <097db82c-c9d1-4532-694a-b7ecbdd67532@ssi.bg>
On Mon, Apr 20, 2026 at 08:24:56PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 3 Apr 2026, Pablo Neira Ayuso wrote:
>
> > On Fri, Apr 03, 2026 at 05:15:50PM +0300, Julian Anastasov wrote:
> > >
> > > Hello,
> > >
> > > On Tue, 31 Mar 2026, Waiman Long wrote:
> > >
> > > > v2:
> > > > - Rebased on top of linux-next
> > > >
> > > > Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for preferred
> > > > affinity management"), the HK_TYPE_KTHREAD housekeeping cpumask may no
> > > > longer be correct in showing the actual CPU affinity of kthreads that
> > > > have no predefined CPU affinity. As the ipvs networking code is still
> > > > using HK_TYPE_KTHREAD, we need to make HK_TYPE_KTHREAD reflect the
> > > > reality.
> > > >
> > > > This patch series makes HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > > and uses RCU to protect access to the HK_TYPE_KTHREAD housekeeping
> > > > cpumask.
> > > >
> > > > Waiman Long (2):
> > > > sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > > ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
> > >
> > > The patchset looks good to me for nf-next, thanks!
> > >
> > > Acked-by: Julian Anastasov <ja@ssi.bg>
> > >
> > > Pablo, Florian, as a bugfix this patchset missed
> > > the chance to be applied before the changes that are in
> > > nf-next in ip_vs.h, there is little fuzz there. If there
> > > is no chance to resolve it somehow, we can apply it
> > > on top of nf-next where it now applies successfully.
> >
> > One way to handle this is to follow up with nf-next as you suggest,
> > then send a backport that applies cleanly for -stable once it is
> > released.
> >
> > Else, let me know if I am misunderstanding.
>
> This patchset is now material for the net tree. To help it,
> I just posted patch "ipvs: fix races around est_mutex and est_cpulist"
> that can be applied before this patchset to the net tree.
> Can we get this patchset for the net tree?
Yes, I am preparing a PR.
BTW, did you get look at the report provided by the AI assistant?
https://sashiko.dev/#/?list=org.kernel.vger.netfilter-devel
If not, please repost to get initial feedback from it.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: hns: use u32 for register offset in RCB TX coalescing
From: Jakub Kicinski @ 2026-04-20 17:38 UTC (permalink / raw)
To: Agalakov Daniil
Cc: Jian Shen, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, netdev, linux-kernel, lvc-project, Roman Razov
In-Reply-To: <20260420144047.2846673-1-ade@amicon.ru>
On Mon, 20 Apr 2026 17:40:19 +0300 Agalakov Daniil wrote:
> The local variable reg in hns_rcb_get_tx_coalesced_frames() and
> hns_rcb_set_tx_coalesced_frames() holds a register offset passed to
> dsaf_read_dev()/dsaf_write_dev(). Register offsets on this hardware
> are 32-bit values; using u64 was misleading.
net-next is closed during the merge window.
If you repost please improve the "why". As is I don't think this patch
is worth merging.
^ permalink raw reply
* Re: [PATCH net-next] netlink: clean up failed initial dump-start state
From: Jakub Kicinski @ 2026-04-20 17:37 UTC (permalink / raw)
To: Michael Bommarito
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, netdev, Simon Horman,
Kuniyuki Iwashima, Kees Cook, Feng Yang, linux-kernel
In-Reply-To: <20260420162734.854587-1-michael.bommarito@gmail.com>
On Mon, 20 Apr 2026 12:27:34 -0400 Michael Bommarito wrote:
> When __netlink_dump_start() has already installed cb->skb, taken the
> module reference and set cb_running, a failure from the first
> netlink_dump(sk, true) call returns via errout_skb without unwinding the
> callback lifetime. That leaves cb_running set and defers module_put()
> and consume_skb(cb->skb) until userspace drains the socket or closes it.
On a quick look I can't see which path clears the dump state in case we
keep failing to allocate an skb. Could you add more info on that?
> Share the normal callback teardown in a helper and use it on successful
> completion and on the initial lock_taken=true failure path. Keep the
> lock_taken=false continuation path unchanged, because recvmsg()-driven
> retries legitimately preserve cb_running when they run out of receive
> room.
>
> Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
> Assisted-by: Claude:claude-opus-4-6
> Assisted-by: Codex:gpt-5-4
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> Validation inside a UML guest on current mainline:
>
> - An unprivileged local task (uid=65534, no CAP_NET_ADMIN) opens a
> plain NETLINK_ROUTE socket, preloads sk_rmem_alloc with echoed
> NLMSG_ERROR replies from an unsupported rtnetlink type, then issues
> RTM_GETLINK | NLM_F_DUMP | NLM_F_ACK.
> - Stock kernel: the initial __netlink_dump_start() hits the rmem gate
> and returns via errout_skb with cb_running stuck at 1 until
> recvmsg() or close() drives forward progress.
> - Patched kernel: the same probe leaves cb_running clear immediately
> on the lock_taken=true failure, and the larger-rcvbuf continuation
> path (legitimate dump in progress) is unchanged.
>
> A scaling pass on 3500 such wedged sockets in a 256M UML guest shows
> about 3.8-3.9 MiB of extra unreclaimable slab (/proc/meminfo
> SUnreclaim) beyond the visible queued rmem on the vulnerable kernel,
> roughly 1.1 KiB/socket. Real accumulation, but the test hits
> RLIMIT_NOFILE long before the guest approaches OOM, so this still
> looks like a local availability cleanup rather than an exhaustion
> primitive.
This should be part of the commit message, it's useful to understanding
the problem. Actually more than the current commit msg TBH.
> No Cc: stable@ on the theory that the bug self-heals on
> recvmsg()/close and the accumulation is mild. Happy to add it and
> route to net if you'd rather see it backported.
>
> net/netlink/af_netlink.c | 30 +++++++++++++++++++-----------
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 4d609d5cf406..7019c17e6879 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2250,6 +2250,20 @@ static int netlink_dump_done(struct netlink_sock *nlk, struct sk_buff *skb,
> return 0;
> }
>
> +static void netlink_dump_cleanup(struct netlink_sock *nlk)
> +{
> + struct module *module = nlk->cb.module;
> + struct sk_buff *skb = nlk->cb.skb;
> +
> + if (nlk->cb.done)
> + nlk->cb.done(&nlk->cb);
> +
> + WRITE_ONCE(nlk->cb_running, false);
> + mutex_unlock(&nlk->nl_cb_mutex);
> + module_put(module);
> + consume_skb(skb);
> +}
It's probably better to create a helper that shares the code with
the release path as well. And try not to switch the skb freeing
to consume_skb().
> static int netlink_dump(struct sock *sk, bool lock_taken)
> {
> struct netlink_sock *nlk = nlk_sk(sk);
> @@ -2258,7 +2272,6 @@ static int netlink_dump(struct sock *sk, bool lock_taken)
> struct sk_buff *skb = NULL;
> unsigned int rmem, rcvbuf;
> size_t max_recvmsg_len;
> - struct module *module;
> int err = -ENOBUFS;
> int alloc_min_size;
> int alloc_size;
> @@ -2366,19 +2379,14 @@ static int netlink_dump(struct sock *sk, bool lock_taken)
> else
> __netlink_sendskb(sk, skb);
>
> - if (cb->done)
> - cb->done(cb);
> -
> - WRITE_ONCE(nlk->cb_running, false);
> - module = cb->module;
> - skb = cb->skb;
> - mutex_unlock(&nlk->nl_cb_mutex);
> - module_put(module);
> - consume_skb(skb);
> + netlink_dump_cleanup(nlk);
> return 0;
>
> errout_skb:
> - mutex_unlock(&nlk->nl_cb_mutex);
> + if (lock_taken)
> + netlink_dump_cleanup(nlk);
> + else
> + mutex_unlock(&nlk->nl_cb_mutex);
> kfree_skb(skb);
> return err;
> }
If you're planning to repost - please wait until tomorrow, we ask that
revisions are at least 24h apart so that people across the timezones
have a chance to chime in.
^ permalink raw reply
* Re: [PATCH-next v2 0/2] ipvs: Fix incorrect use of HK_TYPE_KTHREAD housekeeping cpumask
From: Julian Anastasov @ 2026-04-20 17:24 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Waiman Long, Simon Horman, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Florian Westphal,
Phil Sutter, Frederic Weisbecker, Chen Ridong, Phil Auld,
linux-kernel, netdev, lvs-devel, netfilter-devel, coreteam,
sheviks
In-Reply-To: <ac_OscBPYRwt73ic@lemonverbena>
Hello,
On Fri, 3 Apr 2026, Pablo Neira Ayuso wrote:
> On Fri, Apr 03, 2026 at 05:15:50PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 31 Mar 2026, Waiman Long wrote:
> >
> > > v2:
> > > - Rebased on top of linux-next
> > >
> > > Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for preferred
> > > affinity management"), the HK_TYPE_KTHREAD housekeeping cpumask may no
> > > longer be correct in showing the actual CPU affinity of kthreads that
> > > have no predefined CPU affinity. As the ipvs networking code is still
> > > using HK_TYPE_KTHREAD, we need to make HK_TYPE_KTHREAD reflect the
> > > reality.
> > >
> > > This patch series makes HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > and uses RCU to protect access to the HK_TYPE_KTHREAD housekeeping
> > > cpumask.
> > >
> > > Waiman Long (2):
> > > sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
> >
> > The patchset looks good to me for nf-next, thanks!
> >
> > Acked-by: Julian Anastasov <ja@ssi.bg>
> >
> > Pablo, Florian, as a bugfix this patchset missed
> > the chance to be applied before the changes that are in
> > nf-next in ip_vs.h, there is little fuzz there. If there
> > is no chance to resolve it somehow, we can apply it
> > on top of nf-next where it now applies successfully.
>
> One way to handle this is to follow up with nf-next as you suggest,
> then send a backport that applies cleanly for -stable once it is
> released.
>
> Else, let me know if I am misunderstanding.
This patchset is now material for the net tree. To help it,
I just posted patch "ipvs: fix races around est_mutex and est_cpulist"
that can be applied before this patchset to the net tree.
Can we get this patchset for the net tree?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] rhashtable: Restore insecure_elasticity toggle
From: kernel test robot @ 2026-04-20 17:22 UTC (permalink / raw)
To: Herbert Xu, Tejun Heo
Cc: llvm, oe-kbuild-all, Thomas Graf, David Vernet, Andrea Righi,
Changwoo Min, Emil Tsalapatis, linux-crypto, sched-ext,
linux-kernel, Florian Westphal, netdev, NeilBrown
In-Reply-To: <aeLgjAeJuidWNy3N@gondor.apana.org.au>
Hi Herbert,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-nonmm-unstable]
[also build test WARNING on net/main net-next/main linus/master v7.0]
[cannot apply to next-20260420]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Herbert-Xu/rhashtable-Restore-insecure_elasticity-toggle/20260418-233732
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
patch link: https://lore.kernel.org/r/aeLgjAeJuidWNy3N%40gondor.apana.org.au
patch subject: [PATCH] rhashtable: Restore insecure_elasticity toggle
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260421/202604210112.4dByOk9v-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260421/202604210112.4dByOk9v-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604210112.4dByOk9v-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from net/mac80211/s1g.c:9:
In file included from net/mac80211/ieee80211_i.h:27:
include/linux/rhashtable.h:831:32: error: member reference type 'struct rhashtable_params' is not a pointer; did you mean to use '.'?
831 | if (elasticity <= 0 && !params->insecure_elasticity)
| ~~~~~~^~
| .
include/linux/rhashtable.h:839:13: error: member reference type 'struct rhashtable_params' is not a pointer; did you mean to use '.'?
839 | !params->insecure_elasticity)
| ~~~~~~^~
| .
>> net/mac80211/s1g.c:104:36: warning: implicit conversion from 'unsigned long' to '__u16' (aka 'unsigned short') changes value from 18446744073709551614 to 65534 [-Wconstant-conversion]
104 | twt_agrt->req_type &= cpu_to_le16(~IEEE80211_TWT_REQTYPE_REQUEST);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/byteorder/generic.h:90:21: note: expanded from macro 'cpu_to_le16'
90 | #define cpu_to_le16 __cpu_to_le16
| ^
include/uapi/linux/byteorder/big_endian.h:36:53: note: expanded from macro '__cpu_to_le16'
36 | #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
| ~~~~~~~~~~^~~
include/uapi/linux/swab.h:107:12: note: expanded from macro '__swab16'
107 | __fswab16(x))
| ~~~~~~~~~ ^
1 warning and 2 errors generated.
vim +104 net/mac80211/s1g.c
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 95
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 96 static void
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 97 ieee80211_s1g_rx_twt_setup(struct ieee80211_sub_if_data *sdata,
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 98 struct sta_info *sta, struct sk_buff *skb)
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 99 {
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 100 struct ieee80211_mgmt *mgmt = (void *)skb->data;
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 101 struct ieee80211_twt_setup *twt = (void *)mgmt->u.action.u.s1g.variable;
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 102 struct ieee80211_twt_params *twt_agrt = (void *)twt->params;
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 103
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 @104 twt_agrt->req_type &= cpu_to_le16(~IEEE80211_TWT_REQTYPE_REQUEST);
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 105
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 106 /* broadcast TWT not supported yet */
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 107 if (twt->control & IEEE80211_TWT_CONTROL_NEG_TYPE_BROADCAST) {
7ff379ba2d4b7b2 Johannes Berg 2021-09-27 108 twt_agrt->req_type &=
7ff379ba2d4b7b2 Johannes Berg 2021-09-27 109 ~cpu_to_le16(IEEE80211_TWT_REQTYPE_SETUP_CMD);
7ff379ba2d4b7b2 Johannes Berg 2021-09-27 110 twt_agrt->req_type |=
7ff379ba2d4b7b2 Johannes Berg 2021-09-27 111 le16_encode_bits(TWT_SETUP_CMD_REJECT,
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 112 IEEE80211_TWT_REQTYPE_SETUP_CMD);
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 113 goto out;
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 114 }
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 115
30ac96f7cc973bb Howard Hsu 2022-10-27 116 /* TWT Information not supported yet */
30ac96f7cc973bb Howard Hsu 2022-10-27 117 twt->control |= IEEE80211_TWT_CONTROL_RX_DISABLED;
30ac96f7cc973bb Howard Hsu 2022-10-27 118
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 119 drv_add_twt_setup(sdata->local, sdata, &sta->sta, twt);
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 120 out:
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 121 ieee80211_s1g_send_twt_setup(sdata, mgmt->sa, sdata->vif.addr, twt);
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 122 }
f5a4c24e689f54e Lorenzo Bianconi 2021-08-23 123
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/9] x86/extable: switch to using FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-20 17:18 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260420112428.GF3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 01:24:28PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 17, 2026 at 01:36:13PM -0400, Yury Norov wrote:
> > The EX_DATA register is laid out such that EX_DATA_IMM occupied MSB.
> > It's done to make sure that FIELD_GET() will sign-extend the IMM
> > field during extraction.
> >
> > To enforce that, all EX_DATA masks are made signed integers. This
> > works, but relies on the particular implementation of FIELD_GET(),
> > i.e. masking then shifting, not vice versa; and the particular
> > placement of the fields in the register.
>
> I don't think the order of the mask and shift matters in this case. If
> we were to first shift down and then mask, it would still work (after
> all, the mask would also need to be shifted and would also get sign
> extended, effectively ending up as -1).
FIELD_GET() doesn't require mask to be signed when a reg is signed, so
shifting mask may become zero-extended in an alternative implementation:
(reg >> __bf_shf(mask)) & (mask >> __bf_shf(mask)
This all is hypothetical, anyways.
> But yes, this very much depends on the signed field being the topmost
> field and including the MSB.
This is the part I dislike mostly. This would look just like undefined
behavior for the API user: depending on fields placement or type of the
inputs, sometimes FIELD_GET() sign-extendeds the field, and sometimes
not.
We could likely force FIELD_GET() to treat both reg and mask as unsigned
types, and state that explicitly in the documentation.
^ permalink raw reply
* [PATCH net 4/4] gve: Make ethtool config changes synchronous
From: Harshitha Ramamurthy @ 2026-04-20 17:18 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
In-Reply-To: <20260420171837.455487-1-hramamurthy@google.com>
From: Pin-yen Lin <treapking@google.com>
When modifying device features via ethtool, the driver queues the
carrier status update to its workqueue (gve_wq). This leads to a
short link-down state after running the ethtool command.
Use `gve_turnup_and_check_status()` instead of `gve_turnup()` in
`gve_queues_start()` to update the carrier status before returning to
the userspace.
This was discovered by drivers/net/ping.py selftest. The test calls
ping command right after an ethtool configuration, but the interface
could be down without this fix.
Cc: stable@vger.kernel.org
Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues")
Reviewed-by: Joshua Washington <joshwash@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 56 +++++++++++-----------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 8617782791e0..d3b4bec38de5 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1374,6 +1374,33 @@ static void gve_queues_mem_remove(struct gve_priv *priv)
priv->rx = NULL;
}
+static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
+{
+ if (!gve_get_napi_enabled(priv))
+ return;
+
+ if (link_status == netif_carrier_ok(priv->dev))
+ return;
+
+ if (link_status) {
+ netdev_info(priv->dev, "Device link is up.\n");
+ netif_carrier_on(priv->dev);
+ } else {
+ netdev_info(priv->dev, "Device link is down.\n");
+ netif_carrier_off(priv->dev);
+ }
+}
+
+static void gve_turnup_and_check_status(struct gve_priv *priv)
+{
+ u32 status;
+
+ gve_turnup(priv);
+ status = ioread32be(&priv->reg_bar0->device_status);
+ gve_handle_link_status(priv,
+ GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
+}
+
/* The passed-in queue memory is stored into priv and the queues are made live.
* No memory is allocated. Passed-in memory is freed on errors.
*/
@@ -1434,8 +1461,7 @@ static int gve_queues_start(struct gve_priv *priv,
round_jiffies(jiffies +
msecs_to_jiffies(priv->stats_report_timer_period)));
- gve_turnup(priv);
- queue_work(priv->gve_wq, &priv->service_task);
+ gve_turnup_and_check_status(priv);
priv->interface_up_cnt++;
return 0;
@@ -1548,23 +1574,6 @@ static int gve_close(struct net_device *dev)
return 0;
}
-static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
-{
- if (!gve_get_napi_enabled(priv))
- return;
-
- if (link_status == netif_carrier_ok(priv->dev))
- return;
-
- if (link_status) {
- netdev_info(priv->dev, "Device link is up.\n");
- netif_carrier_on(priv->dev);
- } else {
- netdev_info(priv->dev, "Device link is down.\n");
- netif_carrier_off(priv->dev);
- }
-}
-
static int gve_configure_rings_xdp(struct gve_priv *priv,
u16 num_xdp_rings)
{
@@ -2039,15 +2048,6 @@ static void gve_turnup(struct gve_priv *priv)
gve_set_napi_enabled(priv);
}
-static void gve_turnup_and_check_status(struct gve_priv *priv)
-{
- u32 status;
-
- gve_turnup(priv);
- status = ioread32be(&priv->reg_bar0->device_status);
- gve_handle_link_status(priv, GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
-}
-
static struct gve_notify_block *gve_get_tx_notify_block(struct gve_priv *priv,
unsigned int txqueue)
{
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH net 3/4] gve: Use default min ring size when device option values are 0
From: Harshitha Ramamurthy @ 2026-04-20 17:18 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
In-Reply-To: <20260420171837.455487-1-hramamurthy@google.com>
From: Pin-yen Lin <treapking@google.com>
On gvnic devices that support reporting minimum ring sizes, the device
option always includes the min_(rx|tx)_ring_size fields, and the values
will be 0 if they are not configured to be exposed. This makes the
driver allow unexpected small ring size configurations from the
userspace.
Use the default ring size in the driver if the min ring sizes from the
device option are 0.
This was discovered by drivers/net/ring_reconfig.py selftest.
Cc: stable@vger.kernel.org
Fixes: ed4fb326947d ("gve: add support to read ring size ranges from the device")
Reviewed-by: Joshua Washington <joshwash@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_adminq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
index b72cc0fa2ba2..57d898f6fa82 100644
--- a/drivers/net/ethernet/google/gve/gve_adminq.c
+++ b/drivers/net/ethernet/google/gve/gve_adminq.c
@@ -189,7 +189,9 @@ void gve_parse_device_option(struct gve_priv *priv,
*dev_op_modify_ring = (void *)(option + 1);
/* device has not provided min ring size */
- if (option_length == GVE_DEVICE_OPTION_NO_MIN_RING_SIZE)
+ if (option_length == GVE_DEVICE_OPTION_NO_MIN_RING_SIZE ||
+ be16_to_cpu((*dev_op_modify_ring)->min_rx_ring_size) == 0 ||
+ be16_to_cpu((*dev_op_modify_ring)->min_tx_ring_size) == 0)
priv->default_min_ring_size = true;
break;
case GVE_DEV_OPT_ID_FLOW_STEERING:
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH net 2/4] gve: Fix backward stats when interface goes down or configuration is adjusted
From: Harshitha Ramamurthy @ 2026-04-20 17:18 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Debarghya Kundu, Pin-yen Lin
In-Reply-To: <20260420171837.455487-1-hramamurthy@google.com>
From: Debarghya Kundu <debarghyak@google.com>
gve_get_base_stats() sets all the stats to 0, so the stats go backwards
when interface goes down or configuration is adjusted.
Fix this by persisting baseline stats across interface down.
This was discovered by drivers/net/stats.py selftest.
Cc: stable@vger.kernel.org
Fixes: 2e5e0932dff5 ("gve: add support for basic queue stats")
Signed-off-by: Debarghya Kundu <debarghyak@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve.h | 6 ++
drivers/net/ethernet/google/gve/gve_main.c | 64 +++++++++++++++++++---
2 files changed, 63 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
index cbdf3a842cfe..ff7797043908 100644
--- a/drivers/net/ethernet/google/gve/gve.h
+++ b/drivers/net/ethernet/google/gve/gve.h
@@ -794,6 +794,10 @@ struct gve_ptp {
struct gve_priv *priv;
};
+struct gve_ring_err_stats {
+ u64 rx_alloc_fails;
+};
+
struct gve_priv {
struct net_device *dev;
struct gve_tx_ring *tx; /* array of tx_cfg.num_queues */
@@ -882,6 +886,8 @@ struct gve_priv {
unsigned long service_task_flags;
unsigned long state_flags;
+ struct gve_ring_err_stats base_ring_err_stats;
+ struct rtnl_link_stats64 base_net_stats;
struct gve_stats_report *stats_report;
u64 stats_report_len;
dma_addr_t stats_report_bus; /* dma address for the stats report */
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 675382e9756c..8617782791e0 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -105,9 +105,22 @@ static netdev_tx_t gve_start_xmit(struct sk_buff *skb, struct net_device *dev)
return gve_tx_dqo(skb, dev);
}
-static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
+static void gve_add_base_stats(struct gve_priv *priv,
+ struct rtnl_link_stats64 *s)
+{
+ struct rtnl_link_stats64 *base_stats = &priv->base_net_stats;
+
+ s->rx_packets += base_stats->rx_packets;
+ s->rx_bytes += base_stats->rx_bytes;
+ s->rx_dropped += base_stats->rx_dropped;
+ s->tx_packets += base_stats->tx_packets;
+ s->tx_bytes += base_stats->tx_bytes;
+ s->tx_dropped += base_stats->tx_dropped;
+}
+
+static void gve_get_ring_stats(struct gve_priv *priv,
+ struct rtnl_link_stats64 *s)
{
- struct gve_priv *priv = netdev_priv(dev);
unsigned int start;
u64 packets, bytes;
int num_tx_queues;
@@ -142,6 +155,14 @@ static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
}
}
+static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
+{
+ struct gve_priv *priv = netdev_priv(dev);
+
+ gve_get_ring_stats(priv, s);
+ gve_add_base_stats(priv, s);
+}
+
static int gve_alloc_flow_rule_caches(struct gve_priv *priv)
{
struct gve_flow_rules_cache *flow_rules_cache = &priv->flow_rules_cache;
@@ -1493,6 +1514,23 @@ static int gve_queues_stop(struct gve_priv *priv)
return gve_reset_recovery(priv, false);
}
+static void gve_get_ring_err_stats(struct gve_priv *priv,
+ struct gve_ring_err_stats *err_stats)
+{
+ int ring;
+
+ for (ring = 0; ring < priv->rx_cfg.num_queues; ring++) {
+ unsigned int start;
+ struct gve_rx_ring *rx = &priv->rx[ring];
+
+ do {
+ start = u64_stats_fetch_begin(&rx->statss);
+ err_stats->rx_alloc_fails +=
+ rx->rx_skb_alloc_fail + rx->rx_buf_alloc_fail;
+ } while (u64_stats_fetch_retry(&rx->statss, start));
+ }
+}
+
static int gve_close(struct net_device *dev)
{
struct gve_priv *priv = netdev_priv(dev);
@@ -1502,6 +1540,10 @@ static int gve_close(struct net_device *dev)
if (err)
return err;
+ /* Save ring queue and err stats before closing the interface */
+ gve_get_ring_stats(priv, &priv->base_net_stats);
+ gve_get_ring_err_stats(priv, &priv->base_ring_err_stats);
+
gve_queues_mem_remove(priv);
return 0;
}
@@ -2743,12 +2785,20 @@ static void gve_get_base_stats(struct net_device *dev,
struct netdev_queue_stats_rx *rx,
struct netdev_queue_stats_tx *tx)
{
- rx->packets = 0;
- rx->bytes = 0;
- rx->alloc_fail = 0;
+ const struct gve_ring_err_stats *base_err_stats;
+ const struct rtnl_link_stats64 *base_stats;
+ struct gve_priv *priv;
+
+ priv = netdev_priv(dev);
+ base_stats = &priv->base_net_stats;
+ base_err_stats = &priv->base_ring_err_stats;
+
+ rx->packets = base_stats->rx_packets;
+ rx->bytes = base_stats->rx_bytes;
+ rx->alloc_fail = base_err_stats->rx_alloc_fails;
- tx->packets = 0;
- tx->bytes = 0;
+ tx->packets = base_stats->tx_packets;
+ tx->bytes = base_stats->tx_bytes;
}
static const struct netdev_stat_ops gve_stat_ops = {
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH net 1/4] gve: Add NULL pointer checks for per-queue statistics
From: Harshitha Ramamurthy @ 2026-04-20 17:18 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Debarghya Kundu, Pin-yen Lin
In-Reply-To: <20260420171837.455487-1-hramamurthy@google.com>
From: Debarghya Kundu <debarghyak@google.com>
gve_get_[tx/rx]_queue_stats references the [tx/rx] null rings when the
link is down. Add NULL pointer checks to guard this.
This was discovered by drivers/net/stats.py selftest.
Cc: stable@vger.kernel.org
Fixes: 2e5e0932dff5 ("gve: add support for basic queue stats")
Signed-off-by: Debarghya Kundu <debarghyak@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 0ee864b0afe0..675382e9756c 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -2705,9 +2705,13 @@ static void gve_get_rx_queue_stats(struct net_device *dev, int idx,
struct netdev_queue_stats_rx *rx_stats)
{
struct gve_priv *priv = netdev_priv(dev);
- struct gve_rx_ring *rx = &priv->rx[idx];
+ struct gve_rx_ring *rx;
unsigned int start;
+ if (!priv->rx)
+ return;
+ rx = &priv->rx[idx];
+
do {
start = u64_stats_fetch_begin(&rx->statss);
rx_stats->packets = rx->rpackets;
@@ -2721,9 +2725,13 @@ static void gve_get_tx_queue_stats(struct net_device *dev, int idx,
struct netdev_queue_stats_tx *tx_stats)
{
struct gve_priv *priv = netdev_priv(dev);
- struct gve_tx_ring *tx = &priv->tx[idx];
+ struct gve_tx_ring *tx;
unsigned int start;
+ if (!priv->tx)
+ return;
+ tx = &priv->tx[idx];
+
do {
start = u64_stats_fetch_begin(&tx->statss);
tx_stats->packets = tx->pkt_done;
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH net 0/4] gve: Fixes for issues discovered via net selftests
From: Harshitha Ramamurthy @ 2026-04-20 17:18 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
From: Pin-yen Lin <treapking@google.com>
This patch series addresses several issues in the gve driver. All four of these
fixes were uncovered by running the net selftests.
The series includes the following changes:
- Patch 1 adds NULL pointer checks for the per-queue statistics code to
prevent crashes when the rings are queried while the link is down. This
was discovered by the drivers/net/stats.py selftest.
- Patch 2 fixes an issue where interface stats would go backwards when the
interface was brought down or its configuration was adjusted. This was
also discovered by the drivers/net/stats.py selftest.
- Patch 3 ensures the driver falls back to the default minimum ring size if
the corresponding device option values are exposed as 0. This prevents
userspace from configuring unexpectedly small ring sizes. This was
discovered by the drivers/net/ring_reconfig.py selftest.
- Patch 4 makes sure ethtool configuration modifications are done
synchronously before returning to the userspace. This was discovered by
the drivers/net/ping.py selftest.
Debarghya Kundu (2):
gve: Add NULL pointer checks for per-queue statistics
gve: Fix backward stats when interface goes down or configuration is
adjusted
Pin-yen Lin (2):
gve: Use default min ring size when device option values are 0
gve: Make ethtool config changes synchronous
drivers/net/ethernet/google/gve/gve.h | 6 +
drivers/net/ethernet/google/gve/gve_adminq.c | 4 +-
drivers/net/ethernet/google/gve/gve_main.c | 128 +++++++++++++------
3 files changed, 100 insertions(+), 38 deletions(-)
--
2.54.0.rc0.605.g598a273b03-goog
base-commit: 2dddb34dd0d07b01fa770eca89480a4da4f13153
branch: gve-misc-fixes
^ permalink raw reply
* Re: [PATCH v2 0/3] mISDN: fix socket/device lifetime and naming races
From: Jakub Kicinski @ 2026-04-20 17:11 UTC (permalink / raw)
To: Shuvam Pandey; +Cc: netdev
In-Reply-To: <CANAAWHJKfRVO++ZdXYAKSaTH8JCBi_Xeu4DE-Ldaa6zu2Kub6A@mail.gmail.com>
On Sun, 19 Apr 2026 06:09:03 +0545 Shuvam Pandey wrote:
> Please ignore v2 for now. I’m reworking the series and will send a
> corrected v3.
Please hold off until Thursday, I'm intending to delete ISDN from the
tree. Please resend if the code still exists in Linus's tree at that
point.
^ permalink raw reply
* Re: [PATCH bpf v3 2/2] selftests/bpf: Test TCP_NODELAY in TCP hdr opt callbacks
From: Martin KaFai Lau @ 2026-04-20 17:09 UTC (permalink / raw)
To: KaFai Wan
Cc: daniel, john.fastabend, sdf, ast, andrii, eddyz87, memxor, song,
yonghong.song, jolsa, davem, edumazet, kuba, pabeni, horms, shuah,
jiayuan.chen, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <9b3e7c118f5b9105b92f53b66034c1b7884c1372.camel@linux.dev>
On Sat, Apr 18, 2026 at 10:19:47AM +0800, KaFai Wan wrote:
> > > + ret = setsockopt(sk_fds.active_fd, SOL_TCP, TCP_NODELAY, &true_val, sizeof(true_val));
> >
> > Same comment as in v2. Why this setsockopt is needed?
>
> Sorry I miss this. It's from the review of v1, my first version would break the syscall setsockopt
> and other CB besides HDR_OPT_LEN/WRITE_HDR_OPT. So in the test I check setsockopt() and
> bpf_setsockopt() in PASSIVE_ESTABLISHED_CB to make sure patch#1 would not break user space and other
> CB.
ic. Yep, remove it since v3 is not changing the syscall setsockopt.
>
> > The setsockopt in userspace is unnecessary.
>
> Is bpf_setsockopt() in PASSIVE_ESTABLISHED_CB also unnecessary? I'll respin if they are unnecessary.
This one is fine. It checks if the bpf_setsockopt is not affectred in other CB.
^ permalink raw reply
* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-20 17:09 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Tariq Toukan, Boris Pismenny, willemdebruijn.kernel@gmail.com,
andrew+netdev@lunn.ch, daniel.zahka@gmail.com,
davem@davemloft.net, leon@kernel.org, Rahul Rameshbabu,
pabeni@redhat.com, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Raed Salem, Dragos Tatulea,
kees@kernel.org, Mark Bloch, edumazet@google.com, Saeed Mahameed,
netdev@vger.kernel.org, Gal Pressman
In-Reply-To: <d7e2d46769e120a16ce12d345c51a47349733828.camel@nvidia.com>
On Mon, 20 Apr 2026 10:30:46 +0000 Cosmin Ratiu wrote:
> > When psp_dev_create() fails, this function now returns without
> > setting
> > psp->psp, leaving it as NULL. However, priv->psp remains allocated
> > and
> > non-NULL.
> >
> > Does this leave the RX datapath vulnerable to a NULL pointer
> > dereference?
> >
> > If priv->psp is non-NULL, the NIC RX initialization path can still
> > call
> > mlx5_accel_psp_fs_init_rx_tables(), which creates hardware flow
> > steering
> > rules to intercept UDP traffic.
> >
> > If a UDP packet triggers these rules, the hardware flags the CQE with
> > MLX5E_PSP_MARKER_BIT. The RX fast-path sees the marker and invokes
> > mlx5e_psp_offload_handle_rx_skb(), which dereferences the pointer
> > unconditionally:
> >
> > u16 dev_id = priv->psp->psp->id;
> >
> > Since priv->psp->psp is NULL, this will cause a kernel panic. Should
> > priv->psp be cleaned up, or the error propagated, to prevent flow
> > rules
> > from being installed when registration fails?
>
> First, this is preexisting. But more importantly, it's impossible to
> trigger:
> - with no PSP devs, there can be no PSP SAs installed.
> - with no SAs, PSP decryption cannot succeed.
> - all unsuccessfully decrypted PSP packets are dropped by steering.
> - the RX handler will not see any PSP packets with the marker set.
>
> This patch fixes the comparatively way more likely scenario of
> psp_dev_register failing and then mlx5e_psp_unregister passing the
> error pointer to psp_dev_unregister, which will do unpleasant things
> with it.
Sure but why are you leaving the priv->psp struct in place and whatever
FS init has been done? IOW if you really want PSP init to not block
probe why is mlx5e_psp_register() a void function rather than
mlx5e_psp_init() ? Ignoring errors from psp_dev_create()
makes no sense to me - what are you protecting from? kmalloc(GFP_KERNEL)
failing?
^ 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