From: Darrick J. Wong <djwong@kernel.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v5 3/9] iomap: Rename page_done handler to put_folio
Date: Wed, 4 Jan 2023 09:37:08 -0800 [thread overview]
Message-ID: <Y7W5RGsOgOThtlg3@magnolia> (raw)
In-Reply-To: <20221231150919.659533-4-agruenba@redhat.com>
On Sat, Dec 31, 2022 at 04:09:13PM +0100, Andreas Gruenbacher wrote:
> The ->page_done() handler in struct iomap_page_ops is now somewhat
> misnamed in that it mainly deals with unlocking and putting a folio, so
> rename it to ->put_folio().
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/gfs2/bmap.c | 4 ++--
> fs/iomap/buffered-io.c | 4 ++--
> include/linux/iomap.h | 10 +++++-----
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 46206286ad42..0c041459677b 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -967,7 +967,7 @@ static int gfs2_iomap_page_prepare(struct inode *inode, loff_t pos,
> return gfs2_trans_begin(sdp, RES_DINODE + blocks, 0);
> }
>
> -static void gfs2_iomap_page_done(struct inode *inode, loff_t pos,
> +static void gfs2_iomap_put_folio(struct inode *inode, loff_t pos,
> unsigned copied, struct folio *folio)
> {
> struct gfs2_trans *tr = current->journal_info;
> @@ -994,7 +994,7 @@ static void gfs2_iomap_page_done(struct inode *inode, loff_t pos,
>
> static const struct iomap_page_ops gfs2_iomap_page_ops = {
> .page_prepare = gfs2_iomap_page_prepare,
> - .page_done = gfs2_iomap_page_done,
> + .put_folio = gfs2_iomap_put_folio,
> };
>
> static int gfs2_iomap_begin_write(struct inode *inode, loff_t pos,
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e13d5694e299..2a9bab4f3c79 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -580,8 +580,8 @@ static void iomap_put_folio(struct iomap_iter *iter, loff_t pos, size_t ret,
> {
> const struct iomap_page_ops *page_ops = iter->iomap.page_ops;
>
> - if (page_ops && page_ops->page_done) {
> - page_ops->page_done(iter->inode, pos, ret, folio);
> + if (page_ops && page_ops->put_folio) {
> + page_ops->put_folio(iter->inode, pos, ret, folio);
> } else if (folio) {
> folio_unlock(folio);
> folio_put(folio);
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 743e2a909162..10ec36f373f4 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -126,18 +126,18 @@ static inline bool iomap_inline_data_valid(const struct iomap *iomap)
>
> /*
> * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare
> - * and page_done will be called for each page written to. This only applies to
> + * and put_folio will be called for each page written to. This only applies to
"...for each folio written to."
With that fixed,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> * buffered writes as unbuffered writes will not typically have pages
> * associated with them.
> *
> - * When page_prepare succeeds, page_done will always be called to do any
> - * cleanup work necessary. In that page_done call, @folio will be NULL if the
> - * associated folio could not be obtained. When folio is not NULL, page_done
> + * When page_prepare succeeds, put_folio will always be called to do any
> + * cleanup work necessary. In that put_folio call, @folio will be NULL if the
> + * associated folio could not be obtained. When folio is not NULL, put_folio
> * is responsible for unlocking and putting the folio.
> */
> struct iomap_page_ops {
> int (*page_prepare)(struct inode *inode, loff_t pos, unsigned len);
> - void (*page_done)(struct inode *inode, loff_t pos, unsigned copied,
> + void (*put_folio)(struct inode *inode, loff_t pos, unsigned copied,
> struct folio *folio);
>
> /*
> --
> 2.38.1
>
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@kernel.org>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org, cluster-devel@redhat.com
Subject: Re: [PATCH v5 3/9] iomap: Rename page_done handler to put_folio
Date: Wed, 4 Jan 2023 09:37:08 -0800 [thread overview]
Message-ID: <Y7W5RGsOgOThtlg3@magnolia> (raw)
In-Reply-To: <20221231150919.659533-4-agruenba@redhat.com>
On Sat, Dec 31, 2022 at 04:09:13PM +0100, Andreas Gruenbacher wrote:
> The ->page_done() handler in struct iomap_page_ops is now somewhat
> misnamed in that it mainly deals with unlocking and putting a folio, so
> rename it to ->put_folio().
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/gfs2/bmap.c | 4 ++--
> fs/iomap/buffered-io.c | 4 ++--
> include/linux/iomap.h | 10 +++++-----
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 46206286ad42..0c041459677b 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -967,7 +967,7 @@ static int gfs2_iomap_page_prepare(struct inode *inode, loff_t pos,
> return gfs2_trans_begin(sdp, RES_DINODE + blocks, 0);
> }
>
> -static void gfs2_iomap_page_done(struct inode *inode, loff_t pos,
> +static void gfs2_iomap_put_folio(struct inode *inode, loff_t pos,
> unsigned copied, struct folio *folio)
> {
> struct gfs2_trans *tr = current->journal_info;
> @@ -994,7 +994,7 @@ static void gfs2_iomap_page_done(struct inode *inode, loff_t pos,
>
> static const struct iomap_page_ops gfs2_iomap_page_ops = {
> .page_prepare = gfs2_iomap_page_prepare,
> - .page_done = gfs2_iomap_page_done,
> + .put_folio = gfs2_iomap_put_folio,
> };
>
> static int gfs2_iomap_begin_write(struct inode *inode, loff_t pos,
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e13d5694e299..2a9bab4f3c79 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -580,8 +580,8 @@ static void iomap_put_folio(struct iomap_iter *iter, loff_t pos, size_t ret,
> {
> const struct iomap_page_ops *page_ops = iter->iomap.page_ops;
>
> - if (page_ops && page_ops->page_done) {
> - page_ops->page_done(iter->inode, pos, ret, folio);
> + if (page_ops && page_ops->put_folio) {
> + page_ops->put_folio(iter->inode, pos, ret, folio);
> } else if (folio) {
> folio_unlock(folio);
> folio_put(folio);
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 743e2a909162..10ec36f373f4 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -126,18 +126,18 @@ static inline bool iomap_inline_data_valid(const struct iomap *iomap)
>
> /*
> * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare
> - * and page_done will be called for each page written to. This only applies to
> + * and put_folio will be called for each page written to. This only applies to
"...for each folio written to."
With that fixed,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> * buffered writes as unbuffered writes will not typically have pages
> * associated with them.
> *
> - * When page_prepare succeeds, page_done will always be called to do any
> - * cleanup work necessary. In that page_done call, @folio will be NULL if the
> - * associated folio could not be obtained. When folio is not NULL, page_done
> + * When page_prepare succeeds, put_folio will always be called to do any
> + * cleanup work necessary. In that put_folio call, @folio will be NULL if the
> + * associated folio could not be obtained. When folio is not NULL, put_folio
> * is responsible for unlocking and putting the folio.
> */
> struct iomap_page_ops {
> int (*page_prepare)(struct inode *inode, loff_t pos, unsigned len);
> - void (*page_done)(struct inode *inode, loff_t pos, unsigned copied,
> + void (*put_folio)(struct inode *inode, loff_t pos, unsigned copied,
> struct folio *folio);
>
> /*
> --
> 2.38.1
>
next prev parent reply other threads:[~2023-01-04 17:37 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-31 15:09 [Cluster-devel] [PATCH v5 0/9] Turn iomap_page_ops into iomap_folio_ops Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 1/9] iomap: Add iomap_put_folio helper Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:39 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:39 ` Darrick J. Wong
2023-01-08 17:25 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:25 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 2/9] iomap/gfs2: Unlock and put folio in page_done handler Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:40 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:40 ` Darrick J. Wong
2023-01-08 17:26 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 3/9] iomap: Rename page_done handler to put_folio Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:37 ` Darrick J. Wong [this message]
2023-01-04 17:37 ` Darrick J. Wong
2023-01-04 18:51 ` [Cluster-devel] " Andreas Grünbacher
2023-01-04 18:51 ` Andreas Grünbacher
2023-01-08 17:26 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 4/9] iomap: Add iomap_get_folio helper Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:38 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:38 ` Darrick J. Wong
2023-01-08 17:26 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 5/9] iomap/gfs2: Get page in page_prepare handler Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:45 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:45 ` Darrick J. Wong
2023-01-08 17:29 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:29 ` Christoph Hellwig
2023-01-08 19:40 ` [Cluster-devel] " Andreas Gruenbacher
2023-01-08 19:40 ` Andreas Gruenbacher
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 6/9] iomap: Rename page_prepare handler to get_folio Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:46 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:46 ` Darrick J. Wong
2023-01-08 17:31 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:31 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 7/9] iomap/xfs: Eliminate the iomap_valid handler Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:53 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:53 ` Darrick J. Wong
2023-01-04 19:02 ` [Cluster-devel] " Andreas Grünbacher
2023-01-04 19:02 ` Andreas Grünbacher
2023-01-04 19:08 ` [Cluster-devel] " Matthew Wilcox
2023-01-04 19:08 ` Matthew Wilcox
2023-01-08 17:32 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:32 ` Christoph Hellwig
2023-01-08 18:50 ` [Cluster-devel] " Andreas Gruenbacher
2023-01-08 18:50 ` Andreas Gruenbacher
2023-01-10 21:56 ` [Cluster-devel] " Darrick J. Wong
2023-01-10 21:56 ` Darrick J. Wong
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 8/9] iomap: Rename page_ops to folio_ops Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-04 17:53 ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:53 ` Darrick J. Wong
2023-01-08 17:33 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:33 ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 9/9] xfs: Make xfs_iomap_folio_ops static Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2023-01-08 17:33 ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:33 ` 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=Y7W5RGsOgOThtlg3@magnolia \
--to=djwong@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.