linux-kernel - Re: [RFC patch 4/7] futex: Add support for attached futexes

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]

Message-ID: <CALCETrVGbvdmY9wj=Ooj=gr81PV0O9F7T0LLy2sGf19x_1aKug@mail.gmail.com>
Date:	Sun, 3 Apr 2016 09:11:43 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andy Lutomirski <luto@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Darren Hart <darren@...art.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Davidlohr Bueso <dave@...olabs.net>, Chris Mason <clm@...com>,
	"Carlos O'Donell" <carlos@...hat.com>,
	Torvald Riegel <triegel@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes

On Sun, Apr 3, 2016 at 8:56 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Sun, 3 Apr 2016, Andy Lutomirski wrote:
>
>> On Sun, Apr 3, 2016 at 2:57 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> > On Sat, 2 Apr 2016, Andy Lutomirski wrote:
>> >
>> >> On 04/02/2016 04:09 AM, Thomas Gleixner wrote:
>> >> [omitted due to some Thunderbird bug, sigh]
>> >>
>> >> What happens if you mix attached an non-attached ops on the same futex?
>> >
>> > Not much. You might get an error code, sleep forever or the call will just
>> > result in a NOP wasting cpu cycles. That's the same when you mix
>> > shared/private operations on the same futex.
>>
>> What's the workflow?
>>
>> Can the creation of an attached futex fail due to memory allocation
>> problems or any other reason?  If so, how does a library make sure it
>> falls back to a normal futex safely?
>
> Well, other operations on futexes can fail as well and the library or the
> usage site has to take care of it. It's not that different.
>
>> Why can't private futexes be attached by default?
>
> We _can_ attach any futex - private or not - by default.

Then I feel like I'm missing something.  Why does this need an API
change?  Why can't the kernel just attach all futexes?

The reason I'm asking about failures is this:

int some_futex;

Thread 1:
   attach some_futex;
   ...
   wait for some_futex;

Thread 2:
   attach some_futex;
   ...
   wake some_futex;

If one but not both of the attach operations fails and the other
doesn't, then either the thread that failed to attach can't operate on
the futex or, if it tries to fall back to a normal futex, then the
wake won't wake the waiter, right?  This seems fragile.

--Andy