public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
	Christian Brauner <brauner@kernel.org>,
	Carlos Maiolino <cem@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Anuj Gupta <anuj20.g@samsung.com>,
	Kanchan Joshi <joshi.k@samsung.com>,
	linux-block@vger.kernel.org, nvdimm@lists.linux.dev,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 14/15] iomap: support T10 protection information
Date: Wed, 21 Jan 2026 16:59:36 -0800	[thread overview]
Message-ID: <20260122005936.GR5945@frogsfrogsfrogs> (raw)
In-Reply-To: <20260121064339.206019-15-hch@lst.de>

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 ?

> tag validation isn't run from interrupt context.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/iomap/bio.c        | 24 +++++++++++++++++++++---
>  fs/iomap/direct-io.c  | 15 ++++++++++++++-
>  fs/iomap/internal.h   | 13 +++++++++++++
>  fs/iomap/ioend.c      | 20 ++++++++++++++++++--
>  include/linux/iomap.h |  7 +++++++
>  5 files changed, 73 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/iomap/bio.c b/fs/iomap/bio.c
> index b4de67bdd513..f989ffcaac96 100644
> --- a/fs/iomap/bio.c
> +++ b/fs/iomap/bio.c
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2010 Red Hat, Inc.
>   * Copyright (C) 2016-2023 Christoph Hellwig.
>   */
> +#include <linux/bio-integrity.h>
>  #include <linux/iomap.h>
>  #include <linux/pagemap.h>
>  #include "internal.h"
> @@ -17,6 +18,8 @@ static u32 __iomap_read_end_io(struct bio *bio, int error)
>  		iomap_finish_folio_read(fi.folio, fi.offset, fi.length, error);
>  		folio_count++;
>  	}
> +	if (bio_integrity(bio))
> +		fs_bio_integrity_free(bio);
>  	bio_put(bio);
>  	return folio_count;
>  }
> @@ -34,7 +37,11 @@ u32 iomap_finish_ioend_buffered_read(struct iomap_ioend *ioend)
>  static void iomap_bio_submit_read(const struct iomap_iter *iter,
>  		struct iomap_read_folio_ctx *ctx)
>  {
> -	submit_bio(ctx->read_ctx);
> +	struct bio *bio = ctx->read_ctx;
> +
> +	if (iter->iomap.flags & IOMAP_F_INTEGRITY)
> +		fs_bio_integrity_alloc(bio);
> +	submit_bio(bio);
>  }
>  
>  static struct bio_set *iomap_read_bio_set(struct iomap_read_folio_ctx *ctx)
> @@ -91,6 +98,7 @@ int iomap_bio_read_folio_range(const struct iomap_iter *iter,
>  
>  	if (!bio ||
>  	    bio_end_sector(bio) != iomap_sector(&iter->iomap, iter->pos) ||
> +	    bio->bi_iter.bi_size > iomap_max_bio_size(&iter->iomap) - plen ||
>  	    !bio_add_folio(bio, folio, plen, offset_in_folio(folio, iter->pos)))
>  		iomap_read_alloc_bio(iter, ctx, plen);
>  	return 0;
> @@ -107,11 +115,21 @@ int iomap_bio_read_folio_range_sync(const struct iomap_iter *iter,
>  		struct folio *folio, loff_t pos, size_t len)
>  {
>  	const struct iomap *srcmap = iomap_iter_srcmap(iter);
> +	sector_t sector = iomap_sector(srcmap, pos);
>  	struct bio_vec bvec;
>  	struct bio bio;
> +	int error;
>  
>  	bio_init(&bio, srcmap->bdev, &bvec, 1, REQ_OP_READ);
> -	bio.bi_iter.bi_sector = iomap_sector(srcmap, pos);
> +	bio.bi_iter.bi_sector = sector;
>  	bio_add_folio_nofail(&bio, folio, len, offset_in_folio(folio, pos));
> -	return submit_bio_wait(&bio);
> +	if (srcmap->flags & IOMAP_F_INTEGRITY)
> +		fs_bio_integrity_alloc(&bio);
> +	error = submit_bio_wait(&bio);
> +	if (srcmap->flags & IOMAP_F_INTEGRITY) {
> +		if (!error)
> +			error = fs_bio_integrity_verify(&bio, sector, len);
> +		fs_bio_integrity_free(&bio);
> +	}
> +	return error;
>  }
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index 842fc7fecb2d..831378a6ced4 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2010 Red Hat, Inc.
>   * Copyright (c) 2016-2025 Christoph Hellwig.
>   */
> +#include <linux/bio-integrity.h>
>  #include <linux/blk-crypto.h>
>  #include <linux/fscrypt.h>
>  #include <linux/pagemap.h>
> @@ -215,6 +216,9 @@ static void __iomap_dio_bio_end_io(struct bio *bio, bool inline_completion)
>  {
>  	struct iomap_dio *dio = bio->bi_private;
>  
> +	if (bio_integrity(bio))
> +		fs_bio_integrity_free(bio);
> +
>  	if (dio->flags & IOMAP_DIO_BOUNCE) {
>  		bio_iov_iter_unbounce(bio, !!dio->error,
>  				dio->flags & IOMAP_DIO_USER_BACKED);
> @@ -325,8 +329,10 @@ static ssize_t iomap_dio_bio_iter_one(struct iomap_iter *iter,
>  	bio->bi_private = dio;
>  	bio->bi_end_io = iomap_dio_bio_end_io;
>  
> +
>  	if (dio->flags & IOMAP_DIO_BOUNCE)
> -		ret = bio_iov_iter_bounce(bio, dio->submit.iter, UINT_MAX);
> +		ret = bio_iov_iter_bounce(bio, dio->submit.iter,
> +				iomap_max_bio_size(&iter->iomap));
>  	else
>  		ret = bio_iov_iter_get_pages(bio, dio->submit.iter,
>  					     alignment - 1);
> @@ -343,6 +349,13 @@ static ssize_t iomap_dio_bio_iter_one(struct iomap_iter *iter,
>  		goto out_put_bio;
>  	}
>  
> +	if (iter->iomap.flags & IOMAP_F_INTEGRITY) {
> +		if (dio->flags & IOMAP_DIO_WRITE)
> +			fs_bio_integrity_generate(bio);
> +		else
> +			fs_bio_integrity_alloc(bio);
> +	}
> +
>  	if (dio->flags & IOMAP_DIO_WRITE)
>  		task_io_account_write(ret);
>  	else if ((dio->flags & IOMAP_DIO_USER_BACKED) &&
> diff --git a/fs/iomap/internal.h b/fs/iomap/internal.h
> index b39dbc17e3f0..cfe63de9e5c7 100644
> --- a/fs/iomap/internal.h
> +++ b/fs/iomap/internal.h
> @@ -4,6 +4,19 @@
>  
>  #define IOEND_BATCH_SIZE	4096
>  
> +/*
> + * Normally we can build bios as big as the data structure supports.
> + *
> + * But for integrity protected I/O we need to respect the maximum size of the
> + * single contiguous allocation for the integrity buffer.
> + */
> +static inline size_t iomap_max_bio_size(const struct iomap *iomap)
> +{
> +	if (iomap->flags & IOMAP_F_INTEGRITY)
> +		return max_integrity_io_size(bdev_limits(iomap->bdev));
> +	return SIZE_MAX;
> +}
> +
>  u32 iomap_finish_ioend_buffered_read(struct iomap_ioend *ioend);
>  u32 iomap_finish_ioend_direct(struct iomap_ioend *ioend);
>  
> diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
> index 72f20e8c8893..a2931f8c454c 100644
> --- a/fs/iomap/ioend.c
> +++ b/fs/iomap/ioend.c
> @@ -2,6 +2,7 @@
>  /*
>   * Copyright (c) 2016-2025 Christoph Hellwig.
>   */
> +#include <linux/bio-integrity.h>
>  #include <linux/iomap.h>
>  #include <linux/list_sort.h>
>  #include <linux/pagemap.h>
> @@ -59,6 +60,8 @@ static u32 iomap_finish_ioend_buffered_write(struct iomap_ioend *ioend)
>  		folio_count++;
>  	}
>  
> +	if (bio_integrity(bio))
> +		fs_bio_integrity_free(bio);
>  	bio_put(bio);	/* frees the ioend */
>  	return folio_count;
>  }
> @@ -92,6 +95,8 @@ int iomap_ioend_writeback_submit(struct iomap_writepage_ctx *wpc, int error)
>  		return error;
>  	}
>  
> +	if (wpc->iomap.flags & IOMAP_F_INTEGRITY)
> +		fs_bio_integrity_generate(&ioend->io_bio);
>  	submit_bio(&ioend->io_bio);
>  	return 0;
>  }
> @@ -113,10 +118,13 @@ static struct iomap_ioend *iomap_alloc_ioend(struct iomap_writepage_ctx *wpc,
>  }
>  
>  static bool iomap_can_add_to_ioend(struct iomap_writepage_ctx *wpc, loff_t pos,
> -		u16 ioend_flags)
> +		unsigned int map_len, u16 ioend_flags)
>  {
>  	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.

The changes here otherwise look ok to me.

--D

> @@ -181,7 +189,7 @@ ssize_t iomap_add_to_ioend(struct iomap_writepage_ctx *wpc, struct folio *folio,
>  	if (pos == wpc->iomap.offset && (wpc->iomap.flags & IOMAP_F_BOUNDARY))
>  		ioend_flags |= IOMAP_IOEND_BOUNDARY;
>  
> -	if (!ioend || !iomap_can_add_to_ioend(wpc, pos, ioend_flags)) {
> +	if (!ioend || !iomap_can_add_to_ioend(wpc, pos, map_len, ioend_flags)) {
>  new_ioend:
>  		if (ioend) {
>  			error = wpc->ops->writeback_submit(wpc, 0);
> @@ -258,6 +266,14 @@ static u32 iomap_finish_ioend(struct iomap_ioend *ioend, int error)
>  
>  	if (!atomic_dec_and_test(&ioend->io_remaining))
>  		return 0;
> +
> +	if (!ioend->io_error &&
> +	    bio_integrity(&ioend->io_bio) &&
> +	    bio_op(&ioend->io_bio) == REQ_OP_READ) {
> +		ioend->io_error = fs_bio_integrity_verify(&ioend->io_bio,
> +			ioend->io_sector, ioend->io_size);
> +	}
> +
>  	if (ioend->io_flags & IOMAP_IOEND_DIRECT)
>  		return iomap_finish_ioend_direct(ioend);
>  	if (bio_op(&ioend->io_bio) == REQ_OP_READ)
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 24f884b6b0c4..bde16d619654 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -65,6 +65,8 @@ struct vm_fault;
>   *
>   * IOMAP_F_ATOMIC_BIO indicates that (write) I/O will be issued as an atomic
>   * bio, i.e. set REQ_ATOMIC.
> + *
> + * IOMAP_F_INTEGRITY indicates that the filesystems handles integrity metadata.
>   */
>  #define IOMAP_F_NEW		(1U << 0)
>  #define IOMAP_F_DIRTY		(1U << 1)
> @@ -79,6 +81,11 @@ struct vm_fault;
>  #define IOMAP_F_BOUNDARY	(1U << 6)
>  #define IOMAP_F_ANON_WRITE	(1U << 7)
>  #define IOMAP_F_ATOMIC_BIO	(1U << 8)
> +#ifdef CONFIG_BLK_DEV_INTEGRITY
> +#define IOMAP_F_INTEGRITY	(1U << 9)
> +#else
> +#define IOMAP_F_INTEGRITY	0
> +#endif /* CONFIG_BLK_DEV_INTEGRITY */
>  
>  /*
>   * Flag reserved for file system specific usage
> -- 
> 2.47.3
> 
> 

  reply	other threads:[~2026-01-22  0:59 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-21  6:43 support file system generated / verified integrity information Christoph Hellwig
2026-01-21  6:43 ` [PATCH 01/15] block: factor out a bio_integrity_action helper Christoph Hellwig
2026-01-23  0:01   ` Darrick J. Wong
2026-01-23  6:03     ` Christoph Hellwig
2026-01-23  7:13       ` Darrick J. Wong
2026-01-26  5:03         ` Christoph Hellwig
2026-01-25 19:46   ` Kanchan Joshi
2026-01-27 14:07   ` Martin K. Petersen
2026-01-27 14:55   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 02/15] block: factor out a bio_integrity_setup_default helper Christoph Hellwig
2026-01-23  0:05   ` Darrick J. Wong
2026-01-23  6:08     ` Christoph Hellwig
2026-01-23  7:14       ` Darrick J. Wong
2026-01-25 20:14   ` Kanchan Joshi
2026-01-27 14:08   ` Martin K. Petersen
2026-01-27 14:55   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 03/15] block: add a bdev_has_integrity_csum helper Christoph Hellwig
2026-01-23  0:07   ` Darrick J. Wong
2026-01-26 18:03   ` Kanchan Joshi
2026-01-27 14:08   ` Martin K. Petersen
2026-01-27 14:55   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 04/15] block: prepare generation / verification helpers for fs usage Christoph Hellwig
2026-01-23  0:07   ` Darrick J. Wong
2026-01-26 18:04   ` Kanchan Joshi
2026-01-27 14:09   ` Martin K. Petersen
2026-01-27 14:56   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 05/15] block: make max_integrity_io_size public Christoph Hellwig
2026-01-23  0:08   ` Darrick J. Wong
2026-01-26 18:04   ` Kanchan Joshi
2026-01-27 14:10   ` Martin K. Petersen
2026-01-27 14:56   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 06/15] block: add fs_bio_integrity helpers Christoph Hellwig
2026-01-23  0:11   ` Darrick J. Wong
2026-01-26 18:12   ` Kanchan Joshi
2026-01-27  5:15     ` Christoph Hellwig
2026-01-27 14:12   ` Martin K. Petersen
2026-01-27 14:57   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 07/15] block: pass a maxlen argument to bio_iov_iter_bounce Christoph Hellwig
2026-01-22  1:04   ` Darrick J. Wong
2026-01-22  6:04     ` Christoph Hellwig
2026-01-22 18:02       ` Darrick J. Wong
2026-01-27 14:12   ` Martin K. Petersen
2026-01-27 14:57   ` Anuj gupta
2026-01-21  6:43 ` [PATCH 08/15] iomap: refactor iomap_bio_read_folio_range Christoph Hellwig
2026-01-22  0:42   ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 09/15] iomap: pass the iomap_iter to ->submit_read Christoph Hellwig
2026-01-22  0:43   ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 10/15] iomap: only call into ->submit_read when there is a read_ctx Christoph Hellwig
2026-01-22  0:44   ` Darrick J. Wong
2026-01-22  2:44     ` Joanne Koong
2026-01-22  5:59       ` Christoph Hellwig
2026-01-22 18:02         ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 11/15] iomap: allow file systems to hook into buffered read bio submission Christoph Hellwig
2026-01-22  0:49   ` Darrick J. Wong
2026-01-22  6:01     ` Christoph Hellwig
2026-01-22 18:04       ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 12/15] iomap: add a bioset pointer to iomap_read_folio_ops Christoph Hellwig
2026-01-22  0:49   ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 13/15] iomap: support ioends for buffered reads Christoph Hellwig
2026-01-22  0:50   ` Darrick J. Wong
2026-01-21  6:43 ` [PATCH 14/15] iomap: support T10 protection information Christoph Hellwig
2026-01-22  0:59   ` Darrick J. Wong [this message]
2026-01-22  6:03     ` Christoph Hellwig
2026-01-21  6:43 ` [PATCH 15/15] xfs: " Christoph Hellwig
2026-01-22  1:02   ` Darrick J. Wong
2026-01-27 14:54 ` support file system generated / verified integrity information Anuj gupta
2026-01-27 15:16   ` Christoph Hellwig
2026-01-29  9:23     ` Anuj Gupta
  -- strict thread matches above, loose matches on Subject: below --
2026-01-28 16:14 support file system generated / verified integrity information v2 Christoph Hellwig
2026-01-28 16:15 ` [PATCH 14/15] iomap: support T10 protection information Christoph Hellwig
2026-01-28 16:30   ` Darrick J. Wong
2026-02-18  6:11 support file system generated / verified integrity information v3 Christoph Hellwig
2026-02-18  6:12 ` [PATCH 14/15] iomap: support T10 protection information Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260122005936.GR5945@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=hch@lst.de \
    --cc=joshi.k@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nvdimm@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox