[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <PH0PR04MB7416746F354376654DD601869B029@PH0PR04MB7416.namprd04.prod.outlook.com>
Date: Tue, 29 Jun 2021 13:10:50 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: "lijian_8010a29@....com" <lijian_8010a29@....com>,
"clm@...com" <clm@...com>,
"josef@...icpanda.com" <josef@...icpanda.com>,
"dsterba@...e.com" <dsterba@...e.com>
CC: "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
lijian <lijian@...ong.com>
Subject: Re: [PATCH] fs: ntfs: super: added return error value while map
failed
On 29/06/2021 12:41, lijian_8010a29@....com wrote:
> From: lijian <lijian@...ong.com>
>
> When lookup_extent_mapping failed, should return '-ENOENT'.
>
> Signed-off-by: lijian <lijian@...ong.com>
> ---
> fs/btrfs/extent_map.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index 4a8e02f7b6c7..e9d9f2bfc11d 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -305,8 +305,10 @@ int unpin_extent_cache(struct extent_map_tree *tree, u64 start, u64 len,
>
> WARN_ON(!em || em->start != start);
>
> - if (!em)
> + if (!em) {
> + ret = -ENOENT;
> goto out;
> + }
>
> em->generation = gen;
> clear_bit(EXTENT_FLAG_PINNED, &em->flags);
>
You'll still need to properly handle the returned error in the caller,
otherwise this patch makes no sense at all.
Also the subject should be something like "btrfs: handle failures from unpin_extent_cache" or
sth. like this.
Powered by blists - more mailing lists