linux-kernel - Re: [PATCH v3] fadvise: introduce POSIX_FADV_DONTNEED

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] [day] [month] [year] [list]

Message-Id: <201105021357.10560.arnd@arndb.de>
Date:	Mon, 2 May 2011 13:57:10 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Andrea Righi <andrea@...terlinux.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Chinner <david@...morbit.com>,
	Mike Frysinger <vapier@...too.org>,
	Matthew Wilcox <matthew@....cx>,
	Al Viro <viro@...iv.linux.org.uk>,
	Joel Becker <jlbec@...lplan.org>,
	linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] fadvise: introduce POSIX_FADV_DONTNEED_FS

On Friday 29 April 2011, Andrea Righi wrote:
> NOTE #1: to avoid potential DoS in the system the rate of calls to
> fadvise(POSIX_FADV_DONTNEED_FS) from non-privileged users are limited
> according to these settings:
> 
>  - /proc/sys/vm/drop_pagecache_ratelimit: the minimum length of time
>    allowed beetween two different bursts of fadvise(POSIX_FADV_DONTNEED_FS)
> 
>  - /proc/sys/vm/drop_pagecache_ratelimit_burst: the number of calls to
>    fadvise(POSIX_FADV_DONTNEED_FS) that can be issued before enforcing
>    the rate limiting

The ratelimiting interface does not give me the happy feeling I had with
the original extremely syscall and fadvise, or with strictly limiting it
to certain capabilities. The ratelimit bursts seem well suited for log
messages, but it's not like you would expect anyone to read the fadvise
man page describing these and think "oh, of course, that's obviously
why it has to be done this way".

I don't have a perfect solution myself, but there are a few things
that feel wrong about yours:

* The rules for /proc/sys/vm/drop_caches and the fadvise are different
* You need to tune two variables to set one thing
* The rate limit is independent of the number of file systems you
  operate on: When you have mounted 20 file systems, you need to
  sleep for five seconds after flushing half of them, but you can
  flush one ten times in a row without being throttled.
* Returning an error gives no feedback about how soon it can
  be retried, in case you really need to flush.

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