Re: [PATCH] fs: report direct io constraints through file_getattr

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 09, 2026 at 11:14:47AM +0200, Jan Kara wrote:
> On Thu 09-07-26 09:13:52, Christoph Hellwig wrote:
> > On Tue, Jul 07, 2026 at 06:18:43PM -0700, Keith Busch wrote:
> > > +		u32 dio_align = ext4_dio_alignment(inode);
> > > +
> > > +		if (dio_align != 0) {
> > 
> > 
> > > +			struct block_device *bdev = inode->i_sb->s_bdev;
> > > +
> > > +			if (dio_align == 1) {
> > > +				fa->fsx_dio_mem_align = bdev_dma_alignment(bdev) + 1;
> > > +				fa->fsx_dio_offset_align = bdev_logical_block_size(bdev);
> > > +				fa->fsx_dio_read_offset_align = bdev_logical_block_size(bdev);
> > > +			} else {
> > > +				fa->fsx_dio_mem_align = dio_align;
> > > +				fa->fsx_dio_offset_align = dio_align;
> > > +				fa->fsx_dio_read_offset_align = dio_align;
> > > +			}
> > 
> > Call bdev_fileattr and override the relevant field as needed?
> > 
> > Question to the ext4 maintainers: why does ext4_dio_alignment
> > affect the in-memory alignment?  If it does so, it should probably
> > also affect the virt boundry alignment..
> 
> I guess that is mostly a historical accident. ext4_dio_alignment() returns
> 1 (iomap alignment is used and that's different for memory and file offset
> alignment), 0 (dio not supported, memory and file offset alignment is
> indeed the same), and blocksize (a special case which can happen for
> fscrypt if it supports dio and where I believe memory alignment
> requirements may be in fact different). I'm adding Eric to CC to answer
> what actual requirements fscrypt has for memory buffers for direct IO. I'd
> expect with inline encryption we would have the same requirements as
> ordinary iomap direct IO and for other code paths I'm not sure... Eric?

Please see Documentation/filesystems/fscrypt.rst:

    The I/O request must be fully aligned to the filesystem block size.
    This means that the file position the I/O is targeting, the lengths
    of all I/O segments, and the memory addresses of all I/O buffers
    must be multiples of this value.  Note that the filesystem block
    size may be greater than the logical block size of the block device.

We go over this about once a year, whenever someone suggests that the
memory alignment requirement is not needed.  blk-crypto-fallback needs
it, the block layer itself needs it, and at least some storage drivers
need it.

To support less memory alignment, we'd need to:

   - Make some fairly complex updates to blk-crypto-fallback to support
     en/decrypting data units split across pages.  Note that there's no
     way to do this with zero overhead on other requests.

   - Update the block layer to not split crypto data units across bvecs,
     regardless of memory alignment.  This also would add more overhead
     to all requests.

   - Test the hardware support on each eMMC and UFS host controller
     individually and opt in the ones that actually correctly handle
     crypto data units split across DMA segments.  We already know it
     does *not* work on at least one.

   - And finally update the filesystems as the last step, not the first.

So far I haven't seen the point.  Yes, applications can benefit from the
lower alignment in theory.  But especially with encryption/decryption,
it isn't at all easy to support.  This has apparently been getting
learned the hard way, as (for example) alignment was initially relaxed
for dm-crypt without testing it, and it had to be reverted
(https://lore.kernel.org/dm-devel/20221103152559.1909328-1-kbusch@meta.com/).

- Eric