Re: [patch] futex API cleanups, futex-api-cleanup-2.5.69-A2

[Jamie Lokier]

Davide Libenzi wrote:
> > In message <[e-mail]> 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