Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4011198ybg; Sun, 7 Jun 2020 18:25:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPjy7FwHNu4eqawHLEtYt5PYjBBvSDbUWdGB92ua0sfS/fDaK/usJI9kPthIZfAwB0aoxB X-Received: by 2002:a50:cccc:: with SMTP id b12mr19517220edj.68.1591579521340; Sun, 07 Jun 2020 18:25:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591579521; cv=none; d=google.com; s=arc-20160816; b=geFmGiZL9ntb5A04Tt+Du/nSsQvb/SIz+zJAnzXXTnYLAwJ1JOa4Z1SQg5ZB/4KE+3 78oN1W32vpmutsw9m5lUR7ApE8c0hu939v2xudVFppqJLJYxV4hbuVxBIvjxl3aw38Bg 3XvzFHkp36pEur2hrpnSc273zVfsq+kQ3LRvbfJRE22mYrLXS2+tg6ogoxUnH5aiN1Jk hikJBpycpALRCGiomIFqObQoGwyfkAOMccWNfgKczZnn6OKnEYk+G7a24Bsjn/GCQwte n60bWL3MyfPG5dCJQEIgTH4fVbFVKQNM6puVs4QAyp9c85sz94sAeH/LQY15VS5PscH7 nXDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Kv3Fc0YJfz4dpvk4zXq2YNNa1jQiGhgG+QCNA8qYhCE=; b=PIIxyUZOsH4LteSNS3Wnb4X8wRkuSkEBoCw3tj2DXLvgmX6Enyx8fxkW5+Q1bPI14r yMXMQmmrr5KpxTOzKP17cSoPt5Y4GWe/66IQsd94K5hbw0644SxWr8C8HXblbj9NQqrE Atx7DCB/rK9kFXkdnUstS3eiIA5ep0ojiq12SK41ZVq7NzJaQOEKiDpIJZV0PbQAIn1h 4HR51WCtckb7OG4BnQNywaa6v08YcLALLdBMggFx7jE2VCNROeGXPPaDlbfsVuXVOO4d gGMDsAA7vqG+NXjKRz4rYZtLKiR/spGp7NAkUHyuftTEUeZfI151lLxHyOWywZUfoykp kcPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx20si7914296ejb.50.2020.06.07.18.24.34; Sun, 07 Jun 2020 18:25:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728065AbgFHBUH (ORCPT + 99 others); Sun, 7 Jun 2020 21:20:07 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:50534 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727972AbgFHBUH (ORCPT ); Sun, 7 Jun 2020 21:20:07 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id BF881C31F3ECCA726673 for ; Mon, 8 Jun 2020 09:20:03 +0800 (CST) Received: from [127.0.0.1] (10.166.215.198) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.487.0; Mon, 8 Jun 2020 09:20:00 +0800 Subject: Re: [PATCH v2 2/2] ext2: ext2_find_entry() return -ENOENT if no entry found To: Jan Kara CC: References: <20200603063514.3904811-1-yi.zhang@huawei.com> <20200603063514.3904811-2-yi.zhang@huawei.com> <20200605151100.GD13248@quack2.suse.cz> From: "zhangyi (F)" Message-ID: <13a18e5f-faea-f8b6-1072-8e911975ddc2@huawei.com> Date: Mon, 8 Jun 2020 09:20:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200605151100.GD13248@quack2.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.166.215.198] X-CFilter-Loop: Reflected Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2020/6/5 23:11, Jan Kara wrote: > On Wed 03-06-20 14:35:14, zhangyi (F) wrote: >> Almost all callers of ext2_find_entry() transform NULL return value to >> -ENOENT, so just let ext2_find_entry() retuen -ENOENT instead of NULL >> if no valid entry found, and also switch to check the return value of >> ext2_inode_by_name() in ext2_lookup() and ext2_get_parent(). >> >> Signed-off-by: zhangyi (F) >> Suggested-by: Jan Kara > > Thanks for the patch. Just one small nit below. > >> @@ -419,11 +419,16 @@ int ext2_inode_by_name(struct inode *dir, const struct qstr *child, ino_t *ino) >> struct page *page; >> >> de = ext2_find_entry(dir, child, &page); >> - if (IS_ERR_OR_NULL(de)) >> + if (IS_ERR(de)) >> return PTR_ERR(de); >> >> - *ino = le32_to_cpu(de->inode); >> ext2_put_page(page); >> + if (!de->inode) { > > ext2_find_entry() will not ever return de with de->inode == 0 because > ext2_match() never returns true for such entries. So I'd just remove this > condition... > Indeed, I missed this point, will do. Thanks, Yi.