* Re: [PATCH net v2] net/rds: zero per-item info buffer before handing it to visitors
From: patchwork-bot+netdevbpf @ 2026-04-23 4:10 UTC (permalink / raw)
To: Michael Bommarito
Cc: achender, davem, edumazet, kuba, pabeni, sharath.srinivasan,
horms, netdev, linux-rdma, rds-devel, linux-kernel, stable
In-Reply-To: <20260418141047.3398203-1-michael.bommarito@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 18 Apr 2026 10:10:47 -0400 you wrote:
> rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a
> caller-allocated on-stack u64 buffer to a per-connection visitor and
> then copy the full item_len bytes back to user space via
> rds_info_copy() regardless of how much of the buffer the visitor
> actually wrote.
>
> rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only
> write a subset of their output struct when the underlying
> rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl
> and the two GIDs via explicit memsets). Several u32 fields
> (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size,
> cache_allocs) and the 2-byte alignment hole between sl and
> cache_allocs remain as whatever stack contents preceded the visitor
> call and are then memcpy_to_user()'d out to user space.
>
> [...]
Here is the summary with links:
- [net,v2] net/rds: zero per-item info buffer before handing it to visitors
https://git.kernel.org/netdev/net/c/c88eb7e8d839
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] seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode
From: patchwork-bot+netdevbpf @ 2026-04-23 4:10 UTC (permalink / raw)
To: Andrea Mayer
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, anton.makarov11235,
stefano.salsano, netdev, linux-kernel, stable
In-Reply-To: <20260418162838.31979-1-andrea.mayer@uniroma2.it>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 18 Apr 2026 18:28:38 +0200 you wrote:
> When SEG6_IPTUN_MODE_L2ENCAP_RED (L2ENCAP_RED) was introduced, the
> condition in seg6_build_state() that excludes L2 encap modes from
> setting LWTUNNEL_STATE_OUTPUT_REDIRECT was not updated to account for
> the new mode.
> As a consequence, L2ENCAP_RED routes incorrectly trigger seg6_output()
> on the output path, where the packet is silently dropped because
> skb_mac_header_was_set() fails on L3 packets.
>
> [...]
Here is the summary with links:
- [net] seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode
https://git.kernel.org/netdev/net/c/ade67d5f5888
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] sctp: fix sockets_allocated imbalance after sk_clone()
From: patchwork-bot+netdevbpf @ 2026-04-23 4:10 UTC (permalink / raw)
To: Xin Long
Cc: netdev, linux-sctp, davem, kuba, edumazet, pabeni, horms,
marcelo.leitner, kuniyu
In-Reply-To: <af8d66f928dec3e9fcbee8d4a85b7d5a6b86f515.1776460180.git.lucien.xin@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 17 Apr 2026 17:09:40 -0400 you wrote:
> sk_clone() increments sockets_allocated and sets the socket refcount to 2.
> SCTP performs additional accounting in sctp_clone_sock(), so the clone-time
> increment must be undone to avoid double counting.
>
> Note we cannot simply remove the SCTP-side increment, because the SCTP
> destroy path in sctp_destroy_sock() only decrements sockets_allocated when
> sp->ep is set, which may not be true for all failure paths in
> sctp_clone_sock().
>
> [...]
Here is the summary with links:
- [net] sctp: fix sockets_allocated imbalance after sk_clone()
https://git.kernel.org/netdev/net/c/7c9b012d6367
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] mctp i2c: check packet length before marking flow active
From: Jeremy Kerr @ 2026-04-23 3:47 UTC (permalink / raw)
To: William A. Kennington III, Matt Johnston, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wolfram Sang
Cc: netdev, linux-kernel
In-Reply-To: <20260423001517.79219-1-william@wkennington.com>
Hi William,
> Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
> check to ensure we only transition the flow state if we are actually
> going to proceed with the transmission and locking.
Good catch, thanks!
> Subject: [PATCH] mctp i2c: check packet length before marking flow active
You'll want to indicate that this is for the net tree, rather than
net-next, so something like:
Subject: [PATCH net] net: mctp i2c: check packet length [...]
With that change:
Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
Out of curiosity though, how did you hit the hdr_byte_count mismatch in
the first place?
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH] docs: maintainer-netdev: fix typo in "targeting"
From: patchwork-bot+netdevbpf @ 2026-04-23 3:40 UTC (permalink / raw)
To: Ariful Islam Shoikot; +Cc: netdev, linux-doc, workflows, linux-kernel
In-Reply-To: <20260420114554.1026-1-islamarifulshoikat@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 20 Apr 2026 17:45:53 +0600 you wrote:
> Fix spelling mistake "targgeting" -> "targeting" in
> maintainer-netdev.rst
>
> No functional change.
>
> Signed-off-by: Ariful Islam Shoikot <islamarifulshoikat@gmail.com>
>
> [...]
Here is the summary with links:
- docs: maintainer-netdev: fix typo in "targeting"
https://git.kernel.org/netdev/net/c/645d044d7e5c
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] net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()
From: patchwork-bot+netdevbpf @ 2026-04-23 3:40 UTC (permalink / raw)
To: Bingquan Chen
Cc: willemdebruijn.kernel, gregkh, stephen, security, davem, kuba,
edumazet, netdev
In-Reply-To: <20260418112006.78823-1-patzilla007@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 18 Apr 2026 19:20:06 +0800 you wrote:
> In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points
> directly into the mmap'd TX ring buffer shared with userspace. The
> kernel validates the header via __packet_snd_vnet_parse() but then
> re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent
> userspace thread can modify the vnet_hdr fields between validation
> and use, bypassing all safety checks.
>
> [...]
Here is the summary with links:
- [net] net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()
https://git.kernel.org/netdev/net/c/2c054e17d9d4
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 v1] net: validate skb->napi_id in RX tracepoints
From: patchwork-bot+netdevbpf @ 2026-04-23 3:40 UTC (permalink / raw)
To: Kohei Enju
Cc: netdev, linux-trace-kernel, davem, edumazet, kuba, pabeni, horms,
rostedt, mhiramat, mathieu.desnoyers
In-Reply-To: <20260420105427.162816-1-kohei@enjuk.jp>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 20 Apr 2026 10:54:23 +0000 you wrote:
> Since commit 2bd82484bb4c ("xps: fix xps for stacked devices"),
> skb->napi_id shares storage with sender_cpu. RX tracepoints using
> net_dev_rx_verbose_template read skb->napi_id directly and can therefore
> report sender_cpu values as if they were NAPI IDs.
>
> For example, on the loopback path this can report 1 as napi_id, where 1
> comes from raw_smp_processor_id() + 1 in the XPS path:
>
> [...]
Here is the summary with links:
- [net,v1] net: validate skb->napi_id in RX tracepoints
https://git.kernel.org/netdev/net/c/3bfcf396081a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH bpf 2/2] bpf, netkit: reject offloaded programs on attach
From: Jiayuan Chen @ 2026-04-23 3:36 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Jesper Dangaard Brouer, Toke Høiland-Jørgensen, netdev,
linux-kernel
In-Reply-To: <20260423033609.252464-1-jiayuan.chen@linux.dev>
Same issue as the tcx fix: netkit accepts SCHED_CLS programs but never
checks if they were loaded for hardware offload. If someone loads a
program with prog_ifindex pointing to an offload-capable device and then
attaches it to a netkit peer, the bpf_func is bpf_prog_warn_on_exec()
and the first packet triggers the WARN.
Reject offloaded programs in both netkit_prog_attach() and
netkit_link_attach().
Fixes: 35dfaad7188cd ("netkit, bpf: Add bpf programmable net device")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
drivers/net/netkit.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index 5c0e01396e064..c4f764034c90f 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -533,6 +533,9 @@ int netkit_prog_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = netkit_dev_fetch(current->nsproxy->net_ns, attr->target_ifindex,
attr->attach_type);
@@ -788,6 +791,9 @@ int netkit_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = netkit_dev_fetch(current->nsproxy->net_ns,
attr->link_create.target_ifindex,
--
2.43.0
^ permalink raw reply related
* [PATCH bpf 0/2] bpf: prevent offloaded programs from running on host via tcx/netkit
From: Jiayuan Chen @ 2026-04-23 3:36 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Jesper Dangaard Brouer, Toke Høiland-Jørgensen, netdev,
linux-kernel
Yinhao reported a splat [1] when attaching a BPF program loaded with
prog_ifindex (targeted at an offload-capable device such as netdevsim)
to the software path via BPF_TCX_EGRESS. The program's bpf_func had
already been replaced by bpf_prog_warn_on_exec() during offload compile,
so the first packet that reaches tcx_run() trips the WARN:
[ 19.592982] ------------[ cut here ]------------
[ 19.594654] attempt to execute device eBPF program on the host!
[ 19.594659] WARNING: kernel/bpf/offload.c:420 at 0x0, CPU#0: poc/337
[ 19.599906] Modules linked in:
[ 19.600680] CPU: 0 UID: 0 PID: 337 Comm: poc Not tainted
6.18.0-rc7-next-20251125 #10 PREEMPT(none)
[ 19.601659] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 19.602684] RIP: 0010:bpf_prog_warn_on_exec+0xc/0x20
[ 19.603241] Code: 28 00 48 89 ef e8 74 44 2f 00 eb d7 66 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8d 3d a4 eb 95
06 <67> 48 0f b9 3a 31 c0 e9 83 76 44 ff 0f 1f 84 00 00 00 00 00 90 90
[ 19.605093] RSP: 0018:ffff8881066e73d8 EFLAGS: 00010246
[ 19.605663] RAX: ffffffff81cbca70 RBX: ffff8881013c4210 RCX:
0000000000000004
[ 19.606378] RDX: 1ffff11020278842 RSI: ffffc90000563060 RDI:
ffffffff8861b620
[ 19.607107] RBP: ffff8881010d0640 R08: ffff8881013c4210 R09:
ffff8881010d06b0
[ 19.607827] R10: ffff8881010d06c3 R11: ffffc90000563000 R12:
ffffc90000563000
[ 19.608751] R13: ffff8881010d06b4 R14: ffff888115eb1a34 R15:
dffffc0000000000
[ 19.609478] FS: 000000000294c380(0000) GS:ffff8881911e9000(0000)
knlGS:0000000000000000
[ 19.610316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.610943] CR2: 000057f6b9eb38c0 CR3: 00000001010ea000 CR4:
0000000000750ef0
[ 19.611712] PKRU: 55555554
[ 19.612006] Call Trace:
[ 19.612281] <TASK>
[ 19.612523] __dev_queue_xmit+0x22cb/0x3530
[ 19.617607] ip_finish_output2+0x621/0x1a60
[ 19.621371] ip_output+0x170/0x2e0
[ 19.624586] ip_send_skb+0x129/0x180
[ 19.624940] udp_send_skb+0x65d/0x1300
[ 19.625316] udp_sendmsg+0x13bf/0x2000
[ 19.629960] __sys_sendto+0x396/0x470
[ 19.633720] __x64_sys_sendto+0xdc/0x1b0
[ 19.635066] do_syscall_64+0x76/0x10a0
[ 19.641701] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 19.642240] RIP: 0033:0x4240d7
[ 19.642597] Code: 00 89 01 e9 c1 fe ff ff e8 f6 03 00 00 66 0f 1f 44
00 00 f3 0f 1e fa 80 3d 8d 3f 09 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0
[ 19.646088] RSP: 002b:00007fffcb9ecb68 EFLAGS: 00000202 ORIG_RAX:
000000000000002c
[ 19.648938] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
00000000004240d7
[ 19.652116] RDX: 0000000000000008 RSI: 00007fffcb9ecce0 RDI:
0000000000000005
[ 19.653148] RBP: 00007fffcb9eccf0 R08: 00007fffcb9ecbb0 R09:
0000000000000010
[ 19.653951] R10: 0000000000000000 R11: 0000000000000202 R12:
00007fffcb9ece08
[ 19.654760] R13: 00007fffcb9ece18 R14: 00000000004b2868 R15:
0000000000000001
[ 19.657462] </TASK>
[ 19.657703] ---[ end trace 0000000000000000 ]---
The reason is that tcx and netkit never checked for offloaded programs
on attach, unlike XDP which already rejects this in dev_xdp_attach().
This series adds the same guard to both so offloaded programs can't be
attached to the software path.
[1]: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Jiayuan Chen (2):
bpf, tcx: reject offloaded programs on attach
bpf, netkit: reject offloaded programs on attach
drivers/net/netkit.c | 6 ++++++
kernel/bpf/tcx.c | 6 ++++++
2 files changed, 12 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH bpf 1/2] bpf, tcx: reject offloaded programs on attach
From: Jiayuan Chen @ 2026-04-23 3:36 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Yinhao Hu, Kaiyan Mei, Dongliang Mu,
Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Jesper Dangaard Brouer, Toke Høiland-Jørgensen, netdev,
linux-kernel
In-Reply-To: <20260423033609.252464-1-jiayuan.chen@linux.dev>
An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
since it's supposed to run on the NIC, not the host. But tcx doesn't
check this and happily attaches it to the software path, so the first
packet hits the WARN.
XDP already guards this in dev_xdp_attach(); tcx just never got the
same check. Add it to both tcx_prog_attach() and tcx_link_attach().
Use bpf_prog_is_offloaded() instead of bpf_prog_is_dev_bound() so that
dev-bound-only programs (still JITed for host) keep working.
Fixes: e420bed025071 ("bpf: Add fd-based tcx multi-prog infra with link support")
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
Closes: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
kernel/bpf/tcx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
index 02db0113b8e7c..86f4636d5a677 100644
--- a/kernel/bpf/tcx.c
+++ b/kernel/bpf/tcx.c
@@ -16,6 +16,9 @@ int tcx_prog_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = __dev_get_by_index(net, attr->target_ifindex);
if (!dev) {
@@ -315,6 +318,9 @@ int tcx_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct tcx_link *tcx;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = __dev_get_by_index(net, attr->link_create.target_ifindex);
if (!dev) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Kuniyuki Iwashima @ 2026-04-23 3:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, Simon Horman,
corbet, skhan, federico.vaga, carlos.bilbao, avadhut.naik, alexs,
si.yanteng, dzm91, 2023002089, tsbogend, dsahern, jani.nikula,
mchehab+huawei, gregkh, jirislaby, tytso, herbert, ebiggers,
johannes.berg, geert, pablo, tglx, mashiro.chen, mingo, dqfext,
jreuter, sdf, pkshih, enelsonmoore, mkl, toke, kees, crossd,
jlayton, wangliang74, aha310510, takamitz, linux-doc, linux-mips
In-Reply-To: <20260422104522.GK651125@horms.kernel.org>
On Mon, Apr 20, 2026 at 07:18:23PM -0700, Jakub Kicinski wrote:
> Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation
> and all associated hamradio device drivers from the kernel tree.
> This set of protocols has long been a huge bug/syzbot magnet,
> and since nobody stepped up to help us deal with the influx
> of the AI-generated bug reports we need to move it out of tree
> to protect our sanity.
>
> The code is moved to an out-of-tree repo:
> https://github.com/linux-netdev/mod-orphan
> if it's cleaned up and reworked there we can accept it back.
>
> Minimal stub headers are kept for include/net/ax25.h (AX25_P_IP,
> AX25_ADDR_LEN, ax25_address) and include/net/rose.h (ROSE_ADDR_LEN)
> so that the conditional integration code in arp.c and tun.c continues
> to compile and work when the out-of-tree modules are loaded.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
^ permalink raw reply
* Re: Path forward for NFC in the kernel
From: Jakub Kicinski @ 2026-04-23 3:03 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Michael Thalmeier, Raymond Hackley,
Michael Walle, Bongsu Jeon, Mark Greer, netdev, oe-linux-nfc
In-Reply-To: <938496c6-84c1-4d53-bb56-73bbd7b2bdd7@ixit.cz>
On Wed, 22 Apr 2026 15:11:16 +0200 David Heidelberg wrote:
> Yes, this is broadly in line with what I had in mind. To clarify the “limited
> reviews and basic maintenance” phrasing: that was more an attempt to set
> expectations conservatively. I’m prepared to take on the responsibilities you
> outlined — maintaining a tree, collecting and triaging patches, and sending
> regular pull requests.
>
> Regarding reviews and responsiveness: I can do the 48h turnaround for initial
> feedback on submissions (excluding weekends, and occasional travel), and I’ll
> make sure no patch sits unattended. For more complex changes where my current
> NFC-specific knowledge may be a limiting factor, I’ll seek input rather than let
> things stall.
Sounds good. The discussion taking long is perfectly fine. Main concern
to us is not hearing any response for a long time. Then we have to guess
whether the maintainer is planning to respond, or AWOL.
> I’m also planning to ramp up my familiarity with the NFC stack as I go, so I
> expect both the quality and depth of my reviews to improve over time.
>
> If that works for you, I’ll proceed with setting up a public tree and start
> tracking incoming patches.
Works! :)
^ permalink raw reply
* Re: [PATCH net] tcp: make probe0 timer handle expired user timeout
From: Altan Hacigumus @ 2026-04-23 3:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Neal Cardwell, Kuniyuki Iwashima, David S . Miller, David Ahern,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, linux-kernel,
Enke Chen
In-Reply-To: <CANn89iKwgoxM==synaLGKEP3k0jtCJ4b+Bap8ZF9k8yHJGnORg@mail.gmail.com>
On Wed, Apr 22, 2026 at 12:39 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Apr 21, 2026 at 8:31 PM Altan Hacigumus <ahacigu.linux@gmail.com> wrote:
> >
> > On Mon, Apr 20, 2026 at 9:58 PM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Mon, Apr 13, 2026 at 6:36 PM Altan Hacigumus <ahacigu.linux@gmail.com> wrote:
> > > >
> > > > tcp_clamp_probe0_to_user_timeout() computes remaining time in jiffies
> > > > using subtraction with an unsigned lvalue. If elapsed probing time
> > > > already exceeds the configured TCP_USER_TIMEOUT, the subtraction
> > > > underflows and yields a large value.
> > > >
> > > > Handle this expiration case similarly to tcp_clamp_rto_to_user_timeout().
> > > >
> > > > Fixes: 344db93ae3ee ("tcp: make TCP_USER_TIMEOUT accurate for zero window probes")
> > > > Signed-off-by: Altan Hacigumus <ahacigu.linux@gmail.com>
> > > > ---
> > > > net/ipv4/tcp_timer.c | 5 ++++-
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> > > > index 5a14a53a3c9e..4a43356a4e06 100644
> > > > --- a/net/ipv4/tcp_timer.c
> > > > +++ b/net/ipv4/tcp_timer.c
> > > > @@ -50,7 +50,8 @@ static u32 tcp_clamp_rto_to_user_timeout(const struct sock *sk)
> > > > u32 tcp_clamp_probe0_to_user_timeout(const struct sock *sk, u32 when)
> > > > {
> > > > const struct inet_connection_sock *icsk = inet_csk(sk);
> > > > - u32 remaining, user_timeout;
> > > > + u32 user_timeout;
> > > > + s32 remaining;
> > > > s32 elapsed;
> > > >
> > > > user_timeout = READ_ONCE(icsk->icsk_user_timeout);
> > > > @@ -61,6 +62,8 @@ u32 tcp_clamp_probe0_to_user_timeout(const struct sock *sk, u32 when)
> > > > if (unlikely(elapsed < 0))
> > > > elapsed = 0;
> > > > remaining = msecs_to_jiffies(user_timeout) - elapsed;
> > > > + if (remaining <= 0)
> > > > + return 1;
> > >
> > > I do not think this chunk is needed ?
> > > If @remaining is signed, then perhaps change the following line to:
> > >
> > > remaining = max_t(int, remaining, TCP_TIMEOUT_MIN);
> > >
> >
> > The if (remaining <= 0) return 1 handles the already-expired case and
> > mirrors the logic in tcp_clamp_rto_to_user_timeout().
>
> tcp_clamp_rto_to_user_timeout() has two conditionals.
>
> if (remaining <= 0)
> return 1;
> return min_t(u32, icsk->icsk_rto, msecs_to_jiffies(remaining));
>
> First one was to avoid to call msecs_to_jiffies() with a negative number.
>
> tcp_clamp_probe0_to_user_timeout() has 3 tests already, you want to
> add a fourth one...
> I would prefer something less obscure.
> We do not care if we return 1 or 2 (TCP_TIMEOUT_MIN) jiffies
>
okay
> >
> > max_t(s32, remaining, TCP_TIMEOUT_MIN) with remaining changed to s32
> > also fixes the underflow; I used the explicit early return for symmetry
> > with the RTO helper, but I can switch that in v2 if you prefer.
> >
> > > Also, it would be great to have a new packetdrill test.
> > >
> >
> > With packetdrill, AFAICS it would require a late ACK to be processed
> > after TCP_USER_TIMEOUT has elapsed but before tcp_probe_timer() runs the
> > abort check - i.e. a race between the RX softirq path and the timer.
> > This is not purely an event/packet ordering problem, so it is not clear
> > to me how a deterministic behavior can be simulated with packetdrill
> > without tying it to exact probe timing.
>
> I was trying to sense if the bug was serious or not, considering last
> tcp_clamp_probe0_to_user_timeout()
> statement is:
>
> return min_t(u32, remaining, when);
>
> Perhaps you should give more details in the changelog. What were the
> symptoms of this bug, for TCP_USER_TIMEOUT users.
Yes, it at least clamps to @when, but still caused connection teardowns
to be intermittently delayed beyond the user's explicit timeout sockopt.
Will send a v2 accordingly.
Thanks.
^ permalink raw reply
* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-23 2:59 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Boris Pismenny, willemdebruijn.kernel@gmail.com,
andrew+netdev@lunn.ch, daniel.zahka@gmail.com,
davem@davemloft.net, leon@kernel.org,
linux-kernel@vger.kernel.org, edumazet@google.com,
linux-rdma@vger.kernel.org, Rahul Rameshbabu, Raed Salem,
Dragos Tatulea, kees@kernel.org, Mark Bloch, pabeni@redhat.com,
Tariq Toukan, Saeed Mahameed, netdev@vger.kernel.org,
Gal Pressman
In-Reply-To: <5167f0714e3ddf750f80740bf2ab18a7bb567b16.camel@nvidia.com>
On Wed, 22 Apr 2026 15:13:04 +0000 Cosmin Ratiu wrote:
> > > Can you call mlx5e_psp_cleanup() when register fails for now?
> >
> > Done for the next version, currently undergoing testing.
>
> There's a snag: priv->psp may be accessed concurrently from
> mlx5e_get_stats() -> mlx5e_fold_sw_stats64() so we'd need to play
> tricks with RCU and that goes beyond what a net fix should be: It's a
> redesign of how priv->psp is handled in the driver. There's a risk we
> are missing things, or it becomes more intrusive that what a fix should
> be.
Questionable.
> I would like to ask you: let's please not do this redesign of priv->psp
> in a rush, and leave it for the net-next series I mentioned...
>
> To reiterate, would you like to take patch 2?
Sure, whatever. But it has to be reposted, of course.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Jakub Kicinski @ 2026-04-23 2:48 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: andrew+netdev, davem, edumazet, pabeni, netdev, linux-kernel
In-Reply-To: <20260421082005.74a3efb4@kernel.org>
On Tue, 21 Apr 2026 08:20:05 -0700 Jakub Kicinski wrote:
> On Tue, 21 Apr 2026 10:37:38 +0300 Nikola Z. Ivanov wrote:
> > Additionally remove the now redundant zero assignments
> > and reorder the remaining ones so that they more closely
> > match the order of the fields as they appear in the ip header.
>
> Doesn't matter, now that the whole thing is zero-initialized.
> I don't think it's worth the noise in the git history.
I don't see a v2, so just to be clear -- the patch looks good,
just don't reorder the assignments please.
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Philip Prindeville @ 2026-04-23 2:41 UTC (permalink / raw)
To: David Woodhouse
Cc: Jakub Kicinski, davem, openwrt-devel, Guy Ellis, netdev, edumazet,
pabeni, andrew+netdev, horms, corbet, skhan, linux, tsbogend,
maddy, mpe, npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
mchehab+huawei, tytso, herbert, geert, ebiggers, johannes.berg,
jonathan.cameron, kees, kuniyu, fourier.thomas, andriy.shevchenko,
rdunlap, akpm, linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <accbbcdf0ec14ae4d3f21ef5da7091bdcbd6574f.camel@infradead.org>
> On Apr 22, 2026, at 7:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
>>
>> I'm still deleting the solos driver, chances are nobody uses it.
>> Easy enough to revert back in since core is still around.
>> The guiding principle is to keep USB modems and delete
>> the rest as USB ADSL2+ CPEs were most popular historically.
>
> Still not entirely convinced; I worked on both USB ATM modems and on
> Solos, and the Solos is both the most modern and the only one I still
> actually have. And the only one we have native support for that could
> ever do full 24Mb/s ADSL2+, I believe.
>
> If we drop it, OpenWrt will need to drop support for these, which I
> think were quite popular at the time; there were a few UK resellers:
> https://openwrt.org/toh/traverse/geos1_1
>
> I still don't actually care *enough* to try to find an ADSL line I
> could plug one into for testing though... :)
I have 3 boards lying around if anyone wants them.
^ permalink raw reply
* Re: [PATCH net 00/18] Remove a number of ISA and PCMCIA Ethernet drivers
From: Jakub Kicinski @ 2026-04-23 2:44 UTC (permalink / raw)
To: Daniel Palmer
Cc: David Laight, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-doc
In-Reply-To: <CAFr9PXnuyb0jTAhRgJGRmdzUMxP-0HrHHHN3YpQnOn8-nBBC1g@mail.gmail.com>
On Wed, 22 Apr 2026 18:33:15 +0900 Daniel Palmer wrote:
> Seriously though, I think we should have something to mark stuff in
> MAINTAINERS and elsewhere that is in the kernel but only because a few
> people are having fun with it.
IMHO that's not a great use of upstream maintainers' time.
We support loadable modules, perfect fit for retro computing
and drivers which aren't up to the standards.
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Jakub Kicinski @ 2026-04-23 2:38 UTC (permalink / raw)
To: David Woodhouse
Cc: davem, openwrt-devel, Guy Ellis, netdev, edumazet, pabeni,
andrew+netdev, horms, corbet, skhan, linux, tsbogend, maddy, mpe,
npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
mchehab+huawei, tytso, herbert, geert, ebiggers, johannes.berg,
jonathan.cameron, kees, kuniyu, fourier.thomas, andriy.shevchenko,
rdunlap, akpm, linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <accbbcdf0ec14ae4d3f21ef5da7091bdcbd6574f.camel@infradead.org>
On Wed, 22 Apr 2026 14:05:31 +0100 David Woodhouse wrote:
> On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
> > I'm still deleting the solos driver, chances are nobody uses it.
> > Easy enough to revert back in since core is still around.
> > The guiding principle is to keep USB modems and delete
> > the rest as USB ADSL2+ CPEs were most popular historically.
>
> Still not entirely convinced; I worked on both USB ATM modems and on
> Solos, and the Solos is both the most modern and the only one I still
> actually have. And the only one we have native support for that could
> ever do full 24Mb/s ADSL2+, I believe.
>
> If we drop it, OpenWrt will need to drop support for these, which I
> think were quite popular at the time; there were a few UK resellers:
> https://openwrt.org/toh/traverse/geos1_1
>
> I still don't actually care *enough* to try to find an ADSL line I
> could plug one into for testing though... :)
I'm inversely unconvinced. The argument has the ring of "I still have
this HW lying around somewhere", which is usually what prevents us from
shedding all this dead weight code. I don't want to argue, so I'll keep it.
But if one "fix" arrives for this driver - it's going :(
^ permalink raw reply
* [PATCH net v3] ipv6: addrconf: skip ERRDAD transition when address already DEAD
From: Linmao Li @ 2026-04-23 2:32 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni
Cc: horms, stephen, netdev, linux-kernel, Linmao Li
In-Reply-To: <20260421075033.1110816-1-lilinmao@kylinos.cn>
addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD
via addrconf_dad_end(), which drops ifp->lock on return. The lock
is re-acquired after net_info_ratelimited(). A concurrent
ipv6_del_addr() can take the lock in that window, set ifp->state
to DEAD and run list_del_rcu(&ifp->if_list).
addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:
and schedules a new dad_work. The work calls ipv6_del_addr()
again, hitting the already-poisoned list entry:
general protection fault: 0000 [#1] SMP NOPTI
CPU: 4 PID: 217 Comm: kworker/4:1
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:ipv6_del_addr+0xe9/0x280
RAX: dead000000000122
Call Trace:
addrconf_dad_stop+0x113/0x140
addrconf_dad_work+0x28c/0x430
process_one_work+0x1eb/0x3b0
worker_thread+0x4d/0x400
kthread+0x104/0x140
ret_from_fork+0x35/0x40
Fold the addrconf_dad_end() logic into addrconf_dad_failure()
under a single ifp->lock critical section. The STABLE_PRIVACY
branch temporarily drops ifp->lock, so keep a state-is-DEAD
bail-out at errdad: for that remaining window.
Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
net/ipv6/addrconf.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5476b6536eb7..c9ea0d5042d0 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2166,16 +2166,18 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp)
struct net *net = dev_net(idev->dev);
int max_addresses;
- if (addrconf_dad_end(ifp)) {
+ spin_lock_bh(&ifp->lock);
+
+ if (ifp->state != INET6_IFADDR_STATE_DAD) {
+ spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
return;
}
+ ifp->state = INET6_IFADDR_STATE_POSTDAD;
net_info_ratelimited("%s: IPv6 duplicate address %pI6c used by %pM detected!\n",
ifp->idev->dev->name, &ifp->addr, eth_hdr(skb)->h_source);
- spin_lock_bh(&ifp->lock);
-
if (ifp->flags & IFA_F_STABLE_PRIVACY) {
struct in6_addr new_addr;
struct inet6_ifaddr *ifp2;
@@ -2227,6 +2229,11 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp)
errdad:
/* transition from _POSTDAD to _ERRDAD */
+ if (ifp->state == INET6_IFADDR_STATE_DEAD) {
+ spin_unlock_bh(&ifp->lock);
+ in6_ifa_put(ifp);
+ return;
+ }
ifp->state = INET6_IFADDR_STATE_ERRDAD;
spin_unlock_bh(&ifp->lock);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net v2 03/15] drivers: net: 3com: 3c574: Remove this driver
From: Jakub Kicinski @ 2026-04-23 2:21 UTC (permalink / raw)
To: Wei Fang
Cc: Andrew Lunn, Andrew Lunn, Geert Uytterhoeven, Michael Fritscher,
Byron Stanoszek, Daniel Palmer, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan
In-Reply-To: <AM8PR04MB7284CF79628FB99F7A7F20D5882A2@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Thu, 23 Apr 2026 02:14:22 +0000 Wei Fang wrote:
> > The 3c574 was written by Donald Becker between 19973-1998. It is an
>
> Nit: 19973 --> 1993
Will fix when applying FWIW
^ permalink raw reply
* Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer
From: Jakub Kicinski @ 2026-04-23 2:20 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, Sabrina Dubroca, Ralf Lici, Paolo Abeni, Andrew Lunn,
David S. Miller, Eric Dumazet, Hyunwoo Kim
In-Reply-To: <20260422123242.530882-2-antonio@openvpn.net>
On Wed, 22 Apr 2026 14:32:42 +0200 Antonio Quartulli wrote:
> + /* Prevent adding new peers while destroying the ovpn interface.
> + * Failing to do so would end up holding the device reference
> + * endlessly hostage of the new peer object with no chance of
> + * release..
> + */
> + if (ovpn->dev->reg_state >= NETREG_UNREGISTERING)
> + return -ENODEV;
AI review suggests wrapping reg_state read in READ_ONCE(), I think
that's legit. Also nit: I think > or != REGISTERED would be more
idiomatic than comparing >= UNREGSITERING ?
If you agree make sure Sashiko doesn't complain about anything else
once it's public:
https://sashiko.dev/#/patchset/20260422123242.530882-2-antonio@openvpn.net
^ permalink raw reply
* RE: [PATCH net v2 03/15] drivers: net: 3com: 3c574: Remove this driver
From: Wei Fang @ 2026-04-23 2:14 UTC (permalink / raw)
To: Andrew Lunn, Andrew Lunn
Cc: Geert Uytterhoeven, Michael Fritscher, Byron Stanoszek,
Daniel Palmer, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260422-v7-0-0-net-next-driver-removal-v1-v2-3-08a5b59784d5@lunn.ch>
> The 3c574 was written by Donald Becker between 19973-1998. It is an
Nit: 19973 --> 1993
> PCMCIA device, so unlikely to be used with modern kernels.
>
^ permalink raw reply
* Re: [PATCH net-next v7 0/5] TLS read_sock performance scalability
From: Jakub Kicinski @ 2026-04-23 2:08 UTC (permalink / raw)
To: Chuck Lever
Cc: john.fastabend, Sabrina Dubroca, netdev, kernel-tls-handshake,
Chuck Lever, Hannes Reinecke, Alistair Francis
In-Reply-To: <3fc31ab1-23de-4381-b85c-5faa39169ad9@app.fastmail.com>
On Wed, 22 Apr 2026 12:41:43 -0400 Chuck Lever wrote:
> I see that this series is currently not in v7.1. What is left to do?
It's marked as Changes requested in patchwork, possibly due to
mis-reading of the discussion on patch 4. We process patches within
few days (well, we used to before the AI swarm) so if in doubt you
should ask sooner :S
^ permalink raw reply
* Re: [net-next v2 0/3] Add motorcomm 8531s set ds func and 8522 driver
From: Minda Chen @ 2026-04-23 1:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Frank, Andrew Lunn, Heiner Kallweit, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <eea18d2f-5294-40e4-9ea1-87aa55f8ea28@lunn.ch>
>
> On Wed, Apr 22, 2026 at 04:32:52PM +0800, Minda Chen wrote:
> > This patch is for Starfive JHB100 EVB board. JHB100 contain
> > 1 RGMII/RMII and 1 RMII synopsys GMAC cores. In the EVB board, RGMII
> > interface connect with YT8531s Ethernet PHY. RMII interface connect
> > with YT8522 ethernet PHY. So patch 1-2 is for RGMII interface patch 3
> > is RMII is for RMII interface.
> >
> > JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
> > Managent Controller). Similar with Aspeed 27x0.
> >
> > The JHB100 minimal system upstream is in progress:
> > https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.
> > 467700-1-changhuang.liang@starfivetech.com/
>
> Please take a read of sections 1.3 and 1.4 of:
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> Andrew
>
> ---
> pw-bot: cr
I am sorry about the "net-next" in merge window
^ permalink raw reply
* Re: [PATCH 19/23] cgroup/cpuset: Improve check for calling housekeeping_update()
From: Chen Ridong @ 2026-04-23 1:10 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Thomas Gleixner, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan
In-Reply-To: <20260421030351.281436-20-longman@redhat.com>
On 2026/4/21 11:03, Waiman Long wrote:
> By making sure that isolated_hk_cpus matches isolated_cpus at boot time,
> we can more accurately determine if calling housekeeping_update()
> is needed by comparing if the two cpumasks are equal. The
> update_housekeeping flag still have a use in cpuset_handle_hotplug()
> to determine if a work function should be queued to invoke
> cpuset_update_sd_hk_unlock() as it is not supposed to look at
> isolated_hk_cpus without holding cpuset_top_mutex.
>
Currently, isolated_hk_cpus is updated within the cpuset_mutex critical section
(before mutex_unlock(&cpuset_mutex)) in cpuset_update_sd_hk_unlock. Therefore, I
think update_housekeeping can now be removed.
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cgroup/cpuset.c | 36 ++++++++++++++++++++----------------
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index a4eccb0ec0d1..1b0c50b46a49 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1339,26 +1339,29 @@ static void cpuset_update_sd_hk_unlock(void)
> __releases(&cpuset_mutex)
> __releases(&cpuset_top_mutex)
> {
> + update_housekeeping = false;
> +
> /* force_sd_rebuild will be cleared in rebuild_sched_domains_locked() */
> if (force_sd_rebuild)
> rebuild_sched_domains_locked();
>
> - if (update_housekeeping) {
> - update_housekeeping = false;
> - cpumask_copy(isolated_hk_cpus, isolated_cpus);
> -
> - /*
> - * housekeeping_update() is now called without holding
> - * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> - * is still being held for mutual exclusion.
> - */
> - mutex_unlock(&cpuset_mutex);
> - cpus_read_unlock();
> - WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> - mutex_unlock(&cpuset_top_mutex);
> - } else {
> + if (cpumask_equal(isolated_hk_cpus, isolated_cpus)) {
> + /* No housekeeping cpumask update needed */
> cpuset_full_unlock();
> + return;
> }
> +
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> +
> + /*
> + * housekeeping_update() is now called without holding
> + * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> + * is still being held for mutual exclusion.
> + */
> + mutex_unlock(&cpuset_mutex);
> + cpus_read_unlock();
> + WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> + mutex_unlock(&cpuset_top_mutex);
> }
>
> /*
> @@ -3692,10 +3695,11 @@ int __init cpuset_init(void)
>
> BUG_ON(!alloc_cpumask_var(&cpus_attach, GFP_KERNEL));
>
> - if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT))
> + if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) {
> cpumask_andnot(isolated_cpus, cpu_possible_mask,
> housekeeping_cpumask(HK_TYPE_DOMAIN_BOOT));
> -
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> + }
> return 0;
> }
>
--
Best regards,
Ridong
^ permalink raw reply
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