====================
net/mlx5e: XDP, Add support for multi-packet per page
This series removes the limitation of having one packet per page in XDP
mode. This has the following implications:
- XDP in Striding RQ mode can now be used on 64K page systems.
- XDP in Legacy RQ mode was using a single packet per page which on 64K
page systems is quite inefficient. The improvement can be observed
with an XDP_DROP test when running in Legacy RQ mode on a ARM
Neoverse-N1 system with a 64K page size:
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1500 | 15.55 Mpps | 18.99 Mpps | 22.0 % |
| 9000 | 15.53 Mpps | 18.24 Mpps | 17.5 % |
+-----------------------------------------------+
After lifting this limitation, the series switches to using fragments
for the side page in non-linear mode. This small improvement is at most
visible for XDP_DROP tests with small 64B packets and a large enough MTU
for Striding RQ to be in non-linear mode:
+----------------------------------------------------------------------+
| System | MTU | baseline | this change | improvement |
|----------------------+------+------------+-------------+-------------|
| 4K page x86_64 [1] | 9000 | 26.30 Mpps | 30.45 Mpps | 15.80 % |
| 64K page aarch64 [2] | 9000 | 15.27 Mpps | 20.10 Mpps | 31.62 % |
+----------------------------------------------------------------------+
This series does not cover the xsk (AF_XDP) paths for 64K page systems.
net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode
Currently in XDP multi-buffer mode for striding rq a whole page is
allocated for the linear part of the XDP buffer. This is wasteful,
especially on systems with larger page sizes.
This change splits the page into fixed sized fragments. The page is
replenished when the maximum number of allowed fragments is reached.
When a fragment is not used, it will be simply recycled on next packet.
This is great for XDP_DROP as the fragment can be recycled for the next
packet. In the most extreme case (XDP_DROP everything), there will be 0
fragments used => only one linear page allocation for the lifetime of
the XDP program.
The previous page_pool size increase was too conservative (doubling the
size) and now there are much fewer allocations (1/8 for a 4K page). So
drop the page_pool size extension altogether when the linear side page
is used.
This small improvement is at most visible for XDP_DROP tests with small
64B packets and a large enough MTU for Striding RQ to be in non-linear
mode:
+----------------------------------------------------------------------+
| System | MTU | baseline | this change | improvement |
|----------------------+------+------------+-------------+-------------|
| 4K page x86_64 [1] | 9000 | 26.30 Mpps | 30.45 Mpps | 15.80 % |
| 64K page aarch64 [2] | 9000 | 15.27 Mpps | 20.10 Mpps | 31.62 % |
+----------------------------------------------------------------------+
Currently in striding rq there is one mlx5e_frag_page member per WQE for
the linear page. This linear page is used only in XDP multi-buffer mode.
This is wasteful because only one linear page is needed per rq: the page
gets refreshed on every packet, regardless of WQE. Furthermore, it is
not needed in other modes (non-XDP, XDP single-buffer).
This change moves the linear page into its own structure (struct
mlx5_mpw_linear_info) and allocates it only when necessary.
A special structure is created because an upcoming patch will extend
this structure to support fragmentation of the linear page.
Currently XDP mode always uses PAGE_SIZE strides. This limitation
existed because page fragment counting was not implemented when XDP was
added. Furthermore, due to this limitation there were other issues as
well on system with larger pages (e.g. 64K):
- XDP for Striding RQ was effectively disabled on such systems.
- Legacy RQ allows the configuration but uses a fixed scheme of one XDP
buffer per page which is inefficient.
As fragment counting was added during the driver conversion to
page_pool and the support for XDP multi-buffer, it is now possible
to remove this stride size limitation. This patch does just that.
Now it is possible to use XDP on systems with higher page sizes (e.g.
64K):
- For Striding RQ, loading the program is no longer blocked.
Although a 64K page can fit any packet, MTUs that result in
stride > 8K will still make the RQ in non-linear mode. That's
because the HW doesn't support a higher than 8K stride.
- For Legacy RQ, the stride size was PAGE_SIZE which was very
inefficient. Now the stride size will be calculated relative to MTU.
Legacy RQ will always be in linear mode for larger system pages.
This can be observed with an XDP_DROP test [1] when running
in Legacy RQ mode on a ARM Neoverse-N1 system with a 64K
page size:
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1500 | 15.55 Mpps | 18.99 Mpps | 22.0 % |
| 9000 | 15.53 Mpps | 18.24 Mpps | 17.5 % |
+-----------------------------------------------+
There are performance benefits for Striding RQ mode as well:
- Striding RQ non-linear mode now uses 256B strides, just like
non-XDP mode.
- Striding RQ linear mode can now fit a number of XDP buffers per page
that is relative to the MTU size. That means that on 4K page systems
and a small enough MTU, 2 XDP buffers can fit in one page.
The above benefits for Striding RQ can be observed with an
XDP_DROP test [1] when running on a 4K page x86_64 system
(Intel Xeon Platinum 8580):
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1000 | 28.36 Mpps | 33.98 Mpps | 19.82 % |
| 9000 | 20.76 Mpps | 26.30 Mpps | 26.70 % |
+-----------------------------------------------+
[1] Test description:
- xdp-bench with XDP_DROP
- RX: single queue
- TX: sends 64B packets to saturate CPU on RX side
net/mlx5e: XDP, Improve dma address calculation of linear part for XDP_TX
When calculating the dma address of the linear part of an XDP frame, the
formula assumes that there is a single XDP buffer per page. Extend the
formula to allow multiple XDP buffers per page by calculating the data
offset in the page.
This is a preparation for the upcoming removal of a single XDP buffer
per page limitation when the formula will no longer be correct.
net/mlx5e: XSK, Increase size for chunk_size param
When 64K pages are used, chunk_size can take the 64K value
which doesn't fit in u16. This results in overflows that
are detected in mlx5e_mpwrq_log_wqe_sz().
songxiebing [Wed, 25 Mar 2026 02:17:52 +0000 (10:17 +0800)]
ASoC: intel: avs: Fix type mismatch in variable assignment
The input parameter requirement for snd_pcm_format_physical_with is
snd_pcm_format_t,but params->codec.format is __u32, resulting in a
mismatch error:
sparse warnings: (new ones prefixed by >>)
>> sound/soc/intel/avs/probes.c:147:58: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected restricted snd_pcm_format_t [usertype] format @@ got unsigned int [usertype] format @@
sound/soc/intel/avs/probes.c:147:58: sparse: expected restricted snd_pcm_format_t [usertype] format
sound/soc/intel/avs/probes.c:147:58: sparse: got unsigned int [usertype] format
So here, the format is cast to snd_pcm_format_t.
Signed-off-by: songxiebing <songxiebing@kylinos.cn> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512190032.hnwn9mCV-lkp@intel.com/ Link: https://patch.msgid.link/20260325021752.238203-1-songxiebing@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org>
GC scratch allocations can wrap around and use the same buffer twice, and
the current code fails to account for that. So far this worked due to
rounding in the block layer, but changes to the bio allocator drop the
over-provisioning and generic/256 or generic/361 will now usually fail
when running against the current block tree.
Simplify the allocation to always pass the maximum value that is easier to
verify, as a saving of up to one bvec per allocation isn't worth the
effort to verify a complicated calculated value.
Fixes: 102f444b57b3 ("xfs: rework zone GC buffer management") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: untangle the open zones reporting in mountinfo
Keeping a value per line makes parsing much easier, so move the maximum
number of open zones into a separate line, and also add a new line for
the number of open open GC zones. While that has to be either 0 or 1
currently having a value future-proofs the interface for adding more open
GC zones if needed.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Add a sysfs attribute for the current number of open zones so that it
can be trivially read from userspace in monitoring or testing software.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Currently the open zone used for garbage collection is a special snow
flake, and it has been a bit annoying for some further zoned XFS work
I've been doing.
Remove the zi_open_gc_field and instead track the open GC zone in the
zi_open_zones list together with the normal open zones, and keep an extra
pointer and a reference of in the GC thread's data structure. This means
anything iterating over open zones just has to look at zi_open_zones, and
the life time rules are consistent. It also helps to add support for
multiple open GC zones if we ever need them, and removes a bit of code.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Currently picking of the GC target zone is a bit odd as it is done both
in the main "can we start new GC cycles" routine and in the low-level
block allocator for GC. This was mostly done to work around the rules
for when code in a waitqueue wait loop can sleep.
But with a trick to check if the process state has been set to running to
discover if the wait loop has to be retried, all this becomes much
simpler. We can select a GC zone just before writing, and bail out of
starting new work if we can't find a usable zone.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Merge xfs_zone_gc_ensure_target into xfs_zone_gc_select_target
to keep all zone selection code together.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: rename xfs_zone_gc_iter_next to xfs_zone_gc_iter_irec
This function returns the current iterator position, which makes the
_next postfix a bit misleading.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The open zone is what holds the rtg reference for us. This doesn't
matter until we support shrinking, and even then is rather theoretical
because we can't shrink away a just filled zone in a tiny race window,
but let's play safe here.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs: add a separate tracepoint for stealing an open zone for GC
The case where we have to reuse an already open zone warrants a different
trace point vs the normal opening of a GC zone.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The code currently used to select the new GC target zone when the
previous one is full also handles the case where there is no current GC
target zone at all. Make use of that to simplify the logic in
xfs_zone_gc_mount.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()
ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is
zero or i_dtime is set, treating them as deleted. However, the case of
i_nlink == 0 with a non-zero mode and zero dtime slips through. Since
ext2 has no orphan list, such a combination can only result from
filesystem corruption - a legitimate inode deletion always sets either
i_dtime or clears i_mode before freeing the inode.
A crafted image can exploit this gap to present such an inode to the
VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via
ext2_unlink(), ext2_rename() and ext2_rmdir():
Extend the existing i_nlink == 0 check to also catch this case,
reporting the corruption via ext2_error() and returning -EFSCORRUPTED.
This rejects the inode at load time and prevents it from reaching any
of the namei.c paths.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
David Carlier [Sun, 5 Apr 2026 15:47:17 +0000 (16:47 +0100)]
ext2: use get_random_u32() where appropriate
Use the typed random integer helpers instead of
get_random_bytes() when filling a single integer variable.
The helpers return the value directly, require no pointer
or size argument, and better express intent.
Haoxiang Li [Wed, 1 Apr 2026 04:02:41 +0000 (12:02 +0800)]
xfs: fix a resource leak in xfs_alloc_buftarg()
In the error path, call fs_put_dax() to drop the DAX
device reference.
Fixes: 6f643c57d57c ("xfs: implement ->notify_failure() for XFS") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
When running on conventional zones or devices, the zoned allocator does
not have a real write pointer, but instead fakes it up at mount time
based on the last block recorded in the rmap. This can create spurious
"open" zones when the last written blocks in a conventional zone are
invalidated. Add a loop to the mount code to find the conventional zone
with the highest used block in the rmap tree and "finish" it until we
are below the open zones limit.
While we're at it, also error out if there are too many open sequential
zones, which can only happen when the user overrode the max open zones
limit (or with really buggy hardware reducing the limit, but not much
we can do about that).
Fixes: 4e4d52075577 ("xfs: add the zoned space allocator") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_mount_zones has grown a bit too big and unorganized. Split the
zone reporting loop into a separate helper, hiding the rtg variable
there. Print the mount message last, and also keep the VFS writeback
chunk size last instead of in the middle of the logic to calculate
the free/available blocks.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Yuto Ohnuki [Sat, 28 Mar 2026 17:34:10 +0000 (17:34 +0000)]
xfs: fix integer overflow in busy extent sort comparator
xfs_extent_busy_ag_cmp() subtracts two uint32_t values (group
numbers and block numbers) and returns the result as s32. When
the difference exceeds INT_MAX, the result overflows and the sort
order is corrupted.
Use cmp_int() instead, as was done in commit 362c49098086 ("xfs:
fix integer overflow in bmap intent sort comparator").
Fixes: 4a137e09151e ("xfs: keep a reference to the pag for busy extents") Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Yuto Ohnuki [Sat, 28 Mar 2026 17:34:09 +0000 (17:34 +0000)]
xfs: fix integer overflow in deferred intent sort comparators
xfs_extent_free_diff_items(), xfs_refcount_update_diff_items(), and
xfs_rmap_update_diff_items() subtract two uint32_t group numbers
and return the result as int, which can overflow when the difference
exceeds INT_MAX.
Use cmp_int() instead, as was done in commit 362c49098086 ("xfs:
fix integer overflow in bmap intent sort comparator").
Fixes: c13418e8eb37 ("xfs: give xfs_rmap_intent its own perag reference") Fixes: f6b384631e1e ("xfs: give xfs_extfree_intent its own perag reference") Fixes: 00e7b3bac1dc ("xfs: give xfs_refcount_intent its own perag reference") Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
John Hubbard [Sat, 4 Apr 2026 02:12:02 +0000 (19:12 -0700)]
rust: sizes: add SizeConstants trait for device address space constants
The SZ_* constants are usize, matching the CPU pointer width. But
device address spaces have their own widths (32-bit MMIO windows,
64-bit GPU framebuffers, etc.), so drivers end up casting these
constants with SZ_1M as u64 or helper functions. This adds
boilerplate with no safety benefit.
Add a SizeConstants trait with associated SZ_* constants, implemented
for u32, u64, and usize. With the trait in scope, callers write
u64::SZ_1M or u32::SZ_4K to get the constant in their device's
native width. All SZ_* values fit in a u32, so every implementation
is lossless. Each impl has a const assert to catch any future
constant that would overflow.
A define_sizes! macro generates everything from a single internal
list of names. The macro takes the target types as arguments, so
adding a new target type requires changing only the call site.
spi: spi-fsl-lpspi: make struct lpspi_config::mode u32
The struct lpspi_config::mode holds a copy of the mode of struct
spi_device::mode. In commit 937e6d756422 ("spi: expand mode support") the
struct spi_device::mode was increased from u16 to u32.
Increase the struct lpspi_config::mode to u32 avoid truncating the mode
variable.
spi: spi-fsl-lpspi: fsl_lpspi_set_cmd(): remove obfuscated and obsolete assignment of TCR_CPOL and SPI_CPHA
Commit 7ae4d097b752 ("spi: spi-fsl-lpspi: Handle clock polarity and phase")
enhances the driver with clock polarity and phase handling.
Among other things that commit in fsl_lpspi_set_cmd() explicitly set the
bits TCR_CPOL and TCR_CPHA bits in the TCR register depending on their
corresponding bits in the SPI mode (SPI_CPOL and SPI_CPHA), to configure
clock polarity and phase.
That change made the assignment of the lowest 2 bits of lpspi_config::mode
shifted by << 30 to the TCR register obsolete. The lowest 2 bits of struct
lpspi_config::mode (= SPI_CPOL and SPI_CPHA) match the corresponding bits
in the TCR register (TCR_CPOL and TCR_CPHA) if shifted.
Keep the better readable and maintainable version provided in commit 7ae4d097b752 ("spi: spi-fsl-lpspi: Handle clock polarity and phase") and
remove the obfuscated version.
spi: spi-fsl-lpspi: fsl_lpspi_set_cmd(): use mode from struct fsl_lpspi_data::config::mode
Commit 7ae4d097b752 ("spi: spi-fsl-lpspi: Handle clock polarity and phase")
enhances the driver with clock polarity and phase handling. That commit
adds a 2nd argument ("struct spi_device *spi") to the fsl_lpspi_set_cmd()
function.
The "spi" pointer is used to access the "mode" of the current transfer.
However the mode is already available via "fsl_lpspi->config.mode".
To simplify the driver remove the 2nd argument and use
"fsl_lpspi->config.mode" to access the mode.
net: rfkill: prevent unlimited numbers of rfkill events from being created
Userspace can create an unlimited number of rfkill events if the system
is so configured, while not consuming them from the rfkill file
descriptor, causing a potential out of memory situation. Prevent this
from bounding the number of pending rfkill events at a "large" number
(i.e. 1000) to prevent abuses like this.
Cc: Johannes Berg <johannes@sipsolutions.net> Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026033013-disfigure-scroll-e25e@gregkh Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johan Hovold [Fri, 27 Mar 2026 11:32:19 +0000 (12:32 +0100)]
wifi: rt2x00usb: fix devres lifetime
USB drivers bind to USB interfaces and any device managed resources
should have their lifetime tied to the interface rather than parent USB
device. This avoids issues like memory leaks when drivers are unbound
without their devices being physically disconnected (e.g. on probe
deferral or configuration changes).
Fix the USB anchor lifetime so that it is released on driver unbind.
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB") Cc: stable@vger.kernel.org # 4.7 Cc: Vishal Thanki <vishalthanki@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260327113219.1313748-1-johan@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Pengpeng Hou [Mon, 23 Mar 2026 07:45:51 +0000 (15:45 +0800)]
wifi: brcmfmac: validate bsscfg indices in IF events
brcmf_fweh_handle_if_event() validates the firmware-provided interface
index before it touches drvr->iflist[], but it still uses the raw
bsscfgidx field as an array index without a matching range check.
Reject IF events whose bsscfg index does not fit in drvr->iflist[]
before indexing the interface array.
Shawn Lin [Mon, 30 Mar 2026 09:53:21 +0000 (17:53 +0800)]
gpio: rockchip: convert to dynamic GPIO base allocation
This driver is used on device tree based platform. Use dynamic
GPIO numberspace base to suppress the warning:
gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
gpio gpiochip2: Static allocation of GPIO base is deprecated, use dynamic allocation.
gpio gpiochip3: Static allocation of GPIO base is deprecated, use dynamic allocation.
gpio gpiochip4: Static allocation of GPIO base is deprecated, use dynamic allocation.
dev-err-probe is an overengineered solution to a simple problem. Use a
combination of wait_for_probe() and device_is_bound() to synchronously
wait for the platform device to probe.
dev-err-probe is an overengineered solution to a simple problem. Use a
combination of wait_for_probe() and device_is_bound() to synchronously
wait for the platform device to probe.
dev-err-probe is an overengineered solution to a simple problem. Use a
combination of wait_for_probe() and device_is_bound() to synchronously
wait for the platform device to probe.
Aleksa Sarai [Tue, 31 Mar 2026 14:46:21 +0000 (01:46 +1100)]
dcache: permit dynamic_dname()s up to NAME_MAX
dynamic_dname() has had an implicit limit of 64 characters since it was
introduced in commit c23fbb6bcb3e ("VFS: delay the dentry name
generation on sockets and pipes"), however it seems that this was a
fairly arbitrary number (suspiciously it was double the previously
hardcoded buffer size).
NAME_MAX seems like a more reasonable and consistent limit for d_name
lengths. While we're at it, we can also remove the unnecessary
stack-allocated array and just memmove() the formatted string to the end
of the buffer.
It should also be noted that at least one driver (in particular,
liveupdate's usage of anon_inode for session files) already exceeded
this limit without noticing that readlink(/proc/self/fd/$n) always
returns -ENAMETOOLONG, so this fixes those drivers as well.
Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") Fixes: c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes") Signed-off-by: Aleksa Sarai <aleksa@amutable.com> Link: https://patch.msgid.link/20260401-dynamic-dname-name_max-v1-1-8ca20ab2642e@amutable.com Tested-by: Luca Boccassi <luca.boccassi@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
This driver provides support for new way of handling platform events,
through the use of GPIO-signaled ACPI events. This mechanism is used on
Intel client platforms released in 2026 and later, starting with Intel
Nova Lake.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260401174526.60881-1-alan.borzeszkowski@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Francesco Lavra [Mon, 30 Mar 2026 16:19:14 +0000 (18:19 +0200)]
pinctrl: mcp23s08: Disable all pin interrupts during probe
A chip being probed may have the interrupt-on-change feature enabled on
some of its pins, for example after a reboot. This can cause the chip to
generate interrupts for pins that don't have a registered nested handler,
which leads to a kernel crash such as below:
This issue has always been present, but has been latent until commit
"f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at probe and
switch cache type"), which correctly removed reg_defaults from the regmap
and as a side effect changed the behavior of the interrupt handler so that
the real value of the MCP_GPINTEN register is now being read from the chip
instead of using a bogus 0 default value; a non-zero value for this
register can trigger the invocation of a nested handler which may not exist
(yet).
Fix this issue by disabling all pin interrupts during initialization.
Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
fs: attr: fix comment formatting and spelling issues
Fix minor comment issues in fs/attr.c reported by checkpatch:
- Wrap long comment lines to comply with the 75-character limit
- Correct spelling of “overriden” to “overridden”
lib/tests/slub_kunit: add a test case for {kmalloc,kfree}_nolock
Testing invocation of {kmalloc,kfree}_nolock() during kmalloc() or
kfree() is tricky, and it is even harder to ensure that slowpaths are
properly tested. Lack of such testing has led to late discovery of
the bug fixed by commit a1e244a9f177 ("mm/slab: use prandom if
!allow_spin").
Add a slub_kunit test that allocates and frees objects in a tight loop
while a perf event triggers interrupts (NMI or hardirq depending on
the arch) on the same task, invoking {kmalloc,kfree}_nolock() from the
overflow handler.
Brian Masney [Fri, 3 Apr 2026 21:12:17 +0000 (17:12 -0400)]
irqchip/irq-pic32-evic: Add __maybe_unused for board_bind_eic_interrupt in COMPILE_TEST
There are a few ifdefs in this driver so that it can be compiled on all
architectures when COMPILE_TEST is set. board_bind_eic_interrupt is
defined in arch/mips/ for normal usage, however when this driver is
compiled with COMPILE_TEST on other architectures, it is defined as a
static variable inside this driver. This causes the following warning:
drivers/irqchip/irq-pic32-evic.c:54:15: warning: variable
'board_bind_eic_interrupt' set but not used [-Wunused-but-set-global]
54 | static void (*board_bind_eic_interrupt)(int irq,
int regset);
| ^
Annotate the static variable with __maybe_unused to avoid having to put
even more ifdefs into this driver.
Fixes: 282f8b547d51d ("irqchip/irq-pic32-evic: Define board_bind_eic_interrupt for !MIPS builds") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260403-irq-pic32-evic-unused-v1-1-447cdc0675ec@redhat.com Closes: https://lore.kernel.org/oe-kbuild-all/202603300715.4HuMMAFb-lkp@intel.com/
Hao Li [Fri, 3 Apr 2026 07:37:36 +0000 (15:37 +0800)]
slub: use N_NORMAL_MEMORY in can_free_to_pcs to handle remote frees
Memory hotplug now keeps N_NORMAL_MEMORY up to date correctly, so make
can_free_to_pcs() use it.
As a result, when freeing objects on memoryless nodes, or on nodes that
have memory but only in ZONE_MOVABLE, the objects can be freed to the
sheaf instead of going through the slow path.
Signed-off-by: Hao Li <hao.li@linux.dev> Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Link: https://patch.msgid.link/20260403073958.8722-1-hao.li@linux.dev Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Zhengchuan Liang [Sun, 22 Mar 2026 18:46:08 +0000 (11:46 -0700)]
net: af_key: zero aligned sockaddr tail in PF_KEY exports
PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr
payload space, so IPv6 addresses occupy 32 bytes on the wire. However,
`pfkey_sockaddr_fill()` initializes only the first 28 bytes of
`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.
Not every PF_KEY message is affected. The state and policy dump builders
already zero the whole message buffer before filling the sockaddr
payloads. Keep the fix to the export paths that still append aligned
sockaddr payloads with plain `skb_put()`:
Eric Biggers [Sun, 5 Apr 2026 01:15:13 +0000 (18:15 -0700)]
xfrm: Drop support for HMAC-RIPEMD-160
Drop support for HMAC-RIPEMD-160 from IPsec to reduce the UAPI surface
and simplify future maintenance. It's almost certainly unused.
RIPEMD-160 received some attention in the early 2000s when SHA-* weren't
quite as well established. But it never received much adoption outside
of certain niches such as Bitcoin.
It's actually unclear that Linux + IPsec + HMAC-RIPEMD-160 has *ever*
been used, even historically. When support for it was added in 2003, it
was done so in a "cleanup" commit without any justification [1]. It
didn't actually work until someone happened to fix it 5 years later [2].
That person didn't use or test it either [3]. Finally, also note that
"hmac(rmd160)" is by far the slowest of the algorithms in aalg_list[].
Of course, today IPsec is usually used with an AEAD, such as AES-GCM.
But even for IPsec users still using a dedicated auth algorithm, they
almost certainly aren't using, and shouldn't use, HMAC-RIPEMD-160.
Thus, let's just drop support for it. Note: no kconfig update is
needed, since CRYPTO_RMD160 wasn't actually being selected anyway.
References:
[1] linux-history commit d462985fc1941a47
("[IPSEC]: Clean up key manager algorithm handling.")
[2] linux commit a13366c632132bb9
("xfrm: xfrm_algo: correct usage of RIPEMD-160")
[3] https://lore.kernel.org/all/1212340578-15574-1-git-send-email-rueegsegger@swiss-it.ch
Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Miguel Ojeda [Tue, 7 Apr 2026 08:40:11 +0000 (10:40 +0200)]
Merge patch series "rust: bump minimum Rust and `bindgen` versions"
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's Rust versions as our minimum
supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie was released with `bindgen` 0.71.1, which it also still
uses to this day [4].
Debian Trixie's release happened on 2025-08-09 [5], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
There are a few main parts to the series, in this order:
- A few cleanups that can be performed before the bumps.
- The Rust bump (and its cleanups).
- The `bindgen` bump (and its cleanups).
- Documentation updates.
- The `cfi_encoding` patch, added here, which needs the bump.
- The per-version flags support and a Clippy cleanup on top.
struct xfrm_user_report is a __u8 proto field followed by a struct
xfrm_selector which means there is three "empty" bytes of padding, but
the padding is never zeroed before copying to userspace. Fix that up by
zeroing the structure before setting individual member variables.
Cc: stable <stable@kernel.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
struct xfrm_usersa_id has a one-byte padding hole after the proto
field, which ends up never getting set to zero before copying out to
userspace. Fix that up by zeroing out the whole structure before
setting individual variables.
Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
The root cause is a double call to xfrm_pol_hold_rcu() in
xfrm_migrate_policy_find(). The lookup function already returns
a policy with held reference, making the second call redundant.
Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount
imbalance and prevent the memory leak.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype") Signed-off-by: Kotlyarov Mihail <mihailkotlyarow@gmail.com> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
xfrm: hold dev ref until after transport_finish NF_HOOK
After async crypto completes, xfrm_input_resume() calls dev_put()
immediately on re-entry before the skb reaches transport_finish.
The skb->dev pointer is then used inside NF_HOOK and its okfn,
which can race with device teardown.
Remove the dev_put from the async resumption entry and instead
drop the reference after the NF_HOOK call in transport_finish,
using a saved device pointer since NF_HOOK may consume the skb.
This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip
the okfn.
For non-transport exits (decaps, gro, drop) and secondary
async return points, release the reference inline when
async is set.
xfrm: Wait for RCU readers during policy netns exit
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the
policy work items and deleting all policies, but it does not wait for
concurrent RCU readers to leave their read-side critical sections first.
The policy_bydst tables are published via rcu_assign_pointer() and are
looked up through rcu_dereference_check(), so netns teardown must also
wait for an RCU grace period before freeing the table memory.
Fix this by adding synchronize_rcu() before freeing the policy hash tables.
Miguel Ojeda [Sun, 5 Apr 2026 23:53:09 +0000 (01:53 +0200)]
rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
The Clippy `precedence` lint was extended in Rust 1.85.0 to include
bitmasking and shift operations [1]. However, because it generated
many hits, in Rust 1.86.0 it was split into a new `precedence_bits`
lint which is not enabled by default [2].
In other words, only Rust 1.85 has a different behavior. For instance,
it reports:
warning: operator precedence can trip the unwary
--> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5
|
16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT
17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI
| |_________________________________________^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
= note: `-W clippy::precedence` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
help: consider parenthesizing your expression
|
16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI)
|
While so far we try our best to keep all versions Clippy-clean, the
minimum (which is now Rust 1.85.0 after the bump) and the latest stable
are the most important ones; and this may be considered a "false positive"
with respect to the behavior in other versions.
Thus allow this lint for this version using the per-version flags
mechanism introduced in the previous commit.
Miguel Ojeda [Sun, 5 Apr 2026 23:53:08 +0000 (01:53 +0200)]
rust: kbuild: support global per-version flags
Sometimes it is useful to gate global Rust flags per compiler version.
For instance, we may want to disable a lint that has false positives in
a single version [1].
We already had helpers like `rustc-min-version` for that, which we use
elsewhere, but we cannot currently use them for `rust_common_flags`,
which contains the global flags for all Rust code (kernel and host),
because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
does not exist when `rust_common_flags` is defined.
Thus, to support that, introduce `rust_common_flags_per_version`,
defined after the `include/config/auto.conf` inclusion (where
`CONFIG_RUSTC_VERSION` becomes available), and append it to
`rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
In addition, move the expansion of `HOSTRUSTFLAGS` to the same place,
so that users can also override per-version flags [2].
Alice Ryhl [Sun, 5 Apr 2026 23:53:07 +0000 (01:53 +0200)]
rust: declare cfi_encoding for lru_status
By default bindgen will convert 'enum lru_status' into a typedef for an
integer. For the most part, an integer of the same size as the enum
results in the correct ABI, but in the specific case of CFI, that is not
the case. The CFI encoding is supposed to be the same as a struct called
'lru_status' rather than the name of the underlying native integer type.
To fix this, tell bindgen to generate a newtype and set the CFI type
explicitly. Note that we need to set the CFI attribute explicitly as
bindgen is using repr(transparent), which is otherwise identical to the
inner type for ABI purposes.
This allows us to remove the page range helper C function in Binder
without risking a CFI failure when list_lru_walk calls the provided
function pointer.
The --with-attribute-custom-enum argument requires bindgen v0.71 or
greater.
[ In particular, the feature was added in 0.71.0 [1][2].
In addition, `feature(cfi_encoding)` has been available since
Rust 1.71.0 [3].
My testing procedure was to add this to the android17-6.18 branch and
verify that rust_shrink_free_page is successfully called without crash,
and verify that it does in fact crash when the cfi_encoding is set to
other values. Note that I couldn't test this on android16-6.12 as that
branch uses a bindgen version that is too old.
Miguel Ojeda [Sun, 5 Apr 2026 23:53:06 +0000 (01:53 +0200)]
docs: rust: general-information: use real example
Currently the example in the documentation shows a version-based name
for the Kconfig example:
RUSTC_VERSION_MIN_107900
The reason behind it was to possibly avoid repetition in case several
features used the same minimum.
However, we ended up preferring to give them a descriptive name for each
feature added even if that could lead to some repetition. In practice,
the repetition has not happened so far, and even if it does at some point,
it is not a big deal.
Thus replace the example in the documentation with one of our current
examples (after removing previous ones from the bump), to show how they
actually look like, and in case someone `grep`s for it.
In addition, it has the advantage that it shows the `RUSTC_HAS_*`
pattern we follow in `init/Kconfig`, similar to the C side.
The versions provided nowadays by even a distribution like Debian Stable
(and Debian Old Stable) are newer than those mentioned [1].
Thus remove the workaround.
Note that the minimum binutils version in the kernel is still 2.30, so
one could argue part of the note is still relevant, but it is unlikely
a kernel developer using such an old binutils is enabling Rust on a
modern kernel, especially when using distribution toolchains, e.g. the
Rust minimum version is not satisfied by Debian Old Stable.
So we are at the point where keeping the docs short and relevant for
essentially everyone is probably the better trade-off.
Miguel Ojeda [Sun, 5 Apr 2026 23:53:01 +0000 (01:53 +0200)]
docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few
weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu
25.10 has [2][3].
We could update the title and the paragraph, but to simplify and to
make it more consistent with the other distributions' sections, let's
instead just remove that title. It will also reduce the differences
later on to keep it updated. Eventually, when we remove the remaining
subsection for older LTSs, Ubuntu should be a small section like the
other distributions.
Thus remove the title and add the mention of Ubuntu 26.04 LTS.
Now that the minimum supported Rust version is bumped, bump the versioned
Rust packages [1][2][3][4] to that version for Ubuntu in the Quick
Start guide.
In addition, add "may" to the `RUST_LIB_SRC` line since it does not look
like it is needed from a quick test in a Ubuntu 24.04 LTS container.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:56 +0000 (01:52 +0200)]
rust: kbuild: update `bindgen --rust-target` version and replace comment
As the comment in the `Makefile` explains, previously, we needed to
limit ourselves to the list of Rust versions known by `bindgen` for its
`--rust-target` option [1].
In other words, we needed to consult the versions known by the minimum
version of `bindgen` that we supported.
Now that we bumped the minimum version of `bindgen`, that limitation
does not apply anymore since `bindgen` 0.71.0 [2].
Thus replace the comment and simply write our minimum supported Rust
version there, which is much simpler.
See commit 7a5f93ea5862 ("rust: kbuild: set `bindgen`'s Rust target
version") for more details.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:53 +0000 (01:52 +0200)]
rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's `bindgen` versions as our minimum
supported version.
Debian Trixie was released with `bindgen` 0.71.1, which it still uses
to this day [2].
Debian Trixie's release happened on 2025-08-09 [3], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
Thus bump the minimum to the new version.
Then, in later commits, clean up most of the workarounds and other bits
that this upgrade of the minimum allows us.
Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already
unsupported Ubuntu 25.04 had it), and they also provide versioned packages
with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5].
Miguel Ojeda [Sun, 5 Apr 2026 23:52:51 +0000 (01:52 +0200)]
rust: macros: simplify code using `feature(extract_if)`
`feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last
significant change happened in Rust 1.85.0 [3] when the range parameter
was added.
That is, with our new minimum version, we can start using the feature.
Thus simplify the code using the feature and remove the TODO comment.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:46 +0000 (01:52 +0200)]
rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
With the Rust version bump in place, the `RUSTC_HAS_COERCE_POINTEE`
Kconfig (automatic) option is always true.
Thus remove the option and simplify the code.
In particular, this includes removing our use of the predecessor unstable
features we used with Rust < 1.84.0 (`coerce_unsized`, `dispatch_from_dyn`
and `unsize`).
Miguel Ojeda [Sun, 5 Apr 2026 23:52:45 +0000 (01:52 +0200)]
rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify code
With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED`
Kconfig (automatic) option is always true.
Thus remove the option and simplify the code.
In particular, this includes removing the `slice` module which contained
the temporary slice helpers, i.e. the `AsFlattened` extension trait and
its `impl`s.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:44 +0000 (01:52 +0200)]
rust: simplify `RUSTC_VERSION` Kconfig conditions
With the Rust version bump in place, several Kconfig conditions based on
`RUSTC_VERSION` are always true.
Thus simplify them.
The minimum supported major LLVM version by our new Rust minimum version
is now LLVM 18, instead of LLVM 16. However, there are no possible
cleanups for `RUSTC_LLVM_VERSION`.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:43 +0000 (01:52 +0200)]
rust: allow globally `clippy::incompatible_msrv`
`clippy::incompatible_msrv` is not buying us much, and we discussed
allowing it several times in the past.
For instance, there was recently another patch sent to `allow` it where
needed [1]. While that particular case would not be needed after the
minimum version bump to 1.85.0, it is simpler to just allow it to prevent
future instances.
[ In addition, the lint fired without taking into account the features
that have been enabled in a crate [2]. While this was improved in Rust
1.90.0 [3], it would still fire in a case like this patch. ]
Thus do so, and remove the last instance of locally allowing it we have
in the tree (except the one in the vendored `proc_macro2` crate).
Note that we still keep the `msrv` config option in `clippy.toml` since
that affects other lints as well.
Miguel Ojeda [Sun, 5 Apr 2026 23:52:41 +0000 (01:52 +0200)]
rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's Rust versions as our minimum
supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie's release happened on 2025-08-09 [4], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
Thus bump the minimum to the new version.
Then, in later commits, clean up most of the workarounds and other bits
that this upgrade of the minimum allows us.
pin-init was left as-is since the patches come from upstream. And the
vendored crates are unmodified, since we do not want to change those.
Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
tests can also be updated, but there are no suitable ones to simplify.
Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
provide versioned packages with a Rust 1.85.1 toolchain even back to
Ubuntu 22.04 LTS [6].
Miguel Ojeda [Sun, 5 Apr 2026 23:52:39 +0000 (01:52 +0200)]
rust: kbuild: remove unneeded old `allow`s for generated layout tests
The issue that required `allow`s for `cfg(test)` code generated by
`bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1],
so it could have been removed even before the version bump, but it does
not hurt.
projects / thirdparty / linux.git / log
