lkml.org 
[lkml]   [2002]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRE: Users locking memory using futexes
Date

> Perez-Gonzalez, Inaky wrote:
> > [...] each time you lock a futex you are pinning the containing page
> > into physical memory, that would cause that if you have, for
> > example, 4000 futexes locked in 4000 different pages, there is going
> > to be 4 MB of memory locked in [...]
>
> Ouch! It looks to me like userspace can use FUTEX_FD to lock many
> pages of memory, achieving the same as mlock() but without the
> resource checks.

This raises a good point - I guess we should be doing something like
checking user limits (against locked memory, 'ulimit -l'). Something along
the lines of this [warning, dirty-fastly-scratched-draft, untested]:

diff -u futex.c.orig futex.c
--- futex.c.orig 2002-11-11 20:06:22.000000000 -0800
+++ futex.c 2002-11-11 20:08:48.000000000 -0800
@@ -261,8 +261,12 @@
struct page *page;
struct futex_q q;

+ if (current->mm->total_vm + 1 >
+ (current->rlim[RLIMIT_MEMLOCK].rlim_cur >> PAGE_SHIFT))
+ return -ENOMEM;
+
init_waitqueue_head(&q.waiters);
-
+
lock_futex_mm();

page = __pin_page(uaddr - offset);
@@ -358,6 +362,11 @@
if (signal < 0 || signal > _NSIG)
goto out;

+ ret = -ENOMEM;
+ if (current->mm->total_vm + 1 >
+ (current->rlim[RLIMIT_MEMLOCK].rlim_cur >> PAGE_SHIFT))
+ goto out;
+
ret = get_unused_fd();
if (ret < 0)
goto out;
However, we could break the semantics of other programs that expect that the
amount of memory they lock is the only one that is used in the rlimit ...

What else could be done?

Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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