From: Avi Kivity <avi@argo.co.il>
To: Daniel Walker <dwalker@mvista.com>
Cc: Ingo Molnar <mingo@elte.hu>, Johannes Stezenbach <js@linuxtv.org>,
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 11:09:16 +0200 [thread overview]
Message-ID: <43F592BC.9080606@argo.co.il> (raw)
In-Reply-To: <Pine.LNX.4.64.0602161055100.30911@dhcp153.mvista.com>
Daniel Walker wrote:
> On Thu, 16 Feb 2006, Ingo Molnar wrote:
>
>>
>> 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.
>
>
> I don't think this is a weakness in Dave or Inaky's versions. Dave
> at least maintained the bulk of the information in kernel space. The
> uaddr was used for the fast locking in userspace, but not for
> maintaining the robustness .
>
> Correct me if I'm wrong Dave.
In the general case of memory corruption, the data protected by the
robust futex might be corrupted, and no robust futex implementation can
protect against that, In fact it's a lot more likely since the
application code has pointers to the data but not to the robust list.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2006-02-17 9:09 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 [this message]
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=43F592BC.9080606@argo.co.il \
--to=avi@argo.co.il \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=drepper@redhat.com \
--cc=dsingleton@mvista.com \
--cc=dwalker@mvista.com \
--cc=js@linuxtv.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox