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 E8FEE1B394B for ; Tue, 21 Jan 2025 17:00:12 +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=1737478813; cv=none; b=jZqWlFwj+IBmRW3t75oBcFTB8kHdmIirq0aWc8yQoorAKZnwqqvGSbNzecHrVsn7lzdgn0eecdwf2cvTbz7s2Ul5MHLrcs7iTCQkJahEwkAL71OEW/9NsZLYiVFOALy0La8r4v4V+KHOjx5NdWedIWhHe5sKselaZhbV7HcFXDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737478813; c=relaxed/simple; bh=Yrfr2RwBD67uJAD5IUrw6DIO25JQZMHl277q1iw0o4s=; h=Content-Type:MIME-Version:Subject:From:Message-Id:Date:References: In-Reply-To:To:Cc; b=A6GR03Kd4taPTMNo52H8Qsr72aGQxBvng0gmQ8vOQo3vTa5Mn5pUthn1OFgVKgzPR/j0joxj8jGy2lmwVSzsUHofKvdjeU2Z1wXABdQC3eoxGd2mEmt7Zq00pYHmbPC8tj8dV+qv64Ki/MOR9zyFz9YiQI417yPPLP76EAIE09c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dBGqWCDq; 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="dBGqWCDq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 517D7C4CEDF; Tue, 21 Jan 2025 17:00:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737478812; bh=Yrfr2RwBD67uJAD5IUrw6DIO25JQZMHl277q1iw0o4s=; h=Subject:From:Date:References:In-Reply-To:To:Cc:From; b=dBGqWCDqx7LuP2dQlLLxMIqqsOOuD9IJJfLGB1+ubcIIdEh0FvEKnwfVxyYQ2xR9N UEMFHYC7NPqYvH0OmdOEshfMj+mPOH337OZL/nm57fh9GExYmGN2fdYNBJy9QQ/wgI KNdsKbZap4M7hzM30MUXE9q3jyTcWoDBJP9p4qmrad4MHm75rvNL49W0bPVGRrhVl5 V2iNK4EQVsdmsLhvcI1VO01TFml/At5urb71KVB1FccOPMcPLfQ4bnZkqGt2cfev8P +cK5aBVx8c88KsXsSSHIIZzB8fAI57yCKPAlp5hOb1O8SsMsulb3T/S+6qUvDOnD7c TscyN8/gkS1zA== Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id AEF93380AA75; Tue, 21 Jan 2025 17:00:37 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid trying to get invalid block address From: patchwork-bot+f2fs@kernel.org Message-Id: <173747883624.55169.5980716764876460895.git-patchwork-notify@kernel.org> Date: Tue, 21 Jan 2025 17:00:36 +0000 References: <20250117220955.2482817-1-jaegeuk@kernel.org> In-Reply-To: <20250117220955.2482817-1-jaegeuk@kernel.org> To: Jaegeuk Kim Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Hello: This patch was applied to jaegeuk/f2fs.git (dev) by Jaegeuk Kim : On Fri, 17 Jan 2025 22:09:55 +0000 you 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. > > [...] Here is the summary with links: - [f2fs-dev] f2fs: avoid trying to get invalid block address https://git.kernel.org/jaegeuk/f2fs/c/e02938613eb2 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html