Re: [PATCH v2 4/22] iomap: allow iomap_file_buffered_write() take iocb without file

[Matthew Wilcox <willy@infradead.org>]

On Tue, Jan 13, 2026 at 04:43:48PM +0000, Matthew Wilcox wrote:
> On Tue, Jan 13, 2026 at 09:15:35AM +0100, Christoph Hellwig wrote:
> > On Mon, Jan 12, 2026 at 02:22:15PM -0800, Darrick J. Wong wrote:
> > > > +		iter.inode = iocb->ki_filp->f_mapping->host;
> > > > +	} else {
> > > > +		iter.inode = (struct inode *)private;
> > > 
> > > @private is for the filesystem implementation to access, not the generic
> > > iomap code.  If this is intended for fsverity, then shouldn't merkle
> > > tree construction be the only time that fsverity writes to the file?
> > > And shouldn't fsverity therefore have access to the struct file?
> > 
> > It's not passed down, but I think it could easily.
> 
> willy@deadly:~/kernel/linux$ git grep ki_filp |grep file_inode | wc
>     109     575    7766
> willy@deadly:~/kernel/linux$ git grep ki_filp |wc
>     367    1920   23371
> 
> I think there's a pretty strong argument for adding ki_inode to
> struct kiocb.  What do you think?

Regardless of this, I think it's an architectural mistake to not have
struct file available for reading fsverity metadata.  We do have it in
fsverity_ioctl_read_metadata but we don't have it in verify_bh().

But reading the merkel tree block from the verify_bh() completion handler
is bad for performance anyway.  We should submit the metadata reads at
the same time we submit the data reads.  And there, we would have the
struct file.

If we ever have ambitions to support merkel trees on network filesystems,
we'll need to figure out some way to pass the struct file in, so maybe
we should just bite the bullet and do this now?