Re: [PATCH 14/15] iomap: support T10 protection information

[Christoph Hellwig <hch@lst.de>]

On Wed, Jan 21, 2026 at 04:59:36PM -0800, Darrick J. Wong wrote:
> On Wed, Jan 21, 2026 at 07:43:22AM +0100, Christoph Hellwig wrote:
> > Add support for generating / verifying protection information in iomap.
> > This is done by hooking into the bio submission and then using the
> > generic PI helpers.  Compared to just using the block layer auto PI
> > this extends the protection envelope and also prepares for eventually
> > passing through PI from userspace at least for direct I/O.
> > 
> > To generate or verify PI, the file system needs to set the
> > IOMAP_F_INTEGRITY flag on the iomap for the request, and ensure the
> > ioends are used for all integrity I/O.  Additionally the file system
> > should defer read I/O completions to user context so that the guard
> 
>   must ?

Well, the copy isn't actually blocking.  So a small copy might actually
work from hardirq context, but you're not going to make friends with
anyone caring about latency.  I guess that means I should upgrade this
to a "must" :)

> >  {
> >  	struct iomap_ioend *ioend = wpc->wb_ctx;
> >  
> > +	if (ioend->io_bio.bi_iter.bi_size >
> > +	    iomap_max_bio_size(&wpc->iomap) - map_len)
> > +		return false;
> >  	if (ioend_flags & IOMAP_IOEND_BOUNDARY)
> >  		return false;
> >  	if ((ioend_flags & IOMAP_IOEND_NOMERGE_FLAGS) !=
> 
> Unrelated question: should iomap_can_add_to_ioend return false if it did
> an IOMAP_F_ANON_WRITE and the bdevs aren't the same, even if the sectors
> match?  Currently not a problem for XFS, but some day we might want to
> have a file that maps to zones on different devices.

For IOMAP_F_ANON_WRITE the bdev doesn't really matter at this level,
as it applies the actual mapping is done below.  So the bdev is really
just a placeholder here.