[lkml]   [2011]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Change in functionality of futex() system call.
    On Tue, Jun 7, 2011 at 5:26 PM, Kyle Moffett <> wrote:
    > On Tue, Jun 7, 2011 at 15:19, Andrew Lutomirski <> wrote:
    >> On Tue, Jun 7, 2011 at 3:10 PM, David Oliver <> wrote:
    >>> I have software which currently uses shared files for a one way
    >>> transfer of information, which is modeled precisely by the futex (as
    >>> contrasted to the mutex) model. In this case, the number of receivers
    >>> is undetermined, so the number of wakeups is set to maxint.
    >>> The receivers are minimally trusted: they have read access to the
    >>> files, so they cannot accidentally affect other processes use of the
    >>> data. Requiring my files to be writeable by all clients would require
    >>> a serious increase in the amount of software needing to be trusted.
    >> What's wrong with adding a FUTEX_WAIT_NOCONSUME flag then?  Your
    >> program can use it to get exactly the semantics it wants and my
    >> program can use it or not depending on which semantics it wants.
    >> Then we can document in the man page that, on kernels newer than
    >> whichever version introduced the regression, read-only mappings of a
    >> file cannot be used to interfere with futexes on that file.
    > Hmm, I would actually call it "FUTEX_POLL", since that better reflects the
    > operation being performed.
    > Certainly you would want to avoid allowing FUTEX_POLL to "steal"
    > limited wakeups from FUTEX_CMP_REQUEUE or whatever, so you
    > also need a new "FUTEX_NOTIFY".  Alternatively I guess you could just
    > special-case the FUTEX_WAKE && wakeups == INTMAX combination to
    > also notify FUTEX_POLL processes.
    > I almost wonder if long-term there might possibly be some decent way
    > to integrate this with eventfds to allow a thread to wait for notifications from
    > any number of memory addresses as well as other event sources.  This
    > would be a similar extension to signalfd, only for futexes.
    > Cheers,
    > Kyle Moffett

    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

    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.

    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.



    This email, along with any attachments, is confidential. If you
    believe you received this message in error, please contact the
    sender immediately and delete all copies of the message.
    Thank you.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-06-08 17:23    [W:0.024 / U:5.148 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site