lkml.org 
[lkml]   [2011]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Change in functionality of futex() system call.


    On 06/08/2011 08:20 AM, David Oliver wrote:
    > On Tue, Jun 7, 2011 at 5:26 PM, Kyle Moffett <kyle@moffetthome.net> wrote:
    >> On Tue, Jun 7, 2011 at 15:19, Andrew Lutomirski <luto@mit.edu> wrote:
    >>> On Tue, Jun 7, 2011 at 3:10 PM, David Oliver <david@rgmadvisors.com> 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
    > about FUTEX_WAIT_RDONLY?
    >
    > 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.

    I'm inclined to agree with this approach.

    --
    Darren Hart
    Intel Open Source Technology Center
    Yocto Project - Linux Kernel


    \
     
     \ /
      Last update: 2011-06-08 18:23    [from the cache]
    ©2003-2011 Jasper Spaans