Hi Yonggil,
I guess your email client forces converting tab and space characters of
patch, please check that.
On 2022/11/22 10:36, Yonggil Song wrote:
When f2fs chooses GC victim in large section & LFS mode,
next_victim_seg[gc_type] is referenced first. After segment is freed,
Hi Chao,
Thanks for your review.
I'll fix this and resend a mail.
Thanks
>Hi Yonggil,
>
>I guess your email client forces converting tab and space characters of
>patch, please check that.
>
>On 2022/11/22 10:36, Yonggil Song wrote:
>> When f2fs chooses GC victim in large section & LFS mode,
>>
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #89 from bogdan.nico...@gmail.com ---
I confirm the bug persists both with background_gc=on and background_gc=sync.
It's especially prone to manifest when the machine is idle for a long time. It
almost feels like the gc hangs because
On Mon, Nov 21, 2022 at 12:21:31PM +0100, Alexander Potapenko wrote:
> When aops->write_begin() does not initialize fsdata, KMSAN may report
> an error passing the latter to aops->write_end().
>
> Fix this by unconditionally initializing fsdata.
>
> Suggested-by: Eric Biggers
> Fixes:
On Mon, Nov 21, 2022 at 8:46 PM Eric Biggers wrote:
>
> On Mon, Nov 21, 2022 at 12:21:31PM +0100, Alexander Potapenko wrote:
> > When aops->write_begin() does not initialize fsdata, KMSAN may report
> > an error passing the latter to aops->write_end().
> >
> > Fix this by unconditionally
When f2fs chooses GC victim in large section & LFS mode,
next_victim_seg[gc_type] is referenced first. After segment is freed,
next_victim_seg[gc_type] has the next segment number.
However, next_victim_seg[gc_type] still has the last segment number
even after the last segment of section is freed.
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #90 from Guido (guido.iod...@gmail.com) ---
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index a71e818cd67b..c351c3269874 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1325,6 +1325,7 @@ struct page
On Mon, Nov 14, 2022 at 1:38 PM Vishal Moola wrote:
>
> On Sun, Nov 13, 2022 at 11:02 PM Chao Yu wrote:
> >
> > On 2022/10/18 4:24, Vishal Moola (Oracle) wrote:
> > > Converted the function to use a folio_batch instead of pagevec. This is in
> > > preparation for the removal of
On Tue, Nov 22, 2022 at 6:26 PM Vishal Moola wrote:
>
> On Mon, Nov 14, 2022 at 1:38 PM Vishal Moola wrote:
> >
> > On Sun, Nov 13, 2022 at 11:02 PM Chao Yu wrote:
> > >
> > > On 2022/10/18 4:24, Vishal Moola (Oracle) wrote:
> > > > Converted the function to use a folio_batch instead of
