Re: [RFC] [PATCH] drop_pagecache syscall

On Wed, Apr 27, 2011 at 05:57, Andrea Righi wrote:

On Wed, Apr 27, 2011 at 05:50:04AM -0400, Mike Frysinger wrote:

quoted

On Wed, Apr 27, 2011 at 05:47, Andrea Righi wrote:

quoted

On Wed, Apr 27, 2011 at 05:10:41AM -0400, Mike Frysinger wrote:

quoted

On Wed, Apr 27, 2011 at 05:01, Andrea Righi wrote:

quoted

On Wed, Apr 27, 2011 at 10:14:53AM +1000, Dave Chinner wrote:

quoted

On Tue, Apr 26, 2011 at 11:35:27PM +0200, Andrea Righi wrote:

quoted

This functionality can be used by all the applications that want to have a
better control over the page cache management (for example to immediately drop
pages that for sure will not be reused in the near future, without calling
posix_fadvise() for all the files they've touched), or to provide a more fine
grained debugging feature usable by the filesystem benchmarks.

The system call does not require root privileges and it can be called by any
unprivileged application. For example, we can write a userspace tool to run
something like this:

  $ drop-pagecache /path/file_or_dir

That's a potential DOS vector, I think. Drop the pagecache in a hard
loop on the root fs of a busy server and watch it crawl...

Yes, probably we could allow only the CAP_SYS_ADMIN tasks to execute
this syscall.

if /proc/sys/vm/drop_caches has any checks other than file permission
checks (i.e. UID==0), it'd probably be better to copy those rather
than picking something different.

ok, what about checking current_euid() == 0?

that's not what i meant.  if the drop_caches file already has certain
cap checks/whatever in place, let's use those.  if it doesnt, then
picking a cap level as you proposed makes sense.

mmh, drop_caches has a file ownership (root:root) and a permission mask
(0644), how to apply the same checks to a system call? The most similar
thing seems to check the current euid. Am I missing something?

my (limited) understanding is that you should be using cap checks, not UID
-mike