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]

Message-ID: <dab34fd2-b494-8686-bcd7-68beeba4f386@gmail.com>
Date:   Thu, 3 Jun 2021 23:51:41 -0500
From:   Zebediah Figura <z.figura12@...il.com>
To:     André Almeida <andrealmeid@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     kernel@...labora.com, krisman@...labora.com,
        pgriffais@...vesoftware.com, joel@...lfernandes.org,
        malteskarupke@...tmail.fm, linux-api@...r.kernel.org,
        fweimer@...hat.com, libc-alpha@...rceware.org,
        linux-kselftest@...r.kernel.org, shuah@...nel.org, acme@...nel.org,
        corbet@....net, Peter Oskolkov <posk@...k.io>,
        Andrey Semashev <andrey.semashev@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [PATCH v4 00/15] Add futex2 syscalls

On 6/3/21 2:59 PM, André Almeida wrote:
>   ** The wait on multiple problem
> 
>   The use case lies in the Wine implementation of the Windows NT interface
>   WaitMultipleObjects. This Windows API function allows a thread to sleep
>   waiting on the first of a set of event sources (mutexes, timers, signal,
>   console input, etc) to signal.  Considering this is a primitive
>   synchronization operation for Windows applications, being able to quickly
>   signal events on the producer side, and quickly go to sleep on the
>   consumer side is essential for good performance of those running over Wine.
> 

I know this is part of the cover letter, but I really do want to clarify 
that this isn't really accurate. The use case that this is referring to 
is not "the Wine implementation of WaitForMultipleObjects", it is an 
out-of-tree implementation of WaitForMultipleObjects that provides 
improved performance compared to the in-tree implementation.

This is especially salient because:

(1) this out-of-tree implementation is only in a small handful of cases 
any more performant than a different out-of-tree implementation which 
uses eventfd and poll() instead;

(2) these implementations will remain out-of-tree due to compatibility 
and robustness problems;

(3) I believe there is potential for an upstreamable implementation 
which does not rely on futex or futex2.