Re: [PATCH v18 05/15] xfs: handle fsverity I/O in write/read path

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Nov 03, 2026 at 06:53:47AM -0800, Christoph Hellwig wrote:
> > > Sashiko complained about this, but I also really don't understand
> > > how setting ctx->iomap.flags before we even get a mapping to start
> > > with make much sense.  This should be set together with filling the
> > > iomap either way.
> > 
> > The problem here is that when we found a dirty folio to writeback,
> > and we know it's beyond EOF, how to find out that's it's fsverity
> > folio. We don't have any fsverity metadata attach to an inode yet as
> > we are in the process of creating it.
> > 
> > This is not a nice workaround here, but I use stale iomap.flags
> > here. So, every next folio in that iomap has the stale flags from a
> > previous one, which has fsverity set. This should be fine as the
> > only folios written, at this point, are fsverity metadata.
> > 
> > Here I set it for the first folio in the iomap, to get it started.
> > Otherwise, writeback will just will not continue on folios post EOF.
> > 
> > This could be probably done by elevating "verity in construction"
> > into inode_state_flags *shrug*
> 
> Lifting the flag to the VFS feels like a good and nicer than finding
> backways communicaton channels through iomap.  And once we have more
> file systems supporting fsverity a common flag vs one in each
> file system might be worth it even without that.

I don't feel great about reserving space in 'struct inode' just for
temporary state of the FS_IOC_ENABLE_VERITY ioctl.  However, i_state is
currently using only 20 of its 32 available bits anyway, so it actually
would make no difference in the size and there are still plenty of bits
to go.  So sure, if adding I_VERITY_IN_PROGRESS makes things easier for
now, it sounds okay to me.

- Eric