Hongling Zeng [Mon, 31 Aug 2026 05:38:01 +0000 (13:38 +0800)]
btrfs: take commit root semaphore when iterating in mark_block_group_to_copy()
mark_block_group_to_copy() iterates over the commit root with
skip_locking=true. A concurrent transaction commit can swap and free
the commit root during iteration, causing use-after-free when
accessing extent buffers.
Fix it by using path->need_commit_sem to protect the commit root search.
Fixes: 78ce9fc269af ("btrfs: zoned: mark block groups to copy for device-replace") CC: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
btrfs: use kvmalloc() to allocate compression workspace buffer for zlib and zstd
With the experimental bs > ps support, the workspace buffer for both
zlib and zstd can be as large as 64K, and on 4K page sized systems such
kmalloc() calls have a much higher chance to fail, as that requires
physically contiguous memory to fulfill such allocation.
The same also applies to S390's hardware accelerated path, which
requires a buffer size of 4 pages.
Meanwhile lzo is already using kvmalloc() for its buffer, and there is
no special requirement for any physically contiguous memory anyway.
So change the zlib and zstd workspace buffer allocation to use
kvmalloc() to reduce the chance of memory allocation failure.
Reviewed-by: Daniel Vacek <neelx@suse.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Although btrfs doesn't support inlined extents larger than PAGE_SIZE
for bs > ps cases, it's still possible for the experimental bs > ps
support to mount a btrfs created on a system with a much larger page size,
thus can still hit an inlined extent that is way larger than the current
page size.
E.g. a compressed inline extent which has 32K compressed size, is created
on 64K page sized ARM64 with 64K sectorsize, then mounted on x86_64 with
the experimental bs > ps support.
In that case, when reading the compressed inline extent, we need to
allocate a buffer that is the same size as the compressed inline extent
(32K).
That kmalloc() call will request physically contiguous memory for that
32K allocation, and if the system has a very fragmented memory space,
such allocation can fail.
But there is really no reason that we require such buffer to be
physically contiguous, so change it to kvmalloc() to reduce the chance
of allocation failure for bs > ps cases.
And for all bs <= ps cases, the kvmalloc() call will just be fulfilled by
kmalloc() so this will not bring any change to the most common cases.
Only bs > ps will get the benefit of less memory allocation failure.
Reviewed-by: Daniel Vacek <neelx@suse.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
btrfs: tree-log: use kvmalloc() for overwrite_item()
The @src_copy buffer utilized inside overwrite_item() can be as large as
the nodesize.
For an existing btrfs with 64KiB nodesize, it means there is a high
chance to fail the kmalloc() call if there is not enough physically
contiguous pages.
Meanwhile there is really no need for such physically contiguous pages,
as we only use that buffer to compare the content of the item.
Use kvmalloc() to replace the kmalloc() call. For most cases that
kvmalloc() call will be easily fulfilled by regular kmalloc(), but for
really large items and large nodes, kvmalloc() will have a much higher
chance to get memory allocated.
Reviewed-by: Daniel Vacek <neelx@suse.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
There is a bug report that the kmalloc() call inside split_item() failed
with the following call trace, and triggered a transaction abort:
kworker/u69:8: page allocation failure: order:4, mode:0x40c40(GFP_NOFS|__GFP_COMP), nodemask=(null)
CPU: 3 UID: 0 PID: 1154528 Comm: kworker/u69:8 Not tainted 7.0.2 #1 PREEMPTLAZY
Workqueue: events_unbound btrfs_async_reclaim_metadata_space
Call Trace:
<TASK>
dump_stack_lvl+0x47/0x60
warn_alloc.cold+0x67/0xec
__alloc_pages_slowpath.constprop.0+0x9bf/0xed0
__alloc_frozen_pages_noprof+0x1ac/0x1c0
___kmalloc_large_node+0x9d/0xc0
__kmalloc_noprof+0x17b/0x1f0
split_item+0x9e/0x2e0
btrfs_del_csums+0x285/0x400
__btrfs_free_extent.isra.0+0x6de/0x12b0
__btrfs_run_delayed_refs+0x522/0x10c0
btrfs_run_delayed_refs+0x4d/0x1d0
flush_space+0x34d/0x4e0
do_async_reclaim_metadata_space+0x89/0x1d0
btrfs_async_reclaim_metadata_space+0x44/0x60
process_one_work+0x145/0x230
worker_thread+0x185/0x2e0
kthread+0xca/0x100
ret_from_fork+0x14e/0x200
ret_from_fork_asm+0x11/0x20
</TASK>
BTRFS error (device dm-3 state A): Transaction aborted (error -12)
BTRFS: error (device dm-3 state A) in btrfs_del_csums:1053: errno=-12 Out of memory
BTRFS info (device dm-3 state EA): forced readonly
BTRFS: error (device dm-3 state EA) in do_free_extent_accounting:3168: errno=-12 Out of memory
BTRFS error (device dm-3 state EA): failed to run delayed ref for logical 1202913873920 num_bytes 274432 type 184 action 2 ref_mod 1: -12
BTRFS: error (device dm-3 state EA) in btrfs_run_delayed_refs:2247: errno=-12 Out of memory
[CAUSE]
The kmalloc() call is to allocate a buffer to store the full item.
However as shown in the above call trace, the order can be high (4), and
since we're using GFP_NOFS, it's impossible to reclaim memory by writing
back dirty pages.
When there is no physically contiguous memory left, such high order
allocation can easily fail, and if such kmalloc() happens in a critical
path we can trigger a transaction abort.
[FIX]
Instead of kmalloc(), which requires physically contiguous pages, use
kvmalloc().
There is no special requirement for physically contiguous pages here, we
just want virtually contiguous memory as a buffer.
Reported-by: xavierbachmeyer182 <xavierbachmeyer182@protonmail.com> Link: https://lore.kernel.org/linux-btrfs/250decb0-d940-4fe6-9b54-d06e1b293a1b@suse.com/ Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Daniel Vacek <neelx@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Zhen Ni [Mon, 22 Dec 2025 03:59:42 +0000 (11:59 +0800)]
btrfs: replace is_data_bbio() with is_data_inode() for direct usage
After commit 81cea6cd7041 ("btrfs: remove btrfs_bio::fs_info by
extracting it from btrfs_bio::inode"), the btrfs_bio::inode field is
mandatory for all btrfs_bio allocations. The NULL check is redundant and
can be removed.
As is_data_bbio() would be a trivial wrapper for is_data_bbio() replace
all calls in in bio.c
Usama Arif [Fri, 4 Sep 2026 16:41:48 +0000 (09:41 -0700)]
btrfs: zstd: avoid a copy in zstd_decompress_bio()
zstd_decompress_bio() gives zstd a sectorsize-sized scratch buffer, and
btrfs_decompress_buf2page() then copies the part overlapping the read bio
into the destination folios. Every delivered byte is written twice.
Instead, choose the output buffer per streaming call. zstd_map_dest()
kmaps the current page-bounded segment of the read bio, so zstd writes
into the page cache directly. The scratch buffer is kept only for output
with no destination: the prefix before a read starting inside a
compressed extent, which zstd cannot skip, and gaps left by folios
already in the page cache.
Varying the output buffer across calls is safe: btrfs uses the default
ZSTD_bm_buffered mode, where the sliding window lives in the dstream's
internal buffer and the caller's dst is a pure sink. The read bio's
iterator must still advance by exactly the bytes delivered, since
btrfs_decompress_bio() zero-fills from it; that used to happen inside
btrfs_decompress_buf2page() and is now an explicit bio_advance(), made
only for output that reached a folio.
bio_iter_iovec() exposes at most one base page, so direct output is
page-bounded. Compared to the old sectorsize-sized chunks, this can
increase stream calls when sectorsize exceeds PAGE_SIZE, but eliminates
the extra btrfs copy for output delivered to the read bio; the 64 KiB
sectorsize row below shows the copy still wins there.
Benchmarked the change in 2-vCPU x86-64 KVM guests (4 KiB pages, RAM
disk) using a 64 MiB zstd-compressed file. Results are medians of seven
cold-cache reads in each of six interleaved A/B boot pairs; mincore
confirmed zero resident pages before every run.
Normal sequential reads with readahead produced:
sectorsize base patched reduction
4 KiB 8.678 ms 8.004 ms 7.80%
16 KiB 8.216 ms 7.934 ms 3.64%
64 KiB 7.875 ms 7.344 ms 6.88%
Random 4 KiB preads at 4 KiB sectorsize, means of six interleaved A/B
boot pairs, patched better in all six:
base patched gain
264.33 MB/s 272.67 MB/s 3.2%
Signed-off-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Jeff Layton [Tue, 25 Aug 2026 16:04:20 +0000 (12:04 -0400)]
btrfs: pre-allocate delayed dir index for non-overwrite rename
For rename() without an overwrite target, pre-allocate the delayed
dir index before any btree modifications so that ENOMEM can be returned
before the source is unlinked from the old directory.
Add a prealloc parameter to btrfs_add_link() that allows callers to
pass pre-allocated delayed dir index resources. When provided,
btrfs_add_link() takes ownership: it either passes the prealloc to
btrfs_insert_dir_item() (which commits or frees it), or frees it
on early error. All existing callers pass NULL to preserve the current
behavior.
In btrfs_rename(), when new_inode is NULL (no overwrite), call
btrfs_prealloc_delayed_dir_index() before the first btree modification
and pass the result through to btrfs_add_link(). If the prealloc fails,
-ENOMEM is returned before any btree state has changed. The local
prealloc pointer is cleared once ownership passes to btrfs_add_link(),
so the out_fail path only frees one we still own.
For overwrite rename (new_inode != NULL), the transaction still aborts
on ENOMEM since earlier unlink operations have already made irreversible
btree modifications.
Assisted-by: LLM Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Jeff Layton [Tue, 25 Aug 2026 16:04:19 +0000 (12:04 -0400)]
btrfs: handle ENOMEM from btrfs_insert_dir_item() without aborting
Now that btrfs_insert_dir_item() returns -ENOMEM before modifying the
btree (thanks to delayed dir index pre-allocation), callers can handle
ENOMEM gracefully instead of aborting the transaction.
- btrfs_add_link(): add -ENOMEM to the recoverable errors alongside
-EEXIST and -EOVERFLOW.
- btrfs_create_new_inode(): on -ENOMEM from btrfs_add_link(), orphan the
newly-created inode instead of aborting. The inode item was already
written with nlink 1, and discard_new_inode() marks it bad so eviction
won't delete it. So clear_nlink() alone is not enough: persist nlink 0
via btrfs_update_inode(), otherwise orphan cleanup would see nlink > 0,
drop the orphan item, and leak the inode. Fall back to aborting only if
that update also fails.
This turns a filesystem-killing abort into a graceful -ENOMEM return for
create(), mkdir(), mknod(), symlink(), and link() under memory pressure.
Assisted-by: LLM Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Jeff Layton [Tue, 25 Aug 2026 16:04:18 +0000 (12:04 -0400)]
btrfs: pre-allocate delayed dir index before btree modification
Move the delayed dir index allocation in btrfs_insert_dir_item() before
the insert_with_overflow() call that modifies the btree. Previously, the
allocations happened after the DIR_ITEM was already inserted, meaning an
ENOMEM failure left the btree in a partially-modified state that could
only be resolved by aborting the transaction.
Add an optional caller-provided btrfs_dir_index_prealloc parameter to
btrfs_insert_dir_item(). When non-NULL, ownership of the prealloc
transfers to btrfs_insert_dir_item(). When NULL, it allocates internally.
All existing callers pass NULL to preserve the current behavior.
Since ownership transfers, btrfs_insert_dir_item() must free the prealloc
on every path that does not commit it. Route all such exits (including
the early path allocation failure) through a common out_free_prealloc
label, rather than keying cleanup on need_delayed_index.
Remove the btrfs_insert_delayed_dir_index() wrapper, as there are no
more callers.
Assisted-by: LLM Suggested-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Jeff Layton [Tue, 25 Aug 2026 16:04:17 +0000 (12:04 -0400)]
btrfs: split btrfs_insert_delayed_dir_index() into prealloc and commit phases
Split btrfs_insert_delayed_dir_index() into three functions using a new
btrfs_dir_index_prealloc struct to bundle the pre-allocated resources:
- btrfs_prealloc_delayed_dir_index(): allocates the struct and performs
the two GFP_NOFS allocations (delayed node + delayed item) that can
fail with -ENOMEM. Returns the struct, or ERR_PTR on failure.
- btrfs_insert_delayed_dir_index_prealloc(): populates the item data,
inserts into the rb-tree, and reserves metadata space. Cannot fail
with -ENOMEM since all allocations were done in the prealloc step.
- btrfs_free_delayed_dir_index_prealloc(): frees pre-allocated
resources when the caller's btree insertion fails. Tolerates NULL.
The prealloc is returned as a pointer rather than filled into a
caller-provided struct, so that a plain NULL means "no prealloc" and
callers do not need a separate flag to track whether one exists. It is
consumed (and freed) by either the commit or the free helper, so
ownership is unambiguous.
The original btrfs_insert_delayed_dir_index() is refactored into a thin
wrapper that calls the prealloc and commit functions.
This split allows callers to move the fallible memory allocations before
the point of no return (the DIR_ITEM btree insertion), so that -ENOMEM
can be returned cleanly without aborting the transaction.
Assisted-by: LLM Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Daniel Vacek [Wed, 2 Sep 2026 13:56:27 +0000 (15:56 +0200)]
btrfs: use bio::remaining for async checksumming synchronization
We can use bio::remaining counter to sync the offloaded checksumming.
As a result we can slim down the btrfs_bio structure by 24 bytes
and simplify the code a bit.
Moreover this will allow us enabling async checksumming with encryption
where we need to checksum the bounce bio instead of our regular one
embedded in btrfs_bio. And so we need to extend it's lifetime. This is
the preferred way to do so.
This also fixes a bug in experimental build where the async checksumming
was using the system workqueue instead of fs_info::endio_workers.
Fixes: dd57c78aec39 ("btrfs: introduce btrfs_bio::async_csum") Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Daniel Vacek <neelx@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Daniel Vacek [Wed, 2 Sep 2026 09:20:24 +0000 (11:20 +0200)]
btrfs: consume given iter directly instead of copying in csum_one_bio()
Avoid copying the iter twice in async case. We already have a copy
csum_one_bio() can consume directly. No need to copy it again the second
time. We can use this copy also in the sync case and get rid of the
parameter.
Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Daniel Vacek <neelx@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
btrfs: zoned: handle RAID profiles in btrfs_can_activate_zone()
btrfs_can_activate_zone() only accounts for the single and DUP profiles.
For a RAID0, RAID1, RAID1C3, RAID1C4 or RAID10 block group the profile
switch matches no case, so 'ret' stays false and the function reports
that no zone can be activated, even when the devices have plenty of
active zones left.
As a side effect BTRFS_FS_NEED_ZONE_FINISH gets set and, since
btrfs_can_activate_zone() bails out early once that bit is set, data
allocations will fail permanently: writers loop on -EAGAIN and hang in
btrfs_new_extent_direct() waiting for the bit to clear.
Each of these profiles needs one active zone per device, just like
single, so handle them the same way.
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
btrfs: tree-checker: reject file extent items for special files
File extent items are only utilized by regular files or symlinks, other
files like directory/char/block/FIFO/sock files should not have any file
extent item.
Previously we were unable to reject such cases, as the inode item may not
be in the same leaf.
But we already have @prev_key in check_leaf_item(), this means we just
need a new way to pass the mode of the previously hit inode item, then
we can detect such problems.
Introduce a new helper structure, saved_inode_info, to record the inode
number and its mode hit in the same leaf, and keep it across the whole
leaf.
Then if we hit a file extent item, and the inode item is in the same
leaf, we can refer to that to determine if we need to reject the file
extent item.
Now with the following corrupted fs tree, the kernel can safely reject
the leaf:
btrfs: use ordered extent to grab the logical address for submission
In submit_one_sector() we call btrfs_get_extent() to grab the IO extent
map so that we know where the logical location to submit the block.
However there is no guarantee that there is an IO extent map for the
block, and if there is no IO extent map nor ordered extent,
btrfs_get_extent() can grab the file extent from on-disk metadata.
That's why we have ASSERT()s to reject holes and compressed file
extents.
On the other hand, for the write range we should have both an IO extent
map and an ordered extent, so there is no reason not to grab the ordered
extent instead.
There is some minor advantages:
- No hole ordered extent
So no need to rely on ASSERT()s to reject hole extents.
And the ASSERT()s are depending on the kernel config, without
CONFIG_BTRFS_ASSERT those ASSERT()s won't even trigger.
- No IO errors
Unlike btrfs_get_extent() which can return IO error when doing the
metadata tree search, btrfs_lookup_ordered_extent() will either return
an OE or not found.
- Cached OE in bio_ctrl->bbio
At bbio allocation we have already did an OE lookup, and we have a
high chance that the current block also belongs to that OE.
Use that cached OE can reduce the frequency to do an rb-tree search.
- Smaller rb-tree
Unlike extent-map-tree, which can contain cached extent maps, the life
span of ordered extents are much shorter, they get removed from the
ordered tree after the file extent item is inserted into the subvolume
tree.
So doing ordered extent tree search can be a tiny faster.
And since we're here, also address some minor points:
- Add error message for every EUCLEAN error
- Remove a dead comment on btrfs_folio_clear_dirty()
We no longer call folio_clear_dirty_for_io() since commit 095be159f3eb
("btrfs: unify folio dirty flag clearing"), so the folio flag is
still dirty, and the folio dirty flag will be cleared by the last dirty
block.
Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Daniel Vacek <neelx@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
There are 2 features that are marked runtime tweakable inside
/sys/fs/btrfs/features/
- acl
Which is a mount option, and it will not show up in
/sys/fs/btrfs/<fsid>/features/ directory anyway.
- extended_iref
This feature can only be enabled, but not disabled at runtime.
Furthermore it's already the default behavior since 3.12.
So it means this feature is always enabled and cannot be disabled for
modern btrfs.
So there is no need to maintain the ability to modify btrfs' runtime
features through sysfs.
And furthermore, the existing btrfs_feature_attr_store() is race-prone,
it relies on fs_info->transaction_kthread, but our sysfs interfaces are
enabled before transaction_kthread.
Meaning at mount time a sysfs write can trigger NULL pointer dereference
if the transaction_kthread is not yet initialized.
The opposite is also possible during unmount.
Thankfully that race is not possible in the real world, as the only
supported feature is already enabled.
But it also means we do not really need to keep the race-prone
infrastructure, so just remove it completely, and make the per-module
and per-mount features files to be completely read-only.
Even with the sysfs tweakable features removed, we can still enable
extended_iref feature through ioctl.
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Thu, 27 Aug 2026 06:55:30 +0000 (16:25 +0930)]
btrfs: avoid long stall when dropping a non-shared large subvolume
Commit 011b46c30476 ("btrfs: skip subtree scan if it's too high to avoid
low stall in btrfs_commit_transaction()") introduced a mechanism to skip
large subtree during snapshot dropping.
But even for a subvolume without any shared tree blocks, we can still
queue quite a lot of qgroup records into one transaction, and cause a
long qgroup related stall.
So also add a check against the subvolume root level, to determine if we
need to mark qgroup inconsistent.
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Thu, 27 Aug 2026 06:55:29 +0000 (16:25 +0930)]
btrfs: reject new qgroup rescan during subvolume dropping
Commit 011b46c30476 ("btrfs: skip subtree scan if it's too high to avoid
low stall in btrfs_commit_transaction()") introduced a threshold to skip
huge subtree scan during subvolume dropping.
But that's not covering all cases, e.g. rescan can still be started
immediately after that huge subtree skipping.
This will cause rescan to do the same accounting for that subtree
anyway, still causing a long stall during transaction commit.
Introduce a new runtime qgroup flag,
BTRFS_QGROUP_RUNTIME_BIT_REJECT_RESCAN, so that during cleanup of a
subvolume, no new qgroup rescan can be initiated.
The rejection uses the same -EINPROGRESS, as if there is already a
running qgroup rescan.
And since we have the extra bit, we can no longer allow plain assignment
in btrfs_quota_enable(), as the plain assignment will override the
REJECT_RESCAN bit.
To co-operate this new flag:
- Make btrfs_quota_enable() to only set BTRFS_QGROUP_STATUS_BIT_ON
So it won't override the existing
BTRFS_QGROUP_RUNTIME_BIT_REJECT_RESCAN bit.
- Make btrfs_quota_disable() to clear every non-rescan bit
This includes:
* BTRFS_QGROUP_STATUS_BIT_ON
* BTRFS_QGROUP_STATUS_BIT_INCONSISTENT
* BTRFS_QGROUP_RUNTIME_BIT_NO_ACCOUNTING
For rescan related bits, they are either cleared by the rescan thread,
or by the caller who rejects rescan.
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Tue, 25 Aug 2026 04:12:31 +0000 (13:42 +0930)]
btrfs: qgroup: use atomic operations for btrfs_fs_info::qgroup_flags
Currently we define btrfs_fs_info::qgroup_flags as u64, to match the
on-disk qgroup status item's flag.
But for now we have only 4 bits utilized for that flag, and since it's
u64 we have no way to properly use the existing atomic bit operations
(requires an unsigned long pointer).
This results in a lot of non-atomic operations inside qgroup code. Some
maybe fine as other locks are involved, but still it's not a good
practice.
Remove those non-atomic operations by:
- Re-define btrfs_fs_info::qgroup_flags as unsigned long
- Define BTRFS_QGROUP_STATUS_BIT_* and BTRFS_QGROUP_RUNTIME_BIT_*
Instead of the old value define the bit number.
- Use set_bit()/clear_bit()/test_bit() to replace open-coded bit
operations
- Add one extra check at qgroup status item read time
To make sure the on-disk flag is still inside ULONG_MAX.
Otherwise reject the status item and disable qgroup.
- Get rid of unnecessary spinlock when checking a single bit
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Breno Leitao [Mon, 24 Aug 2026 11:54:45 +0000 (04:54 -0700)]
btrfs: skip extent tree lock in the shrinker for inodes without extent maps
find_first_inode_to_shrink() takes inode->extent_tree.lock in write mode
on every inode it walks, only to find out whether that inode has any
extent maps. Most inodes have none, so the lock is taken and dropped
again without any work being done.
Check whether the tree is empty before taking the lock. tree->root is
only modified with the tree lock held for write, so the unlocked read is
a harmless race: a false empty just defers the inode to a later scan,
which already happens whenever the write_trylock() below fails, and a
false non-empty falls through to the existing check under the lock.
Across the Meta production fleet the extent map shrinker is ~0.35% of
non-idle kernel CPU. Attributing callees to their caller,
find_first_inode_to_shrink() is ~65% of that, and the write_trylock() it
does is ~30% of the whole shrinker.
Micro benchmark: a 6 GiB btrfs on a loop device, 100000 empty files kept
open, plus 200 1 MiB files created last so they get the highest inode
numbers and every scan has to walk all the empty ones first. Each round
drops the page cache, re-reads the data files to recreate the extent
maps, then triggers the shrinker with "echo 2 > /proc/sys/vm/drop_caches".
15 rounds per run on ARM64 (Neoverse V2), 8 CPUs, no lock debugging.
Cost of find_first_inode_to_shrink() from the ftrace function profiler,
in ns per inode walked, median of runs:
A separate build with CONFIG_LOCK_STAT, same test, for the extent map
tree rwlock. The shrinker is not the only user of that lock, every
extent map insert and lookup takes it too, which is why the acquisition
count drops by two thirds rather than to nothing:
base patched delta
write acquisitions 628016 228000 -63.7%
hold time total (us) 47512 22717 -52.2%
acq cacheline bounces 1574 1288 -18.2%
Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Wed, 19 Aug 2026 01:06:19 +0000 (10:36 +0930)]
btrfs: remove on-stack paddrs[] array usage
Since the bs > ps support, we have to handle cases where a data block is
inside several discontiguous pages.
Thus we need a local paddrs[] array to assemble a data block for bs > ps
cases.
However to handle all possible bs/ps combinations, we have to declare
such array using the max block size vs page size, no matter the current
block size and page size.
This adds 128 bytes on-stack memory usage for several call sites, and
also introduced several duplicated helpers to calculate checksum for a
data block:
The differences are mostly in how the data is passed.
The first one accepts a contiguous paddr range.
The second one accepts an array of paddrs[].
The last one is just a simple wrapper of the first one.
However the most common interface to iterate a data block is through
bio, and we have already converted most callers to use the bio based
interface, e.g. btrfs_bio_data_csum_ok() and btrfs_csum_one_bio_block().
Convert the remaining two call sites to address the remaining paddrs[]
usage:
- btrfs_calculate_block_csum_pages() inside verify_bio_data_sectors()
This can be switched to btrfs_csum_one_bio_block().
This removes the 128 bytes on-stack memory usage.
- btrfs_calculate_block_csum_pages() inside verify_one_sector()
This call site doesn't use on-stack memory for paddrs[], but reuses
the existing btrfs_raid_bio::bio_paddrs[] or
btrfs_raid_bio::stripe_paddrs[].
So implement a local version called calculate_block_csum_paddrs().
Now there is no fixed on-stack paddrs[] usage anymore.
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Wed, 19 Aug 2026 01:06:18 +0000 (10:36 +0930)]
btrfs: use a shared helper to calculate data checksum for a bio
Since we are already calculating data checksum using bio interface,
extract the generation part into btrfs_csum_one_bio_block(), and use that
to replace the paddrs[] array based solution in csum_one_bio().
This will reduce 128 bytes on-stack memory usage for csum_one_bio().
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Wed, 19 Aug 2026 01:06:17 +0000 (10:36 +0930)]
btrfs: enhance btrfs_data_csum_ok() to use bio for page iteration
Currently btrfs_data_csum_ok() requires a @paddr[] array to iterate all
possible pages for bs > ps cases.
However for all btrfs_data_csum_ok() call sites, we already have a
btrfs_bio, and the bio infrastructure has many flexible ways to iterate
multiple pages already.
Change btrfs_data_csum_ok() to make full use of btrfs_bio by:
- Change the parameter list to require a @bvec_iter pointer
And remove @bio_offset, which can be calculated through @bvec_iter and
bbio->saved_iter.
Also remove paddrs[], we will iterate all the pages using bio
interfaces.
- Make the same parameter changes to repair_one_sector()
- Use bio interfaces to iterate pages from a bio
- Rename the function to btrfs_bio_data_csum_ok()
- Remove on-stack paddrs[] array usage
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Wed, 19 Aug 2026 01:06:16 +0000 (10:36 +0930)]
btrfs: replace btrfs_repair_io_failure() to use bio for page iteration
Currently btrfs_repair_io_failure() uses a @paddrs[] array to iterate
pages.
Such a parameter is required for bs > ps cases, as one fs block crosses
several pages.
However there is a much simpler and existing way to iterate pages: bio
and bvec_iter.
This changes btrfs_repair_io_failure() by:
- Use a const @bvec_iter pointer to locate where the pages are
- Extract file offset/logical from the @bbio
- Require no @step parameter
Above features allow us to shorten the parameter list.
- Rename the function to btrfs_repair_bbio_failure()
- Change the caller in btrfs_repair_eb_io_failure() to allocate a bbio
Unlike the data read path, we do not have a handy bbio in that case.
So we need to allocate one just for btrfs_repair_bbio_failure().
- Change the error reporting in btrfs_repair_bbio_failure() to include
root id and use inode number directly
Now for btree inode we will report a proper inode number (1).
Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Mon, 17 Aug 2026 07:30:43 +0000 (17:00 +0930)]
btrfs: refactor read_key_bytes() to remove the dest_folio parameter
The function read_key_bytes() have 3 call sites:
- For BTRFS_VERITY_DESC_ITEM_KEY offset 0 inside btrfs_get_verity_descriptor()
- For BTRFS_VERITY_DESC_ITEM_KEY offset 1 inside btrfs_get_verity_descriptor()
Those are to read the description items, which are pretty small with
fixed item size.
Those call sites do not utilize the @dest_folio parameter.
- For btrfs_read_merkle_tree_page()
This is to read the BTRFS_VERITY_MERKLE_ITEM_KEY, which can be pretty
large and split into multiple items.
This is the only call site utilizing the @dest_folio parameter.
Just for the only btrfs_read_merkle_tree_page() call site, we have a
complex scheme for @dest and @dest_folio parameters.
Since @dest can be NULL, it means if we pass @dest as NULL, then no
matter if @dest_folio is provided, the merkle data will not be loaded
into that @dest_folio.
This can lead to a bug where a highmem folio is not mapped, then we pass
folio_address(folio), which is NULL, into read_key_bytes(), causing no
data to be written into @dest_folio.
To address the complex scheme between @dest and @dest_folio, remove the
@dest_folio parameter completely, and let the only caller to map the
folio and pass the mapped kernel address into read_key_bytes() instead.
This not only reduces the parameter list, but also make it much clear on
the @dest parameter handling.
The only downside is a longer duration of locally mapped page, but this
should still be fine, as kmap_local_folio() can survive context switch.
Guanghui Yang [Mon, 10 Aug 2026 23:32:27 +0000 (09:02 +0930)]
btrfs: roll back sprout setup after device add failure
btrfs_init_new_device() calls btrfs_setup_sprout() before creating the
first writable chunks for a seed filesystem. That moves the seed devices
out of fs_info->fs_devices, clears the seeding state and installs a new
fsid for the sprout filesystem.
If a later step fails, the error path removes the new device but leaves
fs_info->fs_devices in the partially initialized sprout state. The
mounted filesystem can then be left with no open devices after the
failed device add.
Add the inverse of btrfs_setup_sprout() and use it from the error path
so the mounted seed filesystem is restored before the temporary
seed_devices copy is released.
Fixes: 2b82032c34ec ("Btrfs: Seed device support") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Guanghui Yang <3497809730@qq.com>
[ Fix a conflict with per-profile available space, revert sprout before
updating per-profile available space estimation. ] Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Guanghui Yang [Sat, 8 Aug 2026 06:13:55 +0000 (14:13 +0800)]
btrfs: free unlinked replace target on initialization failure
btrfs_init_dev_replace_tgtdev() allocates the replacement target before
looking up its dev_t and initializing its zoned device information. If
either lookup_bdev() or btrfs_get_dev_zone_info() fails, the device has
not been linked into fs_devices->devices yet, but the error path only
drops the block device file reference.
Free the allocated device on this error path to release its name,
allocation state, zone info, and the device itself.
The issue was found by a failure-path metadata residual analyzer and
verified with targeted failure injection on v6.14.
Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Merge tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Don't destroy user event fields when removal fails
User event fields are destroyed before the event is removed from
visibility. But that can fail leaving the still visible event with no
fields. Move the destroying of the fields to after the event is
successfully removed from visibility.
- Initialize function graph state is fork before calling
copy_exec_state()
For non-CLONE_VM forks, copy_exec_state() allocates a new
task_exec_state. If that allocation fails, ftrace_graph_exit_task()
will free the tasks ret_stack pointer. Since that pointer is still
using the parent's ret_stack, it mistakenly frees the parent's
pointer too.
Call ftrace_graph_init() on the task first which will NULL out the
new tasks's ret_stack and if the copy fails, it will not free
anything.
- Remove FGRAPH_MAX_INDEX
The macro FGRAPH_MAX_INDEX was added but never used. Remove it.
- Save ent_size in function graph printing of nested functions
The function graph tracer needs to look at the next event to see if
the next event is the return of the current function entry. If it is,
it prints a single line:
In order to look at the next event, it must save the current event so
that it has the information to print from it. It saves the event in
the iterator descriptor called "ent". What it doesn't save is the
ent_size of the event which is now used to know if the function graph
arguments are to be printed. The peek doesn't save the size so the
size used happens to be that of the size of the last event that was
seen.
Save the entry event size in the iterator descriptor so that the
correct size is used.
- Fix several errors with freeing data in the histogram code
The histogram code had a lot of leaked or or incorrect accounting
when failures happen. Correct them.
- Fix histogram regression of .percent and .graph modifiers
Up until 6.3 histogram values could have "percent" or "graph"
modifiers that changed how they were printed. But a change that added
restricting histograms values from being strings, stack traces and
other modifiers inadvertently prevented them from using the percent
and graph modifiers, which were legal use cases for values.
Put back the percent and graph modifiers.
- Fix various typos in the comments
- Set the trace_clock before initializing a histogram with clock
argument
The histogram API allows the user to specific which trace clock to
use via a "clock=" string. The histogram is set up first before the
clock is checked. If the passed in clock is not valid, it exits
without fully fixing up the histogram leaving it on the list and a
use-after-free can trigger.
Update the clock argument first and if it fails then exit gracefully
before the histogram trigger is placed on any lists.
- Restore :mod: trailer after parsing in ftrace_set_clr_event
The function ftrace_set_clr_event() modifies the parse string and
needs to put it back to what was passed in. It searches for ":mod:"
via a strsep() but fails to put back the first ':' in the string.
Add back the ':' in the passed in string.
- Take trace_array reference when opening a tracer options file
The options files are dynamically created and some tracers add their
own options. When a tracer adds their own list of options, the
trace_array holding them has an array to hold the list of options for
each tracer. This array increases in size via a krealloc(), and the
new entry gets a newly allocated array to hold the options of the new
tracer being added.
The element in each entry of the tracer's option array holds a
pointer back to the trace_array, a pointer to the tracer it is
associated to, a pointer to the flags of the option.
The issue is that these arrays are freed when the trace_array is
freed when its instance it represents is removed from the instances
directory. There's a race that an open of one of these options files
can happen when the instance is being removed.
Add a new helper function to be called by the open function of the
options file to iterate all existing trace_arrays under a lock and
find the one that has the given option element in one of it's tracer
arrays. If found, then update the associated trace_array's reference
counter to keep it from being freed. If not found, have the open call
return -ENODEV.
- Disable interrupts when acquiring the lock in rb_wake_up_waiters()
The function rb_wake_up_waiters() assumes it will be called in
interrupt context and does not disable irqs when taking
cpu_buffer->reader_lock, which can be called in hard interrupt
context. The issue is in PREEMPT_RT, this function is called in
thread context leaving this lock open to a deadlock.
Take the lock with interrupts disabled.
- Use rcu_assign_pointer() for tmp_ops filter hash
The tmp_ops used in update_ftrace_direct_mod() assigns its
filter_hash field directly, but that field is annotated as __rcu and
sparse complains. Assign it with rcu_assign_pointer()
- Fix use-after-free in enable_trigger_private_data_free()
The trace_event_call is accessed through the event_trigger_data's
trace_event_file pointer to put the trace_event_call on freeing. The
issue is that the trace_event_file data may have been freed already
causing a use-after-free. Add a field to the event_trigger_data that
points directly to the trace_event_call so that it can decrement its
reference directly without needing to go through the
trace_event_file.
- Fix accounting of buffer data remote headers
trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount
the number of pages is needed for the asked for size as it doesn't
take into account the meta data on each page. Add a helper function
to do the calculation properly and use that in these functions.
- Catch nr_page_va overflow in ring_buffer_desc sizing
The number of pages per remote ring buffer is capped by
ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to
overflow that field would silently allocate a descriptor smaller than
what was asked for.
- Do not resize the subbuf order if any per_cpu buffer is disabled
The mmapping of ring buffers disables resizing the subbuffers, but it
is done per-cpu whereas the subbuf size change is done for all the
per_cpu buffers under the buffer->mutex. It could change the size of
some while the mapping is happening on others. Have the resize of the
subbuf order check all the per_cpu buffers under the lock to see if
any of them is disabled before starting and causing an inconsistency
between buffers that are being mapped.
* tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (25 commits)
ring-buffer: Check resize_disabled before publishing the new subbuf order
tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing
tracing/remotes: Account for ring buffer page header in size calculation
tracing: Don't dereference trace_event_file in deferred trigger free
ftrace: Use rcu_assign_pointer() for tmp_ops filter hash
ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()
tracing: Take trace_array reference when opening a tracer options file
tracing: Fix ring_buffer_read_page_size() kernel-doc
tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event()
tracing: Fix memory corruption from a "STACKTRACE" histogram key
tracing: Fix memory corruption from the histogram stacktrace modifier
tracing: Undo the registration when enabling the histogram trigger fails
tracing: Take the reference before publishing the named histogram trigger
tracing: Set the trace clock before registering the histogram trigger
tracing: Fix typo "preceeded" in comment
tracing: Fix typo "availabe" in comment
tracing: Let histogram values keep the percent and graph modifiers
tracing: Keep the entry count when the histogram stats allocation fails
tracing: Free histogram the field rejected for a bad modifier
tracing: Free histogram the var ref when its initialization fails
...
Merge misc regression fixes that seem to have fallen through the cracks
Thorsten continues to track regressions, and reporting on known issues
with fixes that don't seem to make any progress.
I'm going to do an rc3 release later today - let's not keep these known
issues pending for yet another rc for no obvious reason.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info> Link: https://lore.kernel.org/all/46403cf8-9a81-4596-87eb-dde58ae4c5db@leemhuis.info/
* regressions:
media: ipu-bridge: do not use the CVS device lookup for IVSC
wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe
wifi: mt76: mt7921: skip unknown CLC firmware records
media: ipu-bridge: do not use the CVS device lookup for IVSC
Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU
bridge driver") the internal camera no longer works on laptops where the
sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6,
INTC10CF, ov02c10):
intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00
intel-ipu6 0000:00:05.0: Connected 1 cameras
ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed
without device fwnode!
No sensor subdevice is registered, the media graph has no sensor entity
and userspace finds no camera at all.
ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named
"intel_vsc" and returns its mei-csi child. That device is created by
mei_vsc, which on this machine only appears once the LJCA USB bridge and
its SPI controller have probed, about a second after the IPU6 probe that
runs the bridge:
07:59:29.297 platform INTC10CF:00 created (ACPI scan)
07:59:41 intel-ipu6 probe -> ipu_bridge_init()
07:59:42.391 platform intel_vsc created (mei_vsc)
The commit above added two fallbacks for CVS which match on the ACPI
companion alone. They are reached for every entry of ivsc_acpi_ids[],
IVSC IDs included. The IVSC ACPI device has two physical nodes:
INTC10CF:00/physical_node -> platform/INTC10CF:00 (no driver bound)
INTC10CF:00/physical_node1 -> platform/intel_vsc (mei_vsc)
so bus_find_device_by_acpi_dev(&platform_bus_type, adev) returns the bare
platform device. ipu_bridge_instantiate_ivsc() then attaches the IVSC
software node to that device instead of to the mei-csi client, the bridge
reports success, and the probe is never retried. mei_csi later probes
without a fwnode, the CSI-2 link is never described, and the sensor ACPI
device, which has an honoured _DEP on the IVSC device, is never
enumerated.
Before those fallbacks existed the lookup returned NULL here, the bridge
failed with -ENODEV and the probe was retried once the IVSC device had
shown up.
Skip those fallbacks for IVSC devices, keying on the IVSC IDs rather than
the CVS ones: new CVS IDs keep being added, whereas the IVSC list is
complete. CVS binds a driver to the ACPI device itself, so matching on the
companion stays unambiguous there.
Fixes: c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") Link: https://lore.kernel.org/linux-media/20260901194526.6369-1-gvozdoder@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Sergey Zagursky <gvozdoder@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Devin Wittmayer [Tue, 25 Aug 2026 18:17:12 +0000 (11:17 -0700)]
wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe
Some laptops carry a MediaTek power table in their firmware, and the
driver reads it to set a transmit limit for each frequency range. It
only fills in the ranges themselves when it registers the device.
The startup step that does this existed already, but it never programmed
anything. Two recent commits made it run a regulatory update instead,
which sets the limits on the way through, long before registration.
As a result, on a machine that has the table the driver reads through an
empty pointer and the interface never appears:
wifi: mt76: mt7921: skip unknown CLC firmware records
Treat an out-of-range CLC index as newer firmware rather than a
malformed image. linux-firmware 20260810 ships MT7922 records with
idx 3, and rejecting them made mt7921e fail to probe.
Keep the record-length checks, and report those as errors so a
truncated table is visible instead of a silent retry loop.
David Carlier [Sat, 12 Sep 2026 10:39:38 +0000 (11:39 +0100)]
ring-buffer: Check resize_disabled before publishing the new subbuf order
ring_buffer_subbuf_order_set() stores the new order and only then walks
the CPUs, returning -EBUSY if any of them has resizing disabled. A user
mapped buffer has resizing disabled, and __rb_map_vma() reads
buffer->subbuf_order without buffer->mutex, so an mmap of an already
mapped CPU racing the failing order change sizes the mapping with the
new order and inserts pages past the sub-buffer into the VMA.
Check the CPUs before storing the new order.
Cc: stable@vger.kernel.org Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Link: https://patch.msgid.link/20260912103938.1127021-1-devnexen@gmail.com Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing
The number of pages per remote ring buffer is capped by
ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to
overflow that field would silently allocate a descriptor smaller than
what was asked for.
Return SIZE_MAX from trace_buffer_desc_size() on nr_page_va overflow.
tracing/remotes: Account for ring buffer page header in size calculation
trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the
required pages because every ring buffer page contains a header
(BUF_PAGE_HDR_SIZE). Account for that header to ensure allocated remote
ring buffers aren't smaller than requested by the user.
The newly introduced helper __calc_nr_pages_ring_buffer_desc() can
return a value that overflows the descriptor nr_pages field (32 bits).
Merge tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Work around a 'bindgen' 0.73.2 bug that emits an 'allow' attribute
for 'unnecessary_transmutes', which is unknown in older compilers
- Clean 'clippy::as_underscore' lints in generated code by the new
'bindgen' 0.73.0+ releases
- Clean new 'clippy::needless_range_loop' lint for the upcoming Rust
1.100.0 (expected 2026-11-12)
'kernel' crate:
- 'num' module: fix soundness issue in 'Bounded' by sealing the
'Integer' trait
'pin-init' crate:
- Fix unreachable warning for the upcoming Rust 1.100.0 (expected
2026-11-12) due to 'Infallible' becoming an alias of '!'
Samples:
- Add missing newlines in 'pr_*!'s macro calls"
* tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: allow `unknown_lints` in generated bindings for Rust < 1.88
rust: allow `clippy::as_underscore` in the generated bindings
rust: num: seal Integer
drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0
rust: samples: add missing newlines in rust_print_main
rust: pin-init: use irrefutable pattern for `stack_pin_init`
Merge tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull bootconfig fixes from Masami Hiramatsu:
"Fix integer overflow and truncation in size checks.
- Fix size check bypasses caused by integer overflow and truncation
when parsing initrd or standalone bootconfig files, preventing
buffer overflow and out-of-bounds writes in the userspace tool.
- Fix pointer arithmetic wrap-around in get_boot_config_from_initrd()
when handling crafted huge size values, preventing fatal kernel
page faults during early boot"
* tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
bootconfig: Fix integer overflow in initrd size check
tools/bootconfig: Fix integer overflow and truncation in size checks
Merge tag 'timers-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Ingo Molnar:
- Fix clockevents replacement race when a broadcast
device is replaced which may trigger a BUG() crash
(朱恺乾 - Zhu Kaiqian)
- Fix potential timerqueue ordering bug when rearming
a queued timer with nonzero slack (Andrea Parri)
* tag 'timers-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimer: Use hard expiry when updating timers on the same base
tick/broadcast: Plug clockevents replacement race
- In proxy scheduling, account cgroup CPU time to the execution
context, not the scheduling context (Hui Su)
- Likewise, call wq_worker_tick() for the execution context,
not the scheduling context (Hui Su)
* tag 'sched-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/core: Call wq_worker_tick() for the execution context
sched: Account cgroup CPU time to the execution context
sched/eevdf: Fix rb augmented with multi fields
sched/eevdf: Fix augmented max_slice
- Fix KLP checksum false positives triggering with GCC, caused
by quirks in string literal symbol generation (Josh Poimboeuf)
* tag 'objtool-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool/klp: Fix checksums for constant pool references
klp-build: Fix wrong index in funcs cleanup error path
Merge tag 'core-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull entry code fix from Ingo Molnar:
- Fix generic entry code cross-build failure on
!CONFIG_AUDITSYSCALL kernels using older
RISCV64 and S390 cross-compilers (Thomas Gleixner)
* tag 'core-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
entry: Guard syscall_enter_audit() invocation with CONFIG_AUDITSYSCALL
Merge tag 'edac_urgent_for_v7.3_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fix from Borislav Petkov:
- A single fix to altera_edac to use the proper objects when performing
managed device operations instead of using temporary shallow struct
copies which can cause dangling list pointers and havoc eventually
* tag 'edac_urgent_for_v7.3_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/altera: Use parent device for devres in altr_portb_setup()
Merge tag 's390-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- Fix NULL pointer dereferences in s390dbf when setting debug levels or
resizing debug areas while logging events. Remove duplicate messages
about kernel parameter overrides
- Fix PAI perf crashes when per task events move to newly onlined CPUs.
Add CPU hotplug callbacks to allocate and free the per-CPU data
- Fix mutex use in atomic context in AES and PAES CTR code by using
semaphore trylocks instead. Remove conditional locking and enable
Clang CONTEXT_ANALYSIS for the crypto code
- Fix scatterlist walk error handling in AES and PAES and avoid freeing
PAES walk resources twice
- Fix missing scrubbing of temporary AES and PAES buffers, including
AES GCM error paths
- Set missing CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK flags for
PAES
- Fix -EBUSY handling in PAES and PHMAC to avoid cleaning up requests
already queued to the crypto engine
- Fix PAES and PHMAC requests being completed twice on errors
- Fix PAES and PHMAC hangs when key conversion keeps returning -EBUSY
by returning -EIO after the last retry
* tag 's390-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/crypto: Enable CONTEXT_ANALYSIS
s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly
s390/crypto: Fix wrong return code to engine in asynch callbacks
s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine
s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engine
s390/crypto: Fix missing cra_flags in paes_s390
s390/crypto: Fix use of mutex in atomic context in PAES
s390/crypto: Fix missing scrub of temp buffers with PAES algorithm
s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms
s390/crypto: Fix use of mutex in atomic context
s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm
s390/crypto: Fix skcipher_walk return code handling in aes_s390
s390/debug: Fix race between debug area resize and event logging
s390/debug: Do not repeat parameter override notice on debug_set_level()
s390/debug: Fix NULL pointer dereference in debug_set_level()
s390/pai: Support CPU hotplug for PMU PAI
s390/pai: Move locking to event init and delete
s390/pai: Use PAI PMU index as parameter replacing event
Merge tag 'kbuild-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux
Pull Kbuild fixes from Nicolas Schier:
"Fix a build race and builds on stable branches.
The other two are low-hanging fruits from Lorenzo's recent kbuild
speed-up patch set that fix older symbol leakages.
- don't delete in-flight filechk temporaries in asm-headers
A rule for generating header files was changed from using make
$(wildcard) fnglob to 'find' instead; as 'find' finds "hidden"
files by default, temporary files from Kbuild's 'filechk', used for
generating asm header files, may get deleted and break header file
generating.
- scripts/sorttable: Mark long_size as __maybe_unused
Fix builds with clang-23 or newer on trees w/o commit b055f4c431e3
("sorttable: Move ELF parsing into scripts/elf-parse.[ch]");
targetting for backport to stable kernels < 6.19.
- scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms
Update regexp to remove kallsyms entries from kernel binary, saves
about 32 KiB of bzImage.
- scripts/mksysmap: fix escape of '$' in the __pi_ pattern
Prevent arm64 PIE namespace local symbols from appearing System.map
and /proc/kallsyms"
* tag 'kbuild-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
scripts/mksysmap: fix escape of '$' in the __pi_ pattern
scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms
scripts/sorttable: Mark long_size as __maybe_unused
kbuild: don't delete in-flight filechk temporaries in asm-headers
scripts/mksysmap: fix escape of '$' in the __pi_ pattern
Commit b18b047002b7 ("kbuild: change scripts/mksysmap into sed script")
converted scripts/mksysmap from a shell script to a sed script.
However an error was made - escaping of '$' required \\ escaping in shell
but only \ in a sed script.
This was mostly corrected in commit 7a6c355b55c0 ("scripts/mksysmap: Fix
escape chars '$'"), but this fix missed arm64 PIE namespace local symbols
like __pi_$x and __pi_$d which appear in System.map and /proc/kallsyms:
scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms
Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped")
keeps .modinfo symbols out of System.map and kallsyms, which assumes unique
IDs have a format like '__UNIQUE_ID_modinfo123'.
However, commit afb026b6d35c ("compiler: Tweak __UNIQUE_ID() naming"), sent
in the same cycle, changes this to '__UNIQUE_ID_modinfo_123'.
As a result this regexp has never matched and every kernel since v6.18 has
carried one kallsyms entries for every MODULE_INFO() declaration in the
kernel whether the modules are compiled or not.
That's 5,810 entries for an x86 defconfig build and 15,200 for arm64.
On x86 defconfig that is 113 KiB of kallsyms tables and 32 KiB of bzImage,
and every lookup walks past them.
Fix the pattern.
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260908-build-speedup-v1-1-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
scripts/sorttable: Mark long_size as __maybe_unused
When building in a kernel tree prior to commit b055f4c431e3 ("sorttable:
Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer,
which implements a new warning under -Wunused-but-set-variable for
static global variable, there is a warning from sorttable because
long_size is unused when MCOUNT_SORT_ENABLED is not set:
scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global]
452 | static int long_size;
| ^
Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef
directives while insuring the warning does not reappear, as the
aforementioned change does not alter the uses of long_size, so it
appears to be coincidence that the warning disappears after this
refactoring.
kbuild: don't delete in-flight filechk temporaries in asm-headers
Commit 2d69b891e646 ("kbuild: Support generated asm-headers in
subdirectories") switched the stale-wrapper sweep in
scripts/Makefile.asm-headers from $(wildcard $(obj)/*.h) to a find(1)
invocation, so that generated headers in subdirectories are considered.
The two do not match the same set of files. Make's $(wildcard) uses glob
semantics, where a leading '.' has to be matched explicitly, whereas
find's -name uses fnmatch() without FNM_PERIOD, so '*.h' matches
dotfiles as well. filechk writes its output to $(dir $@).tmp_$(notdir $@)
before renaming it into place, so such a scratch file, if it happens to
exist in $(obj) when the sub-make is parsed, is now picked up in
old-headers. It appears in neither generic-y, generated-y nor syscall-y,
is therefore classified as unwanted, and cmd_remove deletes it.
On x86 this races with archprepare, which lists both asm-generic and
arch/x86/include/generated/asm/cpufeaturemasks.h as prerequisites. Under
-j they run concurrently against the same directory, and the build fails
intermittently:
mv: cannot stat 'arch/x86/include/generated/asm/.tmp_cpufeaturemasks.h': No such file or directory
make[1]: *** [arch/x86/Makefile:269: arch/x86/include/generated/asm/cpufeaturemasks.h] Error 1
The same commit also converted the generic wrapper rule to filechk, so
those wrappers now create .tmp_*.h in $(obj) too and can race among
themselves.
Restore the previous behaviour by excluding dotfiles from the sweep.
Subdirectories, which is what the find(1) conversion was for, keep being
descended into. While at it, quote the -name argument: it is currently
expanded by the shell against the build directory before find sees it.
Fixes: 2d69b891e646 ("kbuild: Support generated asm-headers in subdirectories") Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260902161347.4163577-1-vlad.wing@gmail.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
Ali Ahmet Memiş [Fri, 11 Sep 2026 15:56:47 +0000 (18:56 +0300)]
tracing: Don't dereference trace_event_file in deferred trigger free
The enable_event trigger defers trace_event_put_ref() to the
trigger free kthread, but the trace_event_file can already be freed
when the instance is removed.
Keep the trace_event_call directly in enable_trigger_data so the
deferred free does not access the freed trace_event_file.
Cc: stable@vger.kernel.org Fixes: e091351b3881 ("tracing: Delay module ref count for "enable_event" trigger") Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Closes: https://lore.kernel.org/all/20260828134340.2501683A24-agordeev@linux.ibm.com/ Link: https://patch.msgid.link/20260911155650.354844-1-aliamemis@disroot.org Signed-off-by: Ali Ahmet Memiş <aliamemis@disroot.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Leon Hwang [Fri, 11 Sep 2026 14:25:12 +0000 (22:25 +0800)]
ftrace: Use rcu_assign_pointer() for tmp_ops filter hash
tmp_ops.func_hash->filter_hash is annotated __rcu, but
update_ftrace_direct_mod() assigns hash to it directly. Sparse reports an
address-space mismatch.
Use rcu_assign_pointer() for the assignment.
Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911142512.19344-1-leon.hwang@linux.dev Fixes: 50b35c9e50a8 ("ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202609110704.Q3M5vCDV-lkp@intel.com/ Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Merge tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Carlos Maiolino:
"More than the usual amount of fixes.
The highlights here are a block under reservation fix which caused an
assert to be triggered in non-default configurations. The assert,
initially added on 7.3-rc2 just makes the problem explicit but is not
the cause. Another highlight is a missed lock/unlock mutex in the xfs
healthmonitor which was causing lockdeps warnings.
Besides those two, this also contains a myriad of fixes for random
bugs found by LLM tools in the healthmon, scrub and online repair.
A few bug fixes for zoned xfs are also included.
This also includes an accounting fix for our buffer slab cache where
the memory payload associated to each object was not being properly
accounted for.
The remaining of the patches are a few lock context annotations added
and/or fixed. They are mostly disabled by now, but still worth fixing
before we get them enabled.
And last but not least, a few clean ups"
* tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (75 commits)
xfs: advance the findparent inode scan cursor while holding ILOCK
xfs: reset parent pointer args before each dir tree unlink repair
xfs: fix replaying dirent removals into the temporary directory
xfs: fix termination logic in xchk_bmap
xfs: fix rtrmap cross-referencing elision logic
xfs: actually check internal-rtdev fields in the superblock
xfs: fix under-reservation of blocks when repairing sf directories
xfs: take hm->lock in xfs_ioc_health_monitor() before insert
xfs: set IOMAP_F_INTEGRITY for zoned writes on integrity devices
xfs: avoid extra cache flushes for multi-device file systems in xfs_fsync
xfs: don't continue on error in xfs_fsync
xfs: also flush the RT device cache in xlog_write_iclog
xfs: bail out on bitmap errors in xrep_agfl_fill
xfs: snapshot old AGFL before rewriting it
xfs: remove redundant function declaration
xfs: report runtime failures in scrub
xfs: report healthy filesystem events in scrub stats
xfs: snapshot scrub stats when rendering them
xfs: remove several unused and never-implemented declarations
xfs: count escaped corruption errors in scrub stats
...
Merge tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- tree-checker updates, validate values in b-tree item keys, other item
length checks
- don't do unnecessary transaction commit fallback when logging parent
directories
- in zoned mode, initialize space info of a block group early enough so
it does not lead to NULL pointer dereference
* tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: tree-checker: validate name length for extref items
btrfs: tree-checker: validate parent field for inode extref items
btrfs: tree-checker: validate key offset for inode ref keys
btrfs: fix unnecessary transaction commit fallback from btrfs_log_all_parents()
btrfs: set space_info before adding new free space in btrfs_make_block_group()
Merge tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
Pull erofs updates from Gao Xiang:
"The most impactful fix here is to disable LZ4 rolling decompression
for now.
AWS folks recently found their systems could get corrupted data with
some rare, specific LZ4 datasets, and after a deeper analysis, I found
the root cause is that there could be uncontrolled backward memory
copies in the current LZ4 implementation and it breaks the assumption
of the rolling decompression optimization, since the kernel LZ4
codebase is out of our control and it needs more time to plan how to
do next, so disable LZ4 rolling decompression for now to ensure data
correctness for real production on these rare cases first. The
technical details also see the corresponding commit.
Other changes are random minor fixes.
Summary:
- Disable LZ4 rolling decompression for now due to the uncontrolled
LZ4 implementation
- Fix missing sysfs feature entry for xattr prefixes
- Fix invalid LZMA decoders on resize failure
- Rearrange the inode_share cache key to avoid potential collisions
- Fix erofs_bread() when fsoffset is used on sub-page-block EROFS
filesystems"
* tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
erofs: add missing buf->off in erofs_bread()
erofs: delimit inode_share cache key components
erofs: disable LZ4 rolling decompression for now
erofs: preserve LZMA decoders on resize failure
erofs: add sysfs feature entry for xattr prefixes
Merge tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev
Pull fbdev fixes from Helge Deller:
"Two patches for VT core code and fbcon prevent potential out-of-bounds
reads on font or screen size changes, one fix limits the Superblitter
in atafb to supported modes only, and some minor fixes for vfb,
ssd1307fb and omapfb"
* tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: vfb: defer cleanup until the last reference
fbdev: atafb: Restrict SuperBlitter to supported formats
fbdev: ssd1307fb: fix NULL pointer dereference on missing match data
fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo
fbdev: omapfb: Fix __be32 sparse warning in panel_enabled()
vt: hide cursor prior to font changes to avoid out-of-bound reads
Merge tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
Pull IOMMU fixes from Joerg Roedel:
"RISC-V:
- Serialize command queue publication to prevent concurrent producers
from exposing incomplete or out-of-order commands to hardware
- Wait for queue space outside the command queue lock
- Avoid waiting for IOFENCE completion when command enqueue failed
AMD:
- Prevent GA log buffers from being reallocated and leaked during
resume, where allocation also occurs in an unsuitable syscore
callback context
- Fix a regression on older systems whose firmware advertises
incorrect IOMMU features
- Preserve allocation errors when assigning host domain IDs to nested
domains
s390:
- Prevent a NULL dereference when translating an unmapped IOVA with
five-level ZPCI translation tables
Misc:
- Remove a stale MAINTAINERS entry and clean up unused or redundant
AMD IOMMU declarations, macros, and checks"
* tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux:
iommu/amd: Remove unused macro
iommu/amd: Remove redundant checks from interrupt handler path
iommu/amd: Remove redundant check in irq_remapping_select()
iommu/amd: Make iommu_sva_set_dev_pasid as static
MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry
iommu/amd: Fix ineffective error check in nested domain allocation
iommu/amd: Fix premature break in init_iommu_one() again
iommu/amd: Do not reallocate GA log buffers on resume
iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX
iommu/riscv: Avoid waiting on failed command enqueue
iommu/riscv: Serialize command queue publishing
iommu/riscv: Add command queue lock
* tag 'powerpc-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/pasemi: Add a null pointer check to the pas_setup_mce_regs
powerpc/prom: Remove redundant early_init_dt_scan_root() call
selftests/powerpc: use MAP_FAILED instead of (void *)-1 in tm-signal-context-force-tm
powerpc/kexec_file: print configured kernel command line
KVM: PPC: Book3S HV: Set irqfd->producer only on success
powerpc/pseries/htmdump: Fix leak in htmdump_init_debugfs
selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value
selftests/powerpc/pmu/ebb: fix lost_exception_test hang with sched yield change
powerpc/entry: Fix double accounting of user time on interrupt entry
Merge tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"One fix for pf1550 which checked for errors on multiple regulators
but always notified via one of them regardless of which one had the
problem, plus one device ID addition in the fan53555 DT bindings"
* tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: pf1550: fix which regulator is notified
regulator: dt-bindings: fan53555: add tcs,tcs4526
Merge tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fix from Mark Brown:
"New device ID for v7.3: update the DesignWare DT binding to say how to
describe the UltraRISC DP1000 instance of the controller"
* tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dt-bindings: snps,dw-apb-ssi: Add compatible for UltraRISC DP1000 SoC
Merge tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly fixes pull, this seems relatively quiet for the new world,
scattered fixes, mostly amdgpu leading the way, but lots of minor
fixes in other drivers.
Merge tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"From a RISC-V point of view, there's one notable fix here, reverting
an earlier bogus fix to the pointer masking code. Fortunately the
practical impact appears to be small.
- Revert a bad fix, likely LLM-generated, in the pointer masking code
that confused the RISC-V hardware pointer masking implementation
with the Linux kernel tagged address feature
- Fix unexpected faults caused by kprobe instruction slot writes when
!CONFIG_STRICT_MODULE_RWX
- Fix unexpected faults on minimal configurations during runtime code
patching on !CONFIG_STRICT_MODULE_RWX systems
- Fix a misplaced variable clear causing incorrect reuse of previous
values in the RISC-V hardware feature probing code
- Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
than BIT on 64-bit masks; and use a bitmap rather than an unsigned
long on a quantity that can exceed 32 bits
And a few miscellaneous cleanups:
- Avoid a potential dereference-before-NULL-pointer-check bug in the
PMU SBI perf driver
- Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug
table code (like x86 and PPC)
- Report the RISC-V standard ISA extensions Z[v]fhmin when support is
claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
simplify our FPU test code to only check for the presence of the D
extension
- Use an existing kernel string helper in place of some open-coded
code in kernel/usercfi.c
- Fix some yamllint issues in the RISC-V DT bindings for CPUs
- Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into
the RISC-V CFI selftest code
- Update the translation for the simplified Chinese translation of
the RISC-V kernel patch acceptance policy"
* tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS
kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__
docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation
dt-bindings: riscv: cpus: Fix yamllint style issues
riscv: hwprobe: simplify has_fpu() to check D extension only
perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ
riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present
perf: RISC-V: store available counter mask as bitmap
perf: RISC-V: use BIT_ULL for u64 overflow masks
riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS
riscv: hwprobe: initialize pair->value in hwprobe_one_pair()
riscv: use string helper in setup_global_riscv_enable()
Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"
riscv: patch: skip fixmap mapping when kernel text is already writable
riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX
Merge tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
- amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG
- asus-laptop: Fix ACPI event handling
- hp-wmi: Fix board_params typo for 8DD6 board
- x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups
* tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path
platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working
platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2
platform/x86: x86-android-tablets: drop redundant swnode group on YT3
platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support
platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init()
platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
platform/x86: x86-android-tablets: fix Arizona GPIO swnode references
platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG
platform/x86: asus-laptop: Fix ACPI event handling
platform/x86: hp-wmi: Fix board_params typo for 8DD6 board
Merge tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fix from Niklas Cassel:
- Drop documentation for no longer existing pata_legacy kernel
parameters (Ethan)
* tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: pata_legacy: remove documentation for removed module parameters
Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- Fix the start and length check added to iov_iter_extract_bvecs(),
which used iter_iov_addr()/iter_iov_len() helpers that aren't safe
for the ITER_BVEC/FOLIOQ/etc iterator types passed
- sunvdc fixes for an -EIO issue from lack of retries, and unmapping
LDC cookies when the descriptor send fails
- Clear force_abort in ublk_queue_reset_io_flags()
- ublk selftest install fix
* tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
selftests: ublk: add batch IO cases to recover_03
ublk: clear force_abort in ublk_queue_reset_io_flags()
sunvdc: fix -EIO issue due to lack of retries
sunvdc: unmap LDC cookies when the descriptor send fails
block: Fix start and length check added to iov_iter_extract_bvecs()
selftests: ublk: install test_common.sh and trace/ scripts
Merge tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Fix a deadlock in the write path with superblock freezing
- Fix an issue where a provided buffer ring would overconsume when
using MSG_TRUNC
- Keep the CQE flags on iopoll requests when adding kbuf flags
* tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags
io_uring/net: don't overconsume buffers when using MSG_TRUNC
io_uring/net: let io_recv_buf_select return the length of the buffer region
io_uring/rw: end write accounting from ->ki_complete
Merge tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab
Pull slab fixes from Vlastimil Babka:
- Stable fix for an ABA issue causing slab list corruption introduced
in 7.2 (Harry Yoo, with big thanks to Hyunwoo Kim for the thorough
report and initial version of the fix)
- Fix for 7.3 regression of kvfree_rcu() on PREEMPT_RT which can cause
a deadlock from the set_cpus_allowed_force() caller (Vlastimil Babka)
* tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab:
mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race
mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again
ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()
rb_wake_up_waiters() is a irq_work callback which is initialized with
init_irq_work(). As such it will be invoked in thread context on
PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an
option due its usage of wake_up_all(). Since this callback may run in
thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with
disabling interrupts and may not assume that they are disabled.
Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock.
Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de Fixes: 68282dd930ea3 ("ring-buffer: Fix resetting of shortest_full") Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Steven Rostedt [Fri, 11 Sep 2026 02:12:09 +0000 (22:12 -0400)]
tracing: Take trace_array reference when opening a tracer options file
When a tracer option file is opened, it is passed a descriptor that points
to an element on the trace_array's topts array. This element has
information to find the trace array and other information. It uses this
element to take a reference of the trace_array so that the trace_array
does not get removed while this file is opened.
Unfortunately, there's a race condition where the element itself could be
freed by the removal of the instance the trace_array represents causing a
use-after-free as this element that is used to find the trace_array to
increment its reference counter is also freed when the instance is
removed.
To solve this, add a trace_array_tracer_options_get() helper function that
will take the address of the element that is passed to the open function
by the inode->i_private pointer and search all the trace_arrays under a
lock to find the one that the element's address is in the range of the
trace_arrays topts array elements. When a match happens, that trace_array's
reference would be increased.
Note, there's a race where if an admin was deleting and creating trace
instances at the same time and the memory of the old trace_array's array
matched the memory of the new trace_array that it could in theory open the
option from the wrong trace array. But we do not care because it would be
stupid to perform that kind of action. As long as the only thing that can
happen is that the option from the wrong trace array is used and doesn't
crash the kernel it will only make the user confused. But if they are
doing something stupid like this, they are already confused, so no harm
done.
Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910221209.62dad8d3@robin Fixes: 7e2cfbd2d3c86 ("tracing: Have option files inc the trace array ref count") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/ Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
ring_buffer_read_page_size() takes a parameter named rpage, but its
kernel-doc describes page. As a result, kernel-doc reports rpage as
undescribed and page as an excess parameter description.
Rename the documentation entry to match the function.
Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event()
While ftrace_set_clr_event() modifies its input buffer during parsing,
before returning to the caller the buffer is supposed to be restored
to its original state.
This works correctly for the colon between the subsystem and event
but not the colon at the beginning of :mod:.
Restore the colon, so the :mod: trailer is not stripped after
ftrace_set_clr_event().
tracing: Fix memory corruption from a "STACKTRACE" histogram key
"cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined
with an offset and a size of zero so that the filter code can match them
by name. parse_field() maps them onto their common_* equivalents for
backward compatibility, but unlike the common_* names it hands the
placeholder back to the caller instead of NULL.
create_hist_field() takes a non-NULL field as a promise that the record
carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc
word is read from offset 0, that is from common_type, and its low 16
bits are followed as an offset into the record. What is found there
becomes the length of an unbounded memcpy. Pick an event whose id is
small enough that the offset stays inside its own record and the length
is a kernel text address:
Oops: general protection fault, probably for non-canonical address
RIP: 0010:rb_next+0x23/0x60
</IRQ>
RIP: 0010:memcpy+0xc/0x30
event_hist_trigger+0x2e7/0x12c0
Kernel panic - not syncing: Fatal exception in interrupt
Leave the field NULL, which is what the comment above the branch says
the code does and what common_stacktrace already does. FILTER_CPU and
FILTER_COMM are left alone, their create_hist_field() branches never
look at the field.
tracing: Fix memory corruption from the histogram stacktrace modifier
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace"
modifier before it looks the field name up, and nothing afterwards
checks that the name resolved to a field which holds a stacktrace.
create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the
field pointer alone, which reads a __data_loc word from the record and
follows its low 16 bits as an offset into the same record.
event_hist_trigger() takes the first word there as an entry count and
copies that many longs into a 31 entry array:
The timer interrupt landed on the rbtree the copy had already run over.
No debug options are needed for this; KASAN reports the same write as an
out-of-bounds read of 13835058055416381440 bytes.
Documentation/trace/histogram.rst already states the rule, "must be a
long[] type", so enforce it once the name has been resolved. Names which
resolve to no field at all, "hitcount.stacktrace" and the common_*
pseudo-fields, are refused for the same reason: they hold no stacktrace
to read.
tracing: Undo the registration when enabling the histogram trigger fails
Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers
list") described how a trigger that is registered but not on file->triggers
ends up freed while still on the global named_triggers list, and moved the
registration down so that hist_trigger_enable() follows it immediately. One
path still gets there. hist_trigger_enable() adds the trigger and takes it
straight back out when the event cannot be enabled:
list_add_tail_rcu(&data->list, &file->triggers);
update_cond_flag(file);
if (trace_event_trigger_enable_disable(file, 1) < 0) {
list_del_rcu(&data->list);
update_cond_flag(file);
ret--;
}
so the list walk in hist_unregister_trigger() matches nothing, test stays
NULL, and the ->free() that would call del_named_trigger() is skipped.
out_unreg falls through to out_free, which frees the trigger anyway:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff8880091d3160 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 69:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Leave the trigger where hist_unregister_trigger() can find it and let that
undo the registration, which is the only code that knows all of what
cmd_ops->init() took: the named list entry, the hist_pad reference, the
reference on the trigger a named histogram is shared with, and the copied
cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(),
whose sm_ref and buffered event reference are otherwise left behind.
Since ->free() releases trigger_data and, for a trigger that does not share
its histogram, hist_data with it, out_unreg can no longer fall through to
out_free. For a trigger that does share, hist_register_trigger() has
already destroyed the caller's hist_data, so the fall-through was reading
freed memory there as well.
Move the enable_timestamps check in hist_unregister_trigger() above the
->free() call for the same reason: hist_data does not outlive it once the
trigger being removed is the one that owns it.
Cc: stable@vger.kernel.org Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reported-by: Sashiko AI <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
tracing: Take the reference before publishing the named histogram trigger
event_hist_trigger_named_init() puts the trigger on the global
named_triggers list and only then takes the reference on the trigger it
shares its histogram with:
data->ref++;
save_named_trigger(data->named_data->name, data);
ret = event_hist_trigger_init(data->named_data);
if (ret < 0) {
kfree(data->cmd_ops);
data->cmd_ops = &trigger_hist_cmd;
}
return ret;
event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and
nothing takes the trigger back off the list on the way out.
event_hist_trigger_parse() frees it, and the next lookup by name reads the
freed object:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff888009346860 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 67:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Do the reference first and publish once it has succeeded, so that nothing
which can fail runs after the trigger becomes findable.
Cc: stable@vger.kernel.org Fixes: 7ab0fc61ce73 ("tracing: Move histogram trigger variables from stack to per CPU structure") Reported-by: Sashiko AI <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Acked-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
tracing: Set the trace clock before registering the histogram trigger
hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock:
if (data->cmd_ops->init) {
ret = data->cmd_ops->init(data);
if (ret < 0)
goto out;
}
if (hist_data->enable_timestamps) {
ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
if (ret) {
hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
goto out;
}
The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable. event_hist_trigger_parse() then frees it
without taking it off the list, and the next lookup by name reads the
freed object:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff88800915d760 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0x900
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 63:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Set the clock before the trigger is registered, so that nothing which
can fail runs after it is published, the way commit 6f86bdeab633
("tracing: Fix bad hist from corrupting named_triggers list") moved the
registration below the rest of the setup.
tracing_set_filter_buffering() is reference counted, so the init failure
path has to drop the reference that the clock block now takes first.
Correct "preceeded" to "Preceded", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Correct "availabe" to "available", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
tracing: Let histogram values keep the percent and graph modifiers
The .percent and .graph modifiers exist only for histogram values, but a
value carrying either of them has been rejected since v6.3. The example
in Documentation/trace/histogram.rst,
parse_field() sets the two flags only when the field is neither a key nor
a variable, that is, only on a value:
} else if (strncmp(modifier, "percent", 7) == 0) {
if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY))
goto error;
*flags |= HIST_FIELD_FL_PERCENT;
__create_val_field() then rejects a value for carrying them, so no field
can reach hist_trigger_print_val(), where both are implemented.
commit e0213434fe3e ("tracing: Do not let histogram values have some
modifiers") added the check after a value with .buckets oopsed in
hist_field_name(). That happens because .buckets and .log2 make
create_hist_field() build a nested field in operands[0] which
hist_field_name() then walks into. The percent and graph flags do not
create an operand and are not read by hist_field_name(); they are only
used when printing a value.
Stop rejecting the two flags on a value. The check for variables is left
alone, where they are unreachable anyway because parse_field() rejects a
variable carrying them first.
With the two flags removed, the trigger above installs and prints as
documented:
tracing: Keep the entry count when the histogram stats allocation fails
print_entries() uses n_entries both as the number of sort entries and as
its own return value, so the -ENOMEM it stores when the stats allocation
fails overwrites the count that the cleanup still needs:
tracing_map_destroy_sort_entries() takes an unsigned int and loops up to
it, so -ENOMEM arrives as 4294967284. It walks an array of at most
map->max_elts pointers and calls destroy_sort_entry(), which dereferences
and frees, on whatever lies past the end.
Reading the hist file of a trigger with a .percent value, with that
allocation forced to fail:
BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0
Read of size 8 at addr ffffc90000045000 by task init/1
tracing_map_destroy_sort_entries+0xa0/0xb0
hist_show+0x6f7/0x1df0
seq_read_iter+0x2b8/0x1190
vfs_read+0x176/0xa40
The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50
A few pages further the fault is fatal. The registers at the oops confirm
the bound: the loop's end pointer less the array start, over the pointer
size, is 4294967284.
Return the error in a separate variable and leave n_entries holding the
count, the way tracing_map_sort_entries() does on its own error path.
The stats block is only entered for a value carrying .percent or .graph,
which __create_val_field() has rejected since v6.3, so this cannot be
reached in mainline as it stands. It becomes reachable again with
"tracing: hist: let values keep the percent and graph modifiers", so it
should be applied first.
tracing: Free histogram the field rejected for a bad modifier
Writing a hist trigger whose value or variable carries a modifier that is
not allowed there leaks the fields that were built for it.
__create_val_field() takes the field from parse_expr() and stores it in
hist_data->fields[] only after the modifier checks have run:
hist_field = parse_expr(hist_data, file, field_str, flags, var_name,
&n_subexprs);
...
if (hist_field->flags & HIST_FIELD_FL_VAR) {
if (hist_field->flags & (...))
goto err;
} else {
if (hist_field->flags & (...))
goto err;
}
hist_data->fields[val_idx] = hist_field;
Both checks jump past that store, and the err label returns without
freeing anything. The error unwinds to create_hist_data(), which calls
destroy_hist_data() -> destroy_hist_fields(), and that reaches a field
only by walking fields[]. A field that never got there is unreachable.
commit e0213434fe3e ("tracing: Do not let histogram values have some
modifiers") set ret to -EINVAL and fell through to the store, which left
the field owned by fields[] and freed along with the rest of hist_data.
Splitting the check into a value case and a variable case replaced that
fall-through with a goto that skips it.
each correctly rejected with -EINVAL, leave 332 unreferenced objects
(63744 bytes) reported at create_hist_field(); 200 install and remove
cycles of a valid trigger leave none. A '.log2' field is two
allocations, since create_hist_field() puts the plain field in
operands[0] of the log2 field, and both are reported.
Use destroy_hist_field() rather than __destroy_hist_field() so that
operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF,
which is what an operand owned by hist_data->var_refs[] needs; the
rejected field itself is never a var ref, because a var ref never carries
a modifier flag.
tracing: Free histogram the var ref when its initialization fails
create_var_ref() allocates a VAR_REF hist_field and then calls
init_var_ref() to fill it in. When that fails the field is leaked.
commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made destroy_hist_field() return early for
HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's
var_refs[] array instead. create_var_ref() adds the field to that array
only after init_var_ref() has succeeded, so on this path the field is in
neither place and nothing frees it. The call was correct when it was
written, before var refs were taken out of destroy_hist_field().
init_var_ref() cannot free it either. The caller owns the field, so
init_var_ref() undoes only its own string allocations and leaves the
field alone. Freeing it there would leave create_var_ref() passing freed
memory to destroy_hist_field(), which reads its flags.
Call __destroy_hist_field(), which frees the field without consulting
the flag.
tracing: Free histogram var refs regardless of how often they are referenced
Using the same variable three or more times in one hist trigger leaks the
variable reference and its strings when the trigger is removed.
commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made a trigger's var_refs[] array the only owner of a var ref:
destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field
expressions never destroy one. One entry, freed once, no count needed.
commit 8bcebc77e85f ("tracing: Fix histogram code when expression has same
var as value") then made repeated references share one object and added a
count of them. Only the increment side exists, since those expressions
still return early and never drop a reference, so __destroy_hist_field()
sees how many references were created rather than how many are left. It
frees when the decremented count is 0 or 1, so two references work and
three or more leak.
Sharing kept one array entry per object, and create_var_ref() searches and
appends within a single trigger, so nothing outside it holds the object.
Removing a trigger whose variables are still referenced is already refused
by check_var_refs() with -EBUSY. Drop the count and free unconditionally.
Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com Fixes: 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
function_graph: Use the saved entry's size when reprinting it
When a graph entry does not fit in the trace_seq, print_graph_entry()
saves it in the iterator's fgraph_data and reprints it on the next read.
The entry has already been consumed from the ring buffer by then, so the
copy is all that is left of it.
The copy is sized with iter->ent_size, which no longer describes the
saved entry but whatever entry the iterator has moved on to. The
argument count is derived from the same field, so a 72 byte entry saved
and then reprinted ahead of a 48 byte return entry loses its arguments.
Record the size next to the failure flag, so that the two are always set
together, and restore it before reprinting.
FGRAPH_MAX_INDEX has no user, and it expands to FGRAPH_INDEX_SIZE and
FGRAPH_RET_INDEX, neither of which is defined anywhere in the tree. It
was added in that form by commit 91c46b0aa917 ("function_graph:
Implement fgraph_reserve_data() and fgraph_retrieve_data()"), which
introduced the current data word layout under new names, so anything
referencing it would have failed to build ever since.
Jérémy Jean [Sat, 22 Aug 2026 19:53:22 +0000 (19:53 +0000)]
ftrace: fork: Initialize function graph state before copy_exec_state()
dup_task_struct() copies the parent's task_struct, including ret_stack.
ftrace_graph_init_task() clears the copied function graph state, but it
currently runs after copy_exec_state().
For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state.
If that allocation fails, copy_process() reaches bad_fork_free and
free_task() calls ftrace_graph_exit_task(). Since the child still carries
the parent's ret_stack pointer, the unwind frees the parent's active
function graph return stack. The parent subsequently accesses freed memory
from function_graph_enter_regs().
Henry Martin [Fri, 4 Sep 2026 11:52:23 +0000 (19:52 +0800)]
tracing/user_events: Don't destroy fields when event removal fails
destroy_user_event() destroys the event's fields before attempting to
remove the trace event call. If user_event_set_call_visible() fails,
e.g. because the event is still enabled and trace_remove_event_call()
returns -EBUSY, the event is left registered with an irreversibly
destroyed field list. Any subsequent interaction with the event then
operates on an empty field list while it is still fully visible in
tracefs.
Move the field destruction after the call removal, and splice the
field list back onto the event when the removal fails so the event
remains in a consistent state.
Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260904115223.2976446-1-bsdhenrymartin@gmail.com Fixes: 7f5a08c79df35 ("user_events: Add minimal support for trace_event into ftrace") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Reviewed-by: Beau Belgrave <beaub@linux.microsoft.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Merge tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of device-specific small fixes. At this time, the
majority of changes are about ASoC while we have usual suspects like
HD- and USB-audio quirks. Some highlights below.
ASoC Intel / SoundWire:
- Fix bus and stream resource leaks at error path in avs and hda-ext
- More fixes and refactoring in avs for constraining MSBs, async
handling D0ix
- Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682
machines
- Fix uninitialized stream configurations in Realtek SoundWire codecs
- Adjust latency control to fix no-sound issue on RT721-SDCA
ASoC AMD:
- Avoid binding for the acp-da7219-max98357a machine driver
- Add quirks for Acer Nitro AN17-41 and HP 255R G10
- Fix memory leaks in ACP6x
ASoC Codecs & Platforms:
- Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM
imbalances
- Split stereo streams across mono amps on tas2783-sdw
- Fix pop noise on es8326 and enable_count underflow on es8389
- Various fixes for fsl_micfil, sprd, sti, and publish OF module
aliases
- Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs
HD-audio:
- Fix for channel status notification changes
- Quirks for HP laptops
USB-audio:
- Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers
- More hardening in usx2y and us122l drivers
- Quirks for Behringer devices
Misc:
- Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm
- Fix S/PDIF passthrough on CA20K2 in ctxfi"
* tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (65 commits)
ALSA: hdspm: Add a new PCI device ID (1d18:3fc6) for RME HDSPe AIO PCI express audio
ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards
ALSA: hda: Report a change when only the channel status bytes move
ALSA: us122l: Prevent write upgrades for read mappings
ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Max G2 speaker
ASoC: cs35l56: Fix race between kexec and snd_soc_register_component()
ASoC: amd: yc: add quirk for Acer Nitro AN17-41 internal mic
ASoC: mt6351: Publish the OF module alias
ASoC: Intel: SST: Publish the PCI module aliases
ASoC: bcm: bcm63xx: Publish the OF module aliases
ALSA: usb-audio: Add quirk flags for Behringer UV1
ALSA: usb-audio: Add boot quirk for Behringer CM1A
ALSA: hda/realtek: Add quirk for HP Omen 16-wd0xxx mute LED
ALSA: usbusx2y: validate URB actual_length in interrupt callback
ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf
ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough
ALSA: usb: 6fire: Avoid embedded URBs
ALSA: usb: hiface: Avoid embedded URBs
ALSA: usb: ua101: Avoid embedded URBs
ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev
...
iommu/amd: Remove redundant check in irq_remapping_select()
The amd_iommu_irq_remap flag is already validated during irq remapping
domain creation (before calling amd_iommu_create_irq_domain()). The
duplicate check in irq_remapping_select() is unnecessary and can be
removed.
bootconfig: Fix integer overflow in initrd size check
Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd
with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer
arithmetic:
data = ((void *)hdr) - size;
to wrap around on 32-bit systems (or when pointer subtraction overflows).
Because data wraps around, the subsequent bounds check:
if ((unsigned long)data < initrd_start)
evaluates to false, bypassing the check. The kernel then calls
xbc_calc_checksum(data, size), which attempts to read 4GB of memory,
hitting unmapped pages and triggering a fatal kernel page fault during
early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an
unbounded 32-bit size can similarly bypass the initrd_start check.
Fix this by:
1. Ensuring the initrd is at least large enough to contain the bootconfig
footer and verifying hdr is within the initrd bounds.
2. Checking that size does not exceed XBC_DATA_MAX and does not exceed
the available space between initrd_start and hdr before performing
pointer subtraction.
Link: https://lore.kernel.org/all/178905333479.213925.1358412668943562406.stgit@devnote2/ Fixes: de462e5f1071 ("bootconfig: Fix to remove bootconfig data from initrd while boot") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.8-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
tools/bootconfig: Fix integer overflow and truncation in size checks
Sashiko reported that on 32-bit systems, if an attacker crafts size in
the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around
(for instance, if size is 0xFFFFFFFF), the size check in
load_xbc_from_initrd() can be bypassed:
if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) {
pr_err("bootconfig size is too big\n");
return -E2BIG;
}
Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a
corrupted 32-bit size (e.g. 0xFFFFFFFF) against
stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if
size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size
directly into the 32-bit int size parameter of load_xbc_fd(), truncating
large standalone files (>= 2GB).
In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1,
resulting in malloc(0), an integer overflow in read(), and an
out-of-bounds null-byte write.
Fix this by:
1. Rejecting size > XBC_DATA_MAX or
size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd().
2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing
it to load_xbc_fd().
3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd().
projects / linux / log