lkml.org 
[lkml]   [2011]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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


    \
     
     \ /
      Last update: 2011-06-08 17:25    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site