linux-kernel - Re: [PATCH 6/6] futex: fix miss ordered wakeups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jun 2008 18:17:33 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/6] futex: fix miss ordered wakeups

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/