Convert fuse iomap_ops to the new ->iomap_next() callback. Each callback is
generated with the DEFINE_IOMAP_ITER_NEXT()/DEFINE_IOMAP_ITER_NEXT_END()
macros, which wrap the iomap_iter_next() helper to finish the previous
mapping if needed and produce the next one. No functional changes are
intended.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-19-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert hpfs iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-18-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert gfs2 iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT_END() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-17-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert f2fs iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-16-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert ext2 iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT_END() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-14-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert ntfs iomap_ops to the new ->iomap_next() callback. Each callback is
generated with the DEFINE_IOMAP_ITER_NEXT()/DEFINE_IOMAP_ITER_NEXT_END()
macros, which wrap the iomap_iter_next() helper to finish the previous
mapping if needed and produce the next one. No functional changes are
intended.
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-10-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert ntfs3 iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT_END() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-9-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert btrfs iomap_ops to the new ->iomap_next() callback. The callback is
generated with the DEFINE_IOMAP_ITER_NEXT_END() macro, which wraps the
iomap_iter_next() helper to finish the previous mapping if needed and
produce the next one. No functional changes are intended.
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-8-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert xfs iomap_ops to the new ->iomap_next() callback. Each callback is
generated with the DEFINE_IOMAP_ITER_NEXT()/DEFINE_IOMAP_ITER_NEXT_END()
macros, which wrap the iomap_iter_next() helper to finish the previous
mapping if needed and produce the next one. No functional changes are
intended.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-7-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Have one ->iomap_next() callback instead of ->iomap_begin() and
->iomap_end(). ->iomap_next() finishes the previous mapping if needed,
and produces the next mapping.
Collapsing to a single callback lets a performance-critical caller
inline its iteration loop and pass its ->iomap_next() function as a
compile-time constant, so the compiler can devirtualize that callback
into a direct call instead of an indirect call through a function
pointer.
iomap_iter() uses ->iomap_next() when the filesystem provides that
callback and otherwise falls back to the ->iomap_begin()/->iomap_end()
path, so filesystems can be converted one at a time.
Suggested-by: Christoph Hellwig <hch@lst.de>
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-6-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The pending iomap_iter_next conversion creates performance issues for the
new simple direct I/O read fast path, because it assumes a model where
the iterator must be advanced at the end, which the direct I/O read fast
path tries to avoid.
Side step this by splitting the simple path from iomap_dio_rw, and
require the file systems to call into it explicitly, and pass only a
->begin callback. This allows to drop various checks for incompatible
features while creating a requirement for the file system to only call
the simple path for cases that it can handle.
As a side-benefit we can now inline the initial part of the simple
direct I/O read fast path and let the compiler convert the indirect call
to ->begin into a direct call.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Fengnan Chang <changfengnan@bytedance.com>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260729192737.3190206-4-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
In preparation for changing iomap to use an in-iter (->iomap_next())
model, move the iomap_iter() logic out into the new iomap_iter_next()
helper function.
iomap_iter_next() is added as an inlined helper so it can be called
directly by ->iomap_next() implementations where the begin()/end()
callbacks can be direct calls.
The DEFINE_IOMAP_ITER_NEXT() and DEFINE_IOMAP_ITER_NEXT_END() macros are
also provided to generate the boilerplate ->iomap_next() wrapper
functions that simply forward to iomap_iter_next() with the appropriate
begin/end callbacks. DEFINE_IOMAP_ITER_NEXT() is for the common case
where there is no end() callback. DEFINE_IOMAP_ITER_NEXT_END() is for
the case where there is an explicit end() callback.
No functional change intended. The one would-be behavioral difference is
that on the iomap_end() error path (ret < 0 && !advanced), the old code
returned with iter.status left as the caller's last value whereas the
new code zeroes it, but this is not observable in practice as there are
no in-tree callers that read iter.status after the iteration loop.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Fengnan Chang <changfengnan@bytedance.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260729192737.3190206-3-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
A sashiko review of an unrelated patch points out that the folio
batch mechanism used for iomap zero range fails to release the batch
in a couple error scenarios. If either calls to ->iomap_end() or
->iomap_begin() fail, the direct return paths bypass the batch
cleanup.
The ->iomap_end() case is not a practical issue at the moment
because there is no user of the mechanism that returns an error from
this path. The ->iomap_begin() case is theoretically possible
because XFS can invoke the fill helper and error out at various
points thereafter. This subtly complicates things because XFS does
not transfer iomap_flags to the iomap data structure in the error
path.
To deal with both of these issues, first make sure to invoke the
cleanup helper in the error path for either fs callback. Second,
update the helper to clear the flag unconditionally and release the
batch so long as it is populated. This more clearly delineates the
purpose of the flag to control the I/O path and not necessarily the
status of the fbatch, so add a comment around this as well.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 395ed1ef00 ("iomap: optional zero range dirty folio processing")
Signed-off-by: Brian Foster <bfoster@redhat.com>
Link: https://patch.msgid.link/20260729192737.3190206-2-joannelkoong@gmail.com
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Joanne Koong <joannelkoong@gmail.com> says:
iomap/fuse: add helper to keep uptodate bitmap in sync
Filesystems that use iomap normally mark folios uptodate through the iomap
read/write paths, which keep iomap's internal uptodate bitmap in sync.
However, some filesystems need to write data directly into the page cache
outside of those paths (eg fuse, which may need to write server-pushed data
straight into the page cache for servicing notify stores). These filesystems
need a way to mark a folio uptodate that also updates the iomap bitmap so
they're kept in sync.
This series adds iomap_folio_mark_uptodate() for filesystems to do that and
updates the relevant fuse call paths to use this. This is needed before fuse
can enable large folios.
Patch 1 ("fuse: don't clear folio uptodate on writethrough errors") was
originally submitted to the fuse tree [1] but patch 3 ("fuse: use iomap helper
to mark folio uptodate") has a dependency on it, so to make cross-coordination
between trees easier, patch 1 is now part of this series and submitted to the
vfs tree.
[1] https://lore.kernel.org/fuse-devel/20260624205201.842714-1-joannelkoong@gmail.com/
* patches from https://patch.msgid.link/20260707220450.1200943-1-joannelkoong@gmail.com:
fuse: use iomap helper to mark folio uptodate
iomap: add helper to mark folio uptodate
fuse: don't clear folio uptodate on writethrough errors
Link: https://patch.msgid.link/20260707220450.1200943-1-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
When fuse enables large folios, a large folio will be backed by
iomap_folio_state that keeps track of uptodate and dirty state in an
internal bitmap.
Fuse writethrough and notify store paths currently set folio uptodate
state with folio_mark_uptodate(), which touches only the folio-level
flag, but on an iomap-backed folio, that leaves the uptodate bitmap out
of sync.
Use the iomap_folio_mark_uptodate() helper to update both the folio
uptodate state and the iomap uptodate bitmap.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260707220450.1200943-4-joannelkoong@gmail.com
Acked-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Add an exported helper iomap_folio_mark_uptodate() to mark a folio as
uptodate and update its uptodate bitmap if the folio has iomap state
data attached.
This is needed because there are some filesystems (eg fuse) that have
paths outside of conventional iomap calls that need to mark a folio as
uptodate (eg writing server-pushed data directly into the page cache)
and need the iomap-internal uptodate bitmap to be in sync with the
uptodate state of the folio.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260707220450.1200943-3-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
In the writethrough path (fuse_send_write_pages()), if the write to the
server failed or was a short write, the uptodate flag on the folios are
cleared.
As explained by Matthew in [1], this is dangerous because the folio may
be mapped into userspace. The mm code has the invariant that a
non-uptodate folio must never be visible to userspace (to avoid
potentially leaking confidental information to userspace) and has checks
in place for this that if violated can bring down the whole machine.
Practically speaking, the effect of this change for the fuse
writethrough error path is that if an application does a write and then
the server fails to persist the data or only services a short write, the
page cache folio keeps the data the application wrote instead of being
reverted to the server's contents on the next read. The failure is still
reported to the application synchronously through the short count /
error return of the write() syscall. Folios that were only partially
written are unaffected since they were never marked uptodate in the
first place (fuse_fill_write_page() only marks a folio as uptodate if
the whole folio was written to).
[1] https://lore.kernel.org/linux-fsdevel/ajtPMgO65FA1TXhi@casper.infradead.org/
Suggested-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260707220450.1200943-2-joannelkoong@gmail.com
Acked-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Fengnan Chang <changfengnan@bytedance.com> says:
iomap: add simple dio path for small direct I/O
When running 4K random read workloads on high-performance Gen5 NVMe
SSDs, the software overhead in the iomap direct I/O path
(__iomap_dio_rw) becomes a significant bottleneck.
Using io_uring with poll mode for a 4K randread test on a raw block
device:
taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
-n1 -P1 /dev/nvme10n1
Result: ~3.2M IOPS
Running the exact same workload on ext4 and XFS:
taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
-n1 -P1 /mnt/testfile
Result: ~1.92M IOPS
Profiling the ext4 workload reveals that a significant portion of CPU
time is spent on memory allocation and the iomap state machine
iteration:
5.33% [kernel] [k] __iomap_dio_rw
3.26% [kernel] [k] iomap_iter
2.37% [kernel] [k] iomap_dio_bio_iter
2.35% [kernel] [k] kfree
1.33% [kernel] [k] iomap_dio_complete
Introduce a simple dio path to reduce the overhead of iomap. It is
triggered when the request satisfies all of:
- a READ request whose I/O size is <= inode blocksize (fits in a single
block, no splits);
- no custom iomap_dio_ops (dops) registered by the filesystem;
- no caller-accumulated residual (done_before == 0);
- none of IOMAP_DIO_FORCE_WAIT / IOMAP_DIO_PARTIAL / IOMAP_DIO_BOUNCE
set, the range is within i_size, and the inode is not encrypted.
The bio is allocated from a dedicated bioset whose front_pad embeds
struct iomap_dio_simple, so the whole request lives in a single
cacheline-aligned allocation and no separate struct iomap_dio is
needed. Completion is handled inline from ->bi_end_io for the common
success case, and only punted to the s_dio_done_wq workqueue on error.
After this optimization, the heavy generic functions disappear from the
profile, replaced by a single streamlined execution path:
4.83% [kernel] [k] iomap_dio_simple
With this patch, 4K random read IOPS on ext4 increases from 1.92M to
2.19M in the original single-core io_uring poll-mode workload.
Below are the test results using fio:
fs workload qd simple=0 simple=1 gain
ext4 libaio 1 18,740 18,761 +0.11%
ext4 libaio 64 462,850 480,587 +3.83%
ext4 libaio 128 459,498 478,824 +4.21%
ext4 libaio 256 459,938 480,156 +4.40%
ext4 io_uring 1 18,836 18,880 +0.24%
ext4 io_uring 64 568,193 600,625 +5.71%
ext4 io_uring 128 570,998 602,148 +5.46%
ext4 io_uring 256 572,052 602,536 +5.33%
ext4 io_uring_poll 1 19,283 19,272 -0.06%
ext4 io_uring_poll 64 989,735 1,013,342 +2.39%
ext4 io_uring_poll 128 1,467,336 1,538,444 +4.85%
ext4 io_uring_poll 256 1,663,498 1,830,842 +10.06%
xfs libaio 1 18,764 18,776 +0.06%
xfs libaio 64 462,408 480,860 +3.99%
xfs libaio 128 461,280 480,819 +4.24%
xfs libaio 256 461,626 480,190 +4.02%
xfs io_uring 1 18,871 18,903 +0.17%
xfs io_uring 64 570,383 597,399 +4.74%
xfs io_uring 128 568,290 597,370 +5.12%
xfs io_uring 256 570,616 598,775 +4.93%
xfs io_uring_poll 1 19,211 19,315 +0.54%
xfs io_uring_poll 64 989,726 1,008,455 +1.89%
xfs io_uring_poll 128 1,430,426 1,513,064 +5.78%
xfs io_uring_poll 256 1,587,339 1,742,220 +9.76%
* patches from https://patch.msgid.link/20260701033253.46420-1-changfengnan@bytedance.com:
iomap: add simple dio path for small direct I/O
iomap: pass error code to should_report_dio_fserror directly
iomap: factor out iomap_dio_alignment helper
Link: https://patch.msgid.link/20260701033253.46420-1-changfengnan@bytedance.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
When running 4K random read workloads on high-performance Gen5 NVMe
SSDs, the software overhead in the iomap direct I/O path
(__iomap_dio_rw) becomes a significant bottleneck.
Using io_uring with poll mode for a 4K randread test on a raw block
device:
taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
-n1 -P1 /dev/nvme10n1
Result: ~3.2M IOPS
Running the exact same workload on ext4 and XFS:
taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
-n1 -P1 /mnt/testfile
Result: ~1.92M IOPS
Profiling the ext4 workload reveals that a significant portion of CPU
time is spent on memory allocation and the iomap state machine
iteration:
5.33% [kernel] [k] __iomap_dio_rw
3.26% [kernel] [k] iomap_iter
2.37% [kernel] [k] iomap_dio_bio_iter
2.35% [kernel] [k] kfree
1.33% [kernel] [k] iomap_dio_complete
Introduce a simple dio path to reduce the overhead of iomap. It is
triggered when the request satisfies all of:
- a READ request whose I/O size is <= inode blocksize (fits in a single
block, no splits);
- no custom iomap_dio_ops (dops) registered by the filesystem;
- no caller-accumulated residual (done_before == 0);
- none of IOMAP_DIO_FORCE_WAIT / IOMAP_DIO_PARTIAL / IOMAP_DIO_BOUNCE
set, the range is within i_size, and the inode is not encrypted.
The bio is allocated from a dedicated bioset whose front_pad embeds
struct iomap_dio_simple, so the whole request lives in a single
cacheline-aligned allocation and no separate struct iomap_dio is
needed. Completion is handled inline from ->bi_end_io for the common
success case, and only punted to the s_dio_done_wq workqueue on error.
After this optimization, the heavy generic functions disappear from the
profile, replaced by a single streamlined execution path:
4.83% [kernel] [k] iomap_dio_simple
With this patch, 4K random read IOPS on ext4 increases from 1.92M to
2.19M in the original single-core io_uring poll-mode workload.
Below are the test results using fio:
fs workload qd simple=0 simple=1 gain
ext4 libaio 1 18,740 18,761 +0.11%
ext4 libaio 64 462,850 480,587 +3.83%
ext4 libaio 128 459,498 478,824 +4.21%
ext4 libaio 256 459,938 480,156 +4.40%
ext4 io_uring 1 18,836 18,880 +0.24%
ext4 io_uring 64 568,193 600,625 +5.71%
ext4 io_uring 128 570,998 602,148 +5.46%
ext4 io_uring 256 572,052 602,536 +5.33%
ext4 io_uring_poll 1 19,283 19,272 -0.06%
ext4 io_uring_poll 64 989,735 1,013,342 +2.39%
ext4 io_uring_poll 128 1,467,336 1,538,444 +4.85%
ext4 io_uring_poll 256 1,663,498 1,830,842 +10.06%
xfs libaio 1 18,764 18,776 +0.06%
xfs libaio 64 462,408 480,860 +3.99%
xfs libaio 128 461,280 480,819 +4.24%
xfs libaio 256 461,626 480,190 +4.02%
xfs io_uring 1 18,871 18,903 +0.17%
xfs io_uring 64 570,383 597,399 +4.74%
xfs io_uring 128 568,290 597,370 +5.12%
xfs io_uring 256 570,616 598,775 +4.93%
xfs io_uring_poll 1 19,211 19,315 +0.54%
xfs io_uring_poll 64 989,726 1,008,455 +1.89%
xfs io_uring_poll 128 1,430,426 1,513,064 +5.78%
xfs io_uring_poll 256 1,587,339 1,742,220 +9.76%
Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
Link: https://patch.msgid.link/20260701033253.46420-4-changfengnan@bytedance.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Pull NTB updates from Jon Mason:
"An EPF bug fix to prevent an invalid unmap during device removal,
along with documentation fixes and minor AMD driver cleanups"
* tag 'ntb-7.2' of https://github.com/jonmason/ntb:
ntb: amd: Use named initializer for pci_device_id::driver_data
NTB: fix kernel-doc warnings in ntb.h
NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR
ntb_hw_amd: Fix incorrect debug message in link disable path
Pull more input updates from Dmitry Torokhov:
- Updates to Synaptics RMI4 driver to fix potential OOB accesses in F30
and F3A keymap handling
- A workaround in Synaptics RMI4 to tolerate buggy firmware on some
touchpads (e.g. ThinkPad T14 Gen 1) that report incomplete register
descriptor structures, preventing probe failures
- A revert of an incorrect register descriptor address calculation in
Synaptics RMI4 driver
- A fix for a regression in HP GSC PS/2 (gscps2) driver where the
receive buffer write index was not advanced, leaving keyboard and
mouse unusable.
* tag 'input-for-v7.2-rc0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: gscps2 - advance receive buffer write index
Input: rmi4 - tolerate short register descriptor structure
Revert "Input: rmi4 - fix register descriptor address calculation"
Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
Pull pwm fixes from Uwe Kleine-König:
"Two more fixes that I managed to put into the public branch merged
into next before my first pull request but missed to include them in
it.
The first change is a relevant change that fixes misconfigurations due
to a variable overflow. The second is only cosmetic but very obviously
an improvement"
* tag 'pwm/for-7.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages
pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64
Pull more fbdev updates from Helge Deller:
"Fixes for generic fbdev & fbcon code for the handling of modelists
and preventing a potential NULL ptr dereference in the console code.
Fix missed cleanups in the error path of various fbdev drivers.
And Uwe Kleine-König contributed a cleanup patch to use named
initializers in the vga16fb driver"
* tag 'fbdev-for-7.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var
fbcon: fix NULL pointer dereference for a console without vc_data
fbdev: fix use-after-free in store_modes()
fbdev: viafb: return an error when DMA copy times out
fbdev: goldfishfb: fail pan display on base-update timeout
fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
fbdev: pm2fb: unwind WC setup on probe failure
fbdev: vga16fb: Drop unused assignment of platform_device_id driver data
Pull sound fixes from Takashi Iwai:
"A collection of small bug fixes accumulated over the last week.
Most are device-specific fixes while there are a few core fixes as
well.
Here are the highlights:
ALSA Core:
- A fix for an uninitialised heap leak in ALSA sequencer core
- A fix for error handling/resource leak in compress-offload API
USB-audio:
- A teardown-ordering fix in USB MIDI 2.0 to prevent use-after-free
- Bounds and length checks for packet data in Native Instruments
caiaq / Traktor Kontrol input parsers
- Avoidance of expensive kobject path lookups in DualSense controller
matches
- Robustness/memory leak fixes for Qualcomm USB offload driver
- Focusrite Control Protocol (FCP) NULL-pointer dereference fix and a
new device quirk (ISA C8X)
- Device-specific quirks for Yamaha CDS3000 and SC13A
HD-Audio:
- A bunch of quirks and mute/mic-mute LED fixups for various laptops
(Acer, Clevo, Lenovo, HP)
ASoC & SoundWire:
- Avoid failing card registration if the device_link creation fails
- A workaround for SoundWire randconfig build failures by making
helper functions static inline
- Corrected MCLK reference validation for CS530x codecs
- Clean up of untested, problematic guard() macro replacements in
Rockchip SAI driver
- Fix for eDMA maxburst misalignment with channel count in Freescale
ASRC
- Miscellaneous hardware-specific fixes (qcom, rt5650, tlv320aic3x,
tas2781/3)
Others:
- Bounds and length checks for packet data in Apple iSight"
* tag 'sound-fix-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (46 commits)
ALSA: FCP: Fix NULL pointer dereference in interface lookup
ALSA: hda/realtek: Update Acer Nitro ANV15-41 quirk to enable mute LED
ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count
ASoC: codecs: pcm512x: only print info once on no sclk
ASoC: tas2781: Update default register address to TAS2563
ALSA: firewire: isight: bound the sample count to the packet payload
ALSA: usb-audio: qcom: Free QMI handle
ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk
ALSA: usb-audio: avoid kobject path lookup in DualSense match
ALSA: hda/realtek: Add quirk for Acer Nitro ANV15-41
ASoC: soc-core: Don't fail if device_link could not be created
ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()
ASoC: rt5575: Use __le32 for SPI burst write address
ASoC: tas2783: Update loaded firmware names to linux-firmware 20260519
ASoC: SDCA: Validate written enum value in ge_put_enum_double()
ASoC: realtek: Add back local call to sdw_show_ping_status()
ASoC: ti: Add back local call to sdw_show_ping_status()
ASoC: max98373: Add back local call to sdw_show_ping_status()
ASoC: es9356: Add back local call to sdw_show_ping_status()
...
Pull RTC updates from Alexandre Belloni:
"Most of the work and improvements are for features of the m41t93.
The ds1307 also gets support for OSF (Oscillator Stop Flag) for
new variants.
The pcap driver is being removed as the Motorola EZX support was
removed a while ago.
Subsystem:
- add rtc_read_next_alarm() to read next expiring timer
Drivers:
- ds1307: handle OSF for ds1337/ds1339/ds3231, add clock provider for
ds1307, fix wday for rx8130
- m41t93: DT support, alarm, clock provider, watchdog support
- mv: add suspend/resume support for wakeup
- pcap: remove driver
- renesas-rtca3: many fixes"
* tag 'rtc-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (36 commits)
rtc: ds1307: update reference to removed CONFIG_RTC_DRV_DS1307_HWMON
platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
rtc: s35390a: fix typo in comment
rtc: cmos: unregister HPET IRQ handler on probe failure
rtc: ds1307: Fix off-by-one issue with wday for rx8130
dt-bindings: rtc: ds1307: Add epson,rx8901
rtc: bq32000: add delay between RTC reads
rtc: m41t93: Add watchdog support
rtc: m41t93: Add square wave clock provider support
rtc: m41t93: Add alarm support
rtc: m41t93: migrate to regmap api for register access
rtc: m41t93: add device tree support
dt-bindings: rtc: Add ST m41t93
rtc: ds1307: add support for clock provider in ds1307
rtc: mv: add suspend/resume support for wakeup
rtc: aspeed: add AST2700 compatible
dt-bindings: rtc: add ASPEED AST2700 compatible
rtc: interface: fix typos in rtc_handle_legacy_irq() documentation
rtc: msc313: fix NULL deref in shared IRQ handler at probe
rtc: remove unused pcap driver
...
Pull fscrypt fixes from Eric Biggers:
- Fix a bug where in a specific edge case, file contents en/decryption
could be done with the wrong data unit size
- Fix the data structure used for keeping track of users that have
added an fscrypt key to be a simple list instead of a 'struct key'
keyring
This fixes issues such as a lockdep report found by syzbot and
possible unintended interactions with the keyctl() system calls
* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux:
fscrypt: Replace mk_users keyring with simple list
fscrypt: Fix key setup in edge case with multiple data unit sizes
Commit 44f9200699 ("Input: gscps2 - use guard notation when
acquiring spinlock") moved the receive loop into gscps2_read_data()
and gscps2_report_data().
While moving the code, it preserved the writes to
buffer[ps2port->append], but omitted the following producer index
update from the original loop:
ps2port->append = (ps2port->append + 1) & BUFFER_SIZE;
As a result, append never advances. Since gscps2_report_data() only
reports bytes while act != append, the receive buffer always appears
empty and no keyboard or mouse data reaches the serio core.
Restore the omitted index update.
Fixes: 44f9200699 ("Input: gscps2 - use guard notation when acquiring spinlock")
Cc: stable@vger.kernel.org # 6.13+
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/460B5655BA580C60+20260624094739.850306-1-raoxu@uniontech.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some touchpads (e.g. ThinkPad T14 Gen 1) have buggy firmware that reports
a register descriptor structure size that is too small for the number of
registers it claims to have in the presence map. The remaining bytes in
the structure are 0, which with the new strict bounds checking causes the
parser to fail with -EIO, aborting the device probe.
Tolerate such short reads by dropping the remaining (unparseable or
0-size) registers from the list instead of failing the probe,
preventing the driver from trying to use them.
Fixes: 0adb483fbf ("Input: rmi4 - refactor register descriptor parsing")
Reported-by: Barry K. Nathan <barryn@pobox.com>
Tested-by: Barry K. Nathan <barryn@pobox.com>
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The register descriptor presence register is a packet register, which
means its bytes share a single RMI address. It does not occupy
consecutive addresses, and the register structure that follows it
is located at the next RMI address (presence_address + 1), not
(presence_address + presence_size).
Revert the incorrect address calculation introduced in commit
a98518e724.
Reported-by: "Barry K. Nathan" <barryn@pobox.com>
Tested-by: "Barry K. Nathan" <barryn@pobox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The current list initialisation depends on the well hidden two zeros in
the PCI_VDEVICE macro. Instead use a named initialisation that is more
robust and easier to understand.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Correct a function name and function parameter name to avoid
kernel-doc warnings:
Warning: include/linux/ntb.h:575 expecting prototype for
ntb_default_port_count(). Prototype was for ntb_default_peer_port_count()
instead
Warning: include/linux/ntb.h:590 function parameter 'pidx' not
described in 'ntb_default_peer_port_number'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown
path ends up calling pci_iounmap() on the same iomem with some offset,
which is unnecessary and triggers a kernel warning like the following:
Trying to vunmap() nonexistent vm area (0000000069a5ffe8)
WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937
[...]
Call trace:
vunmap+0x58/0x68 (P)
iounmap+0x34/0x48
pci_iounmap+0x2c/0x40
ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf]
pci_device_remove+0x48/0xf8
device_remove+0x50/0x88
device_release_driver_internal+0x1c8/0x228
driver_detach+0x50/0xb0
bus_remove_driver+0x74/0x100
driver_unregister+0x34/0x68
pci_unregister_driver+0x34/0xa0
ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf]
[...]
Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.
Cc: stable@vger.kernel.org
Fixes: e75d5ae8ab ("NTB: epf: Allow more flexibility in the memory BAR map method")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
amd_ntb_link_disable() prints "Enabling Link" which is misleading.
Update the message to reflect that the link is being disabled.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Pull drm fixes from Dave Airlie:
"These are just the fixes from our fixes branch, all pretty small and
scattered.
sysfb:
- drm/sysfb truncation and alignment fixes
edid:
- fix edid OOB read in tile parsing
- increase displayid topology id to correct size
nouveau:
- fix error handling paths in nouveau
amdxdna:
- get_bo_info fix
ivpu:
- fix leak when error handling in ivpu"
* tag 'drm-fixes-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel:
drm/sysfb: Avoid truncating maximum stride
drm/sysfb: Return errno code from drm_sysfb_get_visible_size()
drm/sysfb: Avoid possible truncation with calculating visible size
drm/sysfb: Do not page-align visible size of the framebuffer
drm/edid: fix OOB read in drm_parse_tiled_block()
drm/nouveau: fix reversed error cleanup order in ucopy functions
drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit()
accel/amdxdna: Use caller client for debug BO sync
drm/displayid: fix Tiled Display Topology ID size
accel/ivpu: fix HWS command queue leak on registration failure
Pull drm merge window fixes from Dave Airlie:
"This is the merge window fixes from our next tree, i915/xe and amdgpu
make up all of it.
I've got a separate fixes pull from our fixes branch arriving after
this.
i915:
- Fix corrupted display output on GLK, #16209
- Add missing Spectre mitigation for parallel submit IOCTL
- MTL+ fix for DP resume
- clear CRTC blobs after dropping refs
- fix sharpness filter on DP MST
xe:
- Set TTM beneficial order to 9 in Xe
- Several error path cleanups
- Fix TDR for unstarted jobs on kernel queues
- Several TLB invalidation fixes related to suspending LR queues
- Some small RAS fixes
- Multi-queue suspend fix for LR queues
- Revert inclusion of NVL_S firmware
amdgpu:
- devcoredump fixes
- SMU15 fix
- Various irq put/get imbalance cleanup fixes
- 8K panel fix
- DCN3.5 fix
- lockdep fix
- Cleaner shader sysfs IB overflow fix
- Async flip fixes
- GET_MAPPING_INFO fix
- CP_GFX_SHADOW fix
- Ctx pstate handling fix
- GTT bo move handling fixes
- Old UVD BO placement fixes
- GC9 mode2 reset fix
- IH6.1 version fix
- Soft IH ring fix
amdkfd:
- Fix doorbell/mmio double unpin on free
- CRIU fixes
- SMI event fixes
- Sysfs teardown fix
- Various boundary checking fixes
- Various error checking fixes
- SVM fix"
* tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel: (52 commits)
drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable
drm/i915/gem: Add missing nospec on parallel submit slot
drm/amdgpu: Use system unbound workqueue for soft IH ring
amdgpu/ih6.1: Fix minor version
drm/amdkfd: Use exclusive bounds for SVM split alignment checks
drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2
drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2)
drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older
drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT
drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions
drm/amdgpu: Fix context pstate override handling
drm/amdkfd: Use memdup_array_user to copy data from/to user space at kfd ioctls
drm/amdkfd: check find_first_zero_bit before __set_bit on kfd->doorbell_bitmap
drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl
drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
drm/amdgpu: convert amdgpu_vm_lock_by_pasid() to drm_exec
drm/amdgpu: Don't use UTS_RELEASE directly
drm/amdkfd: Fix NULL deref during sysfs teardown
drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1
drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO
...
Pull ceph updates from Ilya Dryomov:
"This adds support for manual client session reset in CephFS, allowing
operators to get out of tricky livelock situations involving caps and
file locks without evicting the problematic client instance on the MDS
side or rebooting the client node both of which can be disruptive"
* tag 'ceph-for-7.2-rc1' of https://github.com/ceph/ceph-client:
ceph: add manual reset debugfs control and tracepoints
ceph: add client reset state machine and session teardown
ceph: add diagnostic timeout loop to wait_caps_flush()
ceph: harden send_mds_reconnect and handle active-MDS peer reset
ceph: use proper endian conversion for flock_len in reconnect
ceph: convert inode flags to named bit positions and atomic bitops
rbd: switch to dynamic root device
Pull thermal control fixes from Rafael Wysocki:
"These fix a failure path in an Intel thermal driver and prevent
thermal testing module code from being executed after it has been
freed:
- Fix dangling resources on thermal_throttle_online() failure in the
Intel thermal_throttle driver (Ricardo Neri)
- Eliminate a possibility of running thermal testing module code
after that module has been removed (Rafael Wysocki)"
* tag 'thermal-7.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: testing: zone: Flush work items during cleanup
thermal: intel: Fix dangling resources on thermal_throttle_online() failure
Pull power management fixes from Rafael Wysocki:
"These fix the schedutil cpufreq governor and drop a bogus warning
from the cpuidle core:
- Remove a misguided warning along with an inaccurate comment
next to it from the cpuidle core (Rafael Wysocki)
- Clear need_freq_update as appropriate in the .adjust_perf()
path of the schedutil cpufreq governor to avoid calling
cpufreq_driver_adjust_perf() unnecessarily on every scheduler
utilization update (Zhongqiu Han)"
* tag 'pm-7.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpuidle: Allow exit latency to exceed target residency
cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf() path
Pull ACPI support fixes and cleanups from Rafael Wysocki:
"These fix assorted issues and do cleanups in the ACPI support code,
which includes a fix for tools build breakage related to strncpy()
removal:
- Unbreak ACPICA tools builds after switching over to using
strscpy_pad() that is kernel-specific (Rafael Wysocki)
- Fix module parameter file paths in comments in the ACPI code
managing the general sysfs attributes (Zenghui Yu)
- Update kerneldoc comments in the ACPI resource management code to
follow the common style (Andy Shevchenko)
- Fix inverted interface check in ipmi_bmc_gone() that may cause ACPI
IPMI interfaces to be mishandled (Xu Rao)
- Add __cpuidle annotation to idle state management functions related
to ACPI _LPI to avoid trace-induced RCU warnings (Li RongQing)"
* tag 'acpi-7.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: processor_idle: Mark LPI enter functions as __cpuidle
ACPICA: Unbreak tools build after switching over to strscpy_pad()
ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()
ACPI: resource: Amend kernel-doc style
ACPI: sysfs: Fix path of module parameters in comments
