2024-02-15 06:37:18

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 01/14] writeback: don't call mapping_set_error on AOP_WRITEPAGE_ACTIVATE

mapping_set_error should only be called on 0 returns (which it ignores)
or a negative error code.

writepage_cb ends up being able to call writepage_cb on the magic
AOP_WRITEPAGE_ACTIVATE return value from ->writepage which means
success but the caller needs to unlock the page. Ignore that and
just call mapping_set_error on negative errors.

(no fixes tag as this goes back more than 20 years over various renames
and refactors so I've given up chasing down the original introduction)

Signed-off-by: Christoph Hellwig <[email protected]>
---
mm/page-writeback.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f255534986a2f..703e83c69ffe08 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2535,7 +2535,9 @@ static int writepage_cb(struct folio *folio, struct writeback_control *wbc,
{
struct address_space *mapping = data;
int ret = mapping->a_ops->writepage(&folio->page, wbc);
- mapping_set_error(mapping, ret);
+
+ if (ret < 0)
+ mapping_set_error(mapping, ret);
return ret;
}

--
2.39.2



2024-02-15 09:32:15

by Jan Kara

[permalink] [raw]
Subject: Re: [PATCH 01/14] writeback: don't call mapping_set_error on AOP_WRITEPAGE_ACTIVATE

On Thu 15-02-24 07:36:36, Christoph Hellwig wrote:
> mapping_set_error should only be called on 0 returns (which it ignores)
> or a negative error code.
>
> writepage_cb ends up being able to call writepage_cb on the magic
> AOP_WRITEPAGE_ACTIVATE return value from ->writepage which means
> success but the caller needs to unlock the page. Ignore that and
> just call mapping_set_error on negative errors.
>
> (no fixes tag as this goes back more than 20 years over various renames
> and refactors so I've given up chasing down the original introduction)
>
> Signed-off-by: Christoph Hellwig <[email protected]>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <[email protected]>

Honza

> ---
> mm/page-writeback.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3f255534986a2f..703e83c69ffe08 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2535,7 +2535,9 @@ static int writepage_cb(struct folio *folio, struct writeback_control *wbc,
> {
> struct address_space *mapping = data;
> int ret = mapping->a_ops->writepage(&folio->page, wbc);
> - mapping_set_error(mapping, ret);
> +
> + if (ret < 0)
> + mapping_set_error(mapping, ret);
> return ret;
> }
>
> --
> 2.39.2
>
--
Jan Kara <[email protected]>
SUSE Labs, CR

2024-02-15 11:43:06

by Brian Foster

[permalink] [raw]
Subject: Re: [PATCH 01/14] writeback: don't call mapping_set_error on AOP_WRITEPAGE_ACTIVATE

On Thu, Feb 15, 2024 at 07:36:36AM +0100, Christoph Hellwig wrote:
> mapping_set_error should only be called on 0 returns (which it ignores)
> or a negative error code.
>
> writepage_cb ends up being able to call writepage_cb on the magic
> AOP_WRITEPAGE_ACTIVATE return value from ->writepage which means
> success but the caller needs to unlock the page. Ignore that and
> just call mapping_set_error on negative errors.
>
> (no fixes tag as this goes back more than 20 years over various renames
> and refactors so I've given up chasing down the original introduction)
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---

Reviewed-by: Brian Foster <[email protected]>

> mm/page-writeback.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3f255534986a2f..703e83c69ffe08 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2535,7 +2535,9 @@ static int writepage_cb(struct folio *folio, struct writeback_control *wbc,
> {
> struct address_space *mapping = data;
> int ret = mapping->a_ops->writepage(&folio->page, wbc);
> - mapping_set_error(mapping, ret);
> +
> + if (ret < 0)
> + mapping_set_error(mapping, ret);
> return ret;
> }
>
> --
> 2.39.2
>
>