linux-kernel - Re: [PATCH v6 0/7] vfs: Non-blockling buffered fs read (page cache only)

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: <20141202144200.a4ca81a46a43563a8874fd8e@linux-foundation.org>
Date:	Tue, 2 Dec 2014 14:42:00 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Milosz Tanski <milosz@...in.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-aio@...ck.org" <linux-aio@...ck.org>,
	Mel Gorman <mgorman@...e.de>,
	Volker Lendecke <Volker.Lendecke@...net.de>,
	Tejun Heo <tj@...nel.org>, Jeff Moyer <jmoyer@...hat.com>,
	"Theodore Ts'o" <tytso@....edu>, Al Viro <viro@...iv.linux.org.uk>,
	Linux API <linux-api@...r.kernel.org>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH v6 0/7] vfs: Non-blockling buffered fs read (page cache
 only)

On Tue, 2 Dec 2014 17:17:42 -0500 Milosz Tanski <milosz@...in.com> wrote:

> > There have been several incomplete attempts to implement fincore().  If
> > we were to complete those attempts, preadv2() could be implemented
> > using fincore()+pread().  Plus we get fincore(), which is useful for
> > other (but probably similar) reasons.  Probably fincore()+pwrite() could
> > be used to implement pwritev2(), but I don't know what pwritev2() does
> > yet.
> >
> > Implementing fincore() is more flexible, requires less code and is less
> > likely to have bugs.  So why not go that way?  Yes, it's more CPU
> > intensive, but how much?  Is the difference sufficient to justify the
> > preadv2()/pwritev2() approach?
> 
> I would like to see a fincore() functionality (for other reasons) I
> don't think it does the job here. fincore() + preadv() is inherently
> racy as there's no guarantee that the data becomes uncached between
> the two calls.

There will always be holes.  For example find_get_page() could block on
lock_page() while some other process is doing IO. 
page_cache_async_readahead() does lots of memory allocation which can
get blocked for long periods in the page allocator. 
page_cache_async_readahead() can block on synchronous metadata reads,
etc.

The question is whether a simpler approach such as fincore() will be
sufficient.

> This may not matter in some cases, but in others (ones
> that I'm trying to solve) it will introduce unexpected latency.

Details?

> There's no overlap between prwritev2 and fincore() functionality.

Do we actually need pwritev2()?  What's the justification for that?


Please let's examine the alternative(s) seriously.  It would be mistake
to add preadv2/pwritev2 if fincore+pread would have sufficed.  

--
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/