> 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/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:24 EST