From: "Darrick J. Wong" <djwong@kernel.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: brauner@kernel.org, hch@infradead.org, bfoster@redhat.com,
linux-fsdevel@vger.kernel.org, kernel-team@meta.com,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v3 2/8] docs: document iomap writeback's iomap_finish_folio_write() requirement
Date: Tue, 4 Nov 2025 17:22:46 -0800 [thread overview]
Message-ID: <20251105012246.GC196362@frogsfrogsfrogs> (raw)
In-Reply-To: <20251104205119.1600045-3-joannelkoong@gmail.com>
On Tue, Nov 04, 2025 at 12:51:13PM -0800, Joanne Koong wrote:
> Document that iomap_finish_folio_write() must be called after writeback
> on the range completes.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Makes sense,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> Documentation/filesystems/iomap/operations.rst | 3 +++
> include/linux/iomap.h | 4 ++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst
> index c88205132039..4d30723be7fa 100644
> --- a/Documentation/filesystems/iomap/operations.rst
> +++ b/Documentation/filesystems/iomap/operations.rst
> @@ -361,6 +361,9 @@ The fields are as follows:
> delalloc reservations to avoid having delalloc reservations for
> clean pagecache.
> This function must be supplied by the filesystem.
> + If this succeeds, iomap_finish_folio_write() must be called once writeback
> + completes for the range, regardless of whether the writeback succeeded or
> + failed.
>
> - ``writeback_submit``: Submit the previous built writeback context.
> Block based file systems should use the iomap_ioend_writeback_submit
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 8b1ac08c7474..a5032e456079 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -435,6 +435,10 @@ struct iomap_writeback_ops {
> * An existing mapping from a previous call to this method can be reused
> * by the file system if it is still valid.
> *
> + * If this succeeds, iomap_finish_folio_write() must be called once
> + * writeback completes for the range, regardless of whether the
> + * writeback succeeded or failed.
> + *
> * Returns the number of bytes processed or a negative errno.
> */
> ssize_t (*writeback_range)(struct iomap_writepage_ctx *wpc,
> --
> 2.47.3
>
>
next prev parent reply other threads:[~2025-11-05 1:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 20:51 [PATCH v3 0/8] iomap: buffered io changes Joanne Koong
2025-11-04 20:51 ` [PATCH v3 1/8] iomap: account for unaligned end offsets when truncating read range Joanne Koong
2025-11-05 1:27 ` Darrick J. Wong
2025-11-06 17:08 ` Joanne Koong
2025-11-06 23:08 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 2/8] docs: document iomap writeback's iomap_finish_folio_write() requirement Joanne Koong
2025-11-05 1:22 ` Darrick J. Wong [this message]
2025-11-04 20:51 ` [PATCH v3 3/8] iomap: optimize pending async writeback accounting Joanne Koong
2025-11-05 1:28 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 4/8] iomap: simplify ->read_folio_range() error handling for reads Joanne Koong
2025-11-05 1:50 ` Darrick J. Wong
2025-11-06 17:17 ` Joanne Koong
2025-11-06 23:09 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 5/8] iomap: simplify when reads can be skipped for writes Joanne Koong
2025-11-05 1:40 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 6/8] iomap: use loff_t for file positions and offsets in writeback code Joanne Koong
2025-11-05 1:41 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 7/8] iomap: use find_next_bit() for dirty bitmap scanning Joanne Koong
2025-11-05 1:42 ` Darrick J. Wong
2025-11-04 20:51 ` [PATCH v3 8/8] iomap: use find_next_bit() for uptodate " Joanne Koong
2025-11-05 1:42 ` Darrick J. Wong
2025-11-11 12:09 ` [PATCH v3 0/8] iomap: buffered io changes Christian Brauner
2025-11-11 18:05 ` Joanne Koong
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=20251105012246.GC196362@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=joannelkoong@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@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.