* Re: [PATCH net-next v5] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Minxi Hou @ 2026-07-20 3:24 UTC (permalink / raw)
To: netdev; +Cc: aconole, echaudro, i.maximets, kuba
In-Reply-To: <20260709120541.3556748-1-houminxi@gmail.com>
Gentle ping on this patch. It's been about 10 days without review
comments. Please let me know if there are any issues or if a respin
is needed.
Thanks,
Minxi
^ permalink raw reply
* Re: [PATCH v10] mm/page_alloc: boost watermarks on atomic allocation failure
From: Jing Wu @ 2026-07-20 3:38 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Qiliang Yuan, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, SeongJae Park,
Matthew Wilcox, linux-mm, linux-kernel, netdev
In-Reply-To: <e011c6a8-cda5-42ce-9d42-b23d1c81b26b@suse.cz>
From: Qiliang Yuan <realwujing@gmail.com>
Hi Vlastimil,
Thanks for the review, and understood on taking the Ack back - the
v10 changes were substantial, and I won't send v11 just to drop the
tag. I'm folding it into an actual update instead. Let me answer your
three points directly.
1) The Ack
Yours is dropped. I've kept SeongJae's for now since he hasn't said
anything to the contrary, but I'll understand if he'd rather it not
carry over either, given v11 also fixes a debounce race in the atomic
path that nobody, including me, had caught in nine prior rounds:
last_boost_jiffies was checked and updated outside zone->lock, so
concurrent CPUs (e.g. a multi-queue NIC spreading GFP_ATOMIC
allocations across several softirqs) could all pass the
once-per-second check for the same zone before either updated the
timestamp.
2) Real-world benefit and side effects
I don't have a clean before/after deployment number for this exact
patch yet, and I want to be upfront about that. What I do have: a
production host running a downstream 4.19 kernel logged 144 order-0
GFP_ATOMIC failures over a 4h15m window, every single one through the
same NIC driver RX softirq path (bnxt_rx_pages -> net_rx_action ->
__alloc_pages_slowpath), across several unrelated network-facing
services on the box. That's evidence the failure mode is real and
ongoing - it is not evidence that this patch fixes it, and I don't
want to conflate the two.
On side effects: the mechanism is bounded by construction, not just by
intent. Each zone accepts at most one boost per second (the debounce
timer), and watermark_boost is clamped to _watermark[WMARK_HIGH] / 10
per zone, independent of how many zones get boosted in a single
slowpath call. Worst case this adds one extra kswapd wakeup per zone
per second, and the ceiling on any single zone is 10% of its own high
watermark - it can't run away or starve unrelated allocations past
that. I've put this bound into the commit message itself so it isn't
only visible in this thread.
I know a bound isn't a measurement. If it would actually help, I can
try to build a synthetic reproducer (fault-injected GFP_ATOMIC
pressure under load) and come back with before/after numbers instead
of leaving this as theory - let me know if that's the kind of
evidence that would move this forward for you.
3) netdev
Cc'd this time, along with Matthew Wilcox, who asked for the same
thing on v1 and was never followed up on. Sorry that took ten
versions.
Thanks for staying on this thread.
Qiliang
^ permalink raw reply
* [PATCH] net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds
From: Cen Zhang (Microsoft) @ 2026-07-20 3:45 UTC (permalink / raw)
To: jhs, jiri, davem, edumazet, kuba, pabeni
Cc: horms, netdev, linux-kernel, AutonomousCodeSecurity, tgopinath,
kys, blbllhy
u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char,
0-255) into the kernel knode object without bounds validation. When a
packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates
`ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit
value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior
per C11 §6.5.7, triggerable by an unprivileged user via user/network
namespaces.
UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43
shift exponent 32 is too large for 32-bit type int
Fix this by rejecting offshift >= 16 during filter creation in
u32_change().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
---
net/sched/cls_u32.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 8f30cc82181d..e7a9a49353f9 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -1107,6 +1107,13 @@ static int u32_change(struct net *net, struct sk_buff *in_skb,
goto erridr;
}
+ if (s->flags & TC_U32_VAROFFSET && s->offshift >= 16) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "offshift must be less than 16");
+ err = -EINVAL;
+ goto erridr;
+ }
+
n = kzalloc_flex(*n, sel.keys, s->nkeys);
if (n == NULL) {
err = -ENOBUFS;
--
2.53.0
^ permalink raw reply related
* [PATCH net 1/1] packet: synchronize pressure clearing with ring reconfiguration
From: Ren Wei @ 2026-07-20 5:16 UTC (permalink / raw)
To: netdev
Cc: willemdebruijn.kernel, davem, edumazet, pabeni, horms, vega,
xizh2024, enjou1224z
In-Reply-To: <cover.1784454541.git.xizh2024@lzu.edu.cn>
From: Zihan Xi <xizh2024@lzu.edu.cn>
packet_set_ring() updates the RX ring state under sk_receive_queue.lock,
but publishes the tpacket receive mode through po->prot_hook.func after
releasing that lock. packet_poll() and packet_recvmsg() can therefore run
the pressure clearing path after the ring has been cleared while still
seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale
or NULL ring storage.
Serialize pressure clearing with RX ring reconfiguration and update the
receive hook while holding the same queue lock when changing the RX ring.
This keeps the receive hook decision consistent with the ring state used
by the tpacket room checks.
Fixes: 2ccdbaa6d55b ("packet: rollover lock contention avoidance")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
---
net/packet/af_packet.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8e6f3a734ba0..b369f44b4065 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1315,13 +1315,22 @@ static int packet_rcv_has_room(struct packet_sock *po, struct sk_buff *skb)
return ret;
}
-static void packet_rcv_try_clear_pressure(struct packet_sock *po)
+static void __packet_rcv_try_clear_pressure(struct packet_sock *po)
{
if (packet_sock_flag(po, PACKET_SOCK_PRESSURE) &&
__packet_rcv_has_room(po, NULL) == ROOM_NORMAL)
packet_sock_flag_set(po, PACKET_SOCK_PRESSURE, false);
}
+static void packet_rcv_try_clear_pressure(struct packet_sock *po)
+{
+ struct sock *sk = &po->sk;
+
+ spin_lock_bh(&sk->sk_receive_queue.lock);
+ __packet_rcv_try_clear_pressure(po);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
+}
+
static void packet_sock_destruct(struct sock *sk)
{
skb_queue_purge(&sk->sk_error_queue);
@@ -4304,7 +4313,7 @@ static __poll_t packet_poll(struct file *file, struct socket *sock,
TP_STATUS_KERNEL))
mask |= EPOLLIN | EPOLLRDNORM;
}
- packet_rcv_try_clear_pressure(po);
+ __packet_rcv_try_clear_pressure(po);
spin_unlock_bh(&sk->sk_receive_queue.lock);
spin_lock_bh(&sk->sk_write_queue.lock);
if (po->tx_ring.pg_vec) {
@@ -4544,14 +4553,15 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
rb->frame_max = (req->tp_frame_nr - 1);
rb->head = 0;
rb->frame_size = req->tp_frame_size;
+ if (!tx_ring)
+ po->prot_hook.func = po->rx_ring.pg_vec ?
+ tpacket_rcv : packet_rcv;
spin_unlock_bh(&rb_queue->lock);
swap(rb->pg_vec_order, order);
swap(rb->pg_vec_len, req->tp_block_nr);
rb->pg_vec_pages = req->tp_block_size/PAGE_SIZE;
- po->prot_hook.func = (po->rx_ring.pg_vec) ?
- tpacket_rcv : packet_rcv;
skb_queue_purge(rb_queue);
if (atomic_long_read(&po->mapped))
pr_err("packet_mmap: vma is busy: %ld\n",
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next 00/15] net/mlx5e: PSP cleanups and improvements
From: Tariq Toukan @ 2026-07-20 6:05 UTC (permalink / raw)
To: Tariq Toukan, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, netdev, Paolo Abeni
Cc: Aleksandr Loktionov, Boris Pismenny, Chris Mi, Cosmin Ratiu,
Daniel Zahka, Dragos Tatulea, Gal Pressman, Jacob Keller,
Jianbo Liu, Lama Kayal, Leon Romanovsky, linux-kernel, linux-rdma,
Mark Bloch, Raed Salem, Rahul Rameshbabu, Saeed Mahameed,
Stanislav Fomichev, Stanislav Fomichev, Willem de Bruijn
In-Reply-To: <20260707130858.969928-1-tariqt@nvidia.com>
On 07/07/2026 16:08, Tariq Toukan wrote:
> Hi,
>
> This series by Cosmin refactors mlx5 PSP support in preparation for
> HW-GRO support.
> There are almost no functionality changes in all but the last two
> patches, which address a long-standing TODO in mlx5e_psp_set_config().
>
> Regards,
> Tariq
>
> Cosmin Ratiu (15):
> net/mlx5e: psp: Rename the saved psp_dev to 'psd'
> net/mlx5e: psp: Remove PSP steering mutexes
> net/mlx5e: psp: Remove unneeded ref counting for PSP steering
> net/mlx5e: psp: Merge rx_err rule add/delete with ft create/delete
> net/mlx5e: psp: Use helpers for steering object manipulation
> net/mlx5e: psp: Factor out drop rule creation code
> net/mlx5e: psp: Remove unused PSP syndrome copy action
> net/mlx5e: psp: Rename and consolidate steering functions
> net/mlx5e: psp: Adjust rx_check FT size and use a drop_group
> net/mlx5e: psp: Add an RX steering table
> net/mlx5e: psp: Use a single rx_check table
> net/mlx5e: psp: Flatten steering structures
> net/mlx5e: psp: Make PSP steering config dynamic
> net/mlx5e: Return errors from profile->enable
> net/mlx5e: psp: Report PSP dev registration errors
>
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
> .../net/ethernet/mellanox/mlx5/core/en/fs.h | 7 +-
> .../mellanox/mlx5/core/en_accel/en_accel.h | 19 +-
> .../mellanox/mlx5/core/en_accel/psp.c | 1007 ++++++++---------
> .../mellanox/mlx5/core/en_accel/psp.h | 18 +-
> .../mellanox/mlx5/core/en_accel/psp_rxtx.c | 13 +-
> .../mellanox/mlx5/core/en_accel/psp_rxtx.h | 3 +-
> .../net/ethernet/mellanox/mlx5/core/en_main.c | 23 +-
> .../net/ethernet/mellanox/mlx5/core/en_rep.c | 8 +-
> 9 files changed, 516 insertions(+), 584 deletions(-)
>
>
> base-commit: 31816fc5d9acf8cdf226cdd0dc296e8cf15cc033
Hi,
It's been in-flight (still marked New) for ~2 weeks, and is blocking our
queue...
I don't see it tracked in Suie anymore...
All comments in the thread were answered, no changes required for now.
How do we progress with this series?
^ permalink raw reply
* [PATCH net 0/1] tipc: avoid UAF in trace queue dumps
From: Ren Wei @ 2026-07-20 6:45 UTC (permalink / raw)
To: netdev, tipc-discussion
Cc: jmaloy, davem, edumazet, pabeni, horms, ying.xue, tuong.t.lien,
vega, xizh2024, enjou1224z
From: Zihan Xi <xizh2024@lzu.edu.cn>
Hi Linux kernel maintainers,
We found and validated a bug in net/tipc/trace.c and net/tipc/socket.c.
The bug is reachable by a local process that can create TIPC sockets and
enable TIPC tracepoints. We've tested the fix with the reproducer below,
and it should not affect any other functionality.
This series contains one patch:
1/1 tipc: stop socket trace dumps from dereferencing live skb queues
We provide bug details, reproducer steps, and a crash log below.
---- details below ----
Bug details:
tipc_sk_dump() is used by TIPC socket tracepoints, including the poll trace
path. With TIPC_DUMP_ALL it asks tipc_list_dump() to print the socket write
and receive queues, and it also prints the socket backlog head and tail by
passing sk->sk_backlog.head/tail directly to tipc_skb_dump().
These are live socket queues. The trace helper does not have a reliable skb
lifetime guarantee for every queue member it inspects: TIPC socket queues are
serialized by socket or other outer locks, and not all lists use the embedded
sk_buff_head lock as the mutator lock. A concurrent dequeue/free can
therefore leave the trace helper dereferencing a stale skb pointer.
The patch keeps the tracepoint ABI and buffer sizing intact, but makes the
socket trace dump report only the write queue, receive queue, and backlog
lengths. This removes the unsafe skb dereferences from the trace path.
Reproducer:
Guest:
gcc -O2 -pthread -Wall /root/tipc_poc.c -o /root/tipc_poc
mount -t tracefs nodev /sys/kernel/tracing 2>/dev/null || true
tipc node set identity 1.1.1
timeout 30s /root/tipc_poc
Host:
make O=/var/cache/linux-patch/tipc-list-dump-build-ext4 -j$(nproc) bzImage
We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.
------BEGIN poc.c------
#define _GNU_SOURCE
#include <arpa/inet.h>
#include <errno.h>
#include <fcntl.h>
#include <linux/tipc.h>
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#define TRACE "/sys/kernel/tracing"
#define TIPC_TYPE 5555
static volatile int stop_flag;
static int srv_fd, cli_fd;
static void write_file(const char *path, const char *s)
{
int fd = open(path, O_WRONLY | O_TRUNC);
if (fd < 0) { perror(path); exit(1); }
if (write(fd, s, strlen(s)) < 0) { perror("write"); exit(1); }
close(fd);
}
static void enable_trace(void)
{
char path[256];
write_file(TRACE "/tracing_on", "0\n");
write_file(TRACE "/trace", "");
const char *evs[] = {"tipc_sk_poll", "tipc_sk_filter_rcv", "tipc_sk_overlimit1", "tipc_sk_overlimit2"};
for (int i = 0; i < 4; i++) {
snprintf(path, sizeof(path), TRACE "/events/tipc/%s/enable", evs[i]);
write_file(path, "1\n");
}
write_file(TRACE "/tracing_on", "1\n");
}
static void *sender(void *arg)
{
char payload[4096];
long cnt = 0;
memset(payload, 'A', sizeof(payload));
struct sockaddr_tipc dst = {0};
dst.family = AF_TIPC;
dst.addrtype = TIPC_SERVICE_ADDR;
dst.scope = TIPC_CLUSTER_SCOPE;
dst.addr.name.name.type = TIPC_TYPE;
dst.addr.name.name.instance = 1;
dst.addr.name.domain = 0;
while (!stop_flag) {
if (sendto(cli_fd, payload, sizeof(payload), 0, (struct sockaddr *)&dst, sizeof(dst)) >= 0)
cnt++;
}
printf("sent %ld\n", cnt);
return NULL;
}
static void *poller(void *arg)
{
struct pollfd pfd = {.fd = srv_fd, .events = POLLIN};
long cnt = 0;
while (!stop_flag) {
poll(&pfd, 1, 0);
cnt++;
}
printf("poll %ld\n", cnt);
return NULL;
}
static void *receiver(void *arg)
{
char buf[4096];
long cnt = 0;
fcntl(srv_fd, F_SETFL, fcntl(srv_fd, F_GETFL) | O_NONBLOCK);
while (!stop_flag) {
ssize_t n = recv(srv_fd, buf, sizeof(buf), 0);
if (n > 0) cnt++;
else if (n < 0 && errno != EAGAIN && errno != EWOULDBLOCK) {}
}
printf("recv %ld\n", cnt);
return NULL;
}
int main(void)
{
enable_trace();
srv_fd = socket(AF_TIPC, SOCK_RDM, 0);
if (srv_fd < 0) { perror("socket srv"); return 1; }
int rcvbuf = 1 << 20;
setsockopt(srv_fd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));
struct sockaddr_tipc srv = {0};
srv.family = AF_TIPC;
srv.addrtype = TIPC_SERVICE_RANGE;
srv.scope = TIPC_CLUSTER_SCOPE;
srv.addr.nameseq.type = TIPC_TYPE;
srv.addr.nameseq.lower = 1;
srv.addr.nameseq.upper = 1;
if (bind(srv_fd, (struct sockaddr *)&srv, sizeof(srv)) < 0) { perror("bind"); return 1; }
struct sockaddr_tipc name = {0};
socklen_t namelen = sizeof(name);
if (getsockname(srv_fd, (struct sockaddr *)&name, &namelen) < 0) { perror("getsockname"); return 1; }
unsigned int portid = name.addr.id.ref;
printf("server portid %u\n", portid);
char filter[128];
snprintf(filter, sizeof(filter), "%u 0 0 0 0\n", portid);
write_file("/proc/sys/net/tipc/sk_filter", filter);
cli_fd = socket(AF_TIPC, SOCK_RDM, 0);
if (cli_fd < 0) { perror("socket cli"); return 1; }
int imp = TIPC_CRITICAL_IMPORTANCE;
setsockopt(cli_fd, SOL_TIPC, TIPC_IMPORTANCE, &imp, sizeof(imp));
pthread_t th[3];
pthread_create(&th[0], NULL, sender, NULL);
pthread_create(&th[1], NULL, poller, NULL);
pthread_create(&th[2], NULL, receiver, NULL);
sleep(5);
stop_flag = 1;
for (int i = 0; i < 3; i++) pthread_join(th[i], NULL);
system("tail -80 /sys/kernel/tracing/trace");
return 0;
}
------END poc.c--------
----BEGIN crash log----
[ 282.625215][ T9764] page_owner tracks the page as allocated
[ 282.626124][ T9764] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9763, tgid 9760 (python3), ts 282622559122, free_ts 280322580853
[ 282.628916][ T9764] page last free pid 9750 tgid 9750 stack trace:
[ 282.630090][ T9764] Kernel panic - not syncing: KASAN: panic_on_warn set ...
[ 282.631030][ T9764] CPU: 1 UID: 0 PID: 9764 Comm: python3 Not tainted 7.1.0-rc2 #10 PREEMPT(full)
[ 282.632219][ T9764] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 282.633618][ T9764] Call Trace:
[ 282.634056][ T9764] <TASK>
[ 282.634440][ T9764] vpanic+0x6c3/0x790
[ 282.634974][ T9764] ? __pfx_vpanic+0x10/0x10
[ 282.635573][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.636323][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.637064][ T9764] ? irqentry_exit+0x24d/0x830
[ 282.637683][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.638419][ T9764] ? lockdep_hardirqs_on+0x7b/0x110
[ 282.639112][ T9764] ? tipc_skb_dump+0x14a4/0x14d0
[ 282.639756][ T9764] panic+0xca/0xd0
[ 282.640261][ T9764] ? __pfx_panic+0x10/0x10
[ 282.640855][ T9764] check_panic_on_warn+0x61/0x80
[ 282.641542][ T9764] end_report+0x13e/0x180
[ 282.642133][ T9764] kasan_report+0xf4/0x120
[ 282.642764][ T9764] ? tipc_skb_dump+0x14a4/0x14d0
[ 282.643600][ T9764] tipc_skb_dump+0x14a4/0x14d0
[ 282.644400][ T9764] tipc_list_dump+0x1b6/0x2a0
[ 282.645093][ T9764] tipc_sk_dump+0xa92/0xcc0
[ 282.645700][ T9764] ? trace_event_buffer_reserve+0x150/0x300
[ 282.646510][ T9764] trace_event_raw_event_tipc_sk_class+0x2c1/0x490
[ 282.647402][ T9764] ? __pfx_trace_event_raw_event_tipc_sk_class+0x10/0x10
[ 282.648345][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.649114][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.649884][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.650654][ T9764] ? __pfx_tipc_poll+0x10/0x10
[ 282.651310][ T9764] tipc_poll+0x290/0x590
[ 282.651895][ T9764] sock_poll+0x134/0x490
[ 282.652492][ T9764] do_sys_poll+0x507/0xbf0
[ 282.653113][ T9764] ? __pfx_do_sys_poll+0x10/0x10
[ 282.653829][ T9764] ? do_raw_spin_lock+0x12d/0x270
[ 282.654597][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.655369][ T9764] ? do_futex+0x1cd/0x230
[ 282.655977][ T9764] ? __pfx_do_futex+0x10/0x10
[ 282.656614][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.657381][ T9764] __x64_sys_poll+0x181/0x3e0
[ 282.658035][ T9764] ? __pfx___x64_sys_poll+0x10/0x10
[ 282.658745][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.659515][ T9764] ? rcu_is_watching+0x12/0xc0
[ 282.660208][ T9764] do_syscall_64+0x116/0xf80
[ 282.660823][ T9764] ? irqentry_exit+0x117/0x830
[ 282.661476][ T9764] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 282.662266][ T9764] RIP: 0033:0x7f332e77d9ee
[ 282.662861][ T9764] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
[ 282.664714][ T9764] RSP: 002b:00007f332d6fdb58 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
[ 282.665298][ T9764] RAX: ffffffffffffffda RBX: 00007f332d6fe6c0 RCX: 00007f332e77d9ee
[ 282.665838][ T9764] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007f332e604450
[ 282.666442][ T9764] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 282.666986][ T9764] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f332e1834c0
[ 282.667563][ T9764] R13: 000000000c939210 R14: 00007f332d6fe640 R15: 00007f332e19af10
[ 282.668176][ T9764] </TASK>
[ 282.669068][ T9764] Kernel Offset: disabled
[ 282.669366][ T9764] Rebooting in 86400 seconds..
-----END crash log-----
Best regards,
Zihan Xi
Zihan Xi (1):
tipc: avoid use-after-free in trace queue dumps
net/tipc/socket.c | 12 +++---------
net/tipc/trace.c | 44 +++++---------------------------------------
2 files changed, 8 insertions(+), 48 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net 1/1] tipc: avoid use-after-free in trace queue dumps
From: Ren Wei @ 2026-07-20 6:45 UTC (permalink / raw)
To: netdev, tipc-discussion
Cc: jmaloy, davem, edumazet, pabeni, horms, ying.xue, tuong.t.lien,
vega, xizh2024, enjou1224z
In-Reply-To: <cover.1784443039.git.xizh2024@lzu.edu.cn>
From: Zihan Xi <xizh2024@lzu.edu.cn>
TIPC trace helpers can dump live socket queues from contexts such as
poll(). tipc_list_dump() walks the write and receive skb queues and dumps
the head, tail or selected skb entries, while tipc_sk_dump() also dumps the
socket backlog head and tail directly.
Those trace paths do not have a reliable skb lifetime guarantee for every
queue they inspect. TIPC socket queues are serialized by socket or other
outer locks, and not all skb lists use the embedded sk_buff_head lock
as the mutator lock. A concurrent dequeue/free can therefore leave the
trace helper dereferencing a stale skb pointer.
Avoid dereferencing queue members from the socket trace dump path. Keep the
trace ABI and buffer sizing unchanged, but report only queue lengths
for the write queue, receive queue, and backlog. This preserves useful
queue state in trace output without pretending that the trace helper can
safely pin or walk all caller-provided lists.
Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
---
net/tipc/socket.c | 12 +++---------
net/tipc/trace.c | 44 +++++---------------------------------------
2 files changed, 8 insertions(+), 48 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e564341e0216..4b9eb0b401fe 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -4000,15 +4000,9 @@ int tipc_sk_dump(struct sock *sk, u16 dqueues, char *buf)
i += tipc_list_dump(&sk->sk_receive_queue, false, buf + i);
}
- if (dqueues & TIPC_DUMP_SK_BKLGQ) {
- i += scnprintf(buf + i, sz - i, "sk_backlog:\n head ");
- i += tipc_skb_dump(sk->sk_backlog.head, false, buf + i);
- if (sk->sk_backlog.tail != sk->sk_backlog.head) {
- i += scnprintf(buf + i, sz - i, " tail ");
- i += tipc_skb_dump(sk->sk_backlog.tail, false,
- buf + i);
- }
- }
+ if (dqueues & TIPC_DUMP_SK_BKLGQ)
+ i += scnprintf(buf + i, sz - i, "sk_backlog: len = %d\n",
+ READ_ONCE(sk->sk_backlog.len));
return i;
}
diff --git a/net/tipc/trace.c b/net/tipc/trace.c
index 7d2931521e0e..399538d0a369 100644
--- a/net/tipc/trace.c
+++ b/net/tipc/trace.c
@@ -158,49 +158,15 @@ int tipc_skb_dump(struct sk_buff *skb, bool more, char *buf)
/**
* tipc_list_dump - dump TIPC skb list/queue
* @list: list of skbs to be dumped
- * @more: dump more?
- * - false: dump only the head & tail skbs
- * - true: dump the first & last 5 skbs
+ * @more: unused; kept for tracepoint ABI compatibility
* @buf: returned buffer of dump data in format
*/
int tipc_list_dump(struct sk_buff_head *list, bool more, char *buf)
{
- int i = 0;
- size_t sz = (more) ? LIST_LMAX : LIST_LMIN;
- u32 count, len;
- struct sk_buff *hskb, *tskb, *skb, *tmp;
-
- if (!list) {
- i += scnprintf(buf, sz, "(null)\n");
- return i;
- }
+ size_t sz = more ? LIST_LMAX : LIST_LMIN;
- len = skb_queue_len(list);
- i += scnprintf(buf, sz, "len = %d\n", len);
+ if (!list)
+ return scnprintf(buf, sz, "(null)\n");
- if (!len)
- return i;
-
- if (!more) {
- hskb = skb_peek(list);
- i += scnprintf(buf + i, sz - i, " head ");
- i += tipc_skb_dump(hskb, false, buf + i);
- if (len > 1) {
- tskb = skb_peek_tail(list);
- i += scnprintf(buf + i, sz - i, " tail ");
- i += tipc_skb_dump(tskb, false, buf + i);
- }
- } else {
- count = 0;
- skb_queue_walk_safe(list, skb, tmp) {
- count++;
- if (count == 6)
- i += scnprintf(buf + i, sz - i, " .\n .\n");
- if (count > 5 && count <= len - 5)
- continue;
- i += scnprintf(buf + i, sz - i, " #%d ", count);
- i += tipc_skb_dump(skb, false, buf + i);
- }
- }
- return i;
+ return scnprintf(buf, sz, "len = %u\n", skb_queue_len_lockless(list));
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net 1/1] openvswitch: Fix CT limit teardown use-after-free
From: Yuan Tan @ 2026-07-20 6:54 UTC (permalink / raw)
To: Andrew Lunn, Ren Wei, xuyuqiabc
Cc: netdev, dev, aconole, echaudro, i.maximets, davem, edumazet,
pabeni, horms, pshelar, yihung.wei, tonanli66, xuyuqiabc
In-Reply-To: <c357f846-d42c-4b98-acc9-46b751818dca@lunn.ch>
On 7/19/26 19:52, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 10:14:16AM +0800, Ren Wei wrote:
>> From: Yuqi Xu <xuyuqiabc@gmail.com>
>>
>> Packet processing uses CT limit state under RCU, while netns teardown
>> frees that state under ovs_mutex. The CT limit pointer was neither removed
>> from readers nor protected by a grace period, allowing packet processing to
>> dereference the freed state.
>>
>> Replace the pointer before freeing the CT limit state. Wait for in-flight
>> RCU readers before freeing its contents. Serialize CT limit netlink
>> operations with teardown for the full lifetime of their state accesses.
>>
>> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
>> Cc: stable@vger.kernel.org
>> Reported-by: Vega <vega@nebusec.ai>
> Is Vega a person?
Hi Andrew,
Thank you very much for your review!
For context, we had previously understood that using the tool name in
the Reported-by tag was acceptable, based on examples such as
Reported-by: AutonomousCodeSecurity@microsoft.com and Reported-by:
Anthropic.
https://lore.kernel.org/all/20260630171016.11c02dec@kernel.org/
Of course, we’re happy to adjust it if a different format is preferred.
>> Assisted-by: Codex:GPT-5.4
>> Co-developed-by: Nan Li <tonanli66@gmail.com>
>> Signed-off-by: Nan Li <tonanli66@gmail.com>
>> Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
>> Reviewed-by: Ren Wei <enjou1224z@gmail.com>
> Please take a look at
> https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> and the sections that follow. What is listed here does not follow the
> rules.
>
>> @@ -932,11 +932,15 @@ static int ovs_ct_check_limit(struct net *net,
>> const struct sk_buff *skb,
>> const struct ovs_conntrack_info *info)
>> {
>> + const struct ovs_ct_limit_info *ct_limit_info;
>> struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
>> - const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
>> u32 per_zone_limit, connections;
>> u32 conncount_key;
> Reverse Christmas tree. The lines should be sorted longest to
> shortest. Yes, it was already wrong, but you can actually fix it here.
> Andrew
>
> ---
> pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v7 0/2] net: libwx: improve VF ethtool support
From: mengyuanlou @ 2026-07-20 6:59 UTC (permalink / raw)
To: netdev; +Cc: jiawenwu, duanqiangwen, horms, kuba, pabeni
In-Reply-To: <20260710015925.34769-1-mengyuanlou@net-swift.com>
Hi,
Gentle ping.
Any comments on this series would be appreciated.
Thanks.
> 2026年7月10日 09:59，Mengyuan Lou <mengyuanlou@net-swift.com> 写道：
>
> This series improves ethtool support for Wangxun VF drivers
> (ngbevf and txgbevf) in libwx.
>
> This series extends VF support by enabling:
> ring parameter configuration via ethtool -G
> interrupt coalescing configuration via ethtool -C
>
> Patch 1 adds support for set_ringparam in wx_ethtool_ops_vf,
> allowing VF users to adjust TX/RX descriptor ring sizes.
> Patch 2 enables set_coalesce support for VF devices and updates
> EITR programming to use the VF-specific register access helper.
>
> Changelog:
> v7:
> - Remove patch3 and netdev_stat_ops support is deferred to a follow-up patch.
> v6: https://lore.kernel.org/all/20260701100145.23738-1-mengyuanlou@net-swift.com/
> - Patch 1:
> Clarify comments describing wx_set_ring() failure semantics.
> - Patch 2:
> Expand commit message to explain VF ITR encoding changes.
> - Patch 3:
> Protect ring accesses in wx_update_stats().
> v5: https://lore.kernel.org/all/20260615104849.60444-1-mengyuanlou@net-swift.com
> - Patch 3:
> Convert WX_NUM_{RX,TX}_QUEUES macros to take explicit netdev parameter
> as suggested by Simon Horman.
> v4: https://lore.kernel.org/all/20260608103946.25786-1-mengyuanlou@net-swift.com
> sashiko: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260529075147.88398-1-mengyuanlou%40net-swift.com
> - Patch 2:
> PF and VF share the same ITR value range. Update wx_write_eitr_vf() to apply
> identical range clamping as the PF path, ensuring consistent coalesce behavior
> across both device types.
> - Patch 3:
> Remove wx_update_stats in wxvf_down.
> Replace both WX_GLOBAL_STATS_LEN and WX_STATS_LEN macros with type-safe
> static helpers wx_global_stats_len() and wx_stats_len().
> v3: https://lore.kernel.org/all/20260529075147.88398-1-mengyuanlou@net-swift.com
> - Patch 3:
> Drop netdev_stat_ops support from this patch.
> v2: https://lore.kernel.org/all/20260525101115.13151-1-mengyuanlou@net-swift.com
> - Patch 3:
> Remove some stats which can be replaced by standard stats defined in
> include/net/netdev_queues.h.
> - Patch 1:
> Adding a return value to wx_set_ring to make wx_set_ringparam_vf can
> be passed back to userspace.
> Remove freeing and requesting of IRQs. Ring resize only updates descriptor
> resources and does not change MSI-X vector or interrupt configuration,
> so IRQs do not need to be reallocated.
> v1: https://lore.kernel.org/all/20260514103405.42175-1-mengyuanlou@net-swift.com
>
> Mengyuan Lou (2):
> net: libwx: add support for set_ringparam in wx_ethtool_ops_vf
> net: libwx: add support for set_coalesce in wx_ethtool_ops_vf
>
> .../net/ethernet/wangxun/libwx/wx_ethtool.c | 68 ++++++++++++++++++-
> drivers/net/ethernet/wangxun/libwx/wx_lib.c | 9 +--
> drivers/net/ethernet/wangxun/libwx/wx_lib.h | 4 +-
> drivers/net/ethernet/wangxun/libwx/wx_vf.h | 1 -
> .../net/ethernet/wangxun/libwx/wx_vf_common.c | 4 +-
> .../net/ethernet/wangxun/libwx/wx_vf_common.h | 2 +
> .../net/ethernet/wangxun/libwx/wx_vf_lib.c | 13 +++-
> 7 files changed, 90 insertions(+), 11 deletions(-)
>
> --
> 2.30.1
>
^ permalink raw reply
* [PATCH net v3] phonet: check register_netdevice_notifier() error in phonet_device_init()
From: Minhong He @ 2026-07-20 7:00 UTC (permalink / raw)
To: courmisch, davem, edumazet, kuba, pabeni, horms,
remi.denis-courmont
Cc: netdev, linux-kernel, Minhong He
phonet_device_init() registers a netdevice notifier before calling
phonet_netlink_register(), but does not check whether notifier
registration succeeded. On failure, netlink setup still proceeds and
init may return success without the notifier in place.
Also, the existing phonet_netlink_register() failure path called
phonet_device_exit(), which runs rtnl_unregister_all() even though
rtnl_register_many() already unwound any partial registration. Calling
the full exit helper on a partial init is not correct.
Check each registration error and unwind only the steps that have
succeeded so far.
Signed-off-by: Minhong He <heminhong@kylinos.cn>
---
v3:
- Use goto-based unwind; do not call phonet_device_exit() on
phonet_netlink_register() failure (avoids rtnl_unregister_all()
after rtnl_register_many() already unwound).
- Drop Fixes tag (theoretical init failure path; not suitable for
stable autosel).
v2: https://lore.kernel.org/netdev/20260716101504.158387-1-heminhong@kylinos.cn/
- On notifier registration failure, unwind only proc/pernet.
v1: https://lore.kernel.org/netdev/20260713075212.431455-1-heminhong@kylinos.cn/
net/phonet/pn_dev.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index ad44831d6745..f41322a12fb7 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -350,16 +350,30 @@ static struct pernet_operations phonet_net_ops = {
/* Initialize Phonet devices list */
int __init phonet_device_init(void)
{
- int err = register_pernet_subsys(&phonet_net_ops);
+ int err;
+
+ err = register_pernet_subsys(&phonet_net_ops);
if (err)
return err;
proc_create_net("pnresource", 0, init_net.proc_net, &pn_res_seq_ops,
sizeof(struct seq_net_private));
- register_netdevice_notifier(&phonet_device_notifier);
+
+ err = register_netdevice_notifier(&phonet_device_notifier);
+ if (err)
+ goto err_pernet;
+
err = phonet_netlink_register();
if (err)
- phonet_device_exit();
+ goto err_notifier;
+
+ return 0;
+
+err_notifier:
+ unregister_netdevice_notifier(&phonet_device_notifier);
+err_pernet:
+ unregister_pernet_subsys(&phonet_net_ops);
+ remove_proc_entry("pnresource", init_net.proc_net);
return err;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] af_unix: Schedule the garbage collector at task exit
From: Nam Cao @ 2026-07-20 7:16 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel
In-Reply-To: <20260718062736.199E41F000E9@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: Medium]
> Will this race with concurrent task exits and leak cyclic sockets?
>
> In net/unix/garbage.c, unix_schedule_gc() only queues the work if a garbage
> collection is not already running:
>
> void unix_schedule_gc(void)
> {
> if (!READ_ONCE(gc_in_progress))
> queue_work(system_dfl_wq, &unix_gc_work);
> }
>
> If Task A and Task B exit concurrently with dead cyclic sockets:
>
> Task A calls unix_schedule_gc() and triggers the work, which sets
> gc_in_progress to true.
>
> Task B then calls unix_schedule_gc() while the GC is running, observes
> gc_in_progress is true, and silently skips queuing the work.
>
> Task B's newly dead cycles might be missed by the currently running GC pass.
> Since no new GC is queued by Task B, won't those sockets stay behind
> indefinitely until another unrelated task exits, defeating the purpose of
> the patch for concurrent exits?
Yes, this is a pre-existing issue and has been discussed at:
https://lore.kernel.org/lkml/871pde3o54.fsf@yellow.woof/
The solution would be removing gc_in_progress and always calling queue_work().
Since this is not a critical issue, I would fix that after this series
is done.
Nam
^ permalink raw reply
* [PATCH net v3] mctp: check register_netdevice_notifier() error in mctp_device_init()
From: Minhong He @ 2026-07-20 7:25 UTC (permalink / raw)
To: jk, matt, davem, edumazet, kuba, pabeni, horms, kuniyu; +Cc: heminhong, netdev
mctp_device_init() handles errors from rtnl_af_register() and
rtnl_register_many(), but ignores the return value of
register_netdevice_notifier(). If notifier registration fails, init can
still return success while the module is only partially initialized.
Check the notifier registration error and fail module init early.
Fixes: 583be982d934 ("mctp: Add device handling and netlink interface")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
---
v3:
- Correct Fixes tag to 583be982d934 (bug predates d51705614f66).
- No Cc:stable (unlikely init failure path; stable would also need
d51705614f66 as a prereq on older trees).
v2: https://lore.kernel.org/netdev/20260716063534.116793-1-heminhong@kylinos.cn/
v1: https://lore.kernel.org/netdev/20260713073918.419422-1-heminhong@kylinos.cn/
net/mctp/device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mctp/device.c b/net/mctp/device.c
index 2c84df674669..822120e860c8 100644
--- a/net/mctp/device.c
+++ b/net/mctp/device.c
@@ -536,7 +536,9 @@ int __init mctp_device_init(void)
{
int err;
- register_netdevice_notifier(&mctp_dev_nb);
+ err = register_netdevice_notifier(&mctp_dev_nb);
+ if (err)
+ return err;
err = rtnl_af_register(&mctp_af_ops);
if (err)
--
2.25.1
^ permalink raw reply related
* [PATCH net] vlan: fix skb_under_panic() and races when toggling HW VLAN offload
From: Eric Dumazet @ 2026-07-20 7:26 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet, Tangxin Xie
Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(),
which dynamically changes vlandev->hard_header_len.
This causes two issues:
1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)
read dev->hard_header_len without holding RTNL lock. Mutating
hard_header_len dynamically under RTNL creates a data race where upper
layers reserve insufficient headroom based on a stale hard_header_len,
resulting in skb_under_panic when vlan_dev_hard_header() is called.
2. In addition, vlan_transfer_features() updated hard_header_len without
updating header_ops, causing a mismatch between allocated headroom
and header creation.
A VLAN interface may require software VLAN header insertion at any point
(e.g., if reorder_hdr is disabled or HW offload is unavailable). Always
setting hard_header_len = real_dev->hard_header_len + VLAN_HLEN and using
vlan_header_ops unconditionally ensures sufficient headroom is reserved
by all upper layers and avoids any data race on hard_header_len during ETHTOOL
feature changes.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Tangxin Xie <xietangxin@h-partners.com>
Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/8021q/vlan_dev.c | 34 +++-------------------------------
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ec2569b3f8dac629027b4344bc89402decf026d1..acf7f52d1eb2191ec0387dc29e2e9eb34124aa9d 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -502,26 +502,6 @@ static const struct header_ops vlan_header_ops = {
.parse_protocol = vlan_parse_protocol,
};
-static int vlan_passthru_hard_header(struct sk_buff *skb, struct net_device *dev,
- unsigned short type,
- const void *daddr, const void *saddr,
- unsigned int len)
-{
- struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
- struct net_device *real_dev = vlan->real_dev;
-
- if (saddr == NULL)
- saddr = dev->dev_addr;
-
- return dev_hard_header(skb, real_dev, type, daddr, saddr, len);
-}
-
-static const struct header_ops vlan_passthru_header_ops = {
- .create = vlan_passthru_hard_header,
- .parse = eth_header_parse,
- .parse_protocol = vlan_parse_protocol,
-};
-
static const struct device_type vlan_type = {
.name = "vlan",
};
@@ -581,13 +561,8 @@ static int vlan_dev_init(struct net_device *dev)
#endif
dev->needed_headroom = real_dev->needed_headroom;
- if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) {
- dev->header_ops = &vlan_passthru_header_ops;
- dev->hard_header_len = real_dev->hard_header_len;
- } else {
- dev->header_ops = &vlan_header_ops;
- dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
- }
+ dev->header_ops = &vlan_header_ops;
+ dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
dev->netdev_ops = &vlan_netdev_ops;
@@ -1029,10 +1004,7 @@ static void vlan_transfer_features(struct net_device *dev,
netif_inherit_tso_max(vlandev, dev);
- if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
- vlandev->hard_header_len = dev->hard_header_len;
- else
- vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
+ vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
#if IS_ENABLED(CONFIG_FCOE)
vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* Re: [PATCH net-next v2 2/3] af_unix: Do not wait for garbage collector in sendmsg()
From: Nam Cao @ 2026-07-20 7:26 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel,
linux-rt-devel, linux-kernel
In-Reply-To: <20260718062737.8463C1F00A3D@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: High]
> Does removing the unix_schedule_gc() call from unix_prepare_fpl() prevent
> proactive garbage collection of cyclic AF_UNIX file descriptors?
>
> If a long-running application creates a cycle of AF_UNIX sockets and closes
> its own file descriptors to them, the cycle maintains a positive f_count.
> Without this call triggering the garbage collector, the uncollected cyclic
> sockets could accumulate until the application reaches its RLIMIT_NOFILE
> quota, causing subsequent socket operations to fail.
Yes. But an application that creates a huge dead circle of AF_UNIX
sockets is already shady.
And keep scheduling the garbage collector can cause CPU consumption for
nothing, as shown in the v1 thread.
> Additionally, does this change leave the user parameter logic in
> unix_schedule_gc() as dead code?
Yes. That is cleaned up by PATCH 3/3.
Nam
^ permalink raw reply
* Re: [PATCH net v3] gtp: parse extension headers before reading inner protocol
From: Zhixing Chen @ 2026-07-20 7:28 UTC (permalink / raw)
To: Pablo Neira Ayuso, Harald Welte
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, osmocom-net-gprs, netdev
In-Reply-To: <20260708042244.120898-1-running910@gmail.com>
Hi Pablo,
Gentle ping on this v3, in case it fell through the cracks.
It refetches the GTP header after pskb_may_pull() before checking the
extension-header flag, as you pointed out on v2.
Thanks,
Zhixing
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net v2] ice: fix memory leak in ice_lbtest_prepare_rings()
From: Rinitha, SX @ 2026-07-20 7:29 UTC (permalink / raw)
To: Dawei Feng, Nguyen, Anthony L
Cc: Kitszel, Przemyslaw, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jianhao.xu@seu.edu.cn, stable@vger.kernel.org
In-Reply-To: <20260616155742.4052021-1-dawei.feng@seu.edu.cn>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Dawei Feng
> Sent: 16 June 2026 21:28
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; jianhao.xu@seu.edu.cn; Dawei Feng <dawei.feng@seu.edu.cn>; stable@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net v2] ice: fix memory leak in ice_lbtest_prepare_rings()
>
> ice_lbtest_prepare_rings() frees Rx rings only when
> ice_vsi_start_all_rx_rings() fails. If ice_vsi_setup_rx_rings() fails after allocating some descriptors, or if ice_vsi_cfg_lan() fails after the Rx rings were prepared, the function reaches the Tx cleanup path without releasing the initialized Rx resources.
>
> Fix this by adding separate unwind paths for Rx setup failure and LAN configuration failure. The Rx setup failure path releases the partially prepared Rx rings before freeing Tx rings, while later failures first undo the LAN Tx configuration and then release the Rx rings in reverse setup order.
>
> The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have an Intel E800 Series adapter available to run the ethtool offline loopback selftest, no runtime testing was able to be performed.
>
> Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> ---
> Changes in v2:
> - Fix cleanup order
>
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [BUG] vlan: skb_under_panic when toggling NETIF_F_HW_VLAN_CTAG_TX on lower device
From: Eric Dumazet @ 2026-07-20 7:29 UTC (permalink / raw)
To: xietangxin
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, linux-kernel, John Fastabend, Jesse Gross, gaoxingwang1,
huyizhen
In-Reply-To: <d6be3b25-3db3-491c-93d8-7e014427f380@h-partners.com>
On Fri, Jul 17, 2026 at 8:42 AM xietangxin <xietangxin@h-partners.com> wrote:
>
>
> Hi Eric,
>
> Thanks for the suggestion. I tested both parts of your patch locally
> and can confirm the skb_under_panic no longer reproduces.
Excellent, thanks for testing.
>
> your diff is against an older tree. After commit
> cd1c188db109 ("vlan: defer real device state propagation to netdev_work"),
> vlan_transfer_features() has been moved to vlan_dev.c.
Yeah, I had this patch in an old branch, I should have rebased it.
>
> Could you post a formal patch?
Sure thing : https://lore.kernel.org/netdev/20260720072622.3541873-1-edumazet@google.com/T/#u
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] igc: remove napi_synchronize() in igc_down()
From: Ruinskiy, Dima @ 2026-07-20 7:39 UTC (permalink / raw)
To: Maciej Fijalkowski, David Carlier
Cc: intel-wired-lan, netdev, anthony.l.nguyen, przemyslaw.kitszel,
aleksandr.loktionov, advoretsky, stable
In-Reply-To: <alSzCokS7scCoza7@boxer>
On 13/07/2026 12:42, Maciej Fijalkowski wrote:
> On Sun, Jul 12, 2026 at 02:22:42PM +0100, David Carlier wrote:
>> When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
>> torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
>> full budget on every poll, so napi_complete_done() never clears
>> NAPI_STATE_SCHED.
>>
>> igc_down() calls napi_synchronize() before napi_disable(), so it spins
>> forever waiting for that bit and the interface never goes down. Drop the
>> napi_synchronize() and let napi_disable() do the job -- it sets
>> NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
>> ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
>> polling has stopped, matching the recent igb fix b1e067240379.
>>
>> Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy")
>> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: David Carlier <devnexen@gmail.com>
>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>
> This is a mirror of what Alex Dvoretsky did on igb, correct? Did you
> reproduce the same issue on your side or is it a blind shot at this
> driver?
>
> Regardless, I think it's a correct thing to do, but some clarification
> would be nice.
>
>> ---
>> drivers/net/ethernet/intel/igc/igc_main.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
>> index 2c9e2dfd8499..b3883a5a7d7a 100644
>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>> @@ -5352,9 +5352,8 @@ void igc_down(struct igc_adapter *adapter)
>>
>> for (i = 0; i < adapter->num_q_vectors; i++) {
>> if (adapter->q_vector[i]) {
>> - napi_synchronize(&adapter->q_vector[i]->napi);
>> - igc_set_queue_napi(adapter, i, NULL);
>> napi_disable(&adapter->q_vector[i]->napi);
>> + igc_set_queue_napi(adapter, i, NULL);
>> }
>> }
>>
>> --
>> 2.53.0
>>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: at803x: Use a helper to check for phy reset existence
From: patchwork-bot+netdevbpf @ 2026-07-20 7:40 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux, hkallweit1,
netdev, linux-kernel, thomas.petazzoni, linux-arm-msm
In-Reply-To: <20260715101355.88536-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 15 Jul 2026 12:13:54 +0200 you wrote:
> The at803x family of devices are subjected to an errata that requires
> hard-reseting the PHY upon link change.
>
> That can only work if there's a physical reset line wired to the PHY,
> which the driver checks by looking if there's a reset GPIO configured
> for the MDIO device.
>
> [...]
Here is the summary with links:
- [net-next] net: phy: at803x: Use a helper to check for phy reset existence
https://git.kernel.org/netdev/net-next/c/285fd588859f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc()
From: Nam Cao @ 2026-07-20 7:43 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel,
linux-rt-devel, linux-kernel
In-Reply-To: <20260718062736.C97A31F00A3A@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: High]
> Does this call trigger the garbage collector for every exiting task in the
> system?
>
> If an unprivileged user creates a live AF_UNIX cyclic reference and leaves
> them open, while queueing a large number of normal inflight sockets up to
> RLIMIT_NOFILE, the live cycle causes unix_graph_state to persistently be
> UNIX_GRAPH_CYCLIC.
>
> Every task exit would then constantly queue unix_gc_work, which executes
> unix_walk_scc_fast() under the unix_gc_lock spinlock, iterating over all
> inflight sockets:
>
> net/unix/garbage.c:unix_walk_scc_fast() {
> ...
> while (!list_empty(&unix_unvisited_vertices)) {
> ...
> }
>
> Could this O(N) loop iterating over all inflight sockets while holding the
> unix_gc_lock cause severe lock contention and a system-wide performance
> degradation for any AF_UNIX operations like sendmsg and recvmsg that block
> on this lock?
Yes. But this is also a pre-existing issue. An unprivileged user can
already create a huge live circle, and then repeatedly create and close
a AF_UNIX socket which constantly schedules the garbage collector.
Perhaps we should think about a GC scheduling policy. Perhaps like other
garbage collector designs which get scheduled when memory runs low, or
maybe periodic? I can put this on my todo list.
Nam
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v3] ice: fall back to SBQ when LL PHY timer interface times out
From: Rinitha, SX @ 2026-07-20 7:52 UTC (permalink / raw)
To: Korba, Przemyslaw, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw,
Ilichev, Konstantin, Lobakin, Aleksander, Korba, Przemyslaw
In-Reply-To: <20260605120734.1462847-1-przemyslaw.korba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Przemyslaw Korba
> Sent: 05 June 2026 17:36
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Ilichev, Konstantin <konstantin.ilichev@intel.com>; Lobakin, Aleksander <aleksander.lobakin@intel.com>; Korba, Przemyslaw <przemyslaw.korba@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net v3] ice: fall back to SBQ when LL PHY timer interface times out
>
> The low-latency (LL) PHY timer interface relies on a tight, atomic poll of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update / EMPR, FW may need significantly longer than 2ms to start responding to > ATQBAL commands. The first PHY adjust or incval write issued by
> ice_ptp_rebuild_owner() fails with -ETIMEDOUT.
>
>Fix this by falling back to the existing SBQ-based PHY register write path when LL times out. This makes sure PTP is initialized when FW takes longer than expected to come back online.
>
> Steps to reproduce:
> ./nvmupdate64e -if devlink -f
> Update E810 card with nvmupdate64e, and observe dmesg errors:
> Failed to write PHC increment value, status -110
> PTP reset failed, error: -110 (-ETIMEDOUT)
>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net v2] net: erspan: set lltx to avoid sch_direct_xmit deadlock
From: Ido Schimmel @ 2026-07-20 7:53 UTC (permalink / raw)
To: Yun Zhou, edumazet
Cc: dsahern, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel
In-Reply-To: <20260713151435.1815104-1-yun.zhou@windriver.com>
On Mon, Jul 13, 2026 at 11:14:35PM +0800, Yun Zhou wrote:
> erspan_xmit() re-enters the network stack via ip_tunnel_xmit(), causing
> nested acquisition of _xmit_lock on the underlay device while already
> holding the ERSPAN device's _xmit_lock. Both are ARPHRD_ETHER and share
> the same lockdep class, creating an ABBA deadlock:
>
> sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit ->
> ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay]
>
> Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN.
> This is safe as erspan_xmit() has no shared mutable state: o_seqno is
> atomic, stats use atomic_long_inc, and dst_cache is per-CPU. GRETAP,
> the sibling device with identical xmit structure, already sets lltx.
erspan_xmit() (unlike gre_tap_xmit()) is performing non-atomic
__clear_bit() on shared tunnel flags and KCSAN will probably flag it.
Eric had a patch [1] that changes erspan_xmit() to use a private copy of
these flags. I think it's better to wait for Eric's patch to be merged
before setting lltx.
Eric, can you please submit v2 of your patch to net?
Also, doesn't ip6erspan suffer from the same problem? Please try to
reproduce and fix.
[1] https://lore.kernel.org/netdev/20260615140333.3161072-1-edumazet@google.com/
>
> Closes: https://syzkaller.appspot.com/bug?extid=9bda1b9fbb7fbdf9b62b
> Reported-by: syzbot+9bda1b9fbb7fbdf9b62b@syzkaller.appspotmail.com
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> ---
> v2:
> - change subject prefix to [PATCH net]
>
> net/ipv4/ip_gre.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 3efdfb4ffa21..9fbff16cda1d 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1363,6 +1363,8 @@ static int erspan_tunnel_init(struct net_device *dev)
> dev->features |= GRE_FEATURES;
> dev->hw_features |= GRE_FEATURES;
> dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> + /* Skip TX lock: xmit re-enters stack, risking ABBA with underlay */
> + dev->lltx = true;
> netif_keep_dst(dev);
>
> return ip_tunnel_init(dev);
> --
> 2.43.0
>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] igc: remove napi_synchronize() in igc_down()
From: Kadosh, MoriyaX @ 2026-07-20 8:13 UTC (permalink / raw)
To: Ruinskiy, Dima, Maciej Fijalkowski, David Carlier
Cc: intel-wired-lan, netdev, anthony.l.nguyen, przemyslaw.kitszel,
aleksandr.loktionov, advoretsky, stable
In-Reply-To: <c477f099-c365-496a-bb5c-ae8d27d7916f@intel.com>
On 20/07/2026 10:39, Ruinskiy, Dima wrote:
> On 13/07/2026 12:42, Maciej Fijalkowski wrote:
>> On Sun, Jul 12, 2026 at 02:22:42PM +0100, David Carlier wrote:
>>> When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
>>> torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
>>> full budget on every poll, so napi_complete_done() never clears
>>> NAPI_STATE_SCHED.
>>>
>>> igc_down() calls napi_synchronize() before napi_disable(), so it spins
>>> forever waiting for that bit and the interface never goes down. Drop the
>>> napi_synchronize() and let napi_disable() do the job -- it sets
>>> NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
>>> ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
>>> polling has stopped, matching the recent igb fix b1e067240379.
>>>
>>> Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy")
>>> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: David Carlier <devnexen@gmail.com>
>>
>> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>>
>> This is a mirror of what Alex Dvoretsky did on igb, correct? Did you
>> reproduce the same issue on your side or is it a blind shot at this
>> driver?
>>
>> Regardless, I think it's a correct thing to do, but some clarification
>> would be nice.
>>
>>> ---
>>> drivers/net/ethernet/intel/igc/igc_main.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/
>>> ethernet/intel/igc/igc_main.c
>>> index 2c9e2dfd8499..b3883a5a7d7a 100644
>>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>>> @@ -5352,9 +5352,8 @@ void igc_down(struct igc_adapter *adapter)
>>> for (i = 0; i < adapter->num_q_vectors; i++) {
>>> if (adapter->q_vector[i]) {
>>> - napi_synchronize(&adapter->q_vector[i]->napi);
>>> - igc_set_queue_napi(adapter, i, NULL);
>>> napi_disable(&adapter->q_vector[i]->napi);
>>> + igc_set_queue_napi(adapter, i, NULL);
>>> }
>>> }
>>> --
>>> 2.53.0
>>>
> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Tested-by: Moriya Kadosh <moriyax.kadosh@intel.com>
^ permalink raw reply
* [PATCH v11] mm/page_alloc: boost watermarks on atomic allocation failure
From: Qiliang Yuan @ 2026-07-20 8:15 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Brendan Jackman, Johannes Weiner, Zi Yan, Lance Yang,
SeongJae Park, Matthew Wilcox
Cc: netdev, Qiliang Yuan, Jing Wu
Atomic allocations (GFP_ATOMIC) are prone to failure under heavy memory
pressure as they cannot enter direct reclaim.
Handle these failures by introducing a watermark boost mechanism for
atomic requests. Refactor boost_watermark() using an internal helper to
support both fragmentation and atomic paths. Apply zone-proportional
boosts (~0.1% of managed pages) for atomic allocations, while
decoupling it from watermark_boost_factor.
Implement boost_zones_for_atomic() to iterate through and boost all
eligible zones in the zonelist, respecting nodemasks. Use a per-zone
1-second debounce timer via last_boost_jiffies to prevent excessive
boosting. Check and update the debounce timestamp under zone->lock,
alongside the watermark modification, so concurrent callers on other
CPUs cannot all observe a stale timestamp and pile onto the same zone
within the same window. Verify with lockdep. Integrate the mechanism
into the page allocation slowpath specifically for order-0 GFP_ATOMIC
requests.
This approach reuses existing infrastructure and ensures emergency
reserves even if fragmentation boosting is disabled.
The mechanism is bounded by construction. Each zone accepts at most
one boost per second (the debounce timer), and zone->watermark_boost
is clamped to zone->_watermark[WMARK_HIGH] / 10 regardless of how
long the atomic pressure lasts or how many zones are boosted in a
single slowpath call. Worst case, sustained atomic pressure across
all zones in a zonelist adds at most one extra kswapd wakeup per zone
per second, and the boost on any single zone cannot exceed 10% of
that zone's high watermark. It cannot run away or starve unrelated
allocations beyond that ceiling.
This failure signature keeps recurring in production: a host running
a downstream 4.19 kernel logged 144 order-0 GFP_ATOMIC failures over a
4h15m window, all through the same NIC driver receive softirq path,
across several unrelated network-facing services on the box. This
confirms the underlying problem is real and ongoing. It does not by
itself measure this patch's effect, since the fix has not been
deployed on that fleet yet.
Allocation failure logs:
[38535644.718700] node 0: slabs: 1031, objs: 43328, free: 0
[38535644.725059] node 1: slabs: 339, objs: 17616, free: 317
[38535645.428345] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC)
[38535645.436888] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0
[38535645.447664] node 0: slabs: 940, objs: 40864, free: 144
[38535645.454026] node 1: slabs: 322, objs: 19168, free: 383
[38535645.556122] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC)
[38535645.564576] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0
[38535649.655523] warn_alloc: 59 callbacks suppressed
[38535649.655527] swapper/100: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC), nodemask=(null)
[38535649.671692] swapper/100 cpuset=/ mems_allowed=0-1
Signed-off-by: Qiliang Yuan <realwujing@gmail.com>
Signed-off-by: Jing Wu <realwujing@gmail.com>
Acked-by: SeongJae Park <sj@kernel.org>
---
V10 -> V11:
- Fix a debounce race: last_boost_jiffies was checked and updated
outside zone->lock, so concurrent CPUs handling a multi-queue NIC
RX storm could all pass the once-per-second check for the same
zone before either updated the timestamp. Move the check-and-set
under zone->lock alongside the watermark update.
- Add production evidence of the failure signature recurring (see
commit message) in response to Vlastimil's repeated request (v2,
v6, v10) for real-world data on whether this problem is real and
whether the fix helps.
- Drop Vlastimil's Acked-by: he took it back in review of v10,
noting the v10 changes were not trivial. Not resending solely to
drop the tag, per his request; folding it into this update instead.
- Cc netdev and add Matthew Wilcox, per Andrew Morton's (v1, v5) and
Wilcox's (v1) requests to involve the networking maintainers, which
never actually happened in v1-v10.
V9 -> V10:
- Refactor watermark boosting into mechanism (__boost_watermark) and
policy logic.
- Decouple Atomic boost from watermark_boost_factor to ensure
emergency reserves.
- Simplify Atomic boost calculation to ~0.1% of managed pages with a
10% high-WM cap.
- Boost all eligible zones in the zonelist while respecting
nodemasks.
V8 -> V9:
- Use mult_frac() for boost calculation. (SJ)
- Add !can_direct_reclaim check. (Vlastimil)
- Code cleanup: naming, scope, and line limits. (SJ)
- Update tags: Add Vlastimil's Acked-by.
V7 -> V8:
- Use spin_lock_irqsave() to prevent inconsistent lock state
(softirq-on vs in-softirq) as reported by LKP.
V6 -> V7:
- Use local variable for boost_amount to improve code readability.
- Add zone->lock protection in boost_zones_for_atomic().
- Add lockdep assertion in boost_watermark() to prevent locking
mistakes.
- Remove redundant boost call at fail label due to 1-second
debounce.
V5 -> V6:
- Replace magic number ">> 10" with ATOMIC_BOOST_SCALE_SHIFT define.
- Add documentation explaining 0.1% zone size boost rationale.
V4 -> V5:
- Simplify to use native boost_watermark() instead of custom logic.
V3 -> V4:
- Add watermark_scale_boost and gradual decay via balance_pgdat.
V2 -> V3:
- Move debounce timer to per-zone to avoid cross-node interference.
- Optimize candidate zone selection to reduce global reclaim
pressure.
V1 -> V2:
- Add basic debounce logic and scale boosting strength based on zone
size.
v10: https://lore.kernel.org/r/20260214-wujing-mm-page_alloc-v8-v10-1-bdfea431fd97@gmail.com
v9: https://lore.kernel.org/r/20260213-wujing-mm-page_alloc-v8-v9-1-cd99f3a6cb70@gmail.com
v8: https://lore.kernel.org/r/20260212-wujing-mm-page_alloc-v8-v8-1-daba38990cd3@gmail.com
v7: https://lore.kernel.org/all/20260123064231.250767-1-realwujing@gmail.com/
v5: https://lore.kernel.org/all/20260121065740.35616-1-realwujing@gmail.com/
v4: https://lore.kernel.org/all/tencent_D23BFCB69EA088C55AFAF89F926036743E0A@qq.com/
v3: https://lore.kernel.org/all/tencent_44B556221480D8371FBC534ACCF3CE2C8707@qq.com/
v2: https://lore.kernel.org/all/tencent_6FE67BA7BE8376AB038A71ACAD4FF8A90006@qq.com/
v1: https://lore.kernel.org/all/tencent_9DB6637676D639B4B7AEA09CC6A6F9E49D0A@qq.com/
---
include/linux/mmzone.h | 1 +
mm/page_alloc.c | 80 ++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 75ef7c9f9307f..8e37e4e6765b5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -882,6 +882,7 @@ struct zone {
/* zone watermarks, access with *_wmark_pages(zone) macros */
unsigned long _watermark[NR_WMARK];
unsigned long watermark_boost;
+ unsigned long last_boost_jiffies;
unsigned long nr_reserved_highatomic;
unsigned long nr_free_highatomic;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c380f063e8b7b..4517e2c1310ee 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2158,12 +2158,15 @@ bool pageblock_unisolate_and_move_free_pages(struct zone *zone, struct page *pag
#endif /* CONFIG_MEMORY_ISOLATION */
-static inline bool boost_watermark(struct zone *zone)
+/*
+ * Helper for boosting watermarks. Called with zone->lock held.
+ * Use max_boost to limit the boost to a percentage of the high watermark.
+ */
+static inline bool __boost_watermark(struct zone *zone, unsigned long amount,
+ unsigned long max_boost)
{
- unsigned long max_boost;
+ lockdep_assert_held(&zone->lock);
- if (!watermark_boost_factor)
- return false;
/*
* Don't bother in zones that are unlikely to produce results.
* On small machines, including kdump capture kernels running
@@ -2173,9 +2176,6 @@ static inline bool boost_watermark(struct zone *zone)
if ((pageblock_nr_pages * 4) > zone_managed_pages(zone))
return false;
- max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
- watermark_boost_factor, 10000);
-
/*
* high watermark may be uninitialised if fragmentation occurs
* very early in boot so do not boost. We do not fall
@@ -2189,12 +2189,70 @@ static inline bool boost_watermark(struct zone *zone)
max_boost = max(pageblock_nr_pages, max_boost);
- zone->watermark_boost = min(zone->watermark_boost + pageblock_nr_pages,
- max_boost);
+ zone->watermark_boost = min(zone->watermark_boost + amount,
+ max_boost);
return true;
}
+/*
+ * Boost watermarks to increase reclaim pressure when fragmentation occurs
+ * and we fall back to other migratetypes.
+ */
+static inline bool boost_watermark(struct zone *zone)
+{
+ if (!watermark_boost_factor)
+ return false;
+
+ return __boost_watermark(zone, pageblock_nr_pages,
+ mult_frac(zone->_watermark[WMARK_HIGH],
+ watermark_boost_factor, 10000));
+}
+
+/*
+ * Boost watermarks by ~0.1% of zone size on atomic allocation pressure.
+ * This provides zone-proportional safety buffers: ~1MB per 1GB of zone
+ * size. Max boost ceiling is fixed at ~10% of high watermark.
+ *
+ * This emergency reserve is independent of watermark_boost_factor.
+ */
+static inline bool boost_watermark_atomic(struct zone *zone)
+{
+ return __boost_watermark(zone,
+ max(pageblock_nr_pages, zone_managed_pages(zone) / 1000),
+ zone->_watermark[WMARK_HIGH] / 10);
+}
+
+static void boost_zones_for_atomic(struct alloc_context *ac, gfp_t gfp_mask)
+{
+ struct zoneref *z;
+ struct zone *zone;
+ unsigned long now = jiffies;
+
+ for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
+ ac->highest_zoneidx, ac->nodemask) {
+ unsigned long flags;
+ bool should_wake = false;
+
+ /*
+ * Check and update the per-zone debounce timestamp under
+ * zone->lock so concurrent callers on other CPUs (e.g. a
+ * multi-queue NIC spreading GFP_ATOMIC allocations across
+ * several softirqs) cannot all observe a stale timestamp
+ * and pile onto the same zone within the same window.
+ */
+ spin_lock_irqsave(&zone->lock, flags);
+ if (time_after(now, zone->last_boost_jiffies + HZ)) {
+ zone->last_boost_jiffies = now;
+ should_wake = boost_watermark_atomic(zone);
+ }
+ spin_unlock_irqrestore(&zone->lock, flags);
+
+ if (should_wake)
+ wakeup_kswapd(zone, gfp_mask, 0, ac->highest_zoneidx);
+ }
+}
+
/*
* When we are falling back to another migratetype during allocation, should we
* try to claim an entire block to satisfy further allocations, instead of
@@ -4742,6 +4800,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
if (page)
goto got_pg;
+ /* Boost watermarks for atomic requests entering slowpath */
+ if (((gfp_mask & GFP_ATOMIC) == GFP_ATOMIC) && order == 0 && !can_direct_reclaim)
+ boost_zones_for_atomic(ac, gfp_mask);
+
/*
* For costly allocations, try direct compaction first, as it's likely
* that we have enough base pages and don't need to reclaim. For non-
---
base-commit: b54345928fa1dbde534e32ecaa138678fd5d2135
change-id: 20260720-feat-mm-page_alloc-v11-5f415da4aeb0
Best regards,
--
Jing Wu <realwujing@gmail.com>
^ permalink raw reply related
* Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout
From: Stefano Garzarella @ 2026-07-20 8:17 UTC (permalink / raw)
To: Nguyen Dinh Phi
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, syzbot+1b2c9c4a0f8708082678, virtualization, netdev,
linux-kernel
In-Reply-To: <20260719220103.684489-1-phind.uet@gmail.com>
On Mon, Jul 20, 2026 at 05:57:47AM +0800, Nguyen Dinh Phi wrote:
>After vsock_connect() exits the wait loop due to sk->sk_err being
>set, the error was read but not cleared. This left sk->sk_err set
>for subsequent operations.
So, is this a fix? If yes, we should put a Fixes tag.
Also, can you describe how to trigger the issue?
Because I see this in vsock_connect(), so I thought it was in some way
already handled:
/* sk_err might have been set as a result of an earlier
* (failed) connect attempt.
*/
sk->sk_err = 0;
>Switch to sock_error() which atomically reads and clears sk->sk_err,
>so the error is consumed when returned.
>
>Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
>Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Can you explain how this patch fixes that issue?
(this should be the first information to be put in the commit message
IMHO)
I'd like to understand better if this is a fix of real bug or just an
improvement to the code (which is fine by me).
Thanks,
Stefano
>---
> net/vmw_vsock/af_vsock.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 622dbd046799..43eddc33ed12 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1847,14 +1847,11 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
> prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
> }
>
>- if (sk->sk_err) {
>- err = -sk->sk_err;
>+ err = sock_error(sk);
>+ if (err) {
> sk->sk_state = TCP_CLOSE;
> sock->state = SS_UNCONNECTED;
>- } else {
>- err = 0;
> }
>-
> out_wait:
> finish_wait(sk_sleep(sk), &wait);
> out:
>--
>2.53.0
>
^ 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