linux-kernel - RE: [External Mail] Re: [PATCH] f2fs: prevent the current section from being selected as a victim during garbage collection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2d95428375bd4a5592516bb6cefe4592@sk.com>
Date: Thu, 27 Mar 2025 06:43:50 +0000
From: 정요한(JOUNG YOHAN) Mobile AE
	<yohan.joung@...com>
To: Chao Yu <chao@...nel.org>, Yohan Joung <jyh429@...il.com>,
	"jaegeuk@...nel.org" <jaegeuk@...nel.org>, "daeho43@...il.com"
	<daeho43@...il.com>
CC: "linux-f2fs-devel@...ts.sourceforge.net"
	<linux-f2fs-devel@...ts.sourceforge.net>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
	김필현(KIM PILHYUN) Mobile AE <pilhyun.kim@...com>
Subject: RE: [External Mail] Re: [PATCH] f2fs: prevent the current section
 from being selected as a victim during garbage collection

> From: Chao Yu <chao@...nel.org>
> Sent: Thursday, March 27, 2025 3:02 PM
> To: Yohan Joung <jyh429@...il.com>; jaegeuk@...nel.org; daeho43@...il.com
> Cc: chao@...nel.org; linux-f2fs-devel@...ts.sourceforge.net; linux-
> kernel@...r.kernel.org; 정요한(JOUNG YOHAN) Mobile AE <yohan.joung@...com>
> Subject: [External Mail] Re: [PATCH] f2fs: prevent the current section
> from being selected as a victim during garbage collection
> 
> On 3/26/25 22:14, Yohan Joung wrote:
> > When selecting a victim using next_victim_seg in a large section, the
> > selected section might already have been cleared and designated as the
> > new current section, making it actively in use.
> > This behavior causes inconsistency between the SIT and SSA.
> 
> Hi, does this fix your issue?

This is an issue that arises when dividing 
a large section into segments for garbage collection.
caused by the background GC (garbage collection) thread in large section
f2fs_gc(victim_section) -> f2fs_clear_prefree_segments(victim_section)-> 
cursec(victim_section) -> f2fs_gc(victim_section by next_victim_seg)

Because the call stack is different, 
I think that in order to handle everything at once, 
we need to address it within do_garbage_collect, 
or otherwise include it on both sides. What do you think?

[30146.337471][ T1300] F2FS-fs (dm-54): Inconsistent segment (70961) type [0, 1] in SSA and SIT
[30146.346151][ T1300] Call trace:
[30146.346152][ T1300]  dump_backtrace+0xe8/0x10c
[30146.346157][ T1300]  show_stack+0x18/0x28
[30146.346158][ T1300]  dump_stack_lvl+0x50/0x6c
[30146.346161][ T1300]  dump_stack+0x18/0x28
[30146.346162][ T1300]  f2fs_stop_checkpoint+0x1c/0x3c
[30146.346165][ T1300]  do_garbage_collect+0x41c/0x271c
[30146.346167][ T1300]  f2fs_gc+0x27c/0x828
[30146.346168][ T1300]  gc_thread_func+0x290/0x88c
[30146.346169][ T1300]  kthread+0x11c/0x164
[30146.346172][ T1300]  ret_from_fork+0x10/0x20

struct curseg_info : 0xffffff803f95e800 {
	segno        : 0x11531 : 70961
}

struct f2fs_sb_info : 0xffffff8811d12000 {
	next_victim_seg[0] : 0x11531 : 70961
}

> 
> https://lore.kernel.org/linux-f2fs-devel/20250325080646.3291947-2-
> chao@...nel.org
> 
> Thanks,
> 
> >
> > Signed-off-by: Yohan Joung <yohan.joung@...com>
> > ---
> >  fs/f2fs/gc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index
> > 2b8f9239bede..4b5d18e395eb 100644
> > --- a/fs/f2fs/gc.c
> > +++ b/fs/f2fs/gc.c
> > @@ -1926,6 +1926,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, struct
> f2fs_gc_control *gc_control)
> >  		goto stop;
> >  	}
> >
> > +	if (__is_large_section(sbi) &&
> > +			IS_CURSEC(sbi, GET_SEC_FROM_SEG(sbi, segno)))
> > +		goto stop;
> > +
> >  	seg_freed = do_garbage_collect(sbi, segno, &gc_list, gc_type,
> >  				gc_control->should_migrate_blocks,
> >  				gc_control->one_time);