summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31ALSA: 6fire: Use auto-cleanup for firmware loadingTakashi Iwai1-20/+4
Clean up the code for managing the firmware loading in the 6fire driver with __free(firmware) and __free(kfree), so that the loaded firmware and the name string are cleaned up automatically. Only the code refactoring, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260729083735.120219-2-tiwai@suse.de
2026-07-31stop_machine: Make stop_one_cpu_nowait() return voidYury Norov2-18/+15
No caller checks the return value from stop_one_cpu_nowait(). All callers require the callback to run and arrange for the target CPU's stopper to remain enabled while queuing the work. In particular, commit f0498d2a54e7 ("sched: Fix stop_one_cpu_nowait() vs hotplug") added preemption protection to the scheduler callers so that queuing must succeed once the target CPU has been observed online. Therefore, a failure is an unrecoverable violation rather than a condition individual callers can recover from. Diagnose it with WARN_ON_ONCE() in stop_one_cpu_nowait(). A check in the common helper covers current and future callers consistently, while individual checks would duplicate the same non-recoverable handling at every call site. Make the function return void because there is no longer a meaningful result for callers to consume. On UP, warn if the supplied CPU is not the current CPU because the work cannot be scheduled in that case. Signed-off-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Link: https://patch.msgid.link/20260729022355.325058-1-ynorov@nvidia.com
2026-07-31Merge patch series "iomap: convert to in-iter iomap_next() model"Christian Brauner25-289/+426
Joanne Koong <joannelkoong@gmail.com> says: iomap: convert to in-iter iomap_next() model This series implements a suggestion by Christoph for finishing the conversion of iomap to an iterator model. This revives Matthew's previous RFC [1], which had the same intention. Every iomap operation currently drives its iteration through a struct iomap_ops, which contains two callbacks, ->iomap_begin() and ->iomap_end(). iomap_iter() only ever sees these as pointers, so every step of every iteration is an indirect call, including on the hottest paths. This series replaces the begin/end pair with a single ->iomap_next() callback that finishes the previous mapping (if any) and produces the next one. Collapsing to one callback lets a performance-critical caller inline its iteration loop and pass its ->iomap_next() function as a compile-time constant, where the compiler can devirtualize the callback into a direct and inlineable call rather than an indirect one. It also allows future callers more flexibility in expressing custom logic in the IO path for driving the iteration forward. This series has no functional changes intended. The patches are broken down as follows: 1) Patch 1: Brian's fix for folio batch release on iomap callback failures. The bug was reported by Sashiko and is an unlikely/second order error scenario [2] that doesn't need backporting to stable. 2) Patch 2: refactors existing iomap_iter() logic into an iomap_iter_next() function. Sets up DEFINE_IOMAP_ITER_NEXT/DEFINE_IOMAP_ITER_NEXT_END macro. 3) Patch 3 and 4: Christoph's patches for decoupling simple direct i/o reads from iomap_dio_rw and improvement for using GFP_NOWAIT for non-blocking iocbs [3] 4) Patch 5: Adds ->iomap_next() callback as an iomap op 5) Patches 6 to 19: converts each filesystem to ->iomap_next() model [1] https://lore.kernel.org/linux-fsdevel/20200728173216.7184-1-willy@infradead.org/T/#u [2] https://lore.kernel.org/linux-fsdevel/amjztG-DisHYbV9W@bfoster/ [3] https://lore.kernel.org/linux-fsdevel/20260723050201.3381045-1-hch@lst.de/ * patches from https://patch.msgid.link/20260729192737.3190206-1-joannelkoong@gmail.com: exfat: convert iomap ops to ->iomap_next() fuse: convert iomap ops to ->iomap_next() hpfs: convert iomap ops to ->iomap_next() gfs2: convert iomap ops to ->iomap_next() f2fs: convert iomap ops to ->iomap_next() block: convert iomap ops to ->iomap_next() ext2: convert iomap ops to ->iomap_next() zonefs: convert iomap ops to ->iomap_next() erofs: convert iomap ops to ->iomap_next() ext4: convert iomap ops to ->iomap_next() ntfs: convert iomap ops to ->iomap_next() ntfs3: convert iomap ops to ->iomap_next() btrfs: convert iomap ops to ->iomap_next() xfs: convert iomap ops to ->iomap_next() iomap: add ->iomap_next() iomap: use GFP_NOWAIT when application for iomap_dio_simple allocations iomap: decouple simple direct I/O reads from iomap_dio_rw iomap: split iomap_iter() logic into iomap_iter_next() iomap: release the folio batch on iomap callback failures Link: https://patch.msgid.link/20260729192737.3190206-1-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31exfat: convert iomap ops to ->iomap_next()Joanne Koong1-3/+7
Convert exfat iomap_ops to the new ->iomap_next() callback. Each callback is generated with the DEFINE_IOMAP_ITER_NEXT() and 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-20-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31fuse: convert iomap ops to ->iomap_next()Joanne Koong3-5/+8
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>
2026-07-31hpfs: convert iomap ops to ->iomap_next()Joanne Koong1-1/+3
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>
2026-07-31gfs2: convert iomap ops to ->iomap_next()Joanne Koong1-2/+4
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>
2026-07-31f2fs: convert iomap ops to ->iomap_next()Joanne Koong1-1/+3
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>
2026-07-31block: convert iomap ops to ->iomap_next()Joanne Koong1-1/+3
Convert block 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. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Link: https://patch.msgid.link/20260729192737.3190206-15-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31ext2: convert iomap ops to ->iomap_next()Joanne Koong1-2/+4
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>
2026-07-31zonefs: convert iomap ops to ->iomap_next()Joanne Koong1-2/+7
Convert zonefs iomap_ops to the new ->iomap_next() callback. Each 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. Acked-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Link: https://patch.msgid.link/20260729192737.3190206-13-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31erofs: convert iomap ops to ->iomap_next()Joanne Koong2-3/+8
Convert erofs iomap_ops to the new ->iomap_next() callback. Each callback is generated with the DEFINE_IOMAP_ITER_NEXT() and 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: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Link: https://patch.msgid.link/20260729192737.3190206-12-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31ext4: convert iomap ops to ->iomap_next()Joanne Koong2-3/+9
Convert ext4 iomap_ops to the new ->iomap_next() callback. Each 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. Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Baokun Li <libaokun@linux.alibaba.com> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Link: https://patch.msgid.link/20260729192737.3190206-11-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31ntfs: convert iomap ops to ->iomap_next()Joanne Koong1-10/+22
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>
2026-07-31ntfs3: convert iomap ops to ->iomap_next()Joanne Koong1-2/+4
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>
2026-07-31btrfs: convert iomap ops to ->iomap_next()Joanne Koong1-2/+4
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>
2026-07-31xfs: convert iomap ops to ->iomap_next()Joanne Koong2-12/+31
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>
2026-07-31iomap: add ->iomap_next()Joanne Koong2-2/+15
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>
2026-07-31iomap: use GFP_NOWAIT when application for iomap_dio_simple allocationsChristoph Hellwig1-1/+6
For non-blocking iocbs we should avoid blocking allocation where possible, so switch to a GFP_NOWAIT allocation here. 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-5-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31iomap: decouple simple direct I/O reads from iomap_dio_rwChristoph Hellwig8-167/+136
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>
2026-07-31iomap: split iomap_iter() logic into iomap_iter_next()Joanne Koong2-73/+145
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>
2026-07-31iomap: release the folio batch on iomap callback failuresBrian Foster1-4/+14
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: 395ed1ef0012 ("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>
2026-07-31Merge patch series "iomap/fuse: add helper to keep uptodate bitmap in sync"Christian Brauner4-19/+12
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>
2026-07-31fuse: use iomap helper to mark folio uptodateJoanne Koong2-2/+4
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>
2026-07-31iomap: add helper to mark folio uptodateJoanne Koong2-0/+7
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>
2026-07-31fuse: don't clear folio uptodate on writethrough errorsJoanne Koong1-17/+1
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>
2026-07-31Merge patch series "iomap: add simple dio path for small direct I/O"Christian Brauner1-7/+286
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>
2026-07-31iomap: add simple dio path for small direct I/OFengnan Chang1-0/+274
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>
2026-07-31iomap: pass error code to should_report_dio_fserror directlyFengnan Chang1-3/+3
Change should_report_dio_fserror() to take an error code instead of the full struct iomap_dio, decoupling it for reuse by the upcoming simple direct I/O path. No functional change. Signed-off-by: Fengnan Chang <changfengnan@bytedance.com> Link: https://patch.msgid.link/20260701033253.46420-3-changfengnan@bytedance.com Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31iomap: Remove FGP_NOFS from iomap_get_folio()Matthew Wilcox (Oracle)1-1/+1
FGP_NOFS is legacy; filesystems should be using memalloc_nofs_save/restore instead. We have it here in iomap because it was buried in grab_cache_page_write_begin() and we didn't want to change this behaviour as part of the folio transition. I have tested this with XFS and see no issues. Other filesystems (cc'd) may need to make adjustments. Please test with lockdep enabled. Cc: Darrick J. Wong <djwong@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: Sungjong Seo <sj1557.seo@samsung.com> Cc: Yuezhang Mo <yuezhang.mo@sony.com> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Andreas Gruenbacher <agruenba@redhat.com> Cc: Hyunchul Lee <hyc.lee@gmail.com> Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Cc: Carlos Maiolino <cem@kernel.org> Cc: Damien Le Moal <dlemoal@kernel.org> Cc: Naohiro Aota <naohiro.aota@wdc.com> Cc: Johannes Thumshirn <jth@kernel.org> Cc: linux-xfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-block@vger.kernel.org Cc: fuse-devel@lists.linux.dev Cc: gfs2@lists.linux.dev Cc: ntfs3@lists.linux.dev Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260624174228.2015893-1-willy@infradead.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31iomap: factor out iomap_dio_alignment helperFengnan Chang1-4/+9
Extract the alignment computation from iomap_dio_bio_iter() into a standalone helper so the upcoming simple direct I/O path can reuse it without requiring a struct iomap_dio. No functional change. Signed-off-by: Fengnan Chang <changfengnan@bytedance.com> Link: https://patch.msgid.link/20260701033253.46420-2-changfengnan@bytedance.com Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31iomap: add a separate bio_set for iomap_split_ioendChristoph Hellwig1-2/+19
iomap_split_ioend can split bios that already come from iomap_ioend_bioset and thus deadlock when the bioset is exhausted. Add a separate bio_set to avoid this deadlock. Christian Brauner <brauner@kernel.org> says: Mark iomap_ioend_split_bioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot. Fixes: 5fcbd555d483 ("iomap: split bios to zone append limits in the submission handlers") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260629125229.3400726-1-hch@lst.de Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31perf/x86/intel/pt: Drop kernel-doc for deleted struct membersRandy Dunlap1-2/+0
@lost and @topa_index are no longer part of struct pt_buffer so delete their comment lines. Warning: ../arch/x86/events/intel/pt.h:86 Excess struct member 'lost' description in 'pt_buffer' Warning: ../arch/x86/events/intel/pt.h:86 Excess struct member 'topa_index' description in 'pt_buffer' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/20260730233429.285788-2-rdunlap@infradead.org
2026-07-31x86/intel/quark: Clean up function kernel-docRandy Dunlap1-6/+1
Add a short description for imr_self_test() and drop the comments for the non-existent imr_self_test_exit() to avoid kernel-doc warnings: Warning: arch/x86/platform/intel-quark/imr_selftest.c:52 missing initial short description on line: * imr_self_test Warning: ../arch/x86/platform/intel-quark/imr_selftest.c:128 function parameter 'imr_self_test_init' not described in 'device_initcall' Warning: ../arch/x86/platform/intel-quark/imr_selftest.c:128 expecting prototype for imr_self_test_exit(). Prototype was for device_initcall() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260730233429.285788-6-rdunlap@infradead.org
2026-07-31x86/speculation: Drop Excess function parameter descriptionsRandy Dunlap1-2/+0
These function parameters don't exist so drop them to avoid kernel-doc warnings: Warning: ../arch/x86/include/asm/spec-ctrl.h:28 Excess function parameter 'guest_spec_ctrl' description in 'x86_spec_ctrl_set_guest' Warning: ../arch/x86/include/asm/spec-ctrl.h:42 Excess function parameter 'guest_spec_ctrl' description in 'x86_spec_ctrl_restore_host' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260730233429.285788-5-rdunlap@infradead.org
2026-07-31x86/lib: checksum_64.h: Eliminate all kernel-doc warningsRandy Dunlap1-12/+17
- correct missing function parameter names - add missing function return value sections - use the correct function name in comments to avoid these warnings (samples): Warning: arch/x86/include/asm/checksum_64.h:23 No description found for return value of 'csum_fold' Warning: arch/x86/include/asm/checksum_64.h:46 function parameter 'iph' not described in 'ip_fast_csum' Warning: arch/x86/include/asm/checksum_64.h:46 function parameter 'ihl' not described in 'ip_fast_csum' Warning: arch/x86/include/asm/checksum_64.h:46 No description found for return value of 'ip_fast_csum' Warning: arch/x86/include/asm/checksum_64.h:89 expecting prototype for csum_tcpup_nofold(). Prototype was for csum_tcpudp_nofold() instead Warning: arch/x86/include/asm/checksum_64.h:115 expecting prototype for csum_tcpup_magic(). Prototype was for csum_tcpudp_magic() instead Warning: arch/x86/include/asm/checksum_64.h:119 No description found for return value of 'csum_tcpudp_magic' Warning: arch/x86/include/asm/checksum_64.h:129 No description found for return value of 'csum_partial' Warning: ./arch/x86/include/asm/checksum_64.h:175 function parameter '_saddr' not described in 'csum_ipv6_magic' Warning: ./arch/x86/include/asm/checksum_64.h:175 function parameter '_daddr' not described in 'csum_ipv6_magic' Warning: ./arch/x86/include/asm/checksum_64.h:175 Excess function parameter 'saddr' description in 'csum_ipv6_magic' Warning: ./arch/x86/include/asm/checksum_64.h:175 Excess function parameter 'daddr' description in 'csum_ipv6_magic' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260730233429.285788-4-rdunlap@infradead.org
2026-07-31x86/barrier: Use correct parameter names in kernel-docRandy Dunlap1-3/+3
Use the correct macro parameter names in the kernel-doc comments to avoid kernel-doc warnings: Warning: arch/x86/include/asm/barrier.h:35 function parameter 'idx' not described in 'array_index_mask_nospec' Warning: arch/x86/include/asm/barrier.h:35 function parameter 'sz' not described in 'array_index_mask_nospec' Warning: arch/x86/include/asm/barrier.h:35 Excess function parameter 'index' description in 'array_index_mask_nospec' Warning: arch/x86/include/asm/barrier.h:35 Excess function parameter 'size' description in 'array_index_mask_nospec' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260730233429.285788-3-rdunlap@infradead.org
2026-07-31Merge branch 'perf/urgent' into perf/core, to pick up fixesIngo Molnar3347-11517/+24451
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2026-07-31MAINTAINERS: add sys_soc.h to DRIVER COREDanilo Krummrich1-0/+1
The sys_soc.h header was never added to the DRIVER CORE MAINTAINERS entry when the SoC bus was introduced. Add it now. Fixes: 74d1d82cdaae ("drivers/base: add bus for System-on-Chip devices") Signed-off-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260727204543.2286472-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31rust: debugfs: remove unsafe blocks from traits impl for VecJosef Ippisch1-19/+2
The previous implementation used an `unsafe` block to manually cast Vec's slice to a &[u8] using `core::slice::from_raw_parts`. Instead, the implementation can be implemented in safe rust using zerocopy's trait functions `as_bytes()` and `as_mut_bytes()`, respectively, and making use of deref coercion to implicitly cast Vec to &[T] as `FromBytes` and `IntoBytes` automatically are implemented on [T] when they are implemented on T. Signed-off-by: Josef Ippisch <josef.ippisch.dev@mailbox.org> Link: https://patch.msgid.link/20260728-migrate-binarywriter-to-zerocopy-intobytes-v2-2-0a4ec1d3ead4@mailbox.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31rust: debugfs: migrate debugfs traits requirements to zerocopyJosef Ippisch1-13/+11
Migrate `BinaryWriter` and `BinaryReaderMut`'s default implementation's requirements on T from `kernel::transmute` traits to `zerocopy` traits. The additional `zerocopy::Immutable` requirement on `BinaryWriter` does not further restrict the types in practice but is rather a more explicit requirement (that the type does not have interior mutability) and is required by zerocopy for the `as_bytes()` function. Suggested-by: Joshua Liebow-Feeser <joshlf@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/975 Link: https://github.com/Rust-for-Linux/linux/issues/1241 Signed-off-by: Josef Ippisch <josef.ippisch.dev@mailbox.org> Link: https://patch.msgid.link/20260728-migrate-binarywriter-to-zerocopy-intobytes-v2-1-0a4ec1d3ead4@mailbox.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31rust_binder: do not query current thread for all ioctlsAlice Ryhl1-4/+8
The get_current_thread() method is currently called for every ioctl to ensure that a Thread struct exists for the thread calling into the driver. However, not all ioctls require a Thread object, so this means we are unnecessarily creating these objects in cases where we don't need to. If said thread does not invoke BINDER_THREAD_EXIT on exit, Binder's Thread struct stays around until the fd is closed. For long-lived processes the Thread object is effectively leaked. Furthermore, when the BINDER_GET_NODE_DEBUG_INFO ioctl is invoked by libmemunreachable to ensure that objects reachable only through the Binder driver are not considered leaked, this is done from a fork of the process owning the fd, which means that it fails the group_leader check inside get_current_thread(). This results in EINVAL errors for this ioctl, causing libmemunreachable to report a false positive memory leak. Thus, do not invoke get_current_thread() for ioctls that do not require it. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Cc: stable <stable@kernel.org> Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Acked-by: Carlos Llamas <cmllamas@google.com> Link: https://patch.msgid.link/20260727-binder-cur-thread-v1-1-8edf2b64e235@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31nvmem: layouts: Add fixed-layout driverMathieu Dubois-Briand7-33/+74
Current implementation isn't working well when device tree nodes have a phandle on a fixed-layout nvmem node. As the fixed layout is handled in nvmem core, no driver is ever associated with the layout, and the device consumer driver probe is deferred indefinitely. Remove the specific handling of fixed-layout and add a layout driver. This makes the fixed-layout similar to all other layouts, fixing the whole issue. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: stable@vger.kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223404.629248-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFIAelin Reidel1-2/+18
The Apple SPMI NVMEM driver previously cast regmap_bulk_read/write to void * when assigning them to nvmem_config's reg_read/reg_write function pointers. This cast breaks the expected function signature of nvmem_reg_read_t and nvmem_reg_write_t. With CFI enabled, indirect calls through these pointers fail: CFI failure at nvmem_reg_write+0x194/0x1e4 (target: regmap_bulk_write+0x0/0x2c8; expected type: 0x83a189c3) ... Call trace: nvmem_reg_write+0x194/0x1e4 (P) __nvmem_cell_entry_write+0x298/0x2e8 nvmem_cell_write+0x24/0x34 macsmc_reboot_probe+0x1dc/0x454 [macsmc_reboot] ... Introduce thin wrapper functions with the correct nvmem function pointer types to satisfy the CFI checks. Fixes: fe91c24a551c ("nvmem: Add apple-spmi-nvmem driver") Signed-off-by: Aelin Reidel <aelin@mainlining.org> Reported-by: Clayton Craft <craftyguy@postmarketos.org> Tested-by: Clayton Craft <craftyguy@postmarketos.org> Reviewed-by: Sven Peter <sven@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223404.629248-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: fix memory leak in fastrpc_channel_ctx_freeEddie Lin1-0/+1
The 'ctx_idr' is initialized but never destroyed when the channel context is freed, leading to a memory leak. Add idr_destroy() to properly clean up the IDR resources. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Eddie Lin <eddie.lin@oss.qualcomm.com> Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: fix channel ctx ref leak when session alloc failsAnandu Krishnan E1-1/+1
fastrpc_channel_ctx_get() is called in fastrpc_device_open() before fastrpc_session_alloc(). If session alloc fails, the error path returns -EBUSY without calling fastrpc_channel_ctx_put(), leaking the reference. Fix by adding the missing put. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: take fl->lock when moving mmaps on interrupted invokeJunrui Luo1-0/+2
When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor. Fixes: 76e8e4ace1ed ("misc: fastrpc: Safekeep mmaps on interrupted invoke") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: Remove buffer from list prior to unmap operationEkansh Gupta1-4/+10
fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31misc: fastrpc: Fix initial memory allocation for Audio PD memory poolEkansh Gupta1-4/+4
The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260724223342.629168-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-31dcache: keep shrink_dcache_for_umount() making progress on busy rootsKarl Mehltretter1-1/+6
Commit e9895609cb7f ("wind ->s_roots via ->d_sib instead of ->d_hash") moved secondary roots from ->d_hash to ->d_sib. Secondary roots are now d_unhashed(), so __d_drop() returns without removing them from ->s_roots. Consequently, d_drop() in do_one_tree() no longer guarantees progress through the list. If a secondary root is still busy once do_one_tree() is done with it, its final dput() cannot evict it. The root remains ->s_roots.first and the loop selects it forever, holding ->s_umount for write and repeatedly reporting the same dentry. The root does not need a leaked reference of its own for that. Every child pins its parent (d_alloc() takes a reference on it) and umount_check() deliberately reports a busy descendant instead of complaining about its ancestors, so a single leaked dentry reference anywhere below a secondary root is enough. For filesystems that build ->s_root with d_obtain_root() - nfs, ceph, nilfs2 snapshot mounts - that is the entire tree. Before e9895609cb7f, ___d_drop() special-cased IS_ROOT dentries and removed them from ->s_roots regardless of their refcount, so the d_drop() in do_one_tree() detached the root from the superblock no matter what. Commit 9c8c10e262e0 ("more graceful recovery in umount_collect()") deliberately made busy dentries nonfatal: report them and finish the unmount rather than BUG() while holding ->s_umount. Restore that by detaching the root in do_one_tree() itself, next to the d_drop() that used to do it. That covers both callers - the ->s_roots loop and ->s_root, which for the filesystems above is a secondary root as well. In the normal case dentry_unlist() finds ->d_sib already unhashed when eviction occurs. A permanently leaked reference remains leaked after unmount, as it did before e9895609cb7f; if the extra reference is merely delayed, its final dput() may run after teardown has advanced. Leaving the root on ->s_roots is not an alternative: the superblock would then be freed with a live dentry still linked into it, and that dentry's dentry_unlist() would take ->s_roots_lock on freed memory. Christian Brauner <brauner@kernel.org> says: Moved the ->s_roots removal from the shrink_dcache_for_umount() loop into do_one_tree(), so a busy ->s_root obtained from d_obtain_root() is detached on the first pass instead of being reported a second time when the loop picks it off ->s_roots. Extended the commit message with the pinned-ancestor case. Fixes: e9895609cb7f ("wind ->s_roots via ->d_sib instead of ->d_hash") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260729005933.15858-1-kmehltretter@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 05:13:54 +0000