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: Fri, 17 Feb 2006 20:55:15 +0100	[thread overview]
Message-ID: <20060217195515.GA12501@linuxtv.org> (raw)
In-Reply-To: <20060216172007.GB29151@elte.hu>

On Thu, Feb 16, 2006, Ingo Molnar wrote:
> 
> * Johannes Stezenbach <js@linuxtv.org> wrote:
> 
> > 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?
> 
> that's memory corruption - which robust futexes do not (and cannot) 
> solve. Robustness is mostly about handling sudden death (e.g. which is 
> due to oom, or is due to a user killing the task, or due to the 
> application crashing in some non-memory-corrupting way), but it cannot 
> handle all possible failure modes.

Hm, OK, from reading this and the other threads on this
topic I get:

- there is a tradeoff between speed and robustness
- the focus for "robust futexes" is on speed
  (else they wouldn't deserve to be called futexes)
- thus it is acceptable if they are just 99% robust

That's OK, but IMHO it wouldn't hurt to clearly spell
it out in the documentation.


However, this leaves the question: Is there a slower, but 100% robust
alternative on Linux for applications which need it?


Johannes

  parent reply	other threads:[~2006-02-17 19:55 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
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 [this message]
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=20060217195515.GA12501@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.