[lkml]   [2003]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] Futex non-page-pinning fix

On Mon, 25 Aug 2003, Andrew Morton wrote:

> Two issues:
> a) what to do about futexes in file-backed pages? At present the
> attacker can pin arbitrary amount of memory by backing it with a file.
> Your solution won't scale to solving this, because we need to perform
> a futex lookup on every add_to_page_cache(). (Well, it will scale
> fairly well because add_to_page_cache() is ratelimited by the IO speed.
> But it will still suck quite a bit for some people).

add_to_page_cache() can be fairly high-frequency when the pagecache is
created anew (write) and torn down immediately afterwards (temporary
files). So i dont think it's 100% ratelimited by IO speed.

the cleanest thing would be to do the hashtable registration with every
futex existing in the system. But we might get away with doing it only for
FUTEX_FD 'asynchronous' futexes (which are only limited by the # of open
files, per process), and do the usual page pinning (and thus fast) thing
with the 'synchronous' futexes (which are limited to one per context, so
they are resource-limited automatically). As long as the hashtable is
empty, the lookup ought to be really fast.

> Or create RLIM_NRFUTEX.

futexes do have some small lowmem footprint nevertheless (they have a
queue entry structure, etc.), but much less than PAGE_SIZE. So basically
the overhead can be added to the already existing fd footprint, without
changing the balance too much.

but if all futexes pin down one page (worst-case), then to make it really
safe we'll have to use a fairly low default RLIM_NRFUTEX value - which
will decrease the generic utility of futexes.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.128 / U:1.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site