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]
Date:	Wed, 02 Mar 2016 10:15:02 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	axboe@...nel.dk, hch@...radead.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, martin.petersen@...cle.com,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	shane.seymour@....com, bfields@...ldses.org,
	linux-fsdevel@...r.kernel.org, jlayton@...chiereds.net
Subject: Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache

On Tuesday 01 March 2016 20:09:32 Darrick J. Wong wrote:
> This is (yet another) repost of the patch series that fixes the
> existing BLKZEROOUT ioctl to invalidate the page cache if the zeroing
> command to the underlying device succeeds.  This patch is against
> 4.5-rc6 and hasn't changed much in months.
> 
> The new BLKZEROOUT ioctl has the same semantics as the old one, but it
> invalidates the page cache to prevent surprising results, just like
> how dio writes invalidate page cache.
> 
> I've incorporated all the feedback I've received into these patches,
> but haven't heard yea or nay or anything at all from the maintainer.
> Will someone please pick this up for 4.6?
> 
> Comments and questions are, as always, welcome.

I'm missing the background on this, just saw the patch fly by,
so sorry if this has been asked before:

Why do you want to invalidate the cache? Is this to save RAM
or is something else going to write here and you have to invalidate
it for correctness?

If you just want to save RAM, would it be possible to instead
point the page cache to the empty zero page to speed up subsequent
reads? Maybe that just causes more complexity than it helps.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ