On Tue, Dec 17, 2024 at 11:03:27AM +0000, Pavel Begunkov wrote: > On 12/11/24 17:26, Josh Triplett wrote: > > On Wed, Dec 11, 2024 at 01:37:40PM +0000, Pavel Begunkov wrote: > > > Also, do you block somewhere all other opcodes? If it's indeed > > > an under initialised task then it's not safe to run most of them, > > > and you'd never know in what way, unfortunately. An fs write > > > might need a net namespace, a send/recv might decide to touch > > > fs_struct and so on. > > > > I would not expect the new task to be under-initialised, beyond the fact > > that it doesn't have a userspace yet (e.g. it can't return to userspace > > I see, that's good. What it takes to setup a userspace? and is > it expensive? I remember there were good numbers at the time and > I'm to see where the performance improvement comes from. Is it > because the page table is shared? In other word what's the > difference comparing to spinning a new (user space) thread and > executing the rest with a new io_uring instance from it? The goal is to provide all the advantages of `vfork` (and then some), but without the incredibly unsafe vfork limitations. Or, to look at it a different way, posix_spawn but with all the power of io_uring available rather than a handful of "spawn attributes". > > without exec-ing first); if it is, that'd be a bug. It *should* be > > possible to do almost any reasonable opcode. For instance, reasonable > > possibilities include "write a byte to a pipe, open a file, > > install/rearrange some file descriptors, then exec".
