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 8064A3AA50B for ; Thu, 12 Mar 2026 09:07:28 +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=1773306448; cv=none; b=Ub/N05gEQ9Cbbv9LLuRmCtoGS+iPVAaBp2ePGsOdHS6BEvAtTz7pvwD9ypXaVZXqhailx/cC2ssbk6dWuSBYYzzvkuTd1gNBqvCwjgUelezpZp/ARRHK/DRAzVsBOJgRPXxL3BhTXJTFSmZTGT6MkH2NLQajBCnVoFOfnSb/WSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773306448; c=relaxed/simple; bh=7sKKM7B1l0YE6cKv+8Rpmlenk89m5zJGk1VYqlRhXbw=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=ij2VQwomt4aCJYUJ44JKYA41Q1E+1CBGXs39GRu9GbC6/wNWATWdmXeRkOxoZwKkiiZdOq4HKeCxY8n+4Etw/AMVke/xXlNtHRtEQzfxOxkDpgBDH04+d99RCMPHUWlfW+G4lwUfJ2Th8ojjWqs6dovFciCoLcLhwrGulfrFYHY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JljbLDgC; 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="JljbLDgC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ACC9C4CEF7; Thu, 12 Mar 2026 09:07:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773306448; bh=7sKKM7B1l0YE6cKv+8Rpmlenk89m5zJGk1VYqlRhXbw=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=JljbLDgC33B7+ouHCEnYtNkS/GTNX8Msg5J8XTiKTG/NPDhGRQXUE0ITrZPjuA2pY AFaNXxrjgJxVAPuYOAHN4J6+FQoMJgFJ80W0xqvtNkr5ImFwT4DIagOQ8DxGQdCM1C MM5iG33chfJxqGrDgS13hV8ZIOTkLDGghpAut3G2JQOjHwwhGnKY2ifvLQU+D0h2iO Rekr2r4gQL7hODO93VhhzdFpbteLLQ59Fl+mXAxXDYt0N6Jry5aI4zuWX+bLC+ONPe Dlz//fdMXtedQ2zN6nFJHQeFB1jKjDqdH950DI7PCsY8mzksMF1jZNJV9UpVbAoCuE wDnSOY7Yagq+Q== Message-ID: <615947f2-fe08-4875-87d9-baef36897e81@kernel.org> Date: Thu, 12 Mar 2026 17:07:22 +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, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to skip empty sections in f2fs_get_victim To: Daeho Jeong References: <20260310175428.1156719-1-daeho43@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026/3/12 00:05, Daeho Jeong wrote: > On Wed, Mar 11, 2026 at 6:44 AM Chao Yu wrote: >> >> On 2026/3/11 01:54, Daeho Jeong wrote: >>> From: Daeho Jeong >>> >>> In age-based victim selection (ATGC, AT_SSR, or GC_CB), f2fs_get_victim >>> can encounter sections with zero valid blocks. This situation often >>> arises when checkpoint is disabled or due to race conditions between >>> SIT updates and dirty list management. >>> >>> In such cases, f2fs_get_section_mtime() returns INVALID_MTIME, which >>> subsequently triggers a fatal f2fs_bug_on(sbi, mtime == INVALID_MTIME) >>> in add_victim_entry() or get_cb_cost(). >>> >>> This patch adds a check in f2fs_get_victim's selection loop to skip >>> sections with no valid blocks. This prevents unnecessary age >>> calculations for empty sections and avoids the associated kernel panic. >>> This change also allows removing redundant checks in add_victim_entry(). >>> >>> Signed-off-by: Daeho Jeong >>> --- >>> fs/f2fs/gc.c | 9 +++------ >>> 1 file changed, 3 insertions(+), 6 deletions(-) >>> >>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c >>> index 2e0f67946914..981eac629fe9 100644 >>> --- a/fs/f2fs/gc.c >>> +++ b/fs/f2fs/gc.c >>> @@ -521,12 +521,6 @@ static void add_victim_entry(struct f2fs_sb_info *sbi, >>> struct sit_info *sit_i = SIT_I(sbi); >>> unsigned long long mtime = 0; >>> >>> - if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) { >>> - if (p->gc_mode == GC_AT && >>> - get_valid_blocks(sbi, segno, true) == 0) >>> - return; >>> - } >>> - >>> mtime = f2fs_get_section_mtime(sbi, segno); >>> f2fs_bug_on(sbi, mtime == INVALID_MTIME); >>> >>> @@ -889,6 +883,9 @@ int f2fs_get_victim(struct f2fs_sb_info *sbi, unsigned int *result, >>> if (sec_usage_check(sbi, secno)) >>> goto next; >>> >>> + if (!get_valid_blocks(sbi, segno, true)) >>> + goto next; >> >> Well, for f2fs_get_victim(, AT_SSR), once there are no dirty segment, if we >> don't count free segment as candidates, then, we can not find any valid victim? > > Oh, AT_SSR needs to select the free section in this case? I think so, for extreme case. > I am confused. Why do we need the below logic? > Looks like WA for the AT_SSR case? > > In f2fs_get_section_mtime() > out: > if (unlikely(mtime == INVALID_MTIME)) > mtime -= 1; > return mtime; There are two conditions, in a section: a) if there are no valid blocks, it will return INVALID_MTIME. b) if there are vaild blocks, it tries to return mtime which is calculated, but if unlucky the calculated mtime is equal to INVALID_MTIME, in order to distinguish from case a), we will return INVALID_MTIME - 1 instead. Thanks, > > >> >> Thanks, >> >>> + >>> /* Don't touch checkpointed data */ >>> if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) { >>> if (p.alloc_mode == LFS) { >>