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.
