* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Nicolai Buchwitz @ 2026-04-06 20:24 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, workflows,
linux-doc, linux-kernel, mbloch
In-Reply-To: <345722f0-21b1-4970-8c45-ef85edf9d45b@suse.de>
On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
> [...]
>
> Hi Nicolai,
> maybe I am missing something but [2] isn't from sashiko.dev but from
> netdev AI CI instead. See:
> https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
You're right, I mixed up the two systems - the example I linked was
from the netdev AI bot, not Sashiko. My mistake on the link.
I stumbled over Sashiko when I noticed the name appearing more often
in other reviews and then found Jonathan's LWN article about it [1].
Both tools are actively reviewing patches on the list today. I think
it makes sense to document both rather than just one:
The netdev AI bot at netdev-ai.bots.linux.dev
Sashiko at sashiko.dev, which posts reviews publicly on its website
Both use the same review prompts by Chris Mason [2], so there is
common ground - though results will vary between them due to the
different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
on top of the usual AI uncertainty.
I think it would be useful to document that AI reviews are happening
but mixing AI bots might confuse people.
Agreed, I'll rework the patch to distinguish the two systems once
the discussion has been settled.
>
> The documentation mentioned for running the AI locally is correctly
> related to netdev AI bot.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
>> Check for findings on your submissions and address
>> +valid ones before a maintainer has to relay the same questions.
>> +
>
> I wonder what would be the consequences for this. If less experienced
> submitters are expected to address issues pointed out by AI bots they
> might work on something that isn't valid. AFAIU, the AI output is only
> forwarded to the submitter after a maintainer reviewed it and believes
> it makes sense.
Fair point. The wording should make clear that the local tooling is
an optional aid, not an obligation. I'll soften the language around
addressing findings.
Would appreciate input on how much detail is appropriate here -
should the doc just acknowledge that AI review exists and point to
the tooling, or go into more detail about the workflow?
[1] https://lwn.net/Articles/1063292/
[2]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/networking.md
>
> Thanks,
> Fernando.
>
>> +You can also run AI reviews locally before submitting. Instructions
>> +and tooling are available at:
>> +
>> + https://netdev-ai.bots.linux.dev/ai-local.html
>> +
>> Testimonials / feedback
>> -----------------------
>>
Thanks for your input
Nicolai
^ permalink raw reply
* RE: [PATCH iwl-net 8/10] ice: set ETS TLV willing bit in default MIB sent to firmware
From: Ertman, David M @ 2026-04-06 20:22 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org, Hagvi, Yochai
In-Reply-To: <20260403054029.3789616-9-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Sent: Thursday, April 2, 2026 10:40 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org; Hagvi, Yochai <yochai.hagvi@intel.com>
> Subject: [PATCH iwl-net 8/10] ice: set ETS TLV willing bit in default MIB sent to
> firmware
>
> When the FW LLDP agent is active the driver sends an initial
> DCB configuration via set_local_mib. Currently the ETS TLV
> willing bit is clear, which prevents LLDP negotiation and
> renders the FW LLDP mode non-functional.
ice_set_dflt_mib() is only ever called in one place - ice_link_event().
That call is surrounded by a check that calls ice_is_dcb_active(). With the
FW agent active, that check will always return true. This prevents the
ice_set_local_mib() from ever being called when FW is active.
It doesn't seem like this change is necessary.
>
> Add ICE_IEEE_ETS_IS_WILLING to document intent and use it to
> set the willing bit so the FW can negotiate DCB settings with
> the peer. This only affects the default configuration; SW LLDP
> mode overrides it immediately afterwards.
>
> Fixes: 7d9c9b791f9e ("ice: Implement LFC workaround")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yochai Hagvi <yochai.hagvi@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dcb.h | 1 +
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_dcb.h
> b/drivers/net/ethernet/intel/ice/ice_dcb.h
> index be34650..91d6682 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dcb.h
> +++ b/drivers/net/ethernet/intel/ice/ice_dcb.h
> @@ -52,6 +52,7 @@
> #define ICE_IEEE_ETS_CBS_M BIT(ICE_IEEE_ETS_CBS_S)
> #define ICE_IEEE_ETS_WILLING_S 7
> #define ICE_IEEE_ETS_WILLING_M BIT(ICE_IEEE_ETS_WILLING_S)
> +#define ICE_IEEE_ETS_IS_WILLING BIT(ICE_IEEE_ETS_WILLING_S)
> #define ICE_IEEE_ETS_PRIO_0_S 0
> #define ICE_IEEE_ETS_PRIO_0_M (0x7 <<
> ICE_IEEE_ETS_PRIO_0_S)
> #define ICE_IEEE_ETS_PRIO_1_S 4
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> index e7308e3..75a48e5 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -971,7 +971,7 @@ static void ice_set_dflt_mib(struct ice_pf *pf)
> tlv->ouisubtype = htonl(ouisubtype);
>
> buf = tlv->tlvinfo;
> - buf[0] = 0;
> + buf[0] = ICE_IEEE_ETS_IS_WILLING;
>
> /* ETS CFG all UPs map to TC 0. Next 4 (1 - 4) Octets = 0.
> * Octets 5 - 12 are BW values, set octet 5 to 100% BW.
> --
> 2.52.0
>
^ permalink raw reply
* [PATCH net-next] net: phy: realtek: get rid of magic numbers in rtl8201_config_intr()
From: Aleksander Jan Bajkowski @ 2026-04-06 20:12 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, daniel,
vladimir.oltean, michael, olek2, markus.stockhausen, ih,
rmk+kernel, netdev, linux-kernel
Replace the magic numbers with defines. Register names were obtained from
publicly available documentation[1]. This should make it clear what's going
on in the code.
1. RTL8201F/RTL8201FL/RTL8201FN Rev. 1.4 Datasheet
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/phy/realtek/realtek_main.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 75565fbdbf6d..e78f3b9e89db 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -22,7 +22,14 @@
#include "../phylib.h"
#include "realtek.h"
+#define RTL8201F_IER_PAGE 0x07
#define RTL8201F_IER 0x13
+#define RTL8201F_IER_LINK BIT(13)
+#define RTL8201F_IER_DUPLEX BIT(12)
+#define RTL8201F_IER_ANERR BIT(11)
+#define RTL8201F_IER_MASK (RTL8201F_IER_ANERR | \
+ RTL8201F_IER_DUPLEX | \
+ RTL8201F_IER_LINK)
#define RTL8201F_ISR 0x1e
#define RTL8201F_ISR_ANERR BIT(15)
@@ -346,11 +353,13 @@ static int rtl8201_config_intr(struct phy_device *phydev)
if (err)
return err;
- val = BIT(13) | BIT(12) | BIT(11);
- err = phy_write_paged(phydev, 0x7, RTL8201F_IER, val);
+ val = RTL8201F_IER_MASK;
+ err = phy_write_paged(phydev, RTL8201F_IER_PAGE,
+ RTL8201F_IER, val);
} else {
val = 0;
- err = phy_write_paged(phydev, 0x7, RTL8201F_IER, val);
+ err = phy_write_paged(phydev, RTL8201F_IER_PAGE,
+ RTL8201F_IER, val);
if (err)
return err;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 net] vsock: fix buffer size clamping order
From: Norbert Szetei @ 2026-04-06 20:04 UTC (permalink / raw)
To: Stefano Garzarella
Cc: davem, edumazet, kuba, pabeni, horms, virtualization, netdev,
linux-kernel, John Villamil
In-Reply-To: <102981F1-2CAE-481F-8FAE-4F3085E25E89@doyensec.com>
Hi,
v2: fix indentation/whitespace issues in the previous patch.
-- >8 --
From f5d160167c862c7f2ad6e6a1d4181d01997b683a Mon Sep 17 00:00:00 2001
From: Norbert Szetei <norbert@doyensec.com>
Date: Mon, 6 Apr 2026 19:52:52 +0200
Subject: [PATCH] vsock: fix buffer size clamping order
In vsock_update_buffer_size(), the buffer size was being clamped to the
maximum first, and then to the minimum. If a user sets a minimum buffer
size larger than the maximum, the minimum check overrides the maximum
check, inverting the constraint.
This breaks the intended socket memory boundaries by allowing the
vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
Fix this by checking the minimum first, and then the maximum. This
ensures the buffer size never exceeds the buffer_max_size.
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
---
net/vmw_vsock/af_vsock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index d912ed2f012a..08f4dfb9782c 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1951,12 +1951,12 @@ static void vsock_update_buffer_size(struct vsock_sock *vsk,
const struct vsock_transport *transport,
u64 val)
{
- if (val > vsk->buffer_max_size)
- val = vsk->buffer_max_size;
-
if (val < vsk->buffer_min_size)
val = vsk->buffer_min_size;
+ if (val > vsk->buffer_max_size)
+ val = vsk->buffer_max_size;
+
if (val != vsk->buffer_size &&
transport && transport->notify_buffer_size)
transport->notify_buffer_size(vsk, &val);
--
2.53.0
> On Apr 6, 2026, at 20:41, Norbert Szetei <norbert@doyensec.com> wrote:
>
> Hi Stefano,
>
> I like option 1 the most, as it is the most straightforward way to fix
> the issue. I am including the patch below. This fixes the clamping
> mismatch, but as you pointed out, it won't solve the root problem
> regarding the issue to arbitrarily set a maximum buffer value.
>
> Since VSOCK uses a unified buffer size rather than separating read and
> write buffers like the core stack, introducing a vsock-specific sysctl
> (e.g., net.vmw_vsock.buffer_max_size) seems the cleanest approach to me.
> I was also considering net.core.wmem_max/rmem_max, but mapping to those
> feels less natural.
>
> If you agree with the vsock-specific sysctl, or have a different
> suggestion, let me know and I will send a follow-up patch for that.
> Thanks.
>
> Best, Norbert
>
> -- >8 --
> From f5d160167c862c7f2ad6e6a1d4181d01997b683a Mon Sep 17 00:00:00 2001
> From: Norbert Szetei <norbert@doyensec.com>
> Date: Mon, 6 Apr 2026 19:52:52 +0200
> Subject: [PATCH] vsock: fix buffer size clamping order
>
> In vsock_update_buffer_size(), the buffer size was being clamped to the
> maximum first, and then to the minimum. If a user sets a minimum buffer
> size larger than the maximum, the minimum check overrides the maximum
> check, inverting the constraint.
>
> This breaks the intended socket memory boundaries by allowing the
> vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
>
> Fix this by checking the minimum first, and then the maximum. This
> ensures the buffer size never exceeds the buffer_max_size.
>
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> ---
> net/vmw_vsock/af_vsock.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index d912ed2f012a..08f4dfb9782c 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -1951,12 +1951,12 @@ static void vsock_update_buffer_size(struct vsock_sock *vsk,
> const struct vsock_transport *transport,
> u64 val)
> {
> - if (val > vsk->buffer_max_size)
> - val = vsk->buffer_max_size;
> -
> if (val < vsk->buffer_min_size)
> val = vsk->buffer_min_size;
> + if (val > vsk->buffer_max_size)
> + val = vsk->buffer_max_size;
> +
> if (val != vsk->buffer_size &&
> transport && transport->notify_buffer_size)
> transport->notify_buffer_size(vsk, &val);
> --
> 2.53.0
>
>> On Mar 31, 2026, at 14:37, Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> On Tue, Mar 24, 2026 at 06:28:12PM +0100, Norbert Szetei wrote:
>>> Hello,
>>>
>>> we have discovered a bug in AF_VSOCK where an unprivileged user can bypass socket
>>> memory constraints. This leads to refcount_t saturation and OOM. While
>>> refcount_t prevents a true UAF by saturating, the resulting state triggers
>>> kernel warnings and kernel panic, depending on the setup.
>>>
>>> In vsock_connectible_setsockopt(), the SO_VM_SOCKETS_BUFFER_MIN_SIZE and
>>> SO_VM_SOCKETS_BUFFER_MAX_SIZE options are used to update the buffer's minimum
>>> and maximum values independently.
>>>
>>> The vsock_update_buffer_size() function clamps the buffer size to the maximum
>>> first, then the minimum:
>>>
>>> // https://github.com/torvalds/linux/blob/c369299895a591d96745d6492d4888259b004a9e/net/vmw_vsock/af_vsock.c#L1950
>>> if (val > vsk->buffer_max_size)
>>> val = vsk->buffer_max_size;
>>>
>>> if (val < vsk->buffer_min_size)
>>> val = vsk->buffer_min_size;
>>>
>>> vsk->buffer_size = val;
>>>
>>> By setting buffer_min_size to a large value, the second clamp overrides the
>>> first, forcing vsk->buffer_size to exceed the intended maximum. The transport
>>> layer then uses this value, allowing unbounded SKB allocation that saturates the
>>> 32-bit sk_wmem_alloc refcount.
>>>
>>> The fix should ensure that SO_VM_SOCKETS_BUFFER_MIN_SIZE cannot be used to set a
>>> value higher than the current buffer_max_size. Conversely,
>>> SO_VM_SOCKETS_BUFFER_MAX_SIZE should not be allowed to be set lower than the
>>> current buffer_min_size.
>>
>> Okay, but that wouldn't change much. As long as the user sets the maximum to match the minimum you set in the POC, it behaves exactly the same way, right?
>>
>> Maybe we should add a sysctl to set a global upper bound, but this is another problem, I agree that we should improve the kernel behavior around min/max. I see 3 options:
>>
>> 1. Just invert the checks, fist check for min, then for max.
>>
>> 2. Simply adjust the min and max values so that they make sense. For example, if the minimum value being set is greater than the maximum, the kernel could adjust the maximum to the same value. However, this would not change the behavior of your POC.
>>
>> 3. Force the minimum to be less than or equal to the maximum. This, however, would require a certain order when setting the minimum and maximum, especially relative to the default. For example, if you increase the minimum beyond the default maximum, you must adjust the maximum first; conversely, if you want to set the maximum below the default minimum, you must adjust the minimum first.
>>
>> I'm more into 1 or 2. 3 IMO is too much.
>>
>> Do you want to send a patch?
>>
>> Thanks,
>> Stefano
>
>
^ permalink raw reply related
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Fernando Fernandez Mancera @ 2026-04-06 19:58 UTC (permalink / raw)
To: Nicolai Buchwitz, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, workflows, linux-doc, linux-kernel
In-Reply-To: <20260406-nb-docs-ai-review-v1-1-b58943762ca9@tipi-net.de>
On 4/6/26 9:40 PM, Nicolai Buchwitz wrote:
> Add a section about Sashiko, the Linux Foundation's open-source
> AI review system for kernel patches. Contributors can check review
> feedback on the Sashiko website and address findings proactively,
> reducing the need for maintainers to relay the same questions.
>
> Also point to the local review tooling at netdev-ai.bots.linux.dev
> for contributors who want to run AI reviews before submitting.
>
> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
> ---
> Sashiko [1] reviews are already being used on the list (e.g. [2])
> but there's no mention of them in the netdev docs. Add a section
> so contributors know they can check and respond to AI review
> feedback directly.
>
> Based on Jakub's reviewer guidance patch [3].
>
> [1] https://sashiko.dev/
> [2] https://lore.kernel.org/all/20260324024235.929875-1-kuba@kernel.org/
> [3] https://lore.kernel.org/all/20260406175334.3153451-1-kuba@kernel.org/
> ---
> Documentation/process/maintainer-netdev.rst | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
> index bda93b459a0533fa1adfd11b756a4f47d1dbaa22..27296afb05d3828a350b4ed5c16907672db9785d 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -559,6 +559,19 @@ Reviewers are highly encouraged to do more in-depth review of submissions
> and not focus exclusively on process issues, trivial or subjective
> matters like code formatting, tags etc.
>
> +AI-assisted review
> +~~~~~~~~~~~~~~~~~~
> +
> +Patches posted to netdev are automatically reviewed by the Sashiko
> +AI review system (https://sashiko.dev/). Results are posted publicly
> +on the website.
Hi Nicolai,
maybe I am missing something but [2] isn't from sashiko.dev but from
netdev AI CI instead. See:
https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
The documentation mentioned for running the AI locally is correctly
related to netdev AI bot.
I think it would be useful to document that AI reviews are happening but
mixing AI bots might confuse people.
> Check for findings on your submissions and address
> +valid ones before a maintainer has to relay the same questions.
> +
I wonder what would be the consequences for this. If less experienced
submitters are expected to address issues pointed out by AI bots they
might work on something that isn't valid. AFAIU, the AI output is only
forwarded to the submitter after a maintainer reviewed it and believes
it makes sense.
Thanks,
Fernando.
> +You can also run AI reviews locally before submitting. Instructions
> +and tooling are available at:
> +
> + https://netdev-ai.bots.linux.dev/ai-local.html
> +
> Testimonials / feedback
> -----------------------
>
^ permalink raw reply
* Re: [PATCH bpf v6 1/2] bpf: tcp: Reject non-TCP skb in bpf_sk_assign_tcp_reqsk()
From: Martin KaFai Lau @ 2026-04-06 19:53 UTC (permalink / raw)
To: Jiayuan Chen
Cc: bpf, Kuniyuki Iwashima, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Stanislav Fomichev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260403015851.148209-2-jiayuan.chen@linux.dev>
On Fri, Apr 03, 2026 at 09:58:27AM +0800, Jiayuan Chen wrote:
> bpf_sk_assign_tcp_reqsk() only validates skb->protocol (L3) but does not
> check the L4 protocol in the IP header. A BPF program can call this kfunc
> on a UDP skb with a valid TCP listener socket, which will succeed and
> attach a TCP reqsk to the UDP skb.
>
> When the UDP skb enters the UDP receive path, skb_steal_sock() returns
> the TCP listener from the reqsk. The UDP code then passes this TCP socket
> to udp_unicast_rcv_skb() -> __udp_enqueue_schedule_skb(), which casts
> it to udp_sock and accesses UDP-specific fields at invalid offsets,
> causing a null pointer dereference and kernel panic:
>
> BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x19d/0x1df0
> Read of size 4 at addr 0000000000000008 by task test_progs/537
>
> CPU: 1 UID: 0 PID: 537 Comm: test_progs Not tainted 7.0.0-rc4+ #46 PREEMPT
> Call Trace:
> <IRQ>
> dump_stack_lvl (lib/dump_stack.c:123)
> print_report (mm/kasan/report.c:487)
> kasan_report (mm/kasan/report.c:597)
> __kasan_check_read (mm/kasan/shadow.c:32)
> __udp_enqueue_schedule_skb (net/ipv4/udp.c:1719)
> udp_queue_rcv_one_skb (net/ipv4/udp.c:2370 net/ipv4/udp.c:2500)
> udp_queue_rcv_skb (net/ipv4/udp.c:2532)
> udp_unicast_rcv_skb (net/ipv4/udp.c:2684)
> __udp4_lib_rcv (net/ipv4/udp.c:2742)
> udp_rcv (net/ipv4/udp.c:2937)
> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:209)
> ip_local_deliver_finish (./include/linux/rcupdate.h:879 net/ipv4/ip_input.c:242)
> ip_local_deliver (net/ipv4/ip_input.c:265)
> __netif_receive_skb_one_core (net/core/dev.c:6164 (discriminator 4))
> __netif_receive_skb (net/core/dev.c:6280)
>
> Fix this by checking the IP header's protocol field in
> bpf_sk_assign_tcp_reqsk() and rejecting non-TCP skbs with -EINVAL.
>
> Note that for IPv6, the nexthdr check does not walk extension headers.
> This is uncommon for TCP SYN packets in practice, and keeping it simple
> was agreed upon by Kuniyuki Iwashima.
sashiko has flagged a similar issue with larger scope.
Please take a look. Thanks.
https://sashiko.dev/#/patchset/20260403015851.148209-1-jiayuan.chen%40linux.dev
^ permalink raw reply
* Re: [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
From: Mark Bloch @ 2026-04-06 19:52 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Jakub Kicinski, Dragos Tatulea, Tariq Toukan, Eric Dumazet,
Paolo Abeni, Andrew Lunn, David S. Miller, Saeed Mahameed,
Leon Romanovsky, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Cosmin Ratiu, Simon Horman, Jacob Keller, Lama Kayal,
Michal Swiatkowski, Carolina Jubran, Nathan Chancellor,
Daniel Zahka, Rahul Rameshbabu, Raed Salem, netdev, linux-rdma,
linux-kernel, bpf, Gal Pressman
In-Reply-To: <d7c247276e39d88e1cd9d86e21c74779@tipi-net.de>
On 06/04/2026 22:13, Nicolai Buchwitz wrote:
> On 6.4.2026 18:31, Mark Bloch wrote:
>> On 06/04/2026 18:43, Jakub Kicinski wrote:
>>> On Sun, 5 Apr 2026 08:08:06 +0200 Dragos Tatulea wrote:
>>>> sashiko says:
>>>
>>> Thanks a lot for reviewing the review! It takes a lot of maintainer time
>
>> [...]
>
>>
>> For example:
>>
>> “Before posting, authors could run a recommended baseline of review tools,
>> where available, to catch obvious issues early. During review, tools such
>> as review-prompts and Sashiko may be used to assist the reviewer.”
>>
>
> There is already https://netdev-ai.bots.linux.dev/ai-local.html which I found really helpful.
Yes, I’m aware of that page, and it’s definitely useful.
The reason I brought this up is that recently, with the rise of sashiko usage, Jakub has
also started pointing out comments coming from it during review, while sashiko itself is
not mentioned anywhere in the official netdev documentation.
Mark
> If this is still the preferred approach, I could draft a patch to add it to Documentation/process/maintainer-netdev.rst
>
>> Mark
>
> Thanks
> Nicolai
^ permalink raw reply
* Re: [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
From: Mark Bloch @ 2026-04-06 19:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Dragos Tatulea, Tariq Toukan, Eric Dumazet, Paolo Abeni,
Andrew Lunn, David S. Miller, Saeed Mahameed, Leon Romanovsky,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Cosmin Ratiu, Simon Horman,
Jacob Keller, Lama Kayal, Michal Swiatkowski, Carolina Jubran,
Nathan Chancellor, Daniel Zahka, Rahul Rameshbabu, Raed Salem,
netdev, linux-rdma, linux-kernel, bpf, Gal Pressman
In-Reply-To: <20260406113038.212d91c0@kernel.org>
On 06/04/2026 21:30, Jakub Kicinski wrote:
> On Mon, 6 Apr 2026 19:31:03 +0300 Mark Bloch wrote:
>> On 06/04/2026 18:43, Jakub Kicinski wrote:
>>> On Sun, 5 Apr 2026 08:08:06 +0200 Dragos Tatulea wrote:
>>>> sashiko says:
>>>
>>> Thanks a lot for reviewing the review! It takes a lot of maintainer time
>>
>> Just to add some context: we started running Sashiko internally,
>> so hopefully trivial issues won’t be missed. I don’t know if
>> you remember our on-list discussion from a few weeks ago, following that
>> discussion right now we have three different internal AI tools reviewing each
>> commit.
>>
>> At the moment this is still manageable, and I think developers should
>> look over all comments from all tools. In our case that currently
>> means three review outputs per commit. It would also be useful to have
>> some official guidance on what authors are recommended to run before
>> posting, so obvious issues can be caught earlier and less reviewer/maintainer
>> time is spent on them.
>>
>> For example:
>>
>> “Before posting, authors could run a recommended baseline of review tools,
>> where available, to catch obvious issues early. During review, tools such
>> as review-prompts and Sashiko may be used to assist the reviewer.”
>
> Please send patches if you think something should be mentioned
> somewhere. It'd be awesome if y'all participated more in upstream
> reviews so that you recommendation could be rooted in what happens
> on the list not just what happens within nVidia.
Fair point.
I can’t speak for the others, but I’ll try to do more upstream reviews
myself. In fact, I already blocked regular time slots each week for that.
Unfortunately, the region I live in has been affected by a certain war
situation recently, and that has derailed quite a few plans on my side.
Hopefully things will settle down sooner rather than later.
Mark
^ permalink raw reply
* [PATCH v4] mm/vmpressure: skip socket pressure for costly order reclaim
From: JP Kobryn (Meta) @ 2026-04-06 19:50 UTC (permalink / raw)
To: linux-mm, willy, hannes, akpm, david, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, kasong, qi.zheng, shakeel.butt, baohua,
axelrasmussen, yuanchu, weixugc, riel, kuba, edumazet
Cc: netdev, linux-kernel, kernel-team
When reclaim is triggered by high order allocations on a fragmented system,
vmpressure() can report poor reclaim efficiency even though the system has
plenty of free memory. This is because many pages are scanned, but few are
found to actually reclaim - the pages are actively in use and don't need to
be freed. The resulting scan:reclaim ratio causes vmpressure() to assert
socket pressure, throttling TCP throughput unnecessarily.
Costly order allocations (above PAGE_ALLOC_COSTLY_ORDER) rely heavily on
compaction to succeed, so poor reclaim efficiency at these orders does not
necessarily indicate memory pressure. The kernel already treats this order
as the boundary where reclaim is no longer expected to succeed and
compaction may take over.
Make vmpressure() order-aware through an additional parameter sourced from
scan_control at existing call sites. Socket pressure is now only asserted
when order <= PAGE_ALLOC_COSTLY_ORDER.
Memcg reclaim is unaffected since try_to_free_mem_cgroup_pages() always
uses order 0, which passes the filter unconditionally. Similarly,
vmpressure_prio() now passes order 0 internally when calling vmpressure(),
ensuring critical pressure from low reclaim priority is not suppressed by
the order filter.
The patch was motivated by a case of impacted net throughput in production.
On one affected host, the memory state at the time showed ~15GB available,
zero cgroup pressure, and the following buddyinfo state:
Order FreePages
0: 133,970
1: 29,230
2: 17,351
3: 18,984
7+: 0
Using bpf, it was found that 94% of vmpressure calls on this host were from
order-7 kswapd reclaim.
TCP minimum recv window is rcv_ssthresh:19712.
Before patch:
723 out of 3,843 (19%) TCP connections stuck at minimum recv window
After live-patching and ~30min elapsed:
0 out of 3,470 TCP connections stuck at minimum recv window
Signed-off-by: JP Kobryn (Meta) <jp.kobryn@linux.dev>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Jakub Kicinski <kuba@kernel.org>
---
v4
- update changelog to include prod data
v3: https://lore.kernel.org/linux-mm/20260406174425.61692-1-jp.kobryn@linux.dev/
- update changelog to justify patch beyond just networking
- update changelog to expand scope of vmpressure beyond kswapd
v2: https://lore.kernel.org/linux-mm/20260402232511.17246-1-jp.kobryn@linux.dev/
- dropped extern specifier from vmpressure decl
- added comment to explain rationale of adjusted conditional
v1: https://lore.kernel.org/all/20260401203752.643259-1-jp.kobryn@linux.dev/
include/linux/vmpressure.h | 9 +++++----
mm/vmpressure.c | 15 ++++++++++++---
mm/vmscan.c | 8 ++++----
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/include/linux/vmpressure.h b/include/linux/vmpressure.h
index 6a2f51ebbfd35..faecd55224017 100644
--- a/include/linux/vmpressure.h
+++ b/include/linux/vmpressure.h
@@ -30,8 +30,8 @@ struct vmpressure {
struct mem_cgroup;
#ifdef CONFIG_MEMCG
-extern void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, bool tree,
- unsigned long scanned, unsigned long reclaimed);
+void vmpressure(gfp_t gfp, int order, struct mem_cgroup *memcg, bool tree,
+ unsigned long scanned, unsigned long reclaimed);
extern void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio);
extern void vmpressure_init(struct vmpressure *vmpr);
@@ -44,8 +44,9 @@ extern int vmpressure_register_event(struct mem_cgroup *memcg,
extern void vmpressure_unregister_event(struct mem_cgroup *memcg,
struct eventfd_ctx *eventfd);
#else
-static inline void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, bool tree,
- unsigned long scanned, unsigned long reclaimed) {}
+static inline void vmpressure(gfp_t gfp, int order, struct mem_cgroup *memcg,
+ bool tree, unsigned long scanned,
+ unsigned long reclaimed) {}
static inline void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg,
int prio) {}
#endif /* CONFIG_MEMCG */
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index 3fbb86996c4d2..f053554e58264 100644
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -218,6 +218,7 @@ static void vmpressure_work_fn(struct work_struct *work)
/**
* vmpressure() - Account memory pressure through scanned/reclaimed ratio
* @gfp: reclaimer's gfp mask
+ * @order: allocation order being reclaimed for
* @memcg: cgroup memory controller handle
* @tree: legacy subtree mode
* @scanned: number of pages scanned
@@ -236,7 +237,7 @@ static void vmpressure_work_fn(struct work_struct *work)
*
* This function does not return any value.
*/
-void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, bool tree,
+void vmpressure(gfp_t gfp, int order, struct mem_cgroup *memcg, bool tree,
unsigned long scanned, unsigned long reclaimed)
{
struct vmpressure *vmpr;
@@ -307,7 +308,15 @@ void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, bool tree,
level = vmpressure_calc_level(scanned, reclaimed);
- if (level > VMPRESSURE_LOW) {
+ /*
+ * Once we go above COSTLY_ORDER, reclaim relies heavily on
+ * compaction to make progress. Reclaim efficiency was never a
+ * great proxy for pressure to begin with, but it's outright
+ * misleading with these high orders. Don't throttle sockets
+ * because somebody is attempting something crazy like an order-7
+ * and predictably struggling.
+ */
+ if (level > VMPRESSURE_LOW && order <= PAGE_ALLOC_COSTLY_ORDER) {
/*
* Let the socket buffer allocator know that
* we are having trouble reclaiming LRU pages.
@@ -348,7 +357,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio)
* to the vmpressure() basically means that we signal 'critical'
* level.
*/
- vmpressure(gfp, memcg, true, vmpressure_win, 0);
+ vmpressure(gfp, 0, memcg, true, vmpressure_win, 0);
}
#define MAX_VMPRESSURE_ARGS_LEN (strlen("critical") + strlen("hierarchy") + 2)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5a8c8fcccbfc9..1342323a0b41f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -5071,8 +5071,8 @@ static int shrink_one(struct lruvec *lruvec, struct scan_control *sc)
shrink_slab(sc->gfp_mask, pgdat->node_id, memcg, sc->priority);
if (!sc->proactive)
- vmpressure(sc->gfp_mask, memcg, false, sc->nr_scanned - scanned,
- sc->nr_reclaimed - reclaimed);
+ vmpressure(sc->gfp_mask, sc->order, memcg, false,
+ sc->nr_scanned - scanned, sc->nr_reclaimed - reclaimed);
flush_reclaim_state(sc);
@@ -6175,7 +6175,7 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
/* Record the group's reclaim efficiency */
if (!sc->proactive)
- vmpressure(sc->gfp_mask, memcg, false,
+ vmpressure(sc->gfp_mask, sc->order, memcg, false,
sc->nr_scanned - scanned,
sc->nr_reclaimed - reclaimed);
@@ -6220,7 +6220,7 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc)
/* Record the subtree's reclaim efficiency */
if (!sc->proactive)
- vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
+ vmpressure(sc->gfp_mask, sc->order, sc->target_mem_cgroup, true,
sc->nr_scanned - nr_scanned, nr_node_reclaimed);
if (nr_node_reclaimed)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Nicolai Buchwitz @ 2026-04-06 19:40 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, workflows, linux-doc, linux-kernel, Nicolai Buchwitz
Add a section about Sashiko, the Linux Foundation's open-source
AI review system for kernel patches. Contributors can check review
feedback on the Sashiko website and address findings proactively,
reducing the need for maintainers to relay the same questions.
Also point to the local review tooling at netdev-ai.bots.linux.dev
for contributors who want to run AI reviews before submitting.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
Sashiko [1] reviews are already being used on the list (e.g. [2])
but there's no mention of them in the netdev docs. Add a section
so contributors know they can check and respond to AI review
feedback directly.
Based on Jakub's reviewer guidance patch [3].
[1] https://sashiko.dev/
[2] https://lore.kernel.org/all/20260324024235.929875-1-kuba@kernel.org/
[3] https://lore.kernel.org/all/20260406175334.3153451-1-kuba@kernel.org/
---
Documentation/process/maintainer-netdev.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index bda93b459a0533fa1adfd11b756a4f47d1dbaa22..27296afb05d3828a350b4ed5c16907672db9785d 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -559,6 +559,19 @@ Reviewers are highly encouraged to do more in-depth review of submissions
and not focus exclusively on process issues, trivial or subjective
matters like code formatting, tags etc.
+AI-assisted review
+~~~~~~~~~~~~~~~~~~
+
+Patches posted to netdev are automatically reviewed by the Sashiko
+AI review system (https://sashiko.dev/). Results are posted publicly
+on the website. Check for findings on your submissions and address
+valid ones before a maintainer has to relay the same questions.
+
+You can also run AI reviews locally before submitting. Instructions
+and tooling are available at:
+
+ https://netdev-ai.bots.linux.dev/ai-local.html
+
Testimonials / feedback
-----------------------
---
base-commit: d00749db443cf420a882c020ce0e6bb5c43009de
change-id: 20260406-nb-docs-ai-review-28b4ff21cf5e
Best regards,
--
Nicolai Buchwitz <nb@tipi-net.de>
^ permalink raw reply related
* Re: [PATCH] gcov: use atomic counter updates to fix concurrent access crashes
From: Nathan Chancellor @ 2026-04-06 19:37 UTC (permalink / raw)
To: Konstantin Khorenko
Cc: Peter Oberparleiter, Mikhail Zaslonko, Nicolas Schier,
Masahiro Yamada, Thomas Weißschuh, Arnd Bergmann,
Steffen Klassert, Herbert Xu, linux-kbuild, linux-kernel, netdev,
Pavel Tikhomirov, Vasileios Almpanis, Jakub Kicinski
In-Reply-To: <20260402141831.1437357-2-khorenko@virtuozzo.com>
On Thu, Apr 02, 2026 at 05:18:31PM +0300, Konstantin Khorenko wrote:
> GCC's GCOV instrumentation can merge global branch counters with loop
> induction variables as an optimization. In inflate_fast(), the inner
> copy loops get transformed so that the GCOV counter value is loaded
> multiple times to compute the loop base address, start index, and end
> bound. Since GCOV counters are global (not per-CPU), concurrent
> execution on different CPUs causes the counter to change between loads,
> producing inconsistent values and out-of-bounds memory writes.
>
> The crash manifests during IPComp (IP Payload Compression) processing
> when inflate_fast() runs concurrently on multiple CPUs:
>
> BUG: unable to handle page fault for address: ffffd0a3c0902ffa
> RIP: inflate_fast+1431
> Call Trace:
> zlib_inflate
> __deflate_decompress
> crypto_comp_decompress
> ipcomp_decompress [xfrm_ipcomp]
> ipcomp_input [xfrm_ipcomp]
> xfrm_input
>
> At the crash point, the compiler generated three loads from the same
> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
> and end for an indexed loop. Another CPU modified the counter between
> loads, making the values inconsistent — the write went 3.4 MB past a
> 65 KB buffer.
>
> Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
> top-level Makefile. This tells GCC that GCOV counters may be
> concurrently accessed, causing counter updates to use atomic
> instructions (lock addq) instead of plain load/store. This prevents
> the compiler from merging counters with loop induction variables.
>
> Applying this globally rather than per-subsystem not only addresses the
> observed crash in zlib but makes GCOV coverage data more consistent
> overall, preventing similar issues in any kernel code path that may
> execute concurrently.
>
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
> Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
While this is obviously a fix, what are the chances of regressions from
this change? As this should only impact GCOV, this could go via whatever
tree carries GCOV patches. If Kbuild is to take this change, my vote
would be to defer it to 7.2 at this point in the development cycle so
that it can have most of a cycle to sit in -next.
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 6b1d9fb1a6b4..a55ad668d6ba 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -806,7 +806,7 @@ all: vmlinux
>
> CFLAGS_GCOV := -fprofile-arcs -ftest-coverage
> ifdef CONFIG_CC_IS_GCC
> -CFLAGS_GCOV += -fno-tree-loop-im
> +CFLAGS_GCOV += -fno-tree-loop-im -fprofile-update=atomic
> endif
> export CFLAGS_GCOV
>
> --
> 2.43.5
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Andrew Lunn @ 2026-04-06 19:24 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Russell King (Oracle), Florian Fainelli, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <faf651039d98fb9c1ffb40dbd98bb16b@tipi-net.de>
On Mon, Apr 06, 2026 at 08:29:38PM +0200, Nicolai Buchwitz wrote:
> On 6.4.2026 19:10, Russell King (Oracle) wrote:
> > On Mon, Apr 06, 2026 at 09:43:55AM -0700, Florian Fainelli wrote:
> > > That is almost a guarantee given, there will be a broken MAC
> >
> > Well, it already exists. modern i.MX platforms use stmmac, and some
> > bright spark wired lpi_intr_o together with the main stmmac interrupt
> > which causes interrupt storms when the receive path exits LPI. This
> > makes stmmac LPI unusable on this platform.
> >
> > So, if i.MX is paired with a PHY that can do its own EEE, then we
> > have this exact scenaro.
>
> For DT-based platforms (like the broken i.MX), this could be addressed
> similar to what we already have with eee-broken-* properties. For
> platforms without DT it's getting more complicated and I can't see a
> way without ethtool.
i.MX is not actually an issue. The MAC EEE is so broken we don't
consider using it. Since it never calls phy_support_eee() PHY EEE will
be used.
It gets more interesting when we actually have PHY EEE support. And a
board using it. And then somebody adds support for MAC EEE which is
partially broken, but better than nothing. It calls phy_support_eee(),
so disabling PHY EEE, which can cause a board using PHY EEE to
regress, because the poor MAC EEE is worse than the PHY EEE which just
got disabled.
With PTP we talked about adding some sort of quality value, so we can
rank the implementations and pick the best. But that never got
implemented.
It is these sorts of corner case regressions which are hard to deal
with.
Andrew
^ permalink raw reply
* Re: [PATCH v3] mm/vmpressure: skip socket pressure for costly order reclaim
From: Andrew Morton @ 2026-04-06 19:16 UTC (permalink / raw)
To: JP Kobryn (Meta)
Cc: linux-mm, willy, hannes, david, ljs, Liam.Howlett, vbabka, rppt,
surenb, mhocko, kasong, qi.zheng, shakeel.butt, baohua,
axelrasmussen, yuanchu, weixugc, riel, kuba, edumazet, netdev,
linux-kernel, kernel-team
In-Reply-To: <6a41259c-bf69-49d5-9cba-80a5feb8ee8a@linux.dev>
On Mon, 6 Apr 2026 12:07:57 -0700 "JP Kobryn (Meta)" <jp.kobryn@linux.dev> wrote:
> Let me know if this data helps, and if you'd like this added to the
> changelog.
>
> On one affected host with impacted net throughput, the memory state at
> the time showed ~15GB available, zero cgroup pressure, and the following
> buddyinfo state:
>
> Order FreePages
> 0: 133,970
> 1: 29,230
> 2: 17,351
> 3: 18,984
> 7+: 0
>
> Using bpf, it was found that 94% of vmpressure calls on this host were
> from order-7 kswapd reclaim.
>
> TCP minimum recv window is rcv_ssthresh:19712.
>
> Before patch:
> 723 out of 3,843 (19%) TCP connections stuck at minimum recv window
>
> After live-patching and ~30min elapsed:
> 0 out of 3,470 TCP connections stuck at minimum recv window
Well I'm impressed ;)
Yes please, it's a useful thing to include. When people look at a
contribution, question #1 is "why should I spend time on this". A
clear (and tasty) description of userspace benefit is the ideal way of
answering that.
^ permalink raw reply
* Re: [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
From: Nicolai Buchwitz @ 2026-04-06 19:13 UTC (permalink / raw)
To: Mark Bloch
Cc: Jakub Kicinski, Dragos Tatulea, Tariq Toukan, Eric Dumazet,
Paolo Abeni, Andrew Lunn, David S. Miller, Saeed Mahameed,
Leon Romanovsky, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Cosmin Ratiu, Simon Horman, Jacob Keller, Lama Kayal,
Michal Swiatkowski, Carolina Jubran, Nathan Chancellor,
Daniel Zahka, Rahul Rameshbabu, Raed Salem, netdev, linux-rdma,
linux-kernel, bpf, Gal Pressman
In-Reply-To: <e0ac9755-fd49-4620-92ce-0f5e4203a95e@nvidia.com>
On 6.4.2026 18:31, Mark Bloch wrote:
> On 06/04/2026 18:43, Jakub Kicinski wrote:
>> On Sun, 5 Apr 2026 08:08:06 +0200 Dragos Tatulea wrote:
>>> sashiko says:
>>
>> Thanks a lot for reviewing the review! It takes a lot of maintainer
>> time
> [...]
>
> For example:
>
> “Before posting, authors could run a recommended baseline of review
> tools,
> where available, to catch obvious issues early. During review, tools
> such
> as review-prompts and Sashiko may be used to assist the reviewer.”
>
There is already https://netdev-ai.bots.linux.dev/ai-local.html which I
found really helpful.
If this is still the preferred approach, I could draft a patch to add it
to Documentation/process/maintainer-netdev.rst
> Mark
Thanks
Nicolai
^ permalink raw reply
* Re: [PATCH v3] mm/vmpressure: skip socket pressure for costly order reclaim
From: JP Kobryn (Meta) @ 2026-04-06 19:07 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, willy, hannes, david, ljs, Liam.Howlett, vbabka, rppt,
surenb, mhocko, kasong, qi.zheng, shakeel.butt, baohua,
axelrasmussen, yuanchu, weixugc, riel, kuba, edumazet, netdev,
linux-kernel, kernel-team
In-Reply-To: <20260406105417.28fda9587146a011af2fb876@linux-foundation.org>
On 4/6/26 10:54 AM, Andrew Morton wrote:
> On Mon, 6 Apr 2026 10:44:25 -0700 "JP Kobryn (Meta)" <jp.kobryn@linux.dev> wrote:
>
>> When reclaim is triggered by high order allocations on a fragmented system,
>> vmpressure() can report poor reclaim efficiency even though the system has
>> plenty of free memory. This is because many pages are scanned, but few are
>> found to actually reclaim - the pages are actively in use and don't need to
>> be freed. The resulting scan:reclaim ratio causes vmpressure() to assert
>> socket pressure, throttling TCP throughput unnecessarily.
>>
>> Costly order allocations (above PAGE_ALLOC_COSTLY_ORDER) rely heavily on
>> compaction to succeed, so poor reclaim efficiency at these orders does not
>> necessarily indicate memory pressure. The kernel already treats this order
>> as the boundary where reclaim is no longer expected to succeed and
>> compaction may take over.
>>
>> Make vmpressure() order-aware through an additional parameter sourced from
>> scan_control at existing call sites. Socket pressure is now only asserted
>> when order <= PAGE_ALLOC_COSTLY_ORDER.
>>
>> Memcg reclaim is unaffected since try_to_free_mem_cgroup_pages() always
>> uses order 0, which passes the filter unconditionally. Similarly,
>> vmpressure_prio() now passes order 0 internally when calling vmpressure(),
>> ensuring critical pressure from low reclaim priority is not suppressed by
>> the order filter.
>
> Thanks. I'd prefer to park this until after next -rc1. I could be
> argued with, but....
>
> What I'm not understanding from the above is how beneficial this patch
> is. Some description of observed before-and-after behavior, preferably
> with impressive measurements?
Let me know if this data helps, and if you'd like this added to the
changelog.
On one affected host with impacted net throughput, the memory state at
the time showed ~15GB available, zero cgroup pressure, and the following
buddyinfo state:
Order FreePages
0: 133,970
1: 29,230
2: 17,351
3: 18,984
7+: 0
Using bpf, it was found that 94% of vmpressure calls on this host were
from order-7 kswapd reclaim.
TCP minimum recv window is rcv_ssthresh:19712.
Before patch:
723 out of 3,843 (19%) TCP connections stuck at minimum recv window
After live-patching and ~30min elapsed:
0 out of 3,470 TCP connections stuck at minimum recv window
^ permalink raw reply
* Re: [PATCH bpf-next v3] bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb
From: Martin KaFai Lau @ 2026-04-06 18:58 UTC (permalink / raw)
To: Sun Jian
Cc: ast, daniel, andrii, eddyz87, song, yonghong.song, john.fastabend,
kpsingh, sdf, haoluo, jolsa, davem, edumazet, kuba, pabeni, horms,
shuah, syzbot+619b9ef527f510a57cfc, bpf, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260402160147.215499-1-sun.jian.kdev@gmail.com>
On Fri, Apr 03, 2026 at 12:01:47AM +0800, Sun Jian wrote:
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index 178c4738e63b..300e2bfc5a62 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -1120,19 +1120,23 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
>
> switch (skb->protocol) {
> case htons(ETH_P_IP):
> - sk->sk_family = AF_INET;
> - if (sizeof(struct iphdr) <= skb_headlen(skb)) {
> - sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
> - sk->sk_daddr = ip_hdr(skb)->daddr;
> + if (skb_headlen(skb) < sizeof(struct iphdr)) {
> + ret = -EINVAL;
> + goto out;
> }
> + sk->sk_family = AF_INET;
> + sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
> + sk->sk_daddr = ip_hdr(skb)->daddr;
> break;
> #if IS_ENABLED(CONFIG_IPV6)
> case htons(ETH_P_IPV6):
> - sk->sk_family = AF_INET6;
> - if (sizeof(struct ipv6hdr) <= skb_headlen(skb)) {
> - sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
> - sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
> + if (skb_headlen(skb) < sizeof(struct ipv6hdr)) {
> + ret = -EINVAL;
> + goto out;
> }
> + sk->sk_family = AF_INET6;
> + sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
> + sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
> break;
> #endif
> default:
> diff --git a/tools/testing/selftests/bpf/prog_tests/empty_skb.c b/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> index 438583e1f2d1..d53567e9cd77 100644
> --- a/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> +++ b/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> @@ -12,6 +12,8 @@ void test_empty_skb(void)
> struct bpf_program *prog;
> char eth_hlen_pp[15];
> char eth_hlen[14];
> + char ipv4_eth_hlen[14];
> + char ipv6_eth_hlen[14];
The eth_hlen_pp and eth_hlen needs to memset zero now.
Instead of adding two more ethhdrs, just reuse the current eth_hlen and
define it as 'struct ethhdr eth_hlen;' instead of a char array.
Add 'h_proto' to the anonymous 'struct { } tests[]'. Initialize
the eth_hlen.h_proto based on the tests[i].h_proto.
Also, this test does not actually reproduce the reading uninit memeory.
It needs a bpf prog to actually trigger it by calling bpf_skb_adjust_room()
based on the report in the "Closes" link. The test should be able
to trigger it without the change in test_run.c
The ai-review has flagged again that it is missing a "Fixes" tag. This
probably started since the bpf_skb_adjust_room helper was introduced.
The selftests should also be in a separate patch 2 following the patch 1
changes in test_run.c.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v6 3/7] net: bcmgenet: add basic XDP support (PASS/DROP)
From: Nicolai Buchwitz @ 2026-04-06 18:57 UTC (permalink / raw)
To: netdev
Cc: Justin Chen, Simon Horman, Mohsin Bashir, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, Eric Dumazet, Paolo Abeni, David S. Miller,
Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
linux-kernel, bpf
In-Reply-To: <20260406083536.839517-4-nb@tipi-net.de>
On 6.4.2026 10:35, Nicolai Buchwitz wrote:
> Add XDP program attachment via ndo_bpf and execute XDP programs in the
> RX path. XDP_PASS builds an SKB from the xdp_buff (handling
> xdp_adjust_head/tail), XDP_DROP returns the page to page_pool without
> SKB allocation.
> [...]
>
> /* Set up checksum offload */
> if (dev->features & NETIF_F_RXCSUM) {
> - rx_csum = (__force __be16)(status->rx_csum & 0xffff);
> if (rx_csum) {
> skb->csum = (__force __wsum)ntohs(rx_csum);
> skb->ip_summed = CHECKSUM_COMPLETE;
Sashiko:
Will this cause hardware checksum validation failures if the XDP program
modifies the packet?
The driver saves the hardware checksum before executing the XDP program,
and
then unconditionally applies CHECKSUM_COMPLETE if XDP_PASS is returned.
If
the BPF program alters the packet payload or adjusts the headers, the
saved
hardware checksum will no longer match the new packet contents.
When the networking stack later attempts to validate this checksum,
won't it
result in a mismatch, causing the packet to be dropped and the stack to
emit
a hardware checksum failure warning?
Does the driver need to clear the hardware checksum and set
skb->ip_summed
to CHECKSUM_NONE when an XDP program is present, or otherwise ensure the
checksum is only applied when the packet is unmodified?
Reponse:
CHECKSUM_COMPLETE with a stale HW checksum causes the stack to fall back
to
software verification, not a silent drop. This is how ice and other XDP
drivers
handle it as well. Programs that modify packets typically return TX or
REDIRECT,
not PASS.
> @@ -3744,6 +3810,37 @@ static int bcmgenet_change_carrier(struct
> net_device *dev, bool new_carrier)
> return 0;
> }
> [...]
^ permalink raw reply
* Re: [PATCH net-next v6 4/7] net: bcmgenet: add XDP_TX support
From: Nicolai Buchwitz @ 2026-04-06 18:52 UTC (permalink / raw)
To: netdev
Cc: Justin Chen, Simon Horman, Mohsin Bashir, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, Eric Dumazet, Paolo Abeni, David S. Miller,
Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
linux-kernel, bpf
In-Reply-To: <20260406083536.839517-5-nb@tipi-net.de>
On 6.4.2026 10:35, Nicolai Buchwitz wrote:
> Implement XDP_TX using ring 16 (DESC_INDEX), the hardware default
> descriptor ring, dedicated to XDP TX for isolation from SKB TX queues.
> [...]
> +
> + if (dma_map) {
> + void *tsb_start;
> +
> + /* The GENET MAC has TBUF_64B_EN set globally, so hardware
> + * expects a 64-byte TSB prefix on every TX buffer. For
> + * redirected frames (ndo_xdp_xmit) we prepend a zeroed TSB
> + * using the frame's headroom.
> + */
> + if (unlikely(xdpf->headroom < sizeof(struct status_64))) {
> + bcmgenet_put_txcb(priv, ring);
> + spin_unlock(&ring->lock);
> + return false;
> + }
> +
> + tsb_start = xdpf->data - sizeof(struct status_64);
> + memset(tsb_start, 0, sizeof(struct status_64));
Sashiko:
Does this memset() overwrite the struct xdp_frame? The xdp_frame is
typically
stored in the headroom immediately before xdpf->data (or before the
metadata).
If the 64-byte status_64 block is zeroed out here, could it destroy the
xdp_frame memory structure and cause a panic when xdp_return_frame() is
later
called during TX completion?
Reponse:
No. The xdp_frame struct ends at data_hard_start + sizeof(xdp_frame).
The headroom (xdpf->headroom) is the gap between that and xdpf->data.
The TSB is written at xdpf->data - 64, which falls inside the headroom,
after
the xdp_frame. The check xdpf->headroom < sizeof(struct status_64)
prevents overlap.
> +
> + dma_len = xdpf->len + sizeof(struct status_64);
> + mapping = dma_map_single(kdev, tsb_start, dma_len,
> + DMA_TO_DEVICE);
> + if (dma_mapping_error(kdev, mapping)) {
> + tx_cb_ptr->skb = NULL;
> + tx_cb_ptr->xdpf = NULL;
> + bcmgenet_put_txcb(priv, ring);
> + spin_unlock(&ring->lock);
> + return false;
> + }
> + } else {
> + struct page *page = virt_to_page(xdpf->data);
> +
> + /* For local XDP_TX the caller already prepended the TSB
> + * into xdpf->data/len, so dma_len == xdpf->len.
> + */
> + dma_len = xdpf->len;
> + mapping = page_pool_get_dma_addr(page) +
> + sizeof(*xdpf) + xdpf->headroom;
Sashiko:
Is this DMA address calculation correct? It evaluates to the offset of
xdp->data_meta relative to xdp->data_hard_start, which completely drops
the
GENET_XDP_HEADROOM (256 bytes) offset applied to the page pool base
address.
Also, if metadata is present, this will point to the metadata instead of
xdpf->data. Could this cause the hardware to read the wrong memory
location
for the Transmit Status Block and truncate the payload?
Reponse:
Correct. page_pool_get_dma_addr() returns the DMA address of the page
start,
not offset by the pool's .offset. sizeof(*xdpf) + xdpf->headroom equals
xdpf->data - data_hard_start, pointing to the TSB. No metadata issue:
for local XDP_TX, data already includes the prepended TSB.
> + dma_sync_single_for_device(kdev, mapping, dma_len,
> [...]
> }
> @@ -2542,9 +2684,15 @@ static int bcmgenet_rx_poll(struct napi_struct
> *napi, int budget)
> {
> struct bcmgenet_rx_ring *ring = container_of(napi,
> struct bcmgenet_rx_ring, napi);
> + struct bcmgenet_priv *priv = ring->priv;
> struct dim_sample dim_sample = {};
> unsigned int work_done;
>
> + /* Reclaim completed XDP TX frames (ring 16 has no interrupt) */
> + if (priv->xdp_tx_ring.free_bds < priv->xdp_tx_ring.size)
> + bcmgenet_tx_reclaim(priv->dev,
> + &priv->xdp_tx_ring, false);
Sashiko:
Since the XDP TX ring capacity is 32 (GENET_Q16_TX_BD_CNT) and the NAPI
budget can be up to 64, could a burst of XDP_TX packets exhaust the TX
ring?
Because the reclaim only happens once at the beginning of the poll,
would
subsequent XDP_TX packets within the same poll be dropped when the ring
fills up?
Reponse:
By design. If the ring fills, frames are dropped, which is kinda
standard XDP backpressure.
Same approach as bnxt, mvneta, and other piggybacked-reclaim drivers.
Adding mid-poll reclaim would add complexity for probably minimal
benefit at 1Gbps.
> [...]
^ permalink raw reply
* Re: [BUG] vsock: refcount_t saturation and OOM via buffer size invariant inversion
From: Norbert Szetei @ 2026-04-06 18:41 UTC (permalink / raw)
To: Stefano Garzarella
Cc: davem, edumazet, kuba, pabeni, horms, virtualization, netdev,
linux-kernel, John Villamil
In-Reply-To: <acuKUpZQq6z1DY_n@sgarzare-redhat>
Hi Stefano,
I like option 1 the most, as it is the most straightforward way to fix
the issue. I am including the patch below. This fixes the clamping
mismatch, but as you pointed out, it won't solve the root problem
regarding the issue to arbitrarily set a maximum buffer value.
Since VSOCK uses a unified buffer size rather than separating read and
write buffers like the core stack, introducing a vsock-specific sysctl
(e.g., net.vmw_vsock.buffer_max_size) seems the cleanest approach to me.
I was also considering net.core.wmem_max/rmem_max, but mapping to those
feels less natural.
If you agree with the vsock-specific sysctl, or have a different
suggestion, let me know and I will send a follow-up patch for that.
Thanks.
Best, Norbert
-- >8 --
From f5d160167c862c7f2ad6e6a1d4181d01997b683a Mon Sep 17 00:00:00 2001
From: Norbert Szetei <norbert@doyensec.com>
Date: Mon, 6 Apr 2026 19:52:52 +0200
Subject: [PATCH] vsock: fix buffer size clamping order
In vsock_update_buffer_size(), the buffer size was being clamped to the
maximum first, and then to the minimum. If a user sets a minimum buffer
size larger than the maximum, the minimum check overrides the maximum
check, inverting the constraint.
This breaks the intended socket memory boundaries by allowing the
vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
Fix this by checking the minimum first, and then the maximum. This
ensures the buffer size never exceeds the buffer_max_size.
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
---
net/vmw_vsock/af_vsock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index d912ed2f012a..08f4dfb9782c 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1951,12 +1951,12 @@ static void vsock_update_buffer_size(struct vsock_sock *vsk,
const struct vsock_transport *transport,
u64 val)
{
- if (val > vsk->buffer_max_size)
- val = vsk->buffer_max_size;
-
if (val < vsk->buffer_min_size)
val = vsk->buffer_min_size;
+ if (val > vsk->buffer_max_size)
+ val = vsk->buffer_max_size;
+
if (val != vsk->buffer_size &&
transport && transport->notify_buffer_size)
transport->notify_buffer_size(vsk, &val);
--
2.53.0
> On Mar 31, 2026, at 14:37, Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> On Tue, Mar 24, 2026 at 06:28:12PM +0100, Norbert Szetei wrote:
>> Hello,
>>
>> we have discovered a bug in AF_VSOCK where an unprivileged user can bypass socket
>> memory constraints. This leads to refcount_t saturation and OOM. While
>> refcount_t prevents a true UAF by saturating, the resulting state triggers
>> kernel warnings and kernel panic, depending on the setup.
>>
>> In vsock_connectible_setsockopt(), the SO_VM_SOCKETS_BUFFER_MIN_SIZE and
>> SO_VM_SOCKETS_BUFFER_MAX_SIZE options are used to update the buffer's minimum
>> and maximum values independently.
>>
>> The vsock_update_buffer_size() function clamps the buffer size to the maximum
>> first, then the minimum:
>>
>> // https://github.com/torvalds/linux/blob/c369299895a591d96745d6492d4888259b004a9e/net/vmw_vsock/af_vsock.c#L1950
>> if (val > vsk->buffer_max_size)
>> val = vsk->buffer_max_size;
>>
>> if (val < vsk->buffer_min_size)
>> val = vsk->buffer_min_size;
>>
>> vsk->buffer_size = val;
>>
>> By setting buffer_min_size to a large value, the second clamp overrides the
>> first, forcing vsk->buffer_size to exceed the intended maximum. The transport
>> layer then uses this value, allowing unbounded SKB allocation that saturates the
>> 32-bit sk_wmem_alloc refcount.
>>
>> The fix should ensure that SO_VM_SOCKETS_BUFFER_MIN_SIZE cannot be used to set a
>> value higher than the current buffer_max_size. Conversely,
>> SO_VM_SOCKETS_BUFFER_MAX_SIZE should not be allowed to be set lower than the
>> current buffer_min_size.
>
> Okay, but that wouldn't change much. As long as the user sets the maximum to match the minimum you set in the POC, it behaves exactly the same way, right?
>
> Maybe we should add a sysctl to set a global upper bound, but this is another problem, I agree that we should improve the kernel behavior around min/max. I see 3 options:
>
> 1. Just invert the checks, fist check for min, then for max.
>
> 2. Simply adjust the min and max values so that they make sense. For example, if the minimum value being set is greater than the maximum, the kernel could adjust the maximum to the same value. However, this would not change the behavior of your POC.
>
> 3. Force the minimum to be less than or equal to the maximum. This, however, would require a certain order when setting the minimum and maximum, especially relative to the default. For example, if you increase the minimum beyond the default maximum, you must adjust the maximum first; conversely, if you want to set the maximum below the default minimum, you must adjust the minimum first.
>
> I'm more into 1 or 2. 3 IMO is too much.
>
> Do you want to send a patch?
>
> Thanks,
> Stefano
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: pull headers in qdisc_pkt_len_segs_init()
From: Joe Damato @ 2026-04-06 18:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <20260403221540.3297753-3-edumazet@google.com>
On Fri, Apr 03, 2026 at 10:15:40PM +0000, Eric Dumazet wrote:
> Most ndo_start_xmit() methods expects headers of gso packets
> to be already in skb->head.
>
> net/core/tso.c users are particularly at risk, because tso_build_hdr()
> does a memcpy(hdr, skb->data, hdr_len);
>
> qdisc_pkt_len_segs_init() already does a dissection of gso packets.
>
> Use pskb_may_pull() instead of skb_header_pointer() to make
> sure drivers do not have to reimplement this.
>
> Some malicious packets could be fed, detect them so that we can
> drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.
>
> Fixes: e876f208af18 ("net: Add a software TSO helper API")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/dropreason-core.h | 3 +++
> net/core/dev.c | 51 +++++++++++++++++++++--------------
> 2 files changed, 34 insertions(+), 20 deletions(-)
>
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: improve wording of reviewer guidance
From: Nicolai Buchwitz @ 2026-04-06 18:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, workflows, linux-doc
In-Reply-To: <20260406175334.3153451-1-kuba@kernel.org>
On 6.4.2026 19:53, Jakub Kicinski wrote:
> Reword the reviewer guidance based on behavior we see on the list.
> Steer folks:
> - towards sending tags
> - away from process issues.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: corbet@lwn.net
> CC: skhan@linuxfoundation.org
> CC: workflows@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> ---
> Documentation/process/maintainer-netdev.rst | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/maintainer-netdev.rst
> b/Documentation/process/maintainer-netdev.rst
> index 3aa13bc2405d..bda93b459a05 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -551,10 +551,12 @@ helpful tips please see
> :ref:`development_advancedtopics_reviews`.
>
> It's safe to assume that netdev maintainers know the community and the
> level
> of expertise of the reviewers. The reviewers should not be concerned
> about
> -their comments impeding or derailing the patch flow.
> +their comments impeding or derailing the patch flow. A Reviewed-by tag
> +is understood to mean "I have reviewed this code to the best of my
> ability"
> +rather than "I can attest this code is correct".
>
I had the same hesitation when starting to review on netdev, unsure if
my R-b
carried any value. Therefore I appreciate the addition.
> -Less experienced reviewers are highly encouraged to do more in-depth
> -review of submissions and not focus exclusively on trivial or
> subjective
> +Reviewers are highly encouraged to do more in-depth review of
> submissions
> +and not focus exclusively on process issues, trivial or subjective
> matters like code formatting, tags etc.
>
> Testimonials / feedback
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
^ permalink raw reply
* Re: [net-next v2 2/3] selftests/net: Test PACKET_STATISTICS drops
From: Jakub Kicinski @ 2026-04-06 18:37 UTC (permalink / raw)
To: Joe Damato
Cc: Willem de Bruijn, netdev, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Shuah Khan, andrew+netdev,
linux-kernel, willemb, linux-kselftest
In-Reply-To: <adPfTwbARPVFLys8@devvm20253.cco0.facebook.com>
On Mon, 6 Apr 2026 09:29:03 -0700 Joe Damato wrote:
> > > + if (cfg_drop) {
> > > + check_packet_stats(fds);
> > > + goto out;
> > > + }
> >
> > Sashiko pointed out
>
> In the future, please link to the AI report.
No. We don't link to CI reports as a general rule to avoid people
posting code just to have it tested.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: qdisc_pkt_len_segs_init() cleanup
From: Joe Damato @ 2026-04-06 18:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <20260403221540.3297753-2-edumazet@google.com>
On Fri, Apr 03, 2026 at 10:15:39PM +0000, Eric Dumazet wrote:
> Reduce indentation level by returning early if the transport header
> was not set.
>
> Add an unlikely() clause as this is not the common case.
>
> No functional change.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/core/dev.c | 62 +++++++++++++++++++++++++-------------------------
> 1 file changed, 31 insertions(+), 31 deletions(-)
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
From: Jakub Kicinski @ 2026-04-06 18:30 UTC (permalink / raw)
To: Mark Bloch
Cc: Dragos Tatulea, Tariq Toukan, Eric Dumazet, Paolo Abeni,
Andrew Lunn, David S. Miller, Saeed Mahameed, Leon Romanovsky,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Cosmin Ratiu, Simon Horman,
Jacob Keller, Lama Kayal, Michal Swiatkowski, Carolina Jubran,
Nathan Chancellor, Daniel Zahka, Rahul Rameshbabu, Raed Salem,
netdev, linux-rdma, linux-kernel, bpf, Gal Pressman
In-Reply-To: <e0ac9755-fd49-4620-92ce-0f5e4203a95e@nvidia.com>
On Mon, 6 Apr 2026 19:31:03 +0300 Mark Bloch wrote:
> On 06/04/2026 18:43, Jakub Kicinski wrote:
> > On Sun, 5 Apr 2026 08:08:06 +0200 Dragos Tatulea wrote:
> >> sashiko says:
> >
> > Thanks a lot for reviewing the review! It takes a lot of maintainer time
>
> Just to add some context: we started running Sashiko internally,
> so hopefully trivial issues won’t be missed. I don’t know if
> you remember our on-list discussion from a few weeks ago, following that
> discussion right now we have three different internal AI tools reviewing each
> commit.
>
> At the moment this is still manageable, and I think developers should
> look over all comments from all tools. In our case that currently
> means three review outputs per commit. It would also be useful to have
> some official guidance on what authors are recommended to run before
> posting, so obvious issues can be caught earlier and less reviewer/maintainer
> time is spent on them.
>
> For example:
>
> “Before posting, authors could run a recommended baseline of review tools,
> where available, to catch obvious issues early. During review, tools such
> as review-prompts and Sashiko may be used to assist the reviewer.”
Please send patches if you think something should be mentioned
somewhere. It'd be awesome if y'all participated more in upstream
reviews so that you recommendation could be rooted in what happens
on the list not just what happens within nVidia.
^ permalink raw reply
* Re: [PATCH net-next v6 7/7] net: bcmgenet: reject MTU changes incompatible with XDP
From: Mohsin Bashir @ 2026-04-06 18:30 UTC (permalink / raw)
To: Nicolai Buchwitz, netdev
Cc: Justin Chen, Simon Horman, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Andrew Lunn, Eric Dumazet,
Paolo Abeni, David S. Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, linux-kernel, bpf
In-Reply-To: <20260406083536.839517-8-nb@tipi-net.de>
>
> +static int bcmgenet_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct bcmgenet_priv *priv = netdev_priv(dev);
> +
> + if (priv->xdp_prog && new_mtu > PAGE_SIZE - GENET_RX_HEADROOM -
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) {
> + netdev_warn(dev, "MTU too large for single-page XDP buffer\n");
> + return -EINVAL;
> + }
> +
> + WRITE_ONCE(dev->mtu, new_mtu);
> + return 0;
> +}
> +
> static const struct net_device_ops bcmgenet_netdev_ops = {
> .ndo_open = bcmgenet_open,
> .ndo_stop = bcmgenet_close,
> @@ -4102,6 +4116,7 @@ static const struct net_device_ops bcmgenet_netdev_ops = {
> .ndo_eth_ioctl = phy_do_ioctl_running,
> .ndo_set_features = bcmgenet_set_features,
> .ndo_get_stats64 = bcmgenet_get_stats64,
> + .ndo_change_mtu = bcmgenet_change_mtu,
> .ndo_change_carrier = bcmgenet_change_carrier,
> .ndo_bpf = bcmgenet_xdp,
> .ndo_xdp_xmit = bcmgenet_xdp_xmit,
Reviewed-by: Mohsin Bashir <hmohsin@meta.com>
^ 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