From: Ingo Molnar <mingo@elte.hu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: [patch 3/4] pi-futex: Fix exit races and locking problems
Date: Fri, 8 Jun 2007 09:16:11 +0200 [thread overview]
Message-ID: <20070608071611.GB30226@elte.hu> (raw)
In-Reply-To: <20070607235801.558491000@linutronix.de>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>
> 1. New entries can be added to tsk->pi_state_list after task completed
> exit_pi_state_list(). The result is memory leakage and deadlocks.
>
> 2. handle_mm_fault() is called under spinlock. The result is obvious.
>
> 3. results in self-inflicted deadlock inside glibc.
> Sometimes futex_lock_pi returns -ESRCH, when it is not expected
> and glibc enters to for(;;) sleep() to simulate deadlock. This problem
> is quite obvious and I think the patch is right. Though it looks like
> each "if" in futex_lock_pi() got some stupid special case "else if". :-)
>
> 4. sometimes futex_lock_pi() returns -EDEADLK,
> when nobody has the lock. The reason is also obvious (see comment
> in the patch), but correct fix is far beyond my comprehension.
> I guess someone already saw this, the chunk:
>
> if (rt_mutex_trylock(&q.pi_state->pi_mutex))
> ret = 0;
>
> is obviously from the same opera. But it does not work, because the
> rtmutex is really taken at this point: wake_futex_pi() of previous
> owner reassigned it to us. My fix works. But it looks very stupid.
> I would think about removal of shift of ownership in wake_futex_pi()
> and making all the work in context of process taking lock.
>
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Fix 1) Avoid the tasklist lock variant of the exit race fix by adding
> an additional state transition to the exit code.
>
> This fixes also the issue, when a task with recursive segfaults
> is not able to release the futexes.
>
> Fix 2) Cleanup the lookup_pi_state() failure path and solve the -ESRCH
> problem finally.
>
> Fix 3) Solve the fixup_pi_state_owner() problem which needs to do the fixup
> in the lock protected section by using the in_atomic userspace access
> functions.
>
> This removes also the ugly lock drop / unqueue inside of fixup_pi_state()
>
> Fix 4) Fix a stale lock in the error path of futex_wake_pi()
>
> Added some error checks for verification.
>
> The -EDEADLK problem is solved by the rtmutex fixups.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
i've read the patch and it looks all good - but obviously testing will
tell us what's up, this stuff is ... complex.
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
next prev parent reply other threads:[~2007-06-08 7:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-08 0:29 [patch 0/4] PI-Futex bugfixes and cleanups Thomas Gleixner
2007-06-08 0:29 ` [patch 1/4] rt-mutex: Fix stale return value Thomas Gleixner
2007-06-08 7:20 ` Ingo Molnar
2007-06-08 0:29 ` [patch 2/4] rt-mutex: Fix chain walk early wakeup bug Thomas Gleixner
2007-06-08 7:18 ` Ingo Molnar
2007-06-08 0:29 ` [patch 3/4] pi-futex: Fix exit races and locking problems Thomas Gleixner
2007-06-08 7:16 ` Ingo Molnar [this message]
2007-06-08 0:29 ` [patch 4/4] FUTEX: Tidy up the code Thomas Gleixner
2007-06-08 7:10 ` 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=20070608071611.GB30226@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=drepper@redhat.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®