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

[Hannes Reinecke <hare@suse.de>]

On 8/28/26 3:49 PM, 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.
> 
> A short IOCB_NOWAIT direct write reaches the same fallback. Taking
> i_rwsem there can now block behind set_blocksize(), and the fallback
> already blocks on writeback of the data it copied in
> direct_write_fallback(). blkdev_write_iter() already rejects a purely
> buffered IOCB_NOWAIT write with -EOPNOTSUPP, so do not enter the
> fallback for IOCB_NOWAIT at all: return the bytes the direct path
> already wrote, or -EAGAIN if none, and let the caller retry.
> 
> The reproducer used was written by an LLM, and is available at [1].
> 
> [1] https://gist.github.com/tzussman/69d06bc57d42a42989eb038b1b5aeb74
> 
> Fixes: 3c20917120ce ("block/bdev: enable large folio support for large logical block sizes")
> 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 | 23 ++++++++++++++++++++---
>   1 file changed, 20 insertions(+), 3 deletions(-)
> 
You gotta love LLMs; no-one would have written up a testcase with
four different threads...
Anyway. There is a reproducer, so we should be fixing it.

Reviewed-by: Hannes Reinecke <hare@kernel.org>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich