linux-kernel - Re: [PATCH] f2fs: fix to correct freed section number during gc

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: <20150923210851.GB36564@jaegeuk-mac02.mot.com>
Date:	Wed, 23 Sep 2015 14:08:51 -0700
From:	Jaegeuk Kim <jaegeuk@...nel.org>
To:	Chao Yu <chao2.yu@...sung.com>
Cc:	linux-f2fs-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: fix to correct freed section number during gc

Hi Chao,

On Wed, Sep 23, 2015 at 06:11:36PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -----Original Message-----
> > From: Jaegeuk Kim [mailto:jaegeuk@...nel.org]
> > Sent: Wednesday, September 23, 2015 6:54 AM
> > To: Chao Yu
> > Cc: linux-f2fs-devel@...ts.sourceforge.net; linux-kernel@...r.kernel.org
> > Subject: Re: [PATCH] f2fs: fix to correct freed section number during gc
> > 
> > Hi Chao,
> > 
> > On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
> > > We pass 'nfree' to has_not_enough_free_secs to check whether there is
> > > enough free section, but 'nfree' indicates the number of segment gced,
> > > should alter the value to section number.
> > 
> > Yeah, but I think we need to increase nfree only when an entire section is gced
> > completely, since sometimes nfree can be increased across sections.
> 
> Agree, I will fix that.
> 
> Still have one question, for foreground gc, why would we give up retry writing
> out pages of last victim, but trying to select another victim for cleanup?
> Will new introduced method cause long latency for caller than before?

Hmm. Very occasionally, I've seen that gc goes into an infinite loop to clean up
one victim. In order to avoid that, I added giving up and then doing gc again.
I think there is no problem in normal cases. Even in an abnormal case, I expect
that next victim would be selected again because that should have lowest moving
cost.

> 
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/