linux-kernel - Re: [PATCH 7/7] io_uring: add futex waitv

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] [day] [month] [year] [list]

Message-ID: <0ffd2e2f-a179-393b-bd0d-cd62a41ecb92@kernel.dk>
Date:   Wed, 12 Jul 2023 09:10:22 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     io-uring@...r.kernel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH 7/7] io_uring: add futex waitv

On 7/12/23 3:31?AM, Peter Zijlstra wrote:
> On Tue, Jul 11, 2023 at 06:47:05PM -0600, Jens Axboe wrote:
>> Needs a bit of splitting and a few hunks should go further back (like
>> the wake handler typedef).
>>
>> WIP, adds IORING_OP_FUTEX_WAITV - pass in an array of futex addresses,
>> and wait on all of them until one of them triggers.
>>
> 
> So I'm once again not following. FUTEX_WAITV is to wait on multiple
> futexes and get a notification when any one of them wakes up with an
> index to indicate which one.

Right

> How exactly is that different from multiple FUTEX_WAIT entries in the
> io_uring thing itself? Admittedly I don't actually know much of anything
> when it comes to io_uring, but isn't the idea that queue multiple
> 'syscall' like things and get individual completions back?
> 
> So how does WAITV make sense here?

You most certainly could just queue N FUTEX_WAIT operations rather than
a single FUTEX_WAITV, but it becomes pretty cumbersome to deal with.
First of all, you'd now get N completions you have to deal with. That's
obviously doable, but you'd probably also need to care about
cancelations of the N-1 FUTEX_WAIT that weren't triggered.

For those reasons, I do think having a separate FUTEX_WAITV makes a lot
more sense. It's a single request and there's no cleanup or cancelation
work to run when just one futex triggers. Tongue in cheek, but you could
also argue that why would you need futex waitv support in the kernel,
when you could just have N processes wait on N futexes? We can certainly
do that a LOT more efficiently with io_uring even without FUTEX_WAITV,
but from an efficiency and usability point of view, having FUTEX_WAITV
makes this a lot easier than dealing with N requests and cancelations on
completion.

-- 
Jens Axboe