All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@mvista.com>
To: Peter Zijlstra <peterz@infradead.org>
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 08:25:07 -0700	[thread overview]
Message-ID: <1214407507.21035.32.camel@localhost.localdomain> (raw)
In-Reply-To: <1214406451.24356.13.camel@lappy.programming.kicks-ass.net>


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).

> > 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).

And yes I can add it to the headers, before it goes up stream.

Daniel


  reply	other threads:[~2008-06-25 15:25 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 [this message]
2008-06-25 16:17           ` Peter Zijlstra
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=1214407507.21035.32.camel@localhost.localdomain \
    --to=dwalker@mvista.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.