All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/4] futex: get_user_pages_fast() for shared futexes
Date: Tue, 30 Sep 2008 12:55:58 +0200	[thread overview]
Message-ID: <48E205BE.8030908@cosmosbay.com> (raw)
In-Reply-To: <1222764669.12646.26.camel@twins.programming.kicks-ass.net>

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;
>  	}
>  
> 
> 
> 





WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/4] futex: get_user_pages_fast() for shared futexes
Date: Tue, 30 Sep 2008 12:55:58 +0200	[thread overview]
Message-ID: <48E205BE.8030908@cosmosbay.com> (raw)
In-Reply-To: <1222764669.12646.26.camel@twins.programming.kicks-ass.net>

Peter Zijlstra a ecrit :
> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-09-30 10:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-26 17:32 [PATCH 0/4] futex: get_user_pages_fast() for shared futexes Peter Zijlstra
2008-09-26 17:32 ` Peter Zijlstra
2008-09-26 17:32 ` [PATCH 1/4] futex: rely on get_user_pages() " Peter Zijlstra
2008-09-26 17:32   ` Peter Zijlstra
2008-09-26 17:32 ` [PATCH 2/4] futex: reduce mmap_sem usage Peter Zijlstra
2008-09-26 17:32   ` Peter Zijlstra
2008-09-26 17:32 ` [PATCH 3/4] futex: use fast_gup() Peter Zijlstra
2008-09-26 17:32   ` Peter Zijlstra
2008-09-26 17:32 ` [PATCH 4/4] futex: cleanup fshared Peter Zijlstra
2008-09-26 17:32   ` Peter Zijlstra
2008-09-27 16:17 ` [PATCH 0/4] futex: get_user_pages_fast() for shared futexes Ingo Molnar
2008-09-27 16:17   ` Ingo Molnar
2008-09-30  7:21   ` Nick Piggin
2008-09-30  7:21     ` Nick Piggin
2008-09-30  8:51     ` Peter Zijlstra
2008-09-30  8:51       ` Peter Zijlstra
2008-09-30 10:39       ` Ingo Molnar
2008-09-30 10:39         ` Ingo Molnar
2008-09-30 10:42       ` Nick Piggin
2008-09-30 10:42         ` Nick Piggin
2008-09-30 10:55       ` Eric Dumazet [this message]
2008-09-30 10:55         ` Eric Dumazet
2008-09-30 11:16         ` Peter Zijlstra
2008-09-30 11:16           ` Peter Zijlstra
2008-10-01  3:13         ` Ulrich Drepper
2008-10-01  3:13           ` Ulrich Drepper
2008-09-30 10:39     ` Ingo Molnar
2008-09-30 10:39       ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48E205BE.8030908@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.