The PHY package API provides private data shared by all PHYs in a
package. Drivers are responsible for synchronizing access to this data,
but the API does not provide a lock for that purpose.
Add phy_package_lock() and phy_package_unlock() for drivers to serialize
access to package-private data, including its initialization.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This reverts commit 13b7e6a96a.
That commit made mt76_dma_cleanup() disable every RX NAPI instance before
deleting it, to silence WARNs in __netif_napi_del_locked() and
page_pool_disable_direct_recycling() seen when unloading mt7915e with an
MT7916.
On mt7921e and mt7925e the same instances are already disabled earlier,
in mt7921e_unregister_device() and mt7925e_unregister_device(), which
only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup(). Each
instance is therefore disabled twice, and napi_disable() is not
idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
set, so the second call spins in usleep_range() forever, waiting for bits
that nobody will clear.
mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
this is hit on every reboot, poweroff and module unload. It is silent:
the stuck task keeps sleeping and rescheduling, so neither the hung task
detector nor the lockup detectors fire, and the last line on the console
is "systemd-shutdown[1]: Rebooting."
task:modprobe state:D stack:25720 pid:7954 tgid:7954
Call Trace:
<TASK>
__schedule+0x11b8/0x26d0
schedule+0xe7/0x2f0
schedule_hrtimeout_range_clock+0x218/0x330
usleep_range_state+0x133/0x1b0
napi_disable_locked+0x37d/0x5f0
napi_disable+0x43/0x80
mt76_dma_cleanup+0x2b4/0x860 [mt76]
mt7921_pci_remove+0x17f/0x350 [mt7921e]
pci_device_remove+0xb6/0x1e0
device_release_driver_internal+0x38d/0x540
driver_detach+0xd0/0x1b0
bus_remove_driver+0x127/0x2d0
pci_unregister_driver+0x2a/0x280
__do_sys_delete_module+0x36a/0x5b0
do_syscall_64+0x11c/0x6d0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Dropping the two driver-side loops instead was tried and rejected: with
them gone, the RX poll can reach mt76_token_release() via
PKT_TYPE_TXRX_NOTIFY and mt7921_mac_tx_free() while
mt76_connac2_tx_token_put() is running idr_destroy(&dev->token) outside
token_lock, which is a use-after-free rather than a hang [1].
Revert for now, so that reboot, poweroff and module unload work again.
The WARNs on mt7915e are a less severe problem than an unbootable
machine, and fixing them belongs in the drivers that delete the NAPI
instances, where each one can pick a point that is safe for its own
teardown order, rather than in the shared mt76_dma_cleanup().
[ This is the "landing soonish" known regression fix mentioned in the
previous networking merge commit - Linus ]
Reported-by: Bert Karwatzki <spasswolf@web.de>
Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818
Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Fixes: 13b7e6a96a ("wifi: mt76: Disable napi when removing device")
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull networking fixes from Paolo Abeni:
"Including fixes from netfilter.
There is a known WiFi/mt76 regression, waiting for a complete fix that
should land soonish.
Previous releases - regressions:
- tcp: fix icsk_ack.ato bitfield overflow
- af_unix: Unlink scc_entry in unix_del_edge()
- ipv4: fix use-after-free in fib_nhc_update_mtu()
- netfilter:
- ipset: fix refcount race between list:set GC and swap
- nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort
path
- sched: act_ct: fix sk_buff leak when the header checks reject a
packet
- sctp: clear new_transport when removing a peer
- dibs: correct freeing of dmb_clientid_arr
- ovpn: fix NULL dereference when killing missing key
- eth:
- veth: fix queue index used to wake the peer txq in veth_poll
- ngbe: fix NULL pointer dereference in non-MSI-X interrupt
enabling
- gve: fix zero-length skb frag with header-split
Previous releases - always broken:
- core: fix skb length accounting after generic XDP frag adjustment
- af_packet: don't send zero-byte data in tpacket_snd().
- eth:
- bnxt: avoid deadlock when canceling IRQ affinity notifier
- ipvlan: inherit needed_headroom and needed_tailroom from
phy_dev"
* tag 'net-7.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (55 commits)
l2tp: fix tunnel and session refcount leak on seq_file release
net/sched: cls_bpf: reject dev-bound programs bound to a different device
sctp: fix use-after-free of cached ASCONF chunk
net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG
sctp: clear new_transport when removing a peer
net/dibs: Correct freeing of dmb_clientid_arr
net/sched: cls_u32: skip hash tables in u32_bind_class()
gve: fix NULL dereference due to missing ptp adjfine
gve: fix zero-length skb frag with header-split
net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain
af_packet: Don't send zero-byte data in tpacket_snd().
tipc: read le->link under the node lock in tipc_node_link_down()
selftests: tls: cover splice after a failed decrypt
net/tls: Fail tls_sw_splice_read() after a failed async decrypt
net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling
net: tap: fix wrong transport_header when sending VLAN-tagged frame
net: packet: fix wrong transport_header when sending VLAN-tagged frame
vxlan: do not arm the ageing timer on a device that is down
ipv4: fix use-after-free in fib_nhc_update_mtu()
NTB: ntb_netdev: Preserve RX queue depth on allocation failure
...
Pull firewire fix from Takashi Sakamoto:
"Fix a NULL pointer dereference in 1394 OHCI PCI driver when probe()
returns early with an error, as detected by Syzkaller"
* tag 'firewire-fixes-7.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix NULL pointer dereference in ar_context_release
Pull gpio fixes from Bartosz Golaszewski:
- use raw_spinlock_t in gpio-ml-ioh to avoid locking context issues
- fix a race condition in gpio-ml-ioh by sharing the register locks
across channels
- fix a use-after-free bug in unbind path in gpio-sloppy-logic-analyzer
* tag 'gpio-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
gpio: ml-ioh: share the register lock across channels
gpio: ml-ioh: use raw_spinlock_t for the register lock
gpiolib: Check gc->get_direction() before calling gpiod_get_direction()
Pull m68k fix from Geert Uytterhoeven:
"Define NR_CPUS to 1.
This fixes a long-standing but never critical before oddity on m68k,
that turned into a serious configuration issue after a recent erofs
change"
* tag 'm68k-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Define NR_CPUS to 1
Breno Leitao says:
====================
netconsole: replace target_list_lock by RCU on userdata hot path
I would like to move netconsole to use RCU on the hot path for
a while instead of target_list_lock. My goal is to have no lock on the
tx side at all and eventually drop CON_NBCON_ATOMIC_UNSAFE, if that is
possible [1].
Start removing target_list_lock on certain parts of the code. This patch
transforms the userdata array into a RCU-protected pointer, and uses the
dynamic mutex as the write lock.
Added a selftest, given we didn't have any netconsole selftest for
userdata operations. Feel free to drop it if this is not useful, dear
maintainers.
Link: https://lore.kernel.org/all/20251121-nbcon-v1-0-503d17b2b4af@debian.org/[1]
Signed-off-by: Breno Leitao <leitao@debian.org>
====================
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-0-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
update_userdata() takes target_list_lock to swap nt->userdata and
nt->userdata_length, then frees the old buffer. Since commit
7eab73b186 ("netconsole: convert to NBCON console infrastructure")
that lock is also the console's device_lock, so writing a userdata value
from configfs serialises against the printk core emitting messages.
The buffer is immutable once published, which is what RCU is for. Move
the string and its length into a single netcons_userdata object and
publish it with rcu_replace_pointer(), freeing the old one with
kfree_rcu().
New userdata design:
0) Unify the userdata fields into a struct netcons_userdata
1) update_userdata() no longer needs target_list_lock.
2) writers stay serialised by dynamic_netconsole_mutex.
3) reading userdata needs an RCU read lock.
No functional change intended.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-1-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
During the error handling path of the driver's probe function, a NULL
pointer dereference can occur in ar_context_release().
When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping
fails), the devres cleanup mechanism invokes release_ohci(). This function
unconditionally calls ar_context_release() to clean up the asynchronous
receive contexts. However, if ar_context_init() was not yet called,
ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by
devres_alloc()).
ar_context_release() immediately dereferences ctx->ohci to get the dev
pointer before checking if the context was actually initialized, leading to
a crash:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543
Call Trace:
release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567
release_nodes drivers/base/devres.c:546 [inline]
devres_release_all+0x1a8/0x260 drivers/base/devres.c:576
device_unbind_cleanup drivers/base/dd.c:597 [inline]
really_probe+0x451/0xae0 drivers/base/dd.c:772
To fix this, move the assignment of the dev pointer after the !ctx->buffer
check. If ctx->buffer is NULL, it indicates that the context was never
successfully initialized and there is nothing to release, safely avoiding
the dereference of the uninitialized ctx->ohci pointer.
Fixes: 5716e58aec ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+d30aad27833a559defab@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab
Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Link: https://lore.kernel.org/r/90c5db71-dd1f-4d46-b9d3-2f1046cbd5ea@mail.kernel.org
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Aditya Garg says:
====================
net: mana: Avoid DMA queue allocation failure under memory fragmentation
The MANA driver can fail to bring up its queues on systems with high
memory utilization because every GDMA queue ring is allocated as a
single dma_alloc_coherent() of the whole power-of-2 ring size. Under
memory fragmentation these high-order allocations may fail, preventing
the driver from creating queues when opening the interface, after a VF
reset, or when reconfiguring channels, ring parameters or MTU.
Per-queue sizes that are problematic, with depth and size given as
(default, max) over the ethtool ring settings:
ring entry depth size
------------------------------------------------------------
TX completion queue 64 B (256, 16384) (16 KB, 1024 KB)
TX send queue 32 B (256, 16384) ( 8 KB, 512 KB)
RX completion queue 64 B (1024, 8192) (64 KB, 512 KB)
RX receive queue 32 B (1024, 8192) (32 KB, 256 KB)
event queue 16 B 2048 (fixed) 32 KB
This series addresses the issue by:
1. Routing all CPU-side ring access through mana_gd_ring_ptr() and
mana_gd_ring_contig_avail(). On a contiguous ring these reduce to
simple arithmetic, so this patch is a pure refactor.
2. Falling back in mana_gd_alloc_memory() to a vector of scattered
order-0 coherent pages when the contiguous allocation fails. The
device sees the same page-list format either way, as
mana_gd_create_dma_region() already describes a ring as a list of
MANA_PAGE_SIZE addresses. The HW channel stays contiguous, as
advertising a scattered page list needs the HW channel itself.
Throughput testing confirms no regression. Since the fallback only
triggers under memory fragmentation, the scattered-page path was enabled
unconditionally for all eligible GDMA queue rings during testing (iperf3,
Gbit/s):
Baseline Patched Patched
Connections Contiguous Contiguous Scattered
-----------------------------------------------
1 46.1 46.2 46.1
16 182 182 182
32 182 182 182
64 182 182 182
====================
Link: https://patch.msgid.link/20260807210002.1695263-1-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Each GDMA queue ring is one dma_alloc_coherent() of the whole ring size.
Such high-order allocations fail first under memory fragmentation, so
queue setup can fail with memory still free.
The hardware does not need the ring physically contiguous:
mana_gd_create_dma_region() already maps it as a list of MANA_PAGE_SIZE
(4K) device addresses. Only the driver's linear CPU view needs
contiguity, and it goes through mana_gd_ring_ptr() and
mana_gd_ring_contig_avail(); change both to map offsets onto
scattered pages.
Add a fallback in mana_gd_alloc_memory(): data-path queues pass
allow_scatter=true, so when the contiguous allocation fails the ring is
backed by a vector of scattered PAGE_SIZE (order-0) coherent pages,
presenting the same DMA page-list layout to the device. The HW channel
bootstrap keeps allow_scatter=false, and the debugfs ring dumper reads
scattered rings through the same helpers.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Link: https://patch.msgid.link/20260807210002.1695263-3-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In preparation for backing GDMA queue memory with a vector of
non-contiguous order-0 coherent pages, route CPU access to a queue's
ring buffer through two new helpers: mana_gd_ring_ptr() returns the CPU
address of a byte offset into the ring, and mana_gd_ring_contig_avail()
the number of bytes left before the ring wraps, so a WQ write that runs
past the end of the ring can be split at that point.
Convert the EQ, CQ and work-request paths to use them.
mana_gd_write_sgl() now takes a byte offset rather than a raw pointer,
so mana_gd_post_work_request() derives the SGL position arithmetically.
While queue memory is contiguous both helpers are simple arithmetic on
the ring base and size, so there is no functional change.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Link: https://patch.msgid.link/20260807210002.1695263-2-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Joel Granados says:
====================
net: sysctl: Const Qualify sysctl ctl_table arrays
What?
=====
We do two things:
1. Reject netns-unsafe: Replace warning and file permission change with
an error (reject registration) when an "unsafe" net sysctl
registration is detected.
2. Const qualify: Const qualify network templated ctl_table arrays and
unconditional kmemdup'ed ctl_table arrays.
Why?
====
The main motivation for this is to continue with the const qualification
of the ctl_table arrays [1]. The permission change inside
ensure_safe_net_sysctl disallows cons qualifiaction as it basically
modifies the entries before running the sysctl registration.
ent->mode &= ~0222;
On reject netns-unsafe?
=======================
* I believe that there is currently now way that the permission change
gets executed [2]
* I found one case where the warning message was posted to lore
(vsock_sysctl_register) [3], but it made its to mainline as part of
the second case in [2].
* We should error anyway because writing to the global sysctl value
through a child netns is indicative of a bug [4].
On Const qualification?
=======================
We can separate the places where network registers sysctl tables into
three groups:
1. Static global: The unchanged global static arrays are passed along to
sysctl register.
2. Always kmemdup: The global static arrays are always kmemdup'ed before
passing them along to sysctl register.
3. Dynamic global: The global static array is changed in place before
passing it along to sysctl register.
This series handles case 1 and 2. It leaves 3 for a later point as
const qualifying those global ctl_tables is more involved.
I would be very thankful if you point me to anything that I have missed
in my analysis that shows that this cannot/shouldn't be done.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/commit/?h=constfy-sysctl-6.14-rc1&id=1751f872cc97f992ed5c4c72c55588db1f0021e1
[2]
I have identified 4 contexts relevant to the ensure_safe_net_sysctl call
inside the network sysctl registration.
1. When the (struct net) == &init_net (like in iw_cm_init): In this case
ensure_safe_net_sysctl is not executed and permission modification
never happens.
2. When the ctl_table data (->data) gets "manually" assigned to
something other init_net (like in vsock_sysctl_register): In this
case ensure_safe_net_sysctl *is* executed but the data that is passed
is neither a module address (!is_module_address) nor a kernel core
address (!is_kernel_core_data); so the permission modification never
happens.
3. When the permissions are explicitly changed on a kmemdup'ed ctl_table
array (like in sysctl_core_net_init): in this case
ensure_safe_net_sysctl *is* executed but the permission modification
never happens as the mode is not writable.
4. When ctl have custom proc_handlers (like in nf_lwtunnel_net_init): In
this case ->data is NULL so it is not a module address
(!is_module_address) nor a kernel core address
(!is_kernel_core_data), so permission modification never happens.
It seems like there is no way of executing the permission change in
ensure_safe_net_sysctl. Please correct me if this is inaccurate and help
me find the case that I missed.
[3]
https://lore.kernel.org/all/20260302194926.90378-1-graf@amazon.com/
[4]
The ensure_safe_net_sysctl function was introduced in Commit:
31c4d2f160 ("net: Ensure net namespace
isolation of sysctls") which states that it is trying to prevent a
leak (indicative of a bug).
[5]
https://patchwork.kernel.org/project/netdevbpf/patch/20260713-jag-net_const_qualify-v3-1-7289fe9eaea6@kernel.org/
====================
Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-0-77e888237c69@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace the warning and file permission change with an error when an
"unsafe" net sysctl registration is detected.
One of the barriers preventing the const qualification of the ctl_tables
in the net directory is the permission (->mode) change in
ensure_safe_net_sysctl. This prep commit removes that barrier and
ensures that the received ctl_table pointer to the net ctl_table
register function is const.
Signed-off-by: Joel Granados <joel.granados@kernel.org>
Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-1-77e888237c69@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The commit that introduced the receive-path latency trace added the
clearing of inc->i_rx_lat_trace[] to rds_inc_init() only;
rds_inc_path_init() never got it.
That asymmetry matters for the one caller that reuses memory:
rds_tcp_data_recv() carves its rds_tcp_incoming out of a kmem_cache
with no zeroing and no constructor, so after rds_inc_path_init() the
array still holds the timestamps of whatever message previously
occupied that slab object. No stale value is user-visible today -
every message that reaches the socket happens to overwrite all four
slots (RX_HDR at allocation, RX_START when the header completes,
RX_END at delivery, RX_CMSG at recvmsg time) before
RDS_CMSG_RXPATH_LATENCY reads them back as deltas - but that is a
property of the current writers, not of the init contract, and a
future trace point or an early-exit path would expose another
message's timestamps to userspace.
Clear the array in rds_inc_path_init() too, so both init helpers
leave the inc fully initialized. memset is the form the clearing
already takes on the rds_inc_init() side since commit 1635bb548f
("net: rds: use memset to optimize the recv"). Hardening only; no
user-visible bug in the current code.
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810055631.299558-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Allison Henderson says:
====================
net/rds: Bug fix ports, part 2
This is the next batch of net/rds fixes ported from the Oracle UEK
kernel, following up on the first set now in net-next [1].
This is v2 of patches 1 and 2 of "net/rds: Bug fix ports, part 2"
[2], which contained two initialization-hardening ports. While
re-reviewing v1's patches 3 and 4 (the fastpath-lock teardown changes)
I found their locking needs more rework than a respin should carry, so
they are split out and will return as their own series together with
two companion fixes. The two patches here are independent of them.
[PATCH net 1/2] net/rds: reinitialize to_be_dropped on rds_send_xmit() restart
Port commit 7f52b9968d79 ("net/rds: rds_send_xmit should INIT_LIST_HEAD (&to_be_dropped) on restart")
https://github.com/oracle/linux-uek/commit/7f52b9968d79
[PATCH net 2/2] net/rds: initialize i_conn_path in rds_inc_init()
Port commit 0ec6a520da4f ("rds: rds_inc_init() should initialize the inc->i_conn_path field")
https://github.com/oracle/linux-uek/commit/0ec6a520da4f
Questions and comments appreciated!
====================
Link: https://patch.msgid.link/20260809005103.82371-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rds_inc_init() initializes every field of the embedded rds_incoming
except i_conn_path, and incomings are not zero-allocated (IB carves
them out of a slab cache). The field therefore holds stale garbage
for incs created by rds_ib.
The loopback transport is different: rds_loop_xmit() re-runs
rds_inc_init() on the message's embedded inc after
rds_send_queue_rm() has already stored the connection path in it, so
there the field holds a live value rather than garbage, and a NULL
store would discard it. Switch rds_loop_xmit() to
rds_inc_path_init() with the connection's single path, which is
exactly the value readers of the field reconstruct for a
non-multipath transport.
With loopback preserving the field, initialize it to NULL in
rds_inc_init() so that any future reader trips over a clean NULL
pointer instead of a stale one, and so the two init helpers
(rds_inc_init/rds_inc_path_init) leave the structure in an
equivalent, fully-initialized state. Hardening only; no reader
dereferences i_conn_path for a non-multipath transport today.
This mirrors Oracle UEK commit "rds: rds_inc_init() should initialize
the inc->i_conn_path field".
Signed-off-by: William Kucharski <william.kucharski@oracle.com>
[achender: port to net-next; keep loopback's i_conn_path valid by
switching rds_loop_xmit() to rds_inc_path_init(); update commit
message]
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260809005103.82371-3-achender@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The to_be_dropped list is declared once at the top of rds_send_xmit()
but the function can loop via "goto restart" after each batch. The
code currently relies on rds_send_remove_from_sock() having emptied
the list entry by entry (via list_del_init()) at the end of the
previous batch; nothing in rds_send_xmit() itself guarantees the list
head is empty when a new batch starts.
Re-initialize the list on every restart, and warn once if it is ever
found non-empty there: entries left on the list at that point would
keep their message reference, their RDS_MSG_ON_SOCK accounting and
their pending RDS_RDMA_DROPPED notification, so a silent re-init
would orphan them. This is hardening: no user-visible bug is known
in the current code.
This mirrors Oracle UEK commit "net/rds: rds_send_xmit should
INIT_LIST_HEAD(&to_be_dropped) on restart".
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Signed-off-by: Sharath Srinivasan <sharath.srinivasan@oracle.com>
[achender: port to net-next (keep the existing LIST_HEAD declaration and
add only the restart re-init); warn if the restart invariant is
violated; update commit message]
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260809005103.82371-2-achender@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Yuyang Huang says:
====================
ipv6: report why a route was deleted in RTM_DELROUTE
When the kernel deletes an IPv6 route on its own, the RTM_DELROUTE
notification does not say why. User space cannot tell a route that
expired from one the router explicitly withdrew, yet the two call for
different reactions: an expired RA route means the router failed to
refresh it in time, which points at a misconfigured or unreliable
router and may warrant action such as disabling IPv6 on that network,
while a zero-lifetime withdrawal is normal, RFC-compliant operation.
This is a general problem for any consumer device running Linux,
especially on Wi-Fi networks, where multicast delivery is not
guaranteed (e.g. frames can be lost around DTIM for clients in power
save mode). The motivating case is Android: the userspace NetworkStack
process listens on RTMGRP_IPV6_ROUTE and today treats any loss of the
IPv6 default route as "router lost". To avoid the device repeatedly
gaining and losing IPv6 connectivity on a badly configured network,
when it detects the device is on a dual-stack network with working
IPv4 connectivity, it defensively clears accept_ra_defrtr and restarts
IPv6, so user space apps stop using broken global IPv6 connectivity
while link-local IPv6 keeps working. That reaction is wrong if the
route was withdrawn by a zero-lifetime RA (some ISPs do this
intentionally for reconfiguration) - with accept_ra_defrtr off, IPv6
never recovers once the router advertises again. It is the right
reaction if the route genuinely expired, since the router failed to
refresh it in time.
Fixing this in user space is not practical: RTM_NEWROUTE carries the
initial route lifetime (in rta_cacheinfo), but the kernel does not
resend it when a later RA refreshes the lifetime. So distinguishing
the cause of an RTM_DELROUTE from user space would mean opening a raw
socket, listening to RAs, and tracking lifetimes independently,
duplicating logic the kernel already has. Sending RTM_NEWROUTE on
every RA lifetime refresh was also considered, but that would be
spammy and is technically wrong, since a lifetime update does not add
a new route.
This series proposes RTA_DEL_REASON instead: it tells user space why
the route was deleted so it can react accordingly. In the Android
case, NetworkStack would defensively disable global IPv6 only on
RT_DEL_REASON_EXPIRED, and take no action on
RT_DEL_REASON_RA_WITHDRAWN, since that is RFC-compliant behavior.
Patches 1 to 6 add RTA_DEL_REASON and enum rt_del_reason to the
rtnetlink uAPI, thread the reason from the kernel-initiated IPv6
deletion paths down to the RTM_DELROUTE notification, and record the
cause: RT_DEL_REASON_EXPIRED for routes garbage collected after their
RTF_EXPIRES lifetime ran out, and RT_DEL_REASON_RA_WITHDRAWN for
default routes, prefix routes and RFC 4191 route information routes
withdrawn by Router Advertisements. Patches 1 to 5 are no-ops on the
wire; the attribute first appears in patch 6. The route addition path
is not touched.
Patches 7 to 9 extend the rt-route Netlink spec with the route
notifications and their multicast groups, split the newroute and
delroute request attribute lists out of the shared getroute reply
list, and add the new attribute and its enum.
Only kernel-initiated deletions that user space cannot otherwise
explain are attributed. User-requested deletions are self-explanatory
to the requester, so they carry no reason; the UAPI documents that
absence and RT_DEL_REASON_UNSPEC must be treated identically, which
keeps the door open for attributing more paths (nexthop removal
cascades, device removal) later.
Patch 10 adds selftests covering all three producer paths: a
GC-expired route, and a default route + PIO prefix route + RIO route
advertised and then withdrawn by hand-crafted RAs over a raw ICMPv6
socket (no external RA tool needed), plus a check that user-requested
deletions carry no attribute. The notifications are decoded with YNL,
which also exercises the rt-route spec additions.
====================
Link: https://patch.msgid.link/20260808005642.26901-1-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Extend rtnetlink.py to check the reason reported in RTM_DELROUTE:
- expired: route with a 2s lifetime collected by the fib6 GC
(gc_interval lowered like fib_tests.sh fib6_gc_test does);
- ra-withdrawn: a single RA advertises a default route (router
lifetime), an on-link prefix route (RFC 4861 prefix information
option) and a route information option route (RFC 4191), then a
second RA withdraws all three with zero lifetimes; the RAs are
crafted over a raw ICMPv6 socket so the test does not depend on an
external RA tool;
- absence: a userspace deletion request records no cause and must not
carry the attribute at all.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-11-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the del-reason attribute and its enum to the route attribute set,
and to the getroute reply, which the route notifications reuse.
The attribute is absent from the newroute and delroute request lists.
RTA_DEL_REASON is above strict_start_type in rtm_ipv6_policy, so
encoding it in a request is rejected with -EINVAL.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-10-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move the body of inet6_rt_notify() to __inet6_rt_notify() and give it
the deletion reason. inet6_rt_notify() keeps its prototype, so the
route addition path does not change.
Add inet6_rt_del_notify() and call it from fib6_del_route().
RTA_DEL_REASON now reaches user space on RTM_DELROUTE for routes the
kernel deleted on its own.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-7-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Record why the kernel deletes an IPv6 route on its own:
- RT_DEL_REASON_EXPIRED for routes reaped by the FIB6 garbage
collector after their RTF_EXPIRES lifetime ran out.
- RT_DEL_REASON_RA_WITHDRAWN for default routes, prefix routes and
RFC 4191 route information routes withdrawn by a zero-lifetime
Router Advertisement.
Deleting a default route because its metric changed is not a
withdrawal, so it keeps RT_DEL_REASON_UNSPEC.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-4-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add RTA_DEL_REASON and enum rt_del_reason to the rtnetlink uAPI, and
add ip6_del_rt_reason(), which takes the reason a route is being
deleted. It has no skip_notify argument: a caller that records a
deletion reason wants the notification that carries it.
The reason is unused for now. Subsequent patches propagate it to the
deletion path and report it on RTM_DELROUTE.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-2-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state
(pd->tunnel and pd->session) is kept in seq_file private data to allow
iteration across multiple read() system calls.
However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels
before reading to end-of-file (EOF), any tunnel or session reference stored in
pd->tunnel / pd->session is left un-dropped when seq_file private data is freed.
Fix this by dropping any remaining pd->tunnel and pd->session references in
pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.
Fixes: 0e0c3fee3a ("l2tp: hold reference on tunnels printed in pppol2tp proc file")
Fixes: f726214d9b ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file")
Reported-by: syzbot+d6fa74e3f19d6ee01e3a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a760f32.01d0871a.3a0d52.004f.GAE@google.com/T/#u
Assisted-by: Jetski:Gemini-3.1-Pro
Cc: James Chapman <jchapman@katalix.com>
Cc: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260811144651.2733424-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
cls_bpf_prog_from_efd() obtained a SCHED_CLS program via
bpf_prog_get_type_dev() but never verified that a device-bound (offloaded)
program's bound netdev matches the TC netdev the classifier is being
attached to. This let a program loaded with prog_ifindex for device A be
attached via cls_bpf + skip_sw to device B; deleting device A then
destroyed the program's offload state while it was still attached to
device B, triggering a netdevsim WARN (panic with panic_on_warn=1).
Mirror the XDP attach path (net/core/dev.c) and reject the attach with
-EINVAL when a dev-bound program's bound device does not match the
target device.
Fixes: 2b3486bc2d ("bpf: Introduce device-bound XDP programs")
Reported-by: vega@nebusec.ai
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/20260809094418.901607-1-jhs@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Simon Wunderlich says:
====================
This cleanup patchset includes the following patches:
- dat: drop non-4addr backwards compatibility, by Sven Eckelmann
- tvlv: handle negative tvlv processing return codes,
by Sven Eckelmann
- improve kernel-doc, add comments and warnings,
by Sven Eckelmann (3 patches)
- coding style: split declarations, reverse x-mas tree,
by Sven Eckelmann (2 patches)
- handle errors in batadv_init(), by Minhong He
- correct NET_RX_* NET_XMIT_* confusion, by Sven Eckelmann
- remove negative returns for batadv_send_skb_unicast,
by Sven Eckelmann
* tag 'batadv-next-pullrequest-20260805' of https://git.open-mesh.org/batadv:
batman-adv: remove negative returns for batadv_send_skb_unicast
batman-adv: correct NET_RX_* NET_XMIT_* confusion
batman-adv: handle errors in batadv_init()
batman-adv: switch var declarations to reverse x-mas tree order
batman-adv: split multiple declarations per line
batman-adv: annotate functions which may reallocate the skbuff
batman-adv: fix kernel-doc for functions holding skb ownership
batman-adv: add missing kernel-doc comments
batman-adv: tvlv: handle negative tvlv processing return codes
batman-adv: dat: drop non-4addr backwards compatibility
====================
Link: https://patch.msgid.link/20260805143200.722098-1-sw@simonwunderlich.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The existing comment for mdev_us says "medium deviation", but this
term is inaccurate. The field stores the "mean deviation" of RTT,
as originally defined in Van Jacobson's paper "Congestion
Avoidance and Control", and it is scaled by 4 (<< 2) in the Linux
implementation.
Update the comment to reflect the correct terminology and storage
format.
Signed-off-by: Ziran Zhang <zhangcoder@yeah.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260805131927.27661-1-zhangcoder@yeah.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Antonio Quartulli says:
====================
Included fixes:
* release key slot crypto transforms from a workqueue rather than an RCU
callback, because crypto_free_aead() may sleep with async or hardware
implementations
* run all deferred ovpn work on a module-owned workqueue and drain it on
module exit, so no work item can still be executing module text after
the module is unloaded
* finish crypto callback cleanup (key slot release and leftover skb)
before dropping the peer reference that gates netdev unregistration
and module removal
* avoid dereferencing a NULL key slot when userspace asks to kill a key
that is not installed on the peer
* tag 'ovpn-net-20260809' of https://github.com/OpenVPN/ovpn-net-next:
ovpn: defer key slot crypto freeing to workqueue
ovpn: run deferred work on a module-owned workqueue
ovpn: finish crypto callback cleanup before peer release
ovpn: fix NULL dereference when killing missing key
====================
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260809212142.2249027-1-antonio@openvpn.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal
ASCONF-ACK completion path releases the chunk and clears the pointer.
However, sctp_asconf_queue_teardown() releases the cached chunk without
clearing addip_last_asconf. During peer restart handling,
sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes
sctp_asconf_queue_teardown() while the association remains alive and leaves
the pointer dangling.
A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(),
which accesses the stale chunk and passes it to sctp_process_asconf_ack(),
causing a use-after-free and a second release.
Clearing the pointer exposes a race with T4 expiry. Peer restart handling
queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses
timer_delete(), which does not wait for a callback already running on
another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after
the purge and dereference NULL.
Clear addip_last_asconf after releasing the cached chunk, and make
sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding
ASCONF remains.
Fixes: a000c01e60 ("sctp: stop pending timers and purge queues when peer restart asoc")
Cc: stable@vger.kernel.org
Suggested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20260809043806.2768302-1-yangyx22@mails.tsinghua.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RTL_GIGA_MAC_VER_EXTENDED implicitly follows
RTL_GIGA_MAC_VER_LAST = RTL_GIGA_MAC_NONE - 1, so it has the same value
as RTL_GIGA_MAC_NONE.
rtl_init_one() therefore sends unknown chips through extended detection.
If TX_CONFIG_V2 reads as zero, they are misidentified as RTL9151AS
instead of being rejected.
Give RTL_GIGA_MAC_VER_EXTENDED a distinct value. It is only a detection
marker and is never stored in tp->mac_version.
Found by Clang's -Wduplicate-enum and verified with a QEMU stub.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260808101941.57666-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On the packet reception path, the ID of the MAC Port on which the packet
was received, is embedded in the RX DMA Descriptor's metadata. The ID is
extracted using the helper function cppi5_desc_get_tags_ids() which fills
in the 16-bit Source Tag into the 'port_id' variable. However, it is only
the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID,
while the upper 8-bits are Hardware-Reserved and carry an arbitrary value.
With the existing logic, sporadic kernel crash is observed due to the
subsequent driver code accessing out-of-bound memory because of an invalid
port_id.
Hence, fix the port_id extraction logic to use only the lower 8-bits of the
Source Tag as the MAC Port ID.
Fixes: 93a7653031 ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sctp_process_asconf_param() stores a newly added peer transport in
asoc->new_transport. After all parameters in the ASCONF chunk have been
processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the
new transport.
An authenticated ASCONF from a remote SCTP peer can add a transport and
remove it again with a wildcard DEL-IP parameter in the same chunk. The
wildcard deletion preserves the transport on which the ASCONF arrived, but
removes the newly added transport through
sctp_assoc_del_nonprimary_peers(). The removal does not clear
asoc->new_transport, leaving it pointing to the removed transport.
sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points
to the removed transport without holding a transport reference. During
local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on
control_chunk_list. After the transport is freed by RCU, a successful
ASCONF_ACK for the replacement address releases the queued HEARTBEAT and
sctp_outq_select_transport() reads the freed transport's state.
The issue was found during a static audit of SCTP objects. With an
authenticated peer, the reproducer triggered the same KASAN report in 2
of 2 unpatched runs on a KASAN-enabled netdev/main kernel:
BUG: KASAN: slab-use-after-free in sctp_outq_select_transport
Read of size 4 at addr ffff88800b9bd95c by task python3/197
Call Trace:
sctp_outq_select_transport+0x549/0x8b0 [sctp]
sctp_outq_flush+0x306/0x2c60 [sctp]
sctp_transport_immediate_rtx+0xaf/0x260 [sctp]
sctp_process_asconf_ack+0xa48/0xf70 [sctp]
Allocated by task 197:
sctp_transport_new+0x68/0x650 [sctp]
sctp_assoc_add_peer+0x258/0x12a0 [sctp]
sctp_process_asconf+0x5e9/0x1090 [sctp]
Last potentially related work creation:
__call_rcu_common.constprop.0+0x77/0xb70
sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp]
sctp_process_asconf+0xd9c/0x1090 [sctp]
The first invalid access was a four-byte read of transport->state at
net/sctp/outqueue.c:833. The same reproducer completed the full
authenticated ASCONF and local-address replacement sequence with this
change without a KASAN report or oops.
Clear new_transport when its peer is removed, before it can be used to
create the HEARTBEAT.
Fixes: 6af29ccc22 ("sctp: Bundle HEAERTBEAT into ASCONF_ACK")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Ming <a0yami@mailbox.org>
Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20260811152803.5629-1-a0yami@mailbox.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The blamed commit updated a tc replace command by adding a handle.
- tc(f"qdisc replace dev {ifname} root {qdisc} {optargs}")
+ tc(f"qdisc replace dev {ifname} root handle 1: {qdisc} {optargs}")
This breaks the test if the root qdisc already has that handle and is of
different kind, with
"Invalid qdisc name: must match existing qdisc."
If no handle is asked, or the kind differs, tc replace removes the old
qdisc and grafts a new one.
If a handle is asked and exists, tc replace tries to change the qdisc
in place, for which the kind must be the same.
It does not trigger in all setups, like netdevsim or debian 13, which
do not have root handle 1:. But it is a common root handle.
Solve the bug by first deleting the existing root qdisc if one exists.
Wrap that command in a try block, because it will fail for default
qdiscs with handle 0: with
"Error: Cannot delete qdisc with handle of zero."
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/netdev/20260810183118.32d5c06a@kernel.org/
Fixes: ef3d6cca02 ("selftests: drv-net: so_txtime: only send test traffic to sch_etf")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260811182856.2702163-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pptp_bind() publishes the socket by its local call ID before it is
connected, so GRE packets can reach pptp_rcv_core() while
PPPOX_CONNECTED is clear.
Such packets are queued on sk_receive_queue, but PPTP provides no recvmsg
operation and never drains the queue after connect. The packets therefore
remain there until socket destruction.
Drop such packets immediately instead. Since PPTP no longer queues packets
on sk_receive_queue, remove the corresponding destructor purge.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Link: https://patch.msgid.link/20260811074948.345834-1-qingfang.deng@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A dibs device interrupt handler can be active after dibs_dev_del() and
may still access dmb_clientid_arr. (UAF)
In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe()
dmb_clientid_arr is freed twice (double free).
Free dmb_clientid_arr in dibs_dev_release() after last reference is gone.
Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok
for now, because no dmbs can be registered before dibs_dev_add().
Fixes: cc21191b58 ("dibs: Move data path to dibs layer")
Cc: stable@vger.kernel.org
Co-developed-by: Hidayath Khan <hidayath@linux.ibm.com>
Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Link: https://patch.msgid.link/20260810111432.2334900-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pull SCSI fixes from James Bottomley:
"Two minor core fixes: one for power management issues in error
handling and the other to fix a deadlock in door locking of SCSI
devices with removable media; and a minor bug fix for the debug
driver"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: scsi_debug: Negate wrapped memcmp() result
scsi: core: Do not block on tag allocation in scsi_eh_lock_door()
scsi: core: pair EH runtime PM get and put
This fixes a Kconfig warning
fs/erofs/Kconfig:137:warning: range is invalid
which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using
NR_CPUS which up to now didn't exist for ARCH=m68k. All other
architectures define this symbol, so fix the outlier.
[geert] This also fixes:
- CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS being set to the
literal NR_CPUS instead of a number by automatic configs like
"make allmodconfig" or "make olddefconfig",
- An infinite loop in manual configs like "make oldconfig" when
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is not present or
has an invalid value in your existing .config.
Fixes: c9b47e6b23 ("erofs: cap LZMA stream pool size")
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://patch.msgid.link/20260731094950.1988084-2-ukleinek@kernel.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Matthieu Baerts says:
====================
mptcp: out-of-order queue pruning
Under memory pressure, a pruning of the MPTCP-level OoO queue might be
required as last resort, to avoid too long recoveries, or even stalls.
Geliang and Gang managed to reproduce this behaviour, and Paolo
improved the situation thanks to the following patches:
- Patches 1-3: improve the MPTCP-level retransmission schema to make
recoveries from memory pressure/after MPTCP-level drop significantly
faster.
- Patches 4-5: make the admission check way stricter for incoming
packets exceeding the memory limits, with some exceptions for fallback
sockets.
- Patches 6-7: implement OoO queue pruning for MPTCP.
====================
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-0-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
