[PATCH 0/2] block device write path fixes

[PATCH 0/2] block device write path fixes

[Tal Zussman]

Two independent fixes for the block device write path. Both issues were
found by Sashiko during review of the "block: enable RWF_DONTCACHE for
block devices" series [1] and are independent of it.

Patch 1 fixes silently lost mmap writes with CONFIG_BUFFER_HEAD=n:
def_blk_aops uses filemap_dirty_folio, which does not set the
per-block dirty bits in the folio's iomap_folio_state, so writeback
finds no dirty blocks and submits no I/O.

Patch 2 makes blkdev_write_iter() take i_rwsem shared around the
buffered-write fallback for a partial direct I/O write. The fallback
currently runs with no lock held and races set_blocksize() changing
i_blkbits and the mapping's minimum folio order, which can trip
VM_BUG_ON_FOLIO in __filemap_add_folio() on kernels with block sizes
above PAGE_SIZE.

Both issues are currently unlikely to be hit in practice due to the
specific configurations required to trigger them.

[1] https://lore.kernel.org/all/20260730-blk-dontcache-v7-0-3e8e6850068d@columbia.edu/

Signed-off-by: Tal Zussman <tz2294@columbia.edu>
---
Tal Zussman (2):
      block: use iomap_dirty_folio for block devices
      block: take i_rwsem for the direct I/O write fallback

 block/fops.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)
---
base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff
change-id: 20260801-blkdev-fixes-771b1c314ebb

Best regards,
-- 
Tal Zussman <tz2294@columbia.edu>

[PATCH 1/2] block: use iomap_dirty_folio for block devices

[Tal Zussman]

With CONFIG_BUFFER_HEAD=n, block devices are written back through iomap,
but def_blk_aops uses filemap_dirty_folio, which only sets PG_dirty. It
does not set the per-block dirty bits in the folio's iomap_folio_state,
so iomap_writeback_folio() finds no dirty range, submits no I/O and
clears PG_dirty, resulting in data loss.

Other iomap users set .dirty_folio to iomap_dirty_folio, which marks the
folio's blocks dirty before calling filemap_dirty_folio().

This is only observable with block size < folio size. With a single
block there is no iomap_folio_state to get out of sync and
iomap_writeback_folio() marks the whole folio dirty itself. For a
page-aligned device, this may require using the BLKBSZSET ioctl to set
the block size, which requires CAP_SYS_ADMIN. A device whose size is not
page aligned already gets a sub-page block size from
set_init_blocksize(), so no ioctl and no privilege is needed.

To reproduce, on a device with a sub-page block size, write a known
pattern with O_DIRECT, mmap the same range, store to it, msync() and
fsync(), then read it back with O_DIRECT. A reproducer is available at
[1].

[1] https://gist.github.com/tzussman/18ab05cba4b3fdc79cce0a69d1fd05b4

Fixes: 925c86a19bac ("fs: add CONFIG_BUFFER_HEAD")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260730-blk-dontcache-v7-0-3e8e6850068d%40columbia.edu?part=5
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
---
 block/fops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/fops.c b/block/fops.c
index 15783a6180de..5b938f673d4f 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -558,7 +558,7 @@ static int blkdev_writepages(struct address_space *mapping,
 }
 
 const struct address_space_operations def_blk_aops = {
-	.dirty_folio	= filemap_dirty_folio,
+	.dirty_folio		= iomap_dirty_folio,
 	.release_folio		= iomap_release_folio,
 	.invalidate_folio	= iomap_invalidate_folio,
 	.read_folio		= blkdev_read_folio,

-- 
2.39.5

[PATCH 2/2] block: take i_rwsem for the direct I/O write fallback

[Tal Zussman]

Commit c0e473a0d226 ("block: fix race between set_blocksize and read
paths") closed a race between set_blocksize() and block device I/O: with
large sector size support, set_blocksize() can change i_blkbits and the
mapping's minimum folio order while a concurrent reader still holds a
folio of the old, smaller order, leading to crashes. In particular, it
made blkdev_write_iter() wrap buffered writes in inode_lock_shared().

However, the direct I/O fallback path was missed in that conversion.
blkdev_write_iter() passes blkdev_buffered_write() as an argument to
direct_write_fallback() with no lock held. A direct write that completes
only partially then finishes as a buffered write with no protection.

This can cause a BUG by racing partial direct writes against
ioctl(BLKBSZSET). Writer threads issue O_DIRECT pwritev() with a
two-segment iovec whose second segment is an unreadable PROT_NONE
mapping. The direct path then writes the first segment, fails to pin the
second, and returns short, entering the fallback. A second thread keeps
toggling the second segment's protection so that some fallbacks get past
fault_in_iov_iter_readable() and reach the page cache, a third thread
populates the page cache with folios of the current block size via
pread() and readahead(), and a fourth thread toggles the block size
between 512 bytes and 64K with BLKBSZSET. The minimum folio order only
moves with block sizes above PAGE_SIZE, i.e. with
CONFIG_TRANSPARENT_HUGEPAGE raising BLK_MAX_BLOCK_SIZE to 64K.

On a CONFIG_DEBUG_VM kernel this yields the following BUG:

  page dumped because: VM_BUG_ON_FOLIO(folio_order(folio) < mapping_min_folio_order(mapping))
  kernel BUG at mm/filemap.c:858!
  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
  RIP: 0010:__filemap_add_folio+0x860/0x8d0
  Call Trace:
   filemap_add_folio+0xc9/0x1f0
   __filemap_get_folio_mpol+0x240/0x660
   iomap_write_begin+0xa87/0xd70
   iomap_file_buffered_write+0x304/0x6a0
   blkdev_write_iter+0x255/0x510
   do_iter_readv_writev+0x23d/0x3c0
   vfs_writev+0x211/0x7d0
   do_pwritev+0x121/0x190
   do_syscall_64+0x121/0x630
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

The same workload also trips WARN_ON_ONCE(pos >= folio_pos(folio) +
fsize) in iomap_trim_folio_range().

Fix this by calling blkdev_buffered_write() in the fallback path under
inode_lock_shared(), matching the plain buffered-write branch. With the
fix the same workload runs clean.

The reproducer used was written by an LLM, and is available at [1].

[1] https://gist.github.com/tzussman/69d06bc57d42a42989eb038b1b5aeb74

Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260730-blk-dontcache-v7-0-3e8e6850068d%40columbia.edu?part=5
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
---
 block/fops.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/block/fops.c b/block/fops.c
index 5b938f673d4f..26711cc239d5 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -763,9 +763,14 @@ static ssize_t blkdev_write_iter(struct kiocb *iocb, struct iov_iter *from)
 
 	if (iocb->ki_flags & IOCB_DIRECT) {
 		ret = blkdev_direct_write(iocb, from);
-		if (ret >= 0 && iov_iter_count(from))
-			ret = direct_write_fallback(iocb, from, ret,
-					blkdev_buffered_write(iocb, from));
+		if (ret >= 0 && iov_iter_count(from)) {
+			ssize_t ret2;
+
+			inode_lock_shared(bd_inode);
+			ret2 = blkdev_buffered_write(iocb, from);
+			inode_unlock_shared(bd_inode);
+			ret = direct_write_fallback(iocb, from, ret, ret2);
+		}
 	} else {
 		/*
 		 * Take i_rwsem and invalidate_lock to avoid racing with

-- 
2.39.5

Re: [PATCH 2/2] block: take i_rwsem for the direct I/O write fallback

[Tal Zussman]

On 8/2/26 7:14 AM, Tal Zussman wrote:
> Commit c0e473a0d226 ("block: fix race between set_blocksize and read
> paths") closed a race between set_blocksize() and block device I/O: with
> large sector size support, set_blocksize() can change i_blkbits and the
> mapping's minimum folio order while a concurrent reader still holds a
> folio of the old, smaller order, leading to crashes. In particular, it
> made blkdev_write_iter() wrap buffered writes in inode_lock_shared().
> 
> However, the direct I/O fallback path was missed in that conversion.
> blkdev_write_iter() passes blkdev_buffered_write() as an argument to
> direct_write_fallback() with no lock held. A direct write that completes
> only partially then finishes as a buffered write with no protection.
> 
> This can cause a BUG by racing partial direct writes against
> ioctl(BLKBSZSET). Writer threads issue O_DIRECT pwritev() with a
> two-segment iovec whose second segment is an unreadable PROT_NONE
> mapping. The direct path then writes the first segment, fails to pin the
> second, and returns short, entering the fallback. A second thread keeps
> toggling the second segment's protection so that some fallbacks get past
> fault_in_iov_iter_readable() and reach the page cache, a third thread
> populates the page cache with folios of the current block size via
> pread() and readahead(), and a fourth thread toggles the block size
> between 512 bytes and 64K with BLKBSZSET. The minimum folio order only
> moves with block sizes above PAGE_SIZE, i.e. with
> CONFIG_TRANSPARENT_HUGEPAGE raising BLK_MAX_BLOCK_SIZE to 64K.
> 
> On a CONFIG_DEBUG_VM kernel this yields the following BUG:
> 
>   page dumped because: VM_BUG_ON_FOLIO(folio_order(folio) < mapping_min_folio_order(mapping))
>   kernel BUG at mm/filemap.c:858!
>   Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
>   RIP: 0010:__filemap_add_folio+0x860/0x8d0
>   Call Trace:
>    filemap_add_folio+0xc9/0x1f0
>    __filemap_get_folio_mpol+0x240/0x660
>    iomap_write_begin+0xa87/0xd70
>    iomap_file_buffered_write+0x304/0x6a0
>    blkdev_write_iter+0x255/0x510
>    do_iter_readv_writev+0x23d/0x3c0
>    vfs_writev+0x211/0x7d0
>    do_pwritev+0x121/0x190
>    do_syscall_64+0x121/0x630
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> The same workload also trips WARN_ON_ONCE(pos >= folio_pos(folio) +
> fsize) in iomap_trim_folio_range().
> 
> Fix this by calling blkdev_buffered_write() in the fallback path under
> inode_lock_shared(), matching the plain buffered-write branch. With the
> fix the same workload runs clean.
> 
> The reproducer used was written by an LLM, and is available at [1].
> 
> [1] https://gist.github.com/tzussman/69d06bc57d42a42989eb038b1b5aeb74
> 
> Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://sashiko.dev/#/patchset/20260730-blk-dontcache-v7-0-3e8e6850068d%40columbia.edu?part=5
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
> ---
>  block/fops.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/block/fops.c b/block/fops.c
> index 5b938f673d4f..26711cc239d5 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -763,9 +763,14 @@ static ssize_t blkdev_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  
>  	if (iocb->ki_flags & IOCB_DIRECT) {
>  		ret = blkdev_direct_write(iocb, from);
> -		if (ret >= 0 && iov_iter_count(from))
> -			ret = direct_write_fallback(iocb, from, ret,
> -					blkdev_buffered_write(iocb, from));
> +		if (ret >= 0 && iov_iter_count(from)) {
> +			ssize_t ret2;
> +
> +			inode_lock_shared(bd_inode);
> +			ret2 = blkdev_buffered_write(iocb, from);
> +			inode_unlock_shared(bd_inode);
> +			ret = direct_write_fallback(iocb, from, ret, ret2);
> +		}
>  	} else {
>  		/*
>  		 * Take i_rwsem and invalidate_lock to avoid racing with
> 

I seem to have stumbled into a Sashiko rabbit hole of issues with IOCB_NOWAIT
and IOCB_ATOMIC here... [1].
I'll wait a day or two and send an update along with some additional fixes
I've spotted.

[1] https://sashiko.dev/#/patchset/20260802-blkdev-fixes-v1-0-a82fc549fd74%40columbia.edu?part=2

Re: [PATCH 1/2] block: use iomap_dirty_folio for block devices

[Christoph Hellwig]

On Sun, Aug 02, 2026 at 07:14:26AM -0400, Tal Zussman wrote:
> To reproduce, on a device with a sub-page block size, write a known
> pattern with O_DIRECT, mmap the same range, store to it, msync() and
> fsync(), then read it back with O_DIRECT. A reproducer is available at

Heh, shared mmap writes to block devices..

> [1].
> 
> [1] https://gist.github.com/tzussman/18ab05cba4b3fdc79cce0a69d1fd05b4

Can you submit this to blktests?

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 2/2] block: take i_rwsem for the direct I/O write fallback

[Christoph Hellwig]

On Sun, Aug 02, 2026 at 08:11:41PM +0300, Tal Zussman wrote:
> >  	} else {
> >  		/*
> >  		 * Take i_rwsem and invalidate_lock to avoid racing with
> > 
> 
> I seem to have stumbled into a Sashiko rabbit hole of issues with IOCB_NOWAIT
> and IOCB_ATOMIC here... [1].
> I'll wait a day or two and send an update along with some additional fixes
> I've spotted.

I think IOCB_ATOMIC vs fallback to buffered I/O is a generally
unsolved issue.  I know ext4 just has a warning, but I'm not
sure how to avoid creating the problem in the first place.

Re: [PATCH 1/2] block: use iomap_dirty_folio for block devices

[Tal Zussman]

On 8/4/26 10:01 AM, Christoph Hellwig wrote: 
> On Sun, Aug 02, 2026 at 07:14:26AM -0400, Tal Zussman wrote:
>> To reproduce, on a device with a sub-page block size, write a known
>> pattern with O_DIRECT, mmap the same range, store to it, msync() and
>> fsync(), then read it back with O_DIRECT. A reproducer is available at
> 
> Heh, shared mmap writes to block devices..
> 
>> [1].
>> 
>> [1] https://urldefense.com/v3/__https://gist.github.com/ 
> tzussman/18ab05cba4b3fdc79cce0a69d1fd05b4__;!!BDUfV1Et5lrpZQ! 
> U2LXFwSk7d0ux5nR34lhpiqhUc75GwdbKoKfJ3Q99AlXZf6q-4Zu4abOqvcnW4gx6nBiH5895_e5MpFV$ <https://urldefense.com/v3/__https://gist.github.com/tzussman/18ab05cba4b3fdc79cce0a69d1fd05b4__;!!BDUfV1Et5lrpZQ!U2LXFwSk7d0ux5nR34lhpiqhUc75GwdbKoKfJ3Q99AlXZf6q-4Zu4abOqvcnW4gx6nBiH5895_e5MpFV$>
> 
> Can you submit this to blktests?

Done: https://github.com/linux-blktests/blktests/pull/258

> 
> Looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 

Thanks!