From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Walker <dwalker@mvista.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 6/6] futex: fix miss ordered wakeups
Date: Wed, 25 Jun 2008 18:17:33 +0200 [thread overview]
Message-ID: <1214410654.24356.22.camel@lappy.programming.kicks-ass.net> (raw)
In-Reply-To: <1214407507.21035.32.camel@localhost.localdomain>
On Wed, 2008-06-25 at 08:25 -0700, Daniel Walker wrote:
> On Wed, 2008-06-25 at 17:07 +0200, Peter Zijlstra wrote:
> > On Wed, 2008-06-25 at 07:36 -0700, Daniel Walker wrote:
> > > On Wed, 2008-06-25 at 07:29 +0200, Peter Zijlstra wrote:
> > >
> > > > Daniel, I'm not sure what to think,.. you were told how broken this
> > > > approach was, you were told to give proper justification for this
> > > > change. You did neither and just reposted the same old broken shite
> > > > again.
> > >
> > > Broken approach ? Never heard that before,
> >
> > I suggest you re-read some of Thomas' emails from last time...
> >
> > http://lkml.org/lkml/2008/6/12/275
>
> Most of what he's saying there is that it breaks real time, and I
> provided a real time fix in this set of patches. I don't have a problem
> with the state mixing, since 99.9% of the time we're dealing operations
> that don't interact (and it's perfectly ok when they do interact).
You're not the maintainer, and you fail to respect their opinion - so
what makes you think your patches are going anywhere but /dev/null?
Also, the main point was about mixing user and kernel space state, you
still do so by including the futex waiter in the same union. That's a
fundamental fugly - no matter if you can make it work.
> > > in fact the problem is
> > > whether or not the changes are needed (not weather their broken).. I
> > > gave justification in the last thread, and I'm not sure why it's unclear
> > > to you..
> >
> > You failed to convince, also justification goes in the changelog, not in
> > random lkml threads.
>
> It boils down to POSIX compliance which was discussed in the last
> thread. POSIX requires the waiters to be sorts for 5-10 different API's
> which ultimately use the futex (most of which aren't at all related to
> PI).
I'm unconvinced, my reading of the spec doesn't say that at all. It says
its up to how things get scheduled.
Also, you have failed to say what real world use cases care about this
behaviour. This was asked multiple times - you never answered any of
those queries.
> And yes I can add it to the headers, before it goes up stream.
Don't bother, at this rate that will be never.
next prev parent reply other threads:[~2008-06-25 16:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 23:20 [PATCH 1/6] futex: checkpatch cleanup Daniel Walker
2008-06-24 23:20 ` [PATCH 2/6] futex: update prio on requeue Daniel Walker
2008-06-24 23:20 ` [PATCH 3/6] mutex debug: add generic blocked_on usage Daniel Walker
2008-06-24 23:20 ` [PATCH 4/6] rtmutex: " Daniel Walker
2008-06-24 23:20 ` [PATCH 5/6] -rt: nested rtmutex blocked_on Daniel Walker
2008-06-24 23:20 ` [PATCH 6/6] futex: fix miss ordered wakeups Daniel Walker
2008-06-25 5:29 ` Peter Zijlstra
2008-06-25 14:36 ` Daniel Walker
2008-06-25 15:07 ` Peter Zijlstra
2008-06-25 15:25 ` Daniel Walker
2008-06-25 16:17 ` Peter Zijlstra [this message]
2008-06-25 16:47 ` Daniel Walker
2008-06-25 19:06 ` Thomas Gleixner
2008-06-25 19:58 ` Daniel Walker
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=1214410654.24356.22.camel@lappy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.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.