Messages in this thread |  | | | From | Andrew Lutomirski <> | | Date | Wed, 8 Jun 2011 11:21:58 -0400 | | Subject | Re: Change in functionality of futex() system call. |
| |
On Wed, Jun 8, 2011 at 11:20 AM, David Oliver <david@rgmadvisors.com> wrote: > > Having a new call is inelegant from a futex(2) user perspective, as > the need for a change is due to the kernel implementation and/or mutex > requirements. The futex() system call, as documented, is ideal for a > single producer to signal multiple receivers of state updates. > > If it is truly necessary to add new variants to futex() to protect > applications that allow untrusted applications read access to their > mutexes, I would avoid both the names suggested, as consumption of > wakeups is not an obvious issue to users, and POLL suggests waiting > for multiple entities as in poll(2) (which is not provided), or > returning immediately (which is orthogonally provided by the timeout > parameter). What is being provided from the user point of view is a > FUTEX_WAIT per the man page, which doesn't require write access. How > about FUTEX_WAIT_RDONLY?
That name sounds good.
> > Alternatively, use the current call and document that when process > performing a FUTEX_WAIT on read-only memory are woken, they do not > count towards the number reported as being woken.
I don't see anything wrong with that, either.
> > Best, IMHO, would be to document that providing read access to mutexes > to untrusted software is unsafe behavior, and restore read only access > to readers of futexes.
I think it should be safe, and it would be easy to make it be safe (i.e. make no changes at all).
--Andy
|  |