linux-kernel - Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

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] [day] [month] [year] [list]

Message-ID: <20160719054918.GB80986@jaegeuk>
Date:	Mon, 18 Jul 2016 22:49:18 -0700
From:	Jaegeuk Kim <jaegeuk@...nel.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

On Mon, Jul 18, 2016 at 08:59:52PM -0700, Christoph Hellwig wrote:
> On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote:
> > >From kernel guys working on android.
> 
> Well, until it's mainline it simply doesn't matter, so NAK to this
> patch.  Tying power behavior to plugs also sounds pretty broken, so we'd
> probably come up with something better if they bothered to actually
> submit their patches upsteam or at least explaining what they want
> to archive.

Actually, the initial patch which drops plugs is not mainlined as well.
So, at this time, I just want to revert it by this patch, since I recognized
that there might be whatever possible use-cases of plugs in another way someday.
So for now, I lost the reason to eliminate the plugs.

Moreover, since every filesystems use plugs, f2fs doesn't need to be an
exceptional case in terms of that (except hm-smr). So, let me sync f2fs
with other filesystems at this moment.

I totally agree that it'd be best to see their patches upstream, but I've
witnessed that it becomes a quite tough challenge to them.

Thanks,