All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Darren Hart <dvhltc@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Nick Piggin <npiggin@suse.de>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: futex: race in lock and unlock&exit for robust futex with PI?
Date: Mon, 28 Jun 2010 18:49:08 +0200	[thread overview]
Message-ID: <1277743748.3561.139.camel@laptop> (raw)
In-Reply-To: <20100628163952.GD24127@tiehlicka.suse.cz>

On Mon, 2010-06-28 at 18:39 +0200, Michal Hocko wrote:
> Would something like the following be acceptable (just a compile
> tested without comments). It simply makes caller of lookup_pi_state to
> decide whether credentials should be checked.

So it was Ingo, who in c87e2837be8 (pi-futex:
futex_lock_pi/futex_unlock_pi support) introduced the euid checks:

+futex_find_get_task():
+       if ((current->euid != p->euid) && (current->euid != p->uid)) {
+               p = NULL;
+               goto out_unlock;
+       }

Ingo, do you remember the rationale behind that? It seems to be causing
grief when two different users contend on the same (shared) futex.

See the below proposed solution.

> diff --git a/kernel/futex.c b/kernel/futex.c
> index e7a35f1..dfe4b11 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -426,7 +426,7 @@ static void free_pi_state(struct futex_pi_state *pi_state)
>   * Look up the task based on what TID userspace gave us.
>   * We dont trust it.
>   */
> -static struct task_struct * futex_find_get_task(pid_t pid)
> +static struct task_struct * futex_find_get_task(pid_t pid, bool check_cred)
>  {
>         struct task_struct *p;
>         const struct cred *cred = current_cred(), *pcred;
> @@ -436,10 +436,12 @@ static struct task_struct * futex_find_get_task(pid_t pid)
>         if (!p) {
>                 p = ERR_PTR(-ESRCH);
>         } else {
> -               pcred = __task_cred(p);
> -               if (cred->euid != pcred->euid &&
> -                   cred->euid != pcred->uid)
> -                       p = ERR_PTR(-ESRCH);
> +               if (check_cred) {
> +                       pcred = __task_cred(p);
> +                       if (cred->euid != pcred->euid &&
> +                           cred->euid != pcred->uid)
> +                               p = ERR_PTR(-ESRCH);
> +               }
>                 else
>                         get_task_struct(p);
>         }
> @@ -506,7 +508,7 @@ void exit_pi_state_list(struct task_struct *curr)
>  
>  static int
>  lookup_pi_state(u32 uval, struct futex_hash_bucket *hb,
> -               union futex_key *key, struct futex_pi_state **ps)
> +               union futex_key *key, struct futex_pi_state **ps, bool check_cred)
>  {
>         struct futex_pi_state *pi_state = NULL;
>         struct futex_q *this, *next;
> @@ -563,7 +565,7 @@ lookup_pi_state(u32 uval, struct futex_hash_bucket *hb,
>          */
>         if (!pid)
>                 return -ESRCH;
> -       p = futex_find_get_task(pid);
> +       p = futex_find_get_task(pid, check_cred);
>         if (IS_ERR(p))
>                 return PTR_ERR(p);
>  
> @@ -705,7 +707,7 @@ retry:
>          * We dont have the lock. Look up the PI state (or create it if
>          * we are the first waiter):
>          */
> -       ret = lookup_pi_state(uval, hb, key, ps);
> +       ret = lookup_pi_state(uval, hb, key, ps, false);
>  
>         if (unlikely(ret)) {
>                 switch (ret) {
> @@ -1258,7 +1260,7 @@ retry_private:
>                         ret = get_futex_value_locked(&curval2, uaddr2);
>                         if (!ret)
>                                 ret = lookup_pi_state(curval2, hb2, &key2,
> -                                                     &pi_state);
> +                                                     &pi_state, true);
>                 }
>  
>                 switch (ret) { 

  parent reply	other threads:[~2010-06-28 16:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-23  9:13 futex: race in lock and unlock&exit for robust futex with PI? Michal Hocko
2010-06-25  2:42 ` Darren Hart
2010-06-25  8:27   ` Michal Hocko
2010-06-25 17:53     ` Darren Hart
2010-06-25 23:35       ` Darren Hart
2010-06-28 14:42         ` Michal Hocko
2010-06-28 14:56           ` Darren Hart
2010-06-28 15:32           ` Michal Hocko
2010-06-28 15:40             ` Michal Hocko
2010-06-28 15:58             ` Michal Hocko
2010-06-28 16:39               ` Michal Hocko
2010-06-28 16:45                 ` Peter Zijlstra
2010-06-28 16:56                   ` Michal Hocko
2010-06-28 16:49                 ` Peter Zijlstra [this message]
2010-06-29  8:42                   ` [PATCH] futex: futex_find_get_task make credentials check conditional Michal Hocko
2010-06-29 14:56                     ` Darren Hart
2010-06-29 15:24                       ` Michal Hocko
2010-06-29 16:41                     ` Linus Torvalds
2010-06-29 16:58                       ` Darren Hart
2010-06-29 18:03                         ` Thomas Gleixner
2010-06-30  7:01                       ` Michal Hocko
2010-06-30  9:55                         ` [PATCH] futex: futex_find_get_task remove credentails check Michal Hocko
2010-06-30 16:43                           ` Darren Hart
2010-07-08  9:28                             ` Michal Hocko
2010-07-08  9:32                               ` Ingo Molnar
2010-07-08  9:39                                 ` Michal Hocko
2010-07-08  9:43                                   ` Peter Zijlstra
2010-07-08  9:50                                     ` Michal Hocko

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=1277743748.3561.139.camel@laptop \
    --to=peterz@infradead.org \
    --cc=dvhltc@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.