lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/4] futex: get_user_pages_fast() for shared futexes
    Peter Zijlstra a écrit :
    > Just to be sure, I only hold the page lock over the get_futex_key() op,
    > and drop it after getting a ref on the futex key.
    >
    > I then drop the futex key ref after the futex op is complete.
    >
    > This assumes the futex key ref is suffucient to guarantee whatever is
    > needed - which is the point I'm still not quite sure about myself.
    >
    > The futex key ref was used between futex ops, with I assume the intent
    > to ensure the futex backing stays valid. However, the key ref only takes
    > a ref on either the inode or the mm, neither which avoid the specific
    > address of the futex to get unmapped between ops.
    >
    > So in that respect we're not worse off than before, and any application
    > doing: futex_wait(), munmap(), futex_wake() is going to suffer. And as
    > far as I understand it get the waiting task stuck in D state for
    > ever-more or somesuch.
    >
    > By now not holding the mmap_sem over the full futex op, but only over
    > the get_futex_key(), that munmap() race gets larger and the actual futex
    > could disappear while we're working on it, but in all cases I looked at
    > that will make the futex op return -EFAULT, so we should be good there.
    >
    > Gah, now that I look at it, it looks like I made get_futex_key()
    > asymetric wrt private futexes, they don't take a ref on the key, but
    > then do drop one... ouch.. Patch below.
    >
    >> Nice work, Peter.
    >
    > Thanks!
    >
    >> BTW. what kinds of things use inter-process futexes as of now?
    >
    > On a regular modern Linux system, not much. But I've been told there are
    > applications out there that do indeed make heavy use of them - as
    > they're part of POSIX etc.. blah blah :-)

    inter-process futexes are still used for pthread creation/join
    (aka clear_child_tid / CLONE_CHILD_CLEARTID)

    kernel/fork.c, functions mm_release() & sys_set_tid_address()

    I am not sure how it could be converted to private futexes, since
    old binaries (static glibc) will use FUTEX_WAKE like calls.

    >
    > Also some legacy stuff that's stuck on an ancient glibc (but somehow did
    > manage to upgrade the kernel) might benefit.
    >
    >
    > ---
    > Subject: futex: fixup get_futex_key() for private futexes
    > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
    >
    > With the get_user_pages_fast() patches we made get_futex_key() obtain a
    > reference on the returned key, but failed to do so for private futexes.
    >

    Sorry I am lost...
    private futexes dont need to get references at all...

    > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    > ---
    > diff --git a/kernel/futex.c b/kernel/futex.c
    > index 197fdab..beee9af 100644
    > --- a/kernel/futex.c
    > +++ b/kernel/futex.c
    > @@ -227,6 +227,7 @@ static int get_futex_key(u32 __user *uaddr, int
    > fshared, union futex_key *key)
    > return -EFAULT;
    > key->private.mm = mm;
    > key->private.address = address;
    > + get_futex_key_refs(key);
    > return 0;
    > }
    >
    >
    >
    >




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2008-09-30 12:59    [W:0.024 / U:96.688 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site