Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: cS3juXIYGcwYZHbrRYB2MqBiKfkAvmeClcX8z0eJgnQQ7pMHRJrpdYr5YWCkTKs8cmlscKtbsN
 wcvyy98f2qLJzuqxpr+MDHKJy2TrkUntwD5NupC/MigCWWV40TVI6KKTTi9sXirmdCCR8cK4F6
 gsoi2hgwmY72PHm7HcbjFCs6dOFyxuPOhtkjLliBHZkyPfQaB6SbuKrP6I1W2JQwcYlE+WDA3b
 WPo1DhPmmx4rr5OrfUImcs8qNBEWNDxlMQBw33fIwA1ffWjMr8mzE2OiRJveiUDX+crJ4Ymg/w
 U2M=
From:   Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To:     "lijian_8010a29@163.com" <lijian_8010a29@163.com>,
        "clm@fb.com" <clm@fb.com>,
        "josef@toxicpanda.com" <josef@toxicpanda.com>,
        "dsterba@suse.com" <dsterba@suse.com>
CC:     "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        lijian <lijian@yulong.com>
Subject: Re: [PATCH] fs: btrfs: extent_map: removed unneeded variable
Thread-Topic: [PATCH] fs: btrfs: extent_map: removed unneeded variable
Thread-Index: AQHXbMQAzBmALZ3G+kSY1PzHly/n7g==
Date:   Tue, 29 Jun 2021 09:04:40 +0000
Message-ID: <PH0PR04MB741666CF29DB96CF0DB0C26B9B029@PH0PR04MB7416.namprd04.prod.outlook.com>
References: <20210629085025.98437-1-lijian_8010a29@163.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m2E9L95qH+RVT4i361uo9DOA+2+ts0WoFoFGo4gvayXvUQAQDSvv7YRA0Mth?=
 =?us-ascii?Q?jEYvMpPoliMM3vsG8ZHIGAaGHWgO8EwZA5jFYBPl2AxU5RNEKBF7rqnPsg3+?=
 =?us-ascii?Q?+eysYy5vctHcbs7iVuGdWlCsp6EXijxxlBrkW2e0URcyORPYd/soV019hwNP?=
 =?us-ascii?Q?ztpFRVy/qO6hQFTNwpa72z3H51ordoU5cMTqxxUay0ujdDNGbfH1AJXPhJJa?=
 =?us-ascii?Q?XgJPWOFDP8SmFnpO6u1U8iB+rZbiek4LGYXIPzmJ0PXRGaVYebsRlyLcmNQO?=
 =?us-ascii?Q?cADIeYJeXnNAhtpXrxnw1xvAiIuUsCC6s/ySTyie8kVwTBk7U08+Ry0ptTPz?=
 =?us-ascii?Q?oM9j5Ycd9yANFp9Pixhc8a/Xc4eRWrvpDAFZ+9CfnrZ0tXE6AzT3H1ynaB5k?=
 =?us-ascii?Q?b/8V7P0vV3l4z49BFzhM6+kgCD/Elu1A4y3rwFWPDo0GKZxjy+MDhFD5kDzY?=
 =?us-ascii?Q?i5KVgWtXS07Y9GO//HDCqOcrflMrOI1I3Alpyu/5mJmidFpJnkwF/fwbg3M5?=
 =?us-ascii?Q?KWL7jo1Azkr9UkUHfbO7gXARLaInCbVl7+ygLv+dg1fRmJ5RlH7S4kHI4jvp?=
 =?us-ascii?Q?3u5ma6Pr025r1KacfTkihih/rE4sAaPwYjfT5LfAYvwQsE4hV5J5YECIQuWS?=
 =?us-ascii?Q?0cBj5WpTRdroOQ6QeMQbtpqWDP9JGpI9Cv5uaAvdNZ3alcZVSnyTHaY4h4jY?=
 =?us-ascii?Q?gZ0JqppjihlzGwMZkgpIwkz6dwdl9JcPW/61CvAqJcsXXcd+AZylaIsgoUPv?=
 =?us-ascii?Q?pq+tEslHq0vpiIVEByjbpxR9wQvl6IZ+uDd/rjtDWxG90SXeit3jOynZUaag?=
 =?us-ascii?Q?BAEO68FfPyK4YummxhZwRgbASNi4qVdQGzPISSmKmQwyQY2/yXbnpY5WqRXP?=
 =?us-ascii?Q?FKwnAuGTJmjjKzIdJxrZ/xm8Ipf63r5PXeRdynRUEly9/PL2rMpZlkLsOL9B?=
 =?us-ascii?Q?ANNRBVSZ2qEy0yhB5nXWNXcKNlDIvMa+8yhfqVAs3cUHepKFzRsVed8OZl5U?=
 =?us-ascii?Q?ZwWibHzHN2FzwaBkujs45Ot6nBzkwDUJaS/oCSxAbK/pth25zJ0+625RvbwQ?=
 =?us-ascii?Q?ui8pN54zSrr4iK6BVoy9q/mFydhRIhJ2wk/NOPQyEszwhGvYA7487YQK8Tyr?=
 =?us-ascii?Q?PXO1w99sJWFriuweHCvVzsIrL+7AbXFpzlw3ulSh7OmOUBoAXRfLqTTqvw6H?=
 =?us-ascii?Q?3sYQnsx3BWsRpo+bRfa9KD3m2NCPJSoNahglGYkeA9VwGUCk351grhX/dv+T?=
 =?us-ascii?Q?s+olzcerp72rzUD8xPhPR7EoYcn7Ia7tamSq4MLXFngG67JQCr3BcS+iJlM5?=
 =?us-ascii?Q?Tlw2l85lN2KfxfxwEZVhLg+n2xc/GZW5/AYIDm/I4XasAg=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR04MB7416.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cfdfd79-ada8-40c3-5694-08d93adceddb
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 09:04:40.5923
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: szguCjZiS5l2IsxCiCIlOh+Q7wLU1+pDzVjdPKwut2TNd6CPR+E9RzN7o1Bg4J5oDPh7JA9nzjVGtPC4a+EcbWWjI6n2cXbB76jRVT6sIZ0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR04MB7269
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 29/06/2021 10:51, lijian_8010a29@163.com wrote:=0A=
> From: lijian <lijian@yulong.com>=0A=
> =0A=
> removed unneeded variable 'ret'.=0A=
=0A=
Wouldn't it make more sense to return an error (-ENOENT??) in case=0A=
the em lookup fails and handle the error in btrfs_finish_ordered_io()=0A=
as this is the only caller of unpin_extent_cache()?=0A=
=0A=
I've actually tripped over this a couple of times already when =0A=
investigating extent map and ordered extent splitting problems=0A=
on zoned filesystems:=0A=
=0A=
	em =3D lookup_extent_mapping(tree, start, len);=0A=
	WARN_ON(!em || em->start !=3D start);=0A=
=0A=
Maybe even turn this WARN_ON() into an ASSERT() when introducing proper=0A=
error handling, as we shouldn't really get there unless we have a logical=
=0A=
error.=0A=