From: Daniel Walker <dwalker@mvista.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ulrich Drepper <drepper@gmail.com>,
Arjan van de Ven <arjan@infradead.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 5/5] futex: fix miss ordered wakeups
Date: Thu, 12 Jun 2008 08:56:33 -0700 [thread overview]
Message-ID: <1213286193.16459.53.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.1.10.0806121636380.3193@apollo.tec.linutronix.de>
On Thu, 2008-06-12 at 17:24 +0200, Thomas Gleixner wrote:
> > Just because you don't use it, doesn't make it useless .. At least
> > there's enough people asking for this that it warrants me writing it..
>
> Which is not really a good technical reason to merge such a
> patch. Your handwaving about "enough people" is just irrelevant. Are
> you going to implement a root hole as well when enough people ask for
> it ?
People asking for something is a very good reason to merge "features" ..
You can like or dislike implementations , but that doesn't reflect on
the nature of the feature.
> But there is also a Real Good technical reason why these patches are
> going nowhere else than into /dev/null:
>
> your approach of hijacking blocked_on is fundamentaly wrong as it
> mixes kernel internal state with user space state.
It mixes kernel state with kernel state, not to mention each state is
isolated from the others.
> It will break in preempt-rt at the point when this state is set and
> the code blocks on a spinlock, which uses the rtmutex based sleeping
> spinlock implementation and overwrites blocked_on.
That's an intersting point, however "preempt-rt" is out of tree, so it's
certainly not going be a reason to reject mainline changes.
> If there would be a real good technical reason to fix this priority
> ordering it could be done with less than 20 lines of code without
> extra locking and wreckage waiting left and right, but I have not yet
> seen a single convincing technical argument or a relevant use case
> which might justify that.
The technical reasons for including this are the same technical reasons
why we want the waiters queued in priority order .. It's a requirement
of posix, where many calls need the ordering and ultimately feed into
the futex interface. So we have every reason to do the ordering
correctly..
If you have a 20 line fix for this then great tell me what it is..
Daniel
next prev parent reply other threads:[~2008-06-12 15:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 20:49 [PATCH 1/5] futex: checkpatch cleanup Daniel Walker
2008-06-11 20:49 ` [PATCH 2/5] futex: update prio on requeue Daniel Walker
2008-06-12 5:22 ` Peter Zijlstra
2008-06-11 20:49 ` [PATCH 3/5] mutex debug: add generic blocked_on usage Daniel Walker
2008-06-12 5:25 ` Peter Zijlstra
2008-06-12 13:21 ` Daniel Walker
2008-06-11 20:49 ` [PATCH 4/5] rtmutex: " Daniel Walker
2008-06-11 20:49 ` [PATCH 5/5] futex: fix miss ordered wakeups Daniel Walker
2008-06-12 6:07 ` Peter Zijlstra
2008-06-12 13:22 ` Daniel Walker
2008-06-12 13:57 ` Peter Zijlstra
2008-06-12 14:04 ` Daniel Walker
2008-06-12 8:56 ` Thomas Gleixner
2008-06-12 13:30 ` Daniel Walker
2008-06-12 13:33 ` Thomas Gleixner
2008-06-12 13:44 ` Daniel Walker
2008-06-12 15:24 ` Thomas Gleixner
2008-06-12 15:56 ` Daniel Walker [this message]
2008-06-12 19:55 ` Thomas Gleixner
2008-06-12 22:09 ` Daniel Walker
2008-06-12 22:43 ` Thomas Gleixner
2008-06-12 23:06 ` Daniel Walker
2008-06-12 23:30 ` Thomas Gleixner
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=1213286193.16459.53.camel@localhost.localdomain \
--to=dwalker@mvista.com \
--cc=arjan@infradead.org \
--cc=drepper@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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 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.