linux-kernel - Re: userspace pagecache management tool

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:	Sat, 3 Mar 2007 15:56:01 -0700
From:	Erik Andersen <andersen@...epoet.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Rik van Riel <riel@...hat.com>,
	bert hubert <bert.hubert@...herlabs.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: userspace pagecache management tool

On Sat Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote:
> On Sat, 03 Mar 2007 17:19:00 -0500 Rik van Riel <riel@...hat.com> wrote:
> 
> > > It is *not* a global instruction.  It uses setenv, so the user's policy
> > > affects only the target process and its forked children.
> > 
> > ... and all other processes accessing the same file(s)!
> > 
> > Your library and the system calls may be limited to one process,
> > but the consequences are global.
> 
> Yes.  So what?  If the user wants to go and evict libc.so from pagecache
> then he can do so - the kernel has provided syscalls with which this can be
> done for at least seven years.  Bad user, shouldn't do that.

I think what Rik is pointing out is that as currently
implemented, posix_fadvise is a much bigger hammer than is
generally useful or desirable.

Using posix_fadvise on the other hand says "immediately drop this
stuff from the pagecache, consequences be damned".  If someone
else happens to be using the specified data, well too bad, they
suffer collateral damage.  Process A can, maliciously or
ignorantly, deny service to process B.

On the other hand, your old but super cool O_STREAMING patch took
a kinder gentler approach, where applications could tell the
kernel "please do not keep this file descriptor's data in cache
on my account since I will not reuse it." If someone else however
was using the same data, the kernel would keep things cached as
usual and thereby avoid doing collateral damage.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
-
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/