Re: [PATCH 0/2] Introduce IORING_OP_MMAP

[Jens Axboe <axboe@kernel.dk>]

On 2/1/26 10:46 AM, David Hildenbrand (arm) wrote:
> On 1/29/26 23:11, Gabriel Krisman Bertazi wrote:
>> Hi,
>>
>> There's been a few requests over time for supporting mmap(2) over
>> io_uring. The reasoning are twofold: 1) serving as base for batching
>> multiple mappings in a single operation 2) supporting mmap of fixed
>> files.
>>
>> Since mmap can operate on either anonymous memory and file descriptors,
>> patch 1 adds support for optional fds in io_uring commands.  Patch 2
>> implements the mmap operation itself.
>>
>> Note this patchset doesn't do any kind of smarter batching in MM.  While
>> we can potentially do some interesting optimizations already, like
>> holding the MM write lock instead of reacquiring it for each mapping, I
>> wanted to focus on the API discussion first.  This is left as future
>> work.
>>
>> liburing support, including testcases, will be sent shortly to the list,
>> but can also be found at:
> 
> Just a general question: why do we unlock each syscall individually,
> and not in some intelligent way, all syscalls at once? :)

The hard part isn't enabling all syscalls at once, that could be
trivially done with an IORING_OP_SYSCALL and the SQE carries arg0..argN.
And for any nonblocking/simple syscall, that would Just Work. The
challenge is for syscalls that block - the whole point of io_uring is
that you should be able to do nonblock issues with sane retries. The
futex series I did some time back is a good example of that - you modify
the existing syscall to expose the waitqueue mechanism, which you can
then use to wait in an async way, and get a callback when some action
needs to be taken.

If you just allow blocking, then you're blocking the entire io_uring
issue pipeline. Which was exactly my main complaint on this patchset,
see the review reply to patch 2.

> I assume supporting arbitrary syscalls could be rather hard (or am I
> wrong? :) ).

See above - it's both trivially easy if you ignore the problems, or
somewhat harder as you'd need to refactor the underlying bits of that
particular syscall first. For some of them, that's hard. Traditionally
syscalls have been fully sync, they will just block and prevent the task
from returning back to userspace until they are done. syscalls with
io_uring is more involved as we simply cannot allow that kind of
blocking.

-- 
Jens Axboe