kernel/linux.git/fs/iomap, branch v6.6.131

iomap: allocate s_dio_done_wq for async reads as well

2026-03-25T10:05:59+00:00

commit 7fd8720dff2d9c70cf5a1a13b7513af01952ec02 upstream. Since commit 222f2c7c6d14 ("iomap: always run error completions in user context"), read error completions are deferred to s_dio_done_wq. This means the workqueue also needs to be allocated for async reads. Fixes: 222f2c7c6d14 ("iomap: always run error completions in user context") Reported-by: syzbot+a2b9a4ed0d61b1efb3f5@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251124140013.902853-1-hch@lst.de Tested-by: syzbot+a2b9a4ed0d61b1efb3f5@syzkaller.appspotmail.com Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Christian Brauner Signed-off-by: Chen Yu Signed-off-by: Greg Kroah-Hartman

iomap: reject delalloc mappings during writeback

2026-03-25T10:05:57+00:00

[ Upstream commit d320f160aa5ff36cdf83c645cca52b615e866e32 ] Filesystems should never provide a delayed allocation mapping to writeback; they're supposed to allocate the space before replying. This can lead to weird IO errors and crashes in the block layer if the filesystem is being malicious, or if it hadn't set iomap->dev because it's a delalloc mapping. Fix this by failing writeback on delalloc mappings. Currently no filesystems actually misbehave in this manner, but we ought to be stricter about things like that. Cc: stable@vger.kernel.org # v5.5 Fixes: 598ecfbaa742ac ("iomap: lift the xfs writeback code to iomap") Signed-off-by: Darrick J. Wong Link: https://patch.msgid.link/20260302173002.GL13829@frogsfrogsfrogs Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Christian Brauner [ no ioend.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

iomap: fix submission side handling of completion side errors

2026-03-04T12:19:28+00:00

[ Upstream commit 4ad357e39b2ecd5da7bcc7e840ee24d179593cd5 ] The "if (dio->error)" in iomap_dio_bio_iter exists to stop submitting more bios when a completion already return an error. Commit cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") made it revert the iov by "copied", which is very wrong given that we've already consumed that range and submitted a bio for it. Fixes: cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Darrick J. Wong Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

iomap: account for unaligned end offsets when truncating read range

2026-01-11T14:21:41+00:00

[ Upstream commit 9d875e0eef8ec15b6b1da0cb9a0f8ed13efee89e ] The end position to start truncating from may be at an offset into a block, which under the current logic would result in overtruncation. Adjust the calculation to account for unaligned end offsets. Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20251111193658.3495942-3-joannelkoong@gmail.com Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

iomap: adjust read range correctly for non-block-aligned positions

2026-01-11T14:21:41+00:00

[ Upstream commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e ] iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks. Signed-off-by: Joanne Koong Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

iomap: always run error completions in user context

2026-01-11T14:21:30+00:00

[ Upstream commit ddb4873286e03e193c5a3bebb5fc6fa820e9ee3a ] At least zonefs expects error completions to be able to sleep. Because error completions aren't performance critical, just defer them to workqueue context unconditionally. Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20251113170633.1453259-3-hch@lst.de Reviewed-by: Jan Kara Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

iomap: factor out a iomap_dio_done helper

2026-01-11T14:21:30+00:00

[ Upstream commit ae2f33a519af3730cacd1c787ebe1f7475df5ba8 ] Split out the struct iomap-dio level final completion from iomap_dio_bio_end_io into a helper to clean up the code and make it reusable. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250206064035.2323428-7-hch@lst.de Reviewed-by: "Darrick J. Wong" Signed-off-by: Christian Brauner Stable-dep-of: ddb4873286e0 ("iomap: always run error completions in user context") Signed-off-by: Sasha Levin

iomap: skip unnecessary ifs_block_is_uptodate check

2025-05-02T05:51:01+00:00

[ Upstream commit 8e3c15ee0d292c413c66fe10201d1b035a0bea72 ] In iomap_adjust_read_range, i is either the first !uptodate block, or it is past last for the second loop looking for trailing uptodate blocks. Assuming there's no overflow (there's no combination of huge folios and tiny blksize) then yeah, there is no point in retesting that the same block pointed to by i is uptodate since we hold the folio lock so nobody else could have set it uptodate. Signed-off-by: Gou Hao Link: https://lore.kernel.org/20250410071236.16017-1-gouhao@uniontech.com Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Suggested-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

iomap: avoid avoid truncating 64-bit offset to 32 bits

2025-01-23T16:21:14+00:00

[ Upstream commit c13094b894de289514d84b8db56d1f2931a0bade ] on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem. Signed-off-by: Marco Nelissen Link: https://lore.kernel.org/r/20250109041253.2494374-1-marco.nelissen@gmail.com Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

iomap: turn iomap_want_unshare_iter into an inline function

2024-11-08T15:28:19+00:00

[ Upstream commit 6db388585e486c0261aeef55f8bc63a9b45756c0 ] iomap_want_unshare_iter currently sits in fs/iomap/buffered-io.c, which depends on CONFIG_BLOCK. It is also in used in fs/dax.c whіch has no such dependency. Given that it is a trivial check turn it into an inline in include/linux/iomap.h to fix the DAX && !BLOCK build. Fixes: 6ef6a0e821d3 ("iomap: share iomap_unshare_iter predicate code with fsdax") Reported-by: kernel test robot Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20241015041350.118403-1-hch@lst.de Reviewed-by: Brian Foster Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin