From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EB6F2260C for ; Mon, 20 Jan 2025 05:27:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737350833; cv=none; b=ZDRnCRhjSWnW4pTvCJoMkT4SvZZApHZDzcXcUsb5YLiDl6g3YADHwRmGoFYIllMNpCcvSqzdPPD9Uf4SpjSdie+DS4EUu+jqak9q6BDvKDg0Bx3BjaYAixgoyCCbO+OeEzpMFdmx1R3loSVSgO5Wcb90TqegoEW2pLFbrH283FI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737350833; c=relaxed/simple; bh=pzAwjPJxS6Eln+ye2RNva3/5+EU2r17j4VQfvjjRO5s=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=qk6QwbGOCFDINRKDfIWMAts9CX4NM465Q/jLeC7+Dw2bwo4vOA+UA1HJBsKnIyON3UcFbtWEi0yYIGN5bK+lopV/Ludis6oTua4fiJk3HANF1T/0aQ4hwOHPl0Ja6w9A92wolWjnEZYVSlz2xyqNBJF4tt1gRLdHMEKjAWEbqZc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cuFrJRGv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cuFrJRGv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26D09C4CEDD; Mon, 20 Jan 2025 05:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737350833; bh=pzAwjPJxS6Eln+ye2RNva3/5+EU2r17j4VQfvjjRO5s=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=cuFrJRGv7Hp7+j1UEoNd1I5hRtHApQtO/QLbyiiXF6dzLnUGkVLVp6r7E34wN03N1 Pvf3JMIEkrFZBXDPHiF9X3NnGKI3vxUCvU4YpoKPYOg6wk7n/AMutjDvY0bhXHINg8 LmdzAPOVmYaI3nhx9jzYK4nkZaXvAUwgZFxgkiO8huJp1ClBT39YzYu3sO4hTRyAE9 ifrgo5LTNaMyAZkZSE6Hh19flFcZaz9a0osmIFer4PyWnrVwntGF2CB5bA65OuG9hd POPItpvP4CoCe909tf4AkQpg/9JfxKR8YoJ2n/2kXjk8k3BcU/zIu4BTGRGhUV4gzg Bn9a1qPYHteLA== Message-ID: <4e1348cc-9b91-40f0-b740-d26530fac6ce@kernel.org> Date: Mon, 20 Jan 2025 13:27:09 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid trying to get invalid block address To: Jaegeuk Kim , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <20250117220955.2482817-1-jaegeuk@kernel.org> Content-Language: en-US From: Chao Yu In-Reply-To: <20250117220955.2482817-1-jaegeuk@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/18/25 06:09, Jaegeuk Kim via Linux-f2fs-devel wrote: > In f2fs_new_inode(), if we fail to get a new inode, we go iput(), followed by > f2fs_evict_inode(). If the inode is not marked as bad, it'll try to call > f2fs_remove_inode_page() which tries to read the inode block given node id. > But, there's no block address allocated yet, which gives a chance to access > a wrong block address, if the block device has some garbage data in NAT table. > > We need to make sure NAT table should have zero data for all the unallocated > node ids, but also would be better to take this unnecessary path as well. > Let's mark the faild inode as bad. > Needs a fixes line? Fixes: 0abd675e97e6 ("f2fs: support plain user/group quota") Otherwise, it looks good to me. Reviewed-by: Chao Yu Thanks, > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/namei.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c > index 57d46e1439de..a278c7da8177 100644 > --- a/fs/f2fs/namei.c > +++ b/fs/f2fs/namei.c > @@ -341,6 +341,7 @@ static struct inode *f2fs_new_inode(struct mnt_idmap *idmap, > trace_f2fs_new_inode(inode, err); > dquot_drop(inode); > inode->i_flags |= S_NOQUOTA; > + make_bad_inode(inode); > if (nid_free) > set_inode_flag(inode, FI_FREE_NID); > clear_nlink(inode);