linux-kernel - Re: [PATCH v4 00/15] Add futex2 syscalls

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:   Tue, 8 Jun 2021 16:18:42 +0300
From:   Andrey Semashev <andrey.semashev@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Nicholas Piggin <npiggin@...il.com>,
        André Almeida <andrealmeid@...labora.com>,
        acme@...nel.org, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        corbet@....net, Davidlohr Bueso <dave@...olabs.net>,
        Darren Hart <dvhart@...radead.org>, fweimer@...hat.com,
        joel@...lfernandes.org, kernel@...labora.com,
        krisman@...labora.com, libc-alpha@...rceware.org,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, malteskarupke@...tmail.fm,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        pgriffais@...vesoftware.com, Peter Oskolkov <posk@...k.io>,
        Steven Rostedt <rostedt@...dmis.org>, shuah@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>, z.figura12@...il.com
Subject: Re: [PATCH v4 00/15] Add futex2 syscalls

On 6/8/21 3:35 PM, Greg KH wrote:
> On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
>> On 6/8/21 2:13 PM, Greg KH wrote:
> 
>>> So what's keeping the futex2 code from doing all that futex1 does so
>>> that the futex1 code can be deleted internally?
>>
>> I think, André will answer this, but my guess is, as stated above, this is a
>> lot of work and time while the intermediate version is already useful.
> 
> useful to who?  I still do not understand what users will be needing
> this.  All I can tell is a single userspace program wants to use it, and
> that is a fork from the real project it was based on and that the
> maintainers have no plan to merge it back.
> 
> So who does need/want this?

I mentioned C++ std::atomic and Boost.Atomic before. Those need variable 
sized futexes.

The project you mention is probably Wine and its derivatives. Those need 
variable sized futexes and "wait for multiple" operation. I'm not sure 
about the "no plan to merge it back" part, I probably missed it in an 
earlier discussion. There are multiple different patches and versions 
out there, and I don't know which one it refers to. But WaitOnAddress 
and WaitForMultipleObjects APIs are very important and I would assume 
Wine wants to emulate those with best efficiency.

I have a media processing engine application that needs 64-bit futexes 
would benefit from a "wait for multiple" function. Its source code is 
not open currently, so I'm not sure if you can count it as a valid user.

There is a generic std::lock algorithm in C++ and an equivalent in 
Boost.Thread that is supposed to lock multiple lockables (a mutex-like 
object). Those could benefit from the "wait for multiple" function in 
some cases, e.g. when the objects are actually futex-based mutexes, and 
the function can access the internal futex. I'm not saying this will 
definitely be implemented, it just looks like a possible optimization to me.

I think someone mentioned databases earlier in the discussion, but I 
don't know the details. I hope someone will be able to expand.