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 4F9E926E6F2 for ; Wed, 18 Mar 2026 03:40:11 +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=1773805211; cv=none; b=byUqnboZej3RHFTTPzogtRpnRv0H2qTF+hW1nI6ILoynvyyOOuSocjtSPbePGDaaMKaNrZjs0B67MtT0UJ8GeQ8kzaZyME9lq4ojttlFpKHMil+2XWZ0XafZ2xqCMadefq88DZn7qrzVuAidFaa06XkbRa3gCCgZ+t2ZVfnvZ5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773805211; c=relaxed/simple; bh=OXMUnIxJ+VFx0JKn/GRXL++ZXg6KH3cw2Oj787ZBwwQ=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=qR6SHIImCC1WTmZLzlt7qXqOqq7MOJm+Sx3j4P32onxjX1cnm63eH4OjgsNlBXEnVY1RTJYEUKCyWIch4Cisu/+r9DgqkLM03tqyD+YYoHefmG6SemJu6FODd8RNOgPRVTN9NIITj5TIcby4BHRfgvud8aCdwnDxloU6ji2Jb7c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p6L3O0yV; 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="p6L3O0yV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7FA3C19421; Wed, 18 Mar 2026 03:40:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773805210; bh=OXMUnIxJ+VFx0JKn/GRXL++ZXg6KH3cw2Oj787ZBwwQ=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=p6L3O0yV4tf4Mw36cWBeZLUdoQ1j69bHxrD0uTlJN1sbeiY1mPRiGpBmP6AvGlBT4 Uuua2n/qzw7JMhBu5puMH89jLEd3Q0aT+pYh368ZwHhwdKkeG0Q2H/uNZ/fNva65TI 6CweUQpyPXFZ0op1wZ9PDD8vcQwTE/5I+bIv3aBlfp04QckMogyO4axNCgh72GF8GZ vxyNVgEUeL2jkQZ3ifky1aHqQo4fdsf+WwhwPPAqmqTe5KrQ0devWC9Xt9bGpHGQIn 68YVkjDxR1UNWUTmCGXT/m0Cvm5EcdlFztnRWBezw21zpAaM+MWdBGv3WAVTEtaU9w RftK/A66/tXsQ== Message-ID: Date: Wed, 18 Mar 2026 11:40:06 +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, syzbot+fc026e87558558f75c00@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v2] f2fs: evict: truncate page cache before clear_inode To: kth5965@gmail.com, jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <9df7bc57-f0e1-4c7b-9ce1-0017eab62c2a@kernel.org> <20260317152838.26664-1-kth5965@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260317152838.26664-1-kth5965@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 2026/3/17 23:28, kth5965@gmail.com wrote: > Hi Chao, > > I checked the repro again based on your comment and added some debug > logs around the related paths. > > What I saw was roughly as follows. > > There was already an abnormal inline state in the read path: > inline flag: set > data_exist: clear > blocks: present > > This case was not rejected by sanity_check_inode(). From what I saw, > the inline sanity check does an early return when inode_has_blocks() > is true, so I think this case was skipped there. I think this may also > explain why there was no sanity warning in the log. > > After that, in the eviction path, i_size was already reduced to 0, but > f2fs_truncate() still entered the inline conversion path, and > f2fs_convert_inline_inode() created folio 0 in the page cache first. > > Then f2fs_convert_inline_folio() handled the empty inline case as > success because of !f2fs_exist_data(inode), and the created folio 0 > remained in the page cache. Because of this, nrpages stayed 1 right > before clear_inode(). The root cause that you pointing out make sense to me. Thanks for the debug and analysis! > > From this, I think there may be two possible directions for fixing > this: > > 1. prevent folio 0 from being created at all in the empty inline case, > or delay folio creation until it is actually needed > 2. detect or guard this abnormal inline state earlier, in sanity check > or before that stage IMO, I think we need to fix both two places: 2) helps to detect this in early stage, so that we can know target inode is corrupted via log and error number returned. However, during 2) process, we will still call into f2fs_evict_inode(), and do inline conversion eventually, so we need to implement 1) to avoid remained page #0 cache, IIUC. What do you think? Thanks, > > At this point, both directions seem possible to me. I wanted to ask > which direction you think would be more appropriate. > > If there is anything else I should check, please let me know. > > Thanks.