Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4252698pxb; Tue, 31 Aug 2021 00:03:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5o9Y8JsWDrvemIkjFi5B0+iep0No3AcNy2IQLVjYRgPoGiDbLtHc6I9IbIv2Pc9oo+p+u X-Received: by 2002:a05:6e02:531:: with SMTP id h17mr19351285ils.288.1630393399893; Tue, 31 Aug 2021 00:03:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630393399; cv=none; d=google.com; s=arc-20160816; b=uE7Ll6qjFzeUoin0gvoGRnqABbzVzV9YwlrLYfb8V0oJaHOdVLUYbJna3eC+BxH9th SBiOvn1EfbuodGgyiIdi0QZXdlNyUvSzgz07oi3nF3pBHBsRkpSghSL7q5EsuwQeY7HF TEqVHlBMmKvJvO63lo4NJNswkVqJEJxPBU8Mf3U4vpFo8+I8h22yczt9iEW9OkuueQUC xPyNmVjoNQfBCsuwsjMGv/RmL1+qL2eu9oFbWK8Ar9D7yA7GwkdqPDEv+pHr3clPdAMk hr332tzReegq55bgfK4i4A3duECs0giTU6zbQIlrm1SKrbj0lbMvKAoo++fLDYl9pxzW QyfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=+FuU3YA04rMiTZ/wk+t5hmLCiN6pCER9S7+7mlXXpw8=; b=WxjaakrA1wHsAbqRVm6E4FYnxbik8xcy4VUGYIdONDjAPvjhpl8el5vbgo+4tNt4rw qBDvGQrhBeVgP7T6C/51g7PR4yBp5ofkj8wPG5N3I+d2TOsx7biXdr38JlE0g92q//Cc v74lP2qG6al+MYVby6wQ/AroW0tDLD2YNBcMnPfBoBUMkm+gWZp/wigedTeCAOw7K9vh XqNQiZ/+C1qcAl4cVnySI/x560tamJtJBfoIzTFT5V+c3I88YmlNtzfmxxkXLfFZbN+J Th8G5CLgXcv9BYl1MPKxhBxXXKijWPqYdNGiRCm20NTuRBjfxy/gqlAgi1EHDCHkNBPS Xfwg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b7si1565059jab.66.2021.08.31.00.02.55; Tue, 31 Aug 2021 00:03:19 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238439AbhHaHC5 (ORCPT + 99 others); Tue, 31 Aug 2021 03:02:57 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:8802 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232209AbhHaHC4 (ORCPT ); Tue, 31 Aug 2021 03:02:56 -0400 Received: from dggeme752-chm.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4GzJ4t47shzYpYB; Tue, 31 Aug 2021 15:01:18 +0800 (CST) Received: from [10.174.178.134] (10.174.178.134) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 31 Aug 2021 15:01:59 +0800 Subject: Re: [PATCH v4 6/6] ext4: prevent getting empty inode buffer To: Theodore Ts'o CC: , , , References: <20210826130412.3921207-1-yi.zhang@huawei.com> <20210826130412.3921207-7-yi.zhang@huawei.com> From: Zhang Yi Message-ID: Date: Tue, 31 Aug 2021 15:01:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.134] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggeme752-chm.china.huawei.com (10.3.19.98) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2021/8/31 11:02, Theodore Ts'o wrote: > On Thu, Aug 26, 2021 at 09:04:12PM +0800, Zhang Yi wrote: >> >> So this patch initialize the inode buffer by filling the in-mem inode >> contents if we skip read I/O, ensure that the buffer is really uptodate. >> >> Signed-off-by: Zhang Yi >> --- >> fs/ext4/inode.c | 22 ++++++++++++++++------ >> 1 file changed, 16 insertions(+), 6 deletions(-) >> >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c >> index 3c36e701e30e..8b37f55b04ad 100644 >> --- a/fs/ext4/inode.c >> +++ b/fs/ext4/inode.c >> @@ -4446,8 +4446,8 @@ static int ext4_fill_raw_inode(struct inode *inode, struct ext4_inode *raw_inode >> * inode. >> */ >> static int __ext4_get_inode_loc(struct super_block *sb, unsigned long ino, >> - struct ext4_iloc *iloc, int in_mem, >> - ext4_fsblk_t *ret_block) >> + struct inode *inode, struct ext4_iloc *iloc, >> + int in_mem, ext4_fsblk_t *ret_block) > > > In this patch you've added a new argument 'inode'. However, if in_mem > is true, and inode is NULL, the kernel will crash with a null pointer > dereference. Furthermore, whenever in_mem is false, the callers pass > in NULL for inode. > > Given that, perhaps we should just drop the in_mem argument, and then > instead of > > if (in_mem) { > > we do: > > if (inode && !ext4_test_inode_state(inode, EXT4_STATE_XATTR) { > > with the comments adjusted accordingly? > > I think it will make the code a bit simpler and readable. > > What do you think? > Yes,although I have already prevent passing 'in_mem' is true but 'inode' is NULL in ext4_get_inode_loc(), using two arguments show the inode in-mem case is not safe. I will remove the 'in_mem' parameter. Thanks, Yi.