Messages in this thread |  | | | Date | Tue, 20 May 2003 02:44:03 +0100 | | From | Jamie Lokier <> | | Subject | Re: [patch] futex API cleanups, futex-api-cleanup-2.5.69-A2 |
| |
Davide Libenzi wrote: > > In message <20030519233353.GD13706@mail.jlokier.co.uk> you write: > > > Ingo Molnar wrote: > > > > FUTEX_FD is an instant DoS, it allows the pinning of one page per file > > > > descriptor, per thread. With a default limit of 1024 open files per > > > > thread, and 256 threads (on a sane/conservative setup), this means 1 GB of > > > > RAM can be pinned down by a normal unprivileged user. > > > > > > The correct solution [;)] is EP_FUTEX - allow a futex to be specified > > > as the source of an epoll event. > > Futexes do support f_op->poll(), isn't it Rusty ? If so, they're supported > by epoll ...
Yes, they do and it should work (I haven't tried, though).
There is a practical problem when waiting on a futex in multiple threads using epoll: you need a separate fd per waiter, rather than an fd per waited-on futex. This is because some uses of futexes depend on waiters being woken in the exact order that they were queued.
To get this ordering, every waiter must allocate its own fd. The only practical way to do this is allocate the fd just prior to waiting, and release it afterwards.
As you can imagine, with many threads this implies a lot of fds, which are in limited supply, and a high rate of allocation and deallocation, which may be relatively slow.
-- Jamie - 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/
|  |