All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@linuxtv.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Ulrich Drepper <drepper@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@infradead.org>,
	David Singleton <dsingleton@mvista.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [patch 0/5] lightweight robust futexes: -V1
Date: Thu, 16 Feb 2006 15:58:23 +0100	[thread overview]
Message-ID: <20060216145823.GA25759@linuxtv.org> (raw)
In-Reply-To: <20060215151711.GA31569@elte.hu>

On Wed, Feb 15, 2006, Ingo Molnar wrote:
> "Robustness" is about dealing with crashes while holding a lock: if a 
> process exits prematurely while holding a pthread_mutex_t lock that is 
> also shared with some other process (e.g. yum segfaults while holding a 
> pthread_mutex_t, or yum is kill -9-ed), then waiters for that lock need 
> to be notified that the last owner of the lock exited in some irregular 
> way.
...
> At the heart of this new approach there is a per-thread private list of 
> robust locks that userspace is holding (maintained by glibc) - which 
> userspace list is registered with the kernel via a new syscall [this 
> registration happens at most once per thread lifetime]. At do_exit() 
> time, the kernel checks this user-space list: are there any robust futex 
> locks to be cleaned up?
...
> i've tested the new syscalls on x86 and x86_64, and have made sure the 
> parsing of the userspace list is robust [ ;-) ] even if the list is 
> deliberately corrupted.

I've no knowledge about all this, and maybe I didn't get your
description, so forgive me if I'm talking garbage.

Anyway: If a process can trash its robust futext list and then
die with a segfault, why are the futexes still robust?
In this case the kernel has no way to wake up waiters with
FUTEX_OWNER_DEAD, or does it?


Johannes

  parent reply	other threads:[~2006-02-16 14:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-15 15:17 [patch 0/5] lightweight robust futexes: -V1 Ingo Molnar
2006-02-15 15:22 ` Ingo Molnar
2006-02-15 17:35 ` Andi Kleen
2006-02-15 17:50   ` Ulrich Drepper
2006-02-15 18:42     ` Andi Kleen
2006-02-15 19:49       ` Christopher Friesen
2006-02-15 20:02         ` Andi Kleen
2006-02-15 20:13           ` Antonio Vargas
2006-02-15 20:25             ` Andi Kleen
2006-02-15 20:59           ` Ingo Molnar
2006-02-15 20:43       ` Ingo Molnar
2006-02-15 19:05 ` Daniel Walker
2006-02-15 19:11   ` Arjan van de Ven
2006-02-15 19:13     ` Daniel Walker
2006-02-15 21:31   ` Ingo Molnar
2006-02-16 15:43     ` Daniel Walker
2006-02-15 21:45 ` Andrew Morton
2006-02-15 22:14   ` Ingo Molnar
2006-02-17 21:59     ` Daniel Jacobowitz
2006-02-16  3:57 ` Darren Hart
2006-02-16 14:58 ` Johannes Stezenbach [this message]
2006-02-16 17:20   ` Ingo Molnar
2006-02-16 19:04     ` Daniel Walker
2006-02-17  9:09       ` Avi Kivity
2006-02-17 19:55     ` Johannes Stezenbach
2006-02-17 20:02       ` Arjan van de Ven

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=20060216145823.GA25759@linuxtv.org \
    --to=js@linuxtv.org \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=drepper@redhat.com \
    --cc=dsingleton@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.