Re: [RFC] [PATCH] drop_pagecache syscall

2 messages, 2 authors, 2011-04-27 · open the first message on its own page

Re: [RFC] [PATCH] drop_pagecache syscall

From: Andrea Righi <hidden>
Date: 2011-04-27 09:47:17

On Wed, Apr 27, 2011 at 05:10:41AM -0400, Mike Frysinger wrote:
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?

Thanks,
-Andrea

Re: [RFC] [PATCH] drop_pagecache syscall

From: Mike Frysinger <hidden>
Date: 2011-04-27 09:50:04

On Wed, Apr 27, 2011 at 05:47, Andrea Righi wrote:
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.
-mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help