Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux
Pull fsverity fix from Eric Biggers:
"Prevent CONFIG_FS_VERITY from being enabled when the page size is
256K, since it doesn't work in that case"
* tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux:
fsverity: add dependency on 64K or smaller pages
Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fixes from Eric Biggers:
- Several test fixes:
- Fix flakiness in the interrupt context tests in certain VMs
- Make the lib/crypto/ KUnit tests depend on the corresponding
library options rather than selecting them. This follows the
standard KUnit convention, and it fixes an issue where enabling
CONFIG_KUNIT_ALL_TESTS pulled in all the crypto library code
- Add a kunitconfig file for lib/crypto/
- Fix a couple stale references to "aes-generic" that made it in
concurrently with the rename to "aes-lib"
- Update the help text for several CRYPTO kconfig options to remove
[12 lines not shown]
Merge tag 'acpi-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fixes from Rafael Wysocki:
- Revert a commit related to ACPI device power management that was
not supposed to make any functional difference, but it did so and
introduced a regression (Rafael Wysocki)
- Update the _CPC object definition in ACPICA to match ACPI 6.6 and
prevent the kernel from printing a false-positive warning regarding
_CPC output package format on platforms shipping with firmware based
on ACPI 6.6 (Saket Dumbre)
* tag 'acpi-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI: PM: Let acpi_dev_pm_attach() skip devices without ACPI PM"
ACPICA: Update the _CPC definition to match ACPI 6.6
Merge tag 'net-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from CAN, netfilter and wireless.
Current release - new code bugs:
- sched: cake: fixup cake_mq rate adjustment for diffserv config
- wifi: fix missing ieee80211_eml_params member initialization
Previous releases - regressions:
- tcp: give up on stronger sk_rcvbuf checks (for now)
Previous releases - always broken:
- net: fix rcu_tasks stall in threaded busypoll
[35 lines not shown]
Merge branch 'acpica'
Merge a fix updating the _CPC object definition in ACPICA to avoid
printing a false-positive output package format warning on new
platforms (Saket Dumbre)
* acpica:
ACPICA: Update the _CPC definition to match ACPI 6.6
Merge tag 'trace-v7.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix thresh_return of function graph tracer
The update to store data on the shadow stack removed the abuse of
using the task recursion word as a way to keep track of what
functions to ignore. The trace_graph_return() was updated to handle
this, but when function_graph tracer is using a threshold (only trace
functions that took longer than a specified time), it uses
trace_graph_thresh_return() instead.
This function was still incorrectly using the task struct recursion
word causing the function graph tracer to permanently set all
functions to "notrace"
- Fix thresh_return nosleep accounting
[79 lines not shown]
Merge branch 'Address-XDP-frags-having-negative-tailroom'
Larysa Zaremba says:
====================
Address XDP frags having negative tailroom
Aside from the issue described below, tailroom calculation does not account
for pages being split between frags, e.g. in i40e, enetc and
AF_XDP ZC with smaller chunks. These series address the problem by
calculating modulo (skb_frag_off() % rxq->frag_size) in order to get
data offset within a smaller block of memory. Please note, xskxceiver
tail grow test passes without modulo e.g. in xdpdrv mode on i40e,
because there is not enough descriptors to get to flipped buffers.
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
[114 lines not shown]
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such case, but due
to tailroom being stored as an unsigned int, it is reported to be somewhere
near UINT_MAX, resulting in a tail being grown, even if the requested
offset is too much (it is around 2K in the abovementioned test). This later
leads to all kinds of unspecific calltraces.
[77 lines not shown]
net: enetc: use truesize as XDP RxQ info frag_size
The only user of frag_size field in XDP RxQ info is
bpf_xdp_frags_increase_tail(). It clearly expects truesize instead of DMA
write size. Different assumptions in enetc driver configuration lead to
negative tailroom.
Set frag_size to the same value as frame_sz.
Fixes: 2768b2e2f7d2 ("net: enetc: register XDP RX queues with frag_size")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean at nxp.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-9-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
libeth, idpf: use truesize as XDP RxQ info frag_size
The only user of frag_size field in XDP RxQ info is
bpf_xdp_frags_increase_tail(). It clearly expects whole buffer size instead
of DMA write size. Different assumptions in idpf driver configuration lead
to negative tailroom.
To make it worse, buffer sizes are not actually uniform in idpf when
splitq is enabled, as there are several buffer queues, so rxq->rx_buf_size
is meaningless in this case.
Use truesize of the first bufq in AF_XDP ZC, as there is only one. Disable
growing tail for regular splitq.
Fixes: ac8a861f632e ("idpf: prepare structures to support XDP")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-8-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
i40e: fix registering XDP RxQ info
Current way of handling XDP RxQ info in i40e has a problem, where frag_size
is not updated when xsk_buff_pool is detached or when MTU is changed, this
leads to growing tail always failing for multi-buffer packets.
Couple XDP RxQ info registering with buffer allocations and unregistering
with cleaning the ring.
Fixes: a045d2f2d03d ("i40e: set xdp_rxq_info::frag_size")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-6-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
The only user of frag_size field in XDP RxQ info is
bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead
of DMA write size. Different assumptions in ice driver configuration lead
to negative tailroom.
This allows to trigger kernel panic, when using
XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to
6912 and the requested offset to a huge value, e.g.
XSK_UMEM__MAX_FRAME_SIZE * 100.
Due to other quirks of the ZC configuration in ice, panic is not observed
in ZC mode, but tailroom growing still fails when it should not.
Use fill queue buffer truesize instead of DMA write size in XDP RxQ info.
Fix ZC mode too by using the new helper.
Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side")
[4 lines not shown]
i40e: use xdp.frame_sz as XDP RxQ info frag_size
The only user of frag_size field in XDP RxQ info is
bpf_xdp_frags_increase_tail(). It clearly expects whole buffer size instead
of DMA write size. Different assumptions in i40e driver configuration lead
to negative tailroom.
Set frag_size to the same value as frame_sz in shared pages mode, use new
helper to set frag_size when AF_XDP ZC is active.
Fixes: a045d2f2d03d ("i40e: set xdp_rxq_info::frag_size")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-7-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
xsk: introduce helper to determine rxq->frag_size
rxq->frag_size is basically a step between consecutive strictly aligned
frames. In ZC mode, chunk size fits exactly, but if chunks are unaligned,
there is no safe way to determine accessible space to grow tailroom.
Report frag_size to be zero, if chunks are unaligned, chunk_size otherwise.
Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-3-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
ice: fix rxq info registering in mbuf packets
XDP RxQ info contains frag_size, which depends on the MTU. This makes the
old way of registering RxQ info before calculating new buffer sizes
invalid. Currently, it leads to frag_size being outdated, making it
sometimes impossible to grow tailroom in a mbuf packet. E.g. fragments are
actually 3K+, but frag size is still as if MTU was 1500.
Always register new XDP RxQ info after reconfiguring memory pools.
Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba at intel.com>
Link: https://patch.msgid.link/20260305111253.2317394-4-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
xdp: use modulo operation to calculate XDP frag tailroom
The current formula for calculating XDP tailroom in mbuf packets works only
if each frag has its own page (if rxq->frag_size is PAGE_SIZE), this
defeats the purpose of the parameter overall and without any indication
leads to negative calculated tailroom on at least half of frags, if shared
pages are used.
There are not many drivers that set rxq->frag_size. Among them:
* i40e and enetc always split page uniformly between frags, use shared
pages
* ice uses page_pool frags via libeth, those are power-of-2 and uniformly
distributed across page
* idpf has variable frag_size with XDP on, so current API is not applicable
* mlx5, mtk and mvneta use PAGE_SIZE or 0 as frag_size for page_pool
As for AF_XDP ZC, only ice, i40e and idpf declare frag_size for it. Modulo
operation yields good results for aligned chunks, they are all power-of-2,
between 2K and PAGE_SIZE. Formula without modulo fails when chunk_size is
[17 lines not shown]
selftests/tc-testing: Add tests exercising act_ife metalist replace behaviour
Add 2 test cases to exercise fix in act_ife's internal metalist
behaviour.
- Update decode ife action into encode with tcindex metadata
- Update decode ife action into encode with multiple metadata
Acked-by: Jamal Hadi Salim <jhs at mojatatu.com>
Signed-off-by: Victor Nogueira <victor at mojatatu.com>
Link: https://patch.msgid.link/20260304140603.76500-2-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
net/sched: act_ife: Fix metalist update behavior
Whenever an ife action replace changes the metalist, instead of
replacing the old data on the metalist, the current ife code is appending
the new metadata. Aside from being innapropriate behavior, this may lead
to an unbounded addition of metadata to the metalist which might cause an
out of bounds error when running the encode op:
[ 138.423369][ C1] ==================================================================
[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)
[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255
[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)
[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 138.425800][ C1] Call Trace:
[ 138.425804][ C1] <IRQ>
[ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)
[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)
[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))
[26 lines not shown]
net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop
When a standalone IPv6 nexthop object is created with a loopback device
(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies
it as a reject route. This is because nexthop objects have no destination
prefix (fc_dst=::), causing fib6_is_reject() to match any loopback
nexthop. The reject path skips fib_nh_common_init(), leaving
nhc_pcpu_rth_output unallocated. If an IPv4 route later references this
nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and
panics.
Simplify the check in fib6_nh_init() to only match explicit reject
routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback
promotion heuristic in fib6_is_reject() is handled separately by
ip6_route_info_create_nh(). After this change, the three cases behave
as follows:
1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):
RTF_REJECT is set, enters reject path, skips fib_nh_common_init().
[22 lines not shown]
selftests: net: add test for IPv4 route with loopback IPv6 nexthop
Add a regression test for a kernel panic that occurs when an IPv4 route
references an IPv6 nexthop object created on the loopback device.
The test creates an IPv6 nexthop on lo, binds an IPv4 route to it, then
triggers a route lookup via ping to verify the kernel does not crash.
./fib_nexthops.sh
Tests passed: 249
Tests failed: 0
Reviewed-by: Ido Schimmel <idosch at nvidia.com>
Signed-off-by: Jiayuan Chen <jiayuan.chen at shopee.com>
Reviewed-by: David Ahern <dsahern at kernel.org>
Link: https://patch.msgid.link/20260304113817.294966-3-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never
initialized because inet6_init() exits before ndisc_init() is called
which initializes it. If an IPv6 packet is injected into the interface,
route_shortcircuit() is called and a NULL pointer dereference happens on
neigh_lookup().
BUG: kernel NULL pointer dereference, address: 0000000000000380
Oops: Oops: 0000 [#1] SMP NOPTI
[...]
RIP: 0010:neigh_lookup+0x20/0x270
[...]
Call Trace:
<TASK>
vxlan_xmit+0x638/0x1ef0 [vxlan]
dev_hard_start_xmit+0x9e/0x2e0
__dev_queue_xmit+0xbee/0x14e0
packet_sendmsg+0x116f/0x1930
[13 lines not shown]
net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never
initialized because inet6_init() exits before ndisc_init() is called
which initializes it. Then, if neigh_suppress is enabled and an ICMPv6
Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will
dereference ipv6_stub->nd_tbl which is NULL, passing it to
neigh_lookup(). This causes a kernel NULL pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000268
Oops: 0000 [#1] PREEMPT SMP NOPTI
[...]
RIP: 0010:neigh_lookup+0x16/0xe0
[...]
Call Trace:
<IRQ>
? neigh_lookup+0x16/0xe0
br_do_suppress_nd+0x160/0x290 [bridge]
br_handle_frame_finish+0x500/0x620 [bridge]
[21 lines not shown]
Merge branch 'maintainers-annual-cleanup-of-inactive-maintainers'
Jakub Kicinski says:
====================
MAINTAINERS: annual cleanup of inactive maintainers
Annual cleanup of inactive maintainers under networking.
The goal is to make sure MAINTAINERS reflect reality for
code which is relatively actively changed (at least 70 commits
in the last 2 years or at least 120 commits in the last 5 years).
Those who either:
- were the initial author / "upstreamer" of the driver; or
- authored at least 1/3rd of the exiting code base (per git blame); or
- authored at least 25% of commits before becoming inactive
are moved to CREDITS.
The discovery of inactive maintainers was done using gitdm tools,
[7 lines not shown]
MAINTAINERS: remove Claudiu Manoil and Alexandre Belloni from Ocelot switch
We have not seen tags from Claudiu for the Ocelot switch driver
in over 5 years. He is active upstream in other NXP subsystems
(ENETC, gianfar), with 46 emails on lore since 2024.
We have not seen tags from Alexandre for the Ocelot switch driver
in over 5 years. He is very active upstream in other subsystems
(RTC, I3C, Atmel/Microchip SoC), with over 1,200 emails on lore
since 2024.
Vladimir Oltean is active.
Subsystem OCELOT ETHERNET SWITCH DRIVER
Changes 180 / 494 (36%)
Last activity: 2026-02-12
Vladimir Oltean <vladimir.oltean at nxp.com>:
Author c22ba07c827f 2026-02-10 00:00:00 33
Tags 026f6513c588 2026-02-12 00:00:00 39
Claudiu Manoil <claudiu.manoil at nxp.com>:
Alexandre Belloni <alexandre.belloni at bootlin.com>:
[12 lines not shown]
MAINTAINERS: remove Jonathan Lemon from OpenCompute PTP
We have not seen emails or tags from Jonathan in over 5 years,
and there is no recent mailing list activity.
Vadim Fedorenko is active.
Subsystem OPENCOMPUTE PTP CLOCK DRIVER
Changes 49 / 130 (37%)
Last activity: 2025-11-25
Jonathan Lemon <jonathan.lemon at gmail.com>:
Vadim Fedorenko <vadim.fedorenko at linux.dev>:
Author d3ca2ef0c915 2025-09-19 00:00:00 5
Tags 648282e2d1e5 2025-11-25 00:00:00 20
Top reviewers:
[7]: horms at kernel.org
[4]: jiri at nvidia.com
[3]: richardcochran at gmail.com
[2]: aleksandr.loktionov at intel.com
INACTIVE MAINTAINER Jonathan Lemon <jonathan.lemon at gmail.com>
[6 lines not shown]
MAINTAINERS: replace Taras Chornyi with Elad Nachman for Marvell Prestera
We have not seen emails or tags from Taras in over 5 years,
and there is no recent mailing list activity.
Elad Nachman has been providing reviews in the last couple
of years and is the top reviewer for this subsystem.
Subsystem MARVELL PRESTERA ETHERNET SWITCH DRIVER
Changes 39 / 157 (24%)
(No activity)
Top reviewers:
[8]: enachman at marvell.com
[6]: horms at kernel.org
[4]: idosch at nvidia.com
[3]: andrew at lunn.ch
[3]: jacob.e.keller at intel.com
[3]: jiri at nvidia.com
INACTIVE MAINTAINER Taras Chornyi <taras.chornyi at plvision.eu>
[2 lines not shown]
MAINTAINERS: remove Thomas Falcon from IBM ibmvnic
We have not seen emails or tags from Thomas's IBM address
(tlfalcon at linux.ibm.com) in over 5 years. Looks like Thomas
is active in perf tooling at Intel (thomas.falcon at intel.com).
Subsystem IBM Power SRIOV Virtual NIC Device Driver
Changes 49 / 134 (36%)
Last activity: 2025-08-26
Haren Myneni <haren at linux.ibm.com>:
Tags 3c14917953a5 2025-08-26 00:00:00 2
Rick Lindsley <ricklind at linux.ibm.com>:
Nick Child <nnac123 at linux.ibm.com>:
Author d93a6caab5d7 2025-03-25 00:00:00 14
Tags d93a6caab5d7 2025-03-25 00:00:00 16
Thomas Falcon <tlfalcon at linux.ibm.com>:
Top reviewers:
[22]: drt at linux.ibm.com
[13]: horms at kernel.org
[9 lines not shown]
MAINTAINERS: remove DENG Qingfang from MediaTek switch
We have not seen tags from DENG Qingfang for the MediaTek
switch driver in over 5 years. He is active upstream with
PPP/PPPoE patches in net-next. Chester and Daniel are active.
Subsystem MEDIATEK SWITCH DRIVER
Changes 26 / 70 (37%)
Last activity: 2025-12-01
Chester A. Unal <chester.a.unal at arinc9.com>:
Tags 585943b7ad30 2025-12-01 00:00:00 7
Daniel Golle <daniel at makrotopia.org>:
Author 497041d76301 2025-04-23 00:00:00 2
Tags 3b87e60d2131 2025-12-01 00:00:00 14
DENG Qingfang <dqfext at gmail.com>:
Sean Wang <sean.wang at mediatek.com>:
Top reviewers:
[4]: andrew at lunn.ch
[4]: florian.fainelli at broadcom.com
[7 lines not shown]
MAINTAINERS: replace Clark Wang with Frank Li for Freescale FEC
We have not seen tags from Clark for FEC in over 5 years.
He has some limited recent activity on the mailing list in other
NXP subsystems (stmmac, phy). Wei Fang and Shenwei Wang are active,
with decent review coverage (61%).
Frank Li has been reviewing code actively more recenty, let's
make it official.
Subsystem FREESCALE IMX / MXC FEC DRIVER
Changes 57 / 92 (61%)
Last activity: 2026-02-10
Wei Fang <wei.fang at nxp.com>:
Author 25eb3058eb70 2026-02-10 00:00:00 33
Tags 25eb3058eb70 2026-02-10 00:00:00 61
Shenwei Wang <shenwei.wang at nxp.com>:
Author d466c16026e9 2025-09-14 00:00:00 6
Tags d466c16026e9 2025-09-14 00:00:00 6
[12 lines not shown]
