Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
"Fix hugetlb write fault livelock, permission overlay and GCS state
preservation across CPU suspend, cpuidle context tracking during
system suspend, GCS mode handling on signal return, AMU counter errata
workarounds, kexec loading of images with a non-zero text_offset and a
spurious ptrace warning:
- Fix hugetlb write fault livelocks caused by stale read-only TLB
entries after another CPU makes the page writable and only performs
a local invalidate. Unlike the generic fault path, hugetlb has no
fix_spurious_fault() fallback
- Save and restore POR_EL0, GCSPR_EL0 and GCSCRE0_EL1 across CPU
suspend
- Restrict cpuidle context tracking in cpu_suspend() to idle tasks,
avoiding context tracking warnings during system suspend
[30 lines not shown]
Merge tag 'sound-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes as usual. A couple of regression fixes are
included in addition to the various quirks and device-specific fixes.
ALSA Core:
- PCM: Fix potential inconsistent PCM state reporting after XRUN
HD-audio:
- Fix sysfs hint parser
- Revert CS4208 fixup for MacBookAir 7,2 due to regressions
- ACPI _DSD fixes for CS35L41 side-codec on various HP laptops
- Device quirks for Acer (Predator, TravelLite) and Dell (Pro QC1255,
XPS 8940)
USB-audio:
- Fix for USB controller bugs reporting oversized packets
- Fix UAF on disconnect in caiaq
[40 lines not shown]
Merge tag 'block-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- ublk fixes: don't publish a new device in the idr until it's fully
set up, and don't hold ublk_ctl_mutex across device removal, as a
stuck filesystem on one device otherwise blocked ADD_DEV and DEL_DEV
for every other ublk device.
- s390/dasd fixes: re-initialize the RCD buffer magic before every
request start, fix a wrong free and refcount leak in the check_tcw
error path, don't trust the userspace-supplied result field in the
format check, and a typo fix.
* tag 'block-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
s390/dasd: Don't trust userspace-supplied result field in format check
s390/dasd: Fix wrong free and refcount leak in build_check_tcw error path
s390/dasd: Re-initialize RCD buffer with "V1.0" before every start
s390/dasd: Fix typo 'immediatly' -> 'immediately'
[2 lines not shown]
Merge tag 'io_uring-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fix from Jens Axboe:
- Don't end the NAPI busy poll early on need_resched() when a single
NAPI is registered, as that left the rest of the wait timeout
sleeping in schedule_hrtimeout() rather than busy polling.
* tag 'io_uring-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/napi: don't end the single NAPI busy poll early on need_resched()
Merge tag 'cifs-fixes-7.4-rc3' of https://git.manguebit.org/linux
Pull smb client fixes from Paulo Alcantara:
- Fix silent data loss in writeback
Since the move to netfslib a transient failure (a reconnect, a lost
handle, an interrupted wait, -ENOMEM, or a task killed while close()
flushes its dirty pages) ended writeback with the folios clean and
no error, dropping the write.
Retry it instead, bounded by the hard and retrans mount options, and
have umount -f abort the retries and the reconnect and credit waits
so the unmount's own sync can't hang
- Prefer a non-O_DIRECT handle for writeback, as Windows rejects
unaligned I/O on O_DIRECT handles and silently dropped about 1% of
the writes in generic/051
[50 lines not shown]
Merge tag 'erofs-for-7.4-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
Pull erofs fixes from Gao Xiang:
- Fix stacked fs check for file-backed mounts with extra devices
- Disallow file-backed mounts on shared backing inodes
- Reset metadata offsets when fsoffset= is used to fix xattr reads
inside and outside the metabox in ont shot
- Refine on-disk format summary
* tag 'erofs-for-7.4-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
docs: erofs: refine the on-disk overview
erofs: reset buf->off in erofs_init_metabuf()
erofs: treat files shared by inode_share as stacked
erofs: apply the stacked fs check to extra file-backed devices
arm64: suspend: Only track cpuidle context for idle tasks
Commit 19235e472798 ("cpuidle, arm64: Fix the ARM64 cpuidle logic") moved
the calls to ct_cpuidle_enter() and ct_cpuidle_exit() into cpu_suspend() so
that arm64 cpuidle could keep RCU watching longer and manage context
tracking internally. However, cpu_suspend() is called not only by cpuidle
via psci_cpu_suspend_enter() (which runs in the context of the idle task),
but also during system suspend via psci_system_suspend_enter() (which runs
in the context of the task initiating suspend, such as a process writing to
/sys/power/state).
When entering system suspend, current is a non-idle task. Calling
ct_cpuidle_enter() invokes ct_kernel_exit() from kernel space (!user) on a
non-idle task. With CONFIG_RCU_EQS_DEBUG enabled, this violates context
tracking invariants and triggers a warning:
WARNING: kernel/context_tracking.c:120 at ct_kernel_exit+0x1b4/0x1f4
kernel/context_tracking.c:118
Call trace:
[33 lines not shown]
arm64: ptrace: don't warn on missing siginfo in a group-stop
PTRACE_ATTACH to a group-stopped child can enter do_jobctl_trap(),
which calls ptrace_stop() without siginfo. If the tracer writes
NT_ARM_SYSTEM_CALL, system_call_set() can change syscallno from
NO_SYSCALL before update_syscall_orig_x0_after_ptrace() checks
last_siginfo. WARN_ON_ONCE(!info) then fires for a valid ptrace stop.
Keep the early return when siginfo is absent, but remove the warning.
This leaves orig_x0 untouched at a non-seized group-stop and preserves
the existing syscall-exit-stop handling.
Fixes: 88b839ce497c ("arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry")
Cc: stable at vger.kernel.org
Signed-off-by: Zhao Gongyi <zhaogongyi at bytedance.com>
Acked-by: Oleg Nesterov <oleg at redhat.com>
Acked-by: Will Deacon <will at kernel.org>
[catalin.marinas at arm.com: modified comment as per Will's suggestion]
Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
ALSA: aw2-alsa: select SND_PCM
Several stanzas in sound/pci/Kconfig select SND_PCM.
SND_AW2 selects nothing at all.
aw2-alsa calls snd_pcm_new, which sound/core/pcm.c provides under SND_PCM.
aw2-alsa.c:(.text+0x554): undefined reference to `snd_pcm_new'
4 symbols are undefined in all.
The driver can be built into vmlinux while SND_PCM is a module, in which
case the symbols are not there at link time.
Select rather than depend on: SND_PCM has no prompt of its own and is only
ever enabled by a select, so a depends on would leave SND_AW2
unselectable.
Reproduced on v7.3, arm64, with CONFIG_SND_AW2=y and CONFIG_SND_PCM=m.
[8 lines not shown]
Merge tag 'asoc-fix-v7.4-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.4
Another week, another pile of driver specific fixes and quirks. We do
have one major fix which addresses a bug introduced by confusion with
the counted_by interfaces that was causing major disruption for a number
of platforms.
Merge tag 'net-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter, wireless and bluetooth.
Previous releases - regressions:
- tcp: rate limit receive queue collapsing
- raw: fix ICMP unreachable sent when receive queue is full
- eth: bnxt_en: take RTNL before netif_close() when aborting FW reset
Previous releases - always broken:
- tcp:
- bound snd_cwnd_clamp to TCP_MAX_SND_CWND
- number of fixes for TCP Fast Open
[41 lines not shown]
arm64: kexec_file: Do not use CMA for images with a non-zero text_offset
image_load() adds text_offset to kernel_segment->mem and subtracts it
from kernel_segment->memsz. For CMA backed segments this breaks the
load path: the payload is copied to page_address(cma), which is the CMA
base, while image->start is set to the adjusted address, so kexec jumps
into the middle of the kernel. kimage_map_segment() has the same
mismatch when a segment has been moved.
The adjusted memsz also breaks the release path: the CMA pages are
freed using segment->memsz >> PAGE_SHIFT, which is fewer than were
allocated, leaking the tail of the allocation.
Both problems are specific to CMA segments, which are accessed through
page_address(cma) and ignore segment->mem. The normal load path uses
segment->mem, so the text_offset adjustment stays consistent there.
Keep honoring text_offset, but load such images from regular memory by
setting image->no_cma: they lose the CMA contiguous allocation, but
keep working.
[10 lines not shown]
arm64: errata: Add Cortex-A715/A720 AMU core counter workaround
On Cortex-A715 (erratum 2738462) and Cortex-A720 (erratum 2738461),
the AMEVCNTR00 counter may continue incrementing while the core
remains in WFE with the clocks being enabled. The resulting core
cycle count may become unreliable.
Add a workaround that effectively treats the AMU counter
as unavailable.
Cc: <stable at vger.kernel.org>
Signed-off-by: Beata Michalska <beata.michalska at arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
arm64: errata: Extend the workaround for broken AMEVCNTR01 counter
The erratum causing significant inaccuracies in the AMU CNT_CYCLES
counter due to WFI/WFE has been identified in additional
microarchitectures.
Extend the existing workaround to cover these implementations,
which are affected by the following errata:
- ARM Cortex-A725 erratum 3821522 (SDEN-2832921)
- ARM Cortex-A720 erratum 4689339 (SDEN-2439421)
- ARM Cortex-A720AE erratum 4689340 (SDEN-3090091)
- ARM Neoverse N3 erratum 4689341 (SDEN-3050973)
- ARM C1-Pro erratum 4689344 (SDEN-3273080)
Cc: <stable at vger.kernel.org>
Signed-off-by: Beata Michalska <beata.michalska at arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Merge branch 'nsh-limit-recursion-in-nsh_gso_segment'
Eric Dumazet says:
====================
nsh: limit recursion in nsh_gso_segment()
Sashiko found that nsh_gso_segment() can call itself, through
skb_mac_gso_segment(), once per stacked NSH header. Nothing limits the
depth, and a 64KB GSO packet made of 8-byte NSH headers overflows the
kernel stack. It was reported while reviewing an unrelated virtio
series [1].
Such a packet can be sent with a packet socket using PACKET_VNET_HDR,
when the nsh module is loaded.
Patch 1 uses the recursion counter added in commit 006c8b834aed ("net:
gso: limit recursive IP-in-IP segmentation"), with the same limit as
IPv4 and IPv6.
[7 lines not shown]
selftests: net: add a test for NSH GSO
Send TCPv4 GSO packets encapsulated in a stack of NSH headers to a
dummy device which has TSO disabled, using a packet socket with
PACKET_VNET_HDR, and count the packets the device transmits.
Packets with one or four NSH headers must be segmented. Packets with
5, 64 or 8000 NSH headers must be dropped: they exceed the recursion
limit of the GSO handlers. Without the limit in nsh_gso_segment(),
the last one overflows the kernel stack.
# ./nsh_gso.sh
PASS: 1 NSH headers: 4 packets sent
PASS: 4 NSH headers: 4 packets sent
PASS: 5 NSH headers: 0 packets sent
PASS: 64 NSH headers: 0 packets sent
PASS: 8000 NSH headers: 0 packets sent
Signed-off-by: Eric Dumazet <edumazet at kernel.org>
[2 lines not shown]
nsh: limit recursion in nsh_gso_segment()
nsh_gso_segment() calls skb_mac_gso_segment() for the inner packet,
which calls nsh_gso_segment() again when the next protocol is NSH,
either directly or behind an inner Ethernet header (ETH_P_TEB).
Nothing limits the depth: a GSO packet made of stacked 8-byte NSH
headers recurses once per header, and a 64KB packet can hold about
8000 of them, overflowing the kernel stack.
Such a packet can be injected with a packet socket using
PACKET_VNET_HDR, or with tun/tap or virtio_net, as nothing checks
that a GSO packet with VIRTIO_NET_HDR_F_NEEDS_CSUM carries the
protocol it claims. It is then segmented in software if the output
device does not support the GSO type:
BUG: TASK stack guard page was hit at ffffcad5c0ab3ff8 (stack is ffffcad5c0ab4000..ffffcad5c0ab8000)
Oops: stack guard page: 0000 [#1] SMP NOPTI
CPU: 3 UID: 0 PID: 337 Comm: nsh_gso Tainted: G E 7.4.0-rc1+ #118 PREEMPT(lazy)
[35 lines not shown]
Merge branch 'net-tls-break-the-connection-after-a-burst-of-empty-data-records'
Jakub Kicinski says:
====================
net: tls: break the connection after a burst of empty data records
Deal with overload of zero-length TLS records. This is the next iteration
of Chuck's series. I tried to make it as simple as possible - break the
connection if sender floods us with zero-length records. Consume / discard
those records even on PEEK to avoid infinite rx_list growth.
https://lore.kernel.org/20261019-tls-follow-on-v6-0-ab01c4ecca0c@kernel.org
====================
Link: https://patch.msgid.link/20261111185522.2859004-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Consume empty data records in tls_sw_splice_read()
A zero-length application_data record decrypts to full_len == 0,
so tls_sw_splice_read() splices zero bytes and returns zero. A zero
return from a splice read means EOF, and the caller tears down a
connection that is still live.
Consume the record and fetch the next one, as tls_sw_read_sock()
does. The cap on consecutive empty records bounds the loop.
When an empty record precedes a close_notify, splice(2) now returns
-EINVAL from the control-record test instead of a false EOF. A
splice that reaches an alert record already reports -EINVAL.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: Sabrina Dubroca <sd at queasysnail.net>
Closes: https://lore.kernel.org/netdev/akaoXcfamBp8_mYe@krikkit/
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Skip the zero_len tests when TLS is unavailable
FIXTURE_SETUP(zero_len) returns early when ulp_sock_pair() reports
that the TCP_ULP setsockopt failed, so on a kernel built without
CONFIG_TLS the TLS_RX setsockopt never runs. TEST_F(zero_len, test)
then sends its raw records over a plain TCP socket, which returns
the ciphertext verbatim. All eight variants FAIL on a machine that
lacks TLS, and those failures mask any real regression in the same
run.
Skip the test when the fixture recorded notls, as the other
fixtures in this file do.
Fixes: a61a3e961baf ("selftests: tls: add tests for zero-length records")
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Cover the cap on consecutive empty records
Check through both recv() and splice() that a run of 128 empty data
records is consumed and the data record behind it is delivered, and
that a run of 129 breaks the connection with EBADMSG before the data
record can be read. Two runs of 128 with a read returning EAGAIN in
between must not break the connection, the cap applies to a burst the
reader cannot keep up with, not to the connection as a whole.
kTLS cannot send an empty record. A TLS 1.3 record of type 0 whose
only byte is the data content type decrypts to one, since the receiver
strips the 0 as padding.
Reviewed-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Extend coverage for zero-length records
The zero_len fixture injects raw pre-encrypted records over a
socket carrying a TLS_RX key only, and some of those records are
zero-length application_data records. Every variant reads the
records back with recvmsg() without MSG_PEEK, so neither splice nor
MSG_PEEK is tested against an empty record.
Add zero_len_splice and zero_len_peek. A zero return from splice()
means EOF, so zero_len_splice checks that a run of empty data
records does not end a live connection. zero_len_peek checks that a
peek reaches the payload behind a run of empty records and leaves
the payload in place for the read that follows. When a payload does
not follow the run, the peek must leave the socket unreadable. An
unfixed kernel returns 0 from splice(), and after the peek poll()
reports the socket readable.
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Break the connection after a burst of empty data records
TLS permits zero-length application_data records, and RFC 8446
suggests them for generating cover traffic. Nothing bounds how many of
them a reader processes back to back, though. They advance neither
loop bound in tls_sw_recvmsg() and tls_sw_read_sock(), so a peer
streaming them faster than the reader decrypts them keeps it in the
kernel for as long as they arrive. recvmsg() does not check for signals
while records are ready, and its peek and async paths queue every empty
record on rx_list. read_sock consumers like nvme-tcp hold the socket
lock throughout and never get control back.
Break the connection once a reader decrypts more than 128 consecutive
empty data records without sleeping or returning to its caller in
between, treating the burst as a protocol violation like a malformed
record header. A stream of empty records which the reader keeps up with
costs no more than any other traffic, so the count starts over on every
read and whenever the reader waits for the next record. The strparser
is stopped before it parses the next record, so the reader gets the
[22 lines not shown]
Merge tag 'for-7.4-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- zoned mode fixes
- fix counting active zones after activation
- redo zone reset after error
- update device lock range during mount and zone loading
to avoid lockdep warnings with device drivers (virtio)
- space accounting and extent buffer handling fixes
- fix keeping zstd workspace for the last level
- handle a real case of a subvolume with 0 refs in the SUBVOL_SYNC
ioctl
- properly handle case of zero num_stripes when reading chunk items
- exclude reloc tree from xarray as it is special and its key does
[20 lines not shown]
net: phy: c45: select BASE-T1 type for the forced speed
Commit 25108a834e14 ("net: phy: c45: add support for 1000BASE-T1 forced
setup") made genphy_c45_pma_setup_forced() write the type selection
field (bits 3:0) of the BASE-T1 PMA/PMD control register (1.2100) on
every forced setup: 1000BASE-T1 for SPEED_1000, and 0 for everything
else. 0 selects 100BASE-T1, so forcing a 10BASE-T1L PHY to 10 Mbit/s
now also switches its PMA to 100BASE-T1, a mode it does not implement.
Seen on an ADIN1110 (internal ADIN1100 PHY): after
ethtool -s ethX autoneg off speed 10 master-slave forced-master
1.2100 reads 0xc000 instead of the 0xc002. Since the field is not
restored by re-enabling autoneg, the PHY keeps the wrong type until
the next forced setup or reset.
Add a helper that returns the type selection value for the forced speed
and the supported link modes: 100BASE-T1, 1000BASE-T1, and 10BASE-T1L or
[16 lines not shown]
net/mlx5e: Fix false WARN_ON_ONCE in flow steering cleanup on RX init failure
mlx5e_attach_netdev() sets rx_mode_active before calling init_rx(), so
any init_rx() failure after mlx5e_create_flow_steering() has succeeded
makes mlx5e_destroy_flow_steering() trip
WARN_ON_ONCE(fs->rx_mode_active) in mlx5e_del_vlan_rules().
Hit in internal regression testing, so kthread creation failed
with -EINTR:
WARNING: CPU: 3 PID: 170 at drivers/net/ethernet/mellanox/mlx5/core/en_fs.c:564 mlx5e_del_vlan_rules+0x295/0x2b0 [mlx5_core]
mlx5e_destroy_flow_steering+0x34/0xc0 [mlx5_core]
mlx5e_init_nic_rx+0x137/0x200 [mlx5_core]
mlx5e_attach_netdev+0x105/0x360 [mlx5_core]
Fix it by creating NIC flow steering with rx_mode_active cleared and
setting it only after profile->init_rx() succeeds. This also lets the
internal error paths of mlx5e_create_flow_steering() destroy partially
created steering without warning. The flag is set in
[11 lines not shown]
net/mlx5e: IPsec, don't match upper proto selectors in crypto offload TX
The mentioned commit introduced support for upper protocol selectors
(protocol & ports) to mlx5 IPsec offload. In crypto offload mode this
causes offloaded TX SAs to stop matching traffic.
In tx_add_rule(), setup_fte_upper_proto_match() is called for all
offload types and programs a match on the upper protocol (TCP/UDP) and
ports. For crypto offload, setup_fte_esp() is then called and sets
ip_protocol to ESP. The resulting rule requires both ESP as the IP
protocol and TCP/UDP ports, which no packet can satisfy, so TX crypto
offload silently stops working for such SAs.
In crypto offload mode the stack builds the ESP packet and the HW only
encrypts it, so the SA rule should only match on the SPI. Move the
setup_fte_upper_proto_match() call under the XFRM_DEV_OFFLOAD_PACKET
case, where the rule matches the plaintext packet and upper protocol
selectors apply.
[11 lines not shown]
tcp: fix request_sock use-after-free during Fast Open accept()
Commit e3d95ad7da4f ("inet: avoid fastopen lock for regular accept()")
made inet_csk_accept() check tfo_listener before taking fastopenq.lock
to avoid taking the lock for connections that did not use Fast Open.
reqsk_fastopen_remove() clears tfo_listener while holding fastopenq.lock,
then reads req->sk. If inet_csk_accept() concurrently observes
tfo_listener after it has been cleared, it skips fastopenq.lock and
drops the last reference to the request_sock. This can free the
request_sock while reqsk_fastopen_remove() is still using it.
If the freed memory is reused for a new request_sock with req->sk ==
NULL, the reset path in reqsk_fastopen_remove() can append the new
request_sock to the original listener's list of requests that caused an
RST. After the new request_sock is freed, the next append writes through
the stale rskq_rst_tail into freed memory.
KASAN reported the following use-after-free when writing
[46 lines not shown]
net: usb: cdc_ncm: don't underflow the NDP room check
cdc_ncm_ndp16() and cdc_ncm_ndp32() verify that the new NDP and the
datagram fit into the NTB with an unsigned subtraction:
if ((ctx->tx_curr_size - skb->len - reserve) < ctx->max_ndp_size)
return NULL;
Nothing guarantees that skb->len plus the reserve stays below
tx_curr_size, and when it does not the subtraction wraps around to a
huge value, the check passes, and the skb_put_zero() of max_ndp_size
bytes that follows overruns the NTB:
skbuff: skb_over_panic: text:ffff80000db33558 len:428 put:172
head:ffff0000c2c66100 tail:0x1ac end:0x140
kernel BUG at net/core/skbuff.c:200
skb_put_zero include/linux/skbuff.h:2595 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1132 [inline]
cdc_ncm_fill_tx_frame+0xdf0/0x30e0 drivers/net/usb/cdc_ncm.c:1309
[33 lines not shown]
net: netns: fix INT_MAX nsid cleanup
A syzkaller reproducer assigning INT_MAX as a peer nsid triggers an
idr_get_next() warning during netns cleanup. With panic_on_warn, this
panics the kernel.
alloc_netid() also overflows reqid + 1 for this nsid. Use
idr_alloc_u32() for requested IDs and idr_get_next_ul() for cleanup so
the cursor can advance past INT_MAX.
QEMU/KVM reproduced the warning without kernel changes or fault
injection. The same reproducer ran without warnings after this change.
Kernel selftests were not run.
Fixes: 7acee67a6bce ("netns: optimize netns cleaning by batching unhash_nsid calls")
Cc: stable at vger.kernel.org
Signed-off-by: Zhao Gongyi <zhaogongyi at bytedance.com>
Link: https://patch.msgid.link/20261111033525.65828-1-zhaogongyi@bytedance.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
