From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Christian Brauner <brauner@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Joanne Koong <joannelkoong@gmail.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-block@vger.kernel.org,
gfs2@lists.linux.dev
Subject: Re: [PATCH 11/12] iomap: add read_folio_range() handler for buffered writes
Date: Fri, 27 Jun 2025 15:18:36 -0400 [thread overview]
Message-ID: <aF7ujFij4GmYuYPu@bfoster> (raw)
In-Reply-To: <20250627070328.975394-12-hch@lst.de>
On Fri, Jun 27, 2025 at 09:02:44AM +0200, Christoph Hellwig wrote:
> From: Joanne Koong <joannelkoong@gmail.com>
>
> Add a read_folio_range() handler for buffered writes that filesystems
> may pass in if they wish to provide a custom handler for synchronously
> reading in the contents of a folio.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> [hch: renamed to read_folio_range, pass less arguments]
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> .../filesystems/iomap/operations.rst | 6 +++++
> fs/iomap/buffered-io.c | 25 +++++++++++--------
> include/linux/iomap.h | 10 ++++++++
> 3 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst
> index 167d3ca7819c..04432f40e7a2 100644
> --- a/Documentation/filesystems/iomap/operations.rst
> +++ b/Documentation/filesystems/iomap/operations.rst
> @@ -68,6 +68,8 @@ The following address space operations can be wrapped easily:
> void (*put_folio)(struct inode *inode, loff_t pos, unsigned copied,
> struct folio *folio);
> bool (*iomap_valid)(struct inode *inode, const struct iomap *iomap);
> + int (*read_folio_range)(const struct iomap_iter *iter,
> + struct folio *folio, loff_t pos, size_t len);
Whitespace ^
> };
>
> iomap calls these functions:
...
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index a77686977a2e..1a9ade77aeeb 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -667,22 +667,23 @@ iomap_write_failed(struct inode *inode, loff_t pos, unsigned len)
> pos + len - 1);
> }
>
> -static int iomap_read_folio_sync(loff_t block_start, struct folio *folio,
> - size_t poff, size_t plen, const struct iomap *iomap)
> +static int iomap_read_folio_range(const struct iomap_iter *iter,
> + struct folio *folio, loff_t pos, size_t len)
> {
> + const struct iomap *srcmap = iomap_iter_srcmap(iter);
> struct bio_vec bvec;
> struct bio bio;
>
> - bio_init(&bio, iomap->bdev, &bvec, 1, REQ_OP_READ);
> - bio.bi_iter.bi_sector = iomap_sector(iomap, block_start);
> - bio_add_folio_nofail(&bio, folio, plen, poff);
> + bio_init(&bio, srcmap->bdev, &bvec, 1, REQ_OP_READ);
> + bio.bi_iter.bi_sector = iomap_sector(srcmap, pos);
> + bio_add_folio_nofail(&bio, folio, len, offset_in_folio(folio, pos));
> return submit_bio_wait(&bio);
> }
Hmm, so this kind of makes my brain hurt... pos here is now the old
block_start and len is the old plen. We used to pass poff to the
add_folio_nofail() call, and now that is dropped and instead we use
offset_in_folio(..., pos). The old poff is an output of the previous
iomap_adjust_read_range() call, which is initially set to
offset_in_folio(folio, *pos), of which *pos is block_start and is bumped
in that function in the same places that poff is. Therefore old poff and
new offset_in_folio(folio, pos) are logically equivalent. Am I following
that correctly?
Brian
>
> -static int __iomap_write_begin(const struct iomap_iter *iter, size_t len,
> +static int __iomap_write_begin(const struct iomap_iter *iter,
> + const struct iomap_write_ops *write_ops, size_t len,
> struct folio *folio)
> {
> - const struct iomap *srcmap = iomap_iter_srcmap(iter);
> struct iomap_folio_state *ifs;
> loff_t pos = iter->pos;
> loff_t block_size = i_blocksize(iter->inode);
> @@ -731,8 +732,12 @@ static int __iomap_write_begin(const struct iomap_iter *iter, size_t len,
> if (iter->flags & IOMAP_NOWAIT)
> return -EAGAIN;
>
> - status = iomap_read_folio_sync(block_start, folio,
> - poff, plen, srcmap);
> + if (write_ops && write_ops->read_folio_range)
> + status = write_ops->read_folio_range(iter,
> + folio, block_start, plen);
> + else
> + status = iomap_read_folio_range(iter,
> + folio, block_start, plen);
> if (status)
> return status;
> }
> @@ -848,7 +853,7 @@ static int iomap_write_begin(struct iomap_iter *iter,
> else if (srcmap->flags & IOMAP_F_BUFFER_HEAD)
> status = __block_write_begin_int(folio, pos, len, NULL, srcmap);
> else
> - status = __iomap_write_begin(iter, len, folio);
> + status = __iomap_write_begin(iter, write_ops, len, folio);
>
> if (unlikely(status))
> goto out_unlock;
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 482787013ff7..b3588dd43105 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -166,6 +166,16 @@ struct iomap_write_ops {
> * locked by the iomap code.
> */
> bool (*iomap_valid)(struct inode *inode, const struct iomap *iomap);
> +
> + /*
> + * Optional if the filesystem wishes to provide a custom handler for
> + * reading in the contents of a folio, otherwise iomap will default to
> + * submitting a bio read request.
> + *
> + * The read must be done synchronously.
> + */
> + int (*read_folio_range)(const struct iomap_iter *iter,
> + struct folio *folio, loff_t pos, size_t len);
> };
>
> /*
> --
> 2.47.2
>
>
next prev parent reply other threads:[~2025-06-27 19:15 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 7:02 refactor the iomap writeback code v3 Christoph Hellwig
2025-06-27 7:02 ` [PATCH 01/12] iomap: pass more arguments using the iomap writeback context Christoph Hellwig
2025-06-27 15:12 ` Brian Foster
2025-06-30 5:44 ` Christoph Hellwig
2025-06-30 12:41 ` Brian Foster
2025-07-02 18:18 ` Darrick J. Wong
2025-07-02 22:00 ` Joanne Koong
2025-07-02 22:23 ` Darrick J. Wong
2025-07-02 18:22 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 02/12] iomap: cleanup the pending writeback tracking in iomap_writepage_map_blocks Christoph Hellwig
2025-06-27 15:12 ` Brian Foster
2025-07-02 18:23 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 03/12] iomap: refactor the writeback interface Christoph Hellwig
2025-06-27 8:23 ` Damien Le Moal
2025-06-27 15:14 ` Brian Foster
2025-06-30 5:42 ` Christoph Hellwig
2025-06-30 12:39 ` Brian Foster
2025-07-02 18:24 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 04/12] iomap: hide ioends from the generic writeback code Christoph Hellwig
2025-06-27 8:26 ` Damien Le Moal
2025-06-27 15:14 ` Brian Foster
2025-06-28 3:09 ` Randy Dunlap
2025-07-02 18:25 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 05/12] iomap: add public helpers for uptodate state manipulation Christoph Hellwig
2025-06-27 15:14 ` Brian Foster
2025-07-02 18:25 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 06/12] iomap: move all ioend handling to ioend.c Christoph Hellwig
2025-06-27 15:15 ` Brian Foster
2025-06-30 5:44 ` Christoph Hellwig
2025-07-02 18:26 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 07/12] iomap: rename iomap_writepage_map to iomap_writeback_folio Christoph Hellwig
2025-06-27 16:38 ` Brian Foster
2025-07-02 18:26 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 08/12] iomap: move folio_unlock out of iomap_writeback_folio Christoph Hellwig
2025-06-27 16:38 ` Brian Foster
2025-06-30 5:45 ` Christoph Hellwig
2025-06-30 12:39 ` Brian Foster
2025-06-27 7:02 ` [PATCH 09/12] iomap: export iomap_writeback_folio Christoph Hellwig
2025-07-02 18:27 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 10/12] iomap: replace iomap_folio_ops with iomap_write_ops Christoph Hellwig
2025-06-27 8:29 ` Damien Le Moal
2025-06-27 19:18 ` Brian Foster
2025-06-30 5:43 ` Christoph Hellwig
2025-07-02 18:28 ` Darrick J. Wong
2025-06-27 7:02 ` [PATCH 11/12] iomap: add read_folio_range() handler for buffered writes Christoph Hellwig
2025-06-27 19:18 ` Brian Foster [this message]
2025-06-30 5:47 ` Christoph Hellwig
2025-06-27 7:02 ` [PATCH 12/12] iomap: build the writeback code without CONFIG_BLOCK Christoph Hellwig
2025-07-02 18:20 ` Darrick J. Wong
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=aF7ujFij4GmYuYPu@bfoster \
--to=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=gfs2@lists.linux.dev \
--cc=hch@lst.de \
--cc=joannelkoong@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.