Index | Thread | Search

From:
"Andrea Pappacoda" <andrea@pappacoda.it>
Subject:
Implementing a spawn(2) system call
To:
<tech@openbsd.org>
Date:
Sat, 12 Oct 2024 12:24:23 +0200

Download raw body.

Thread
  • Andrea Pappacoda:

    Implementing a spawn(2) system call

Hi all! I'm new here, so please do not be kind with me :)

As part of my bachelor's thesis, I'm investigating implementing 
a "spawn" system call in the OpenBSD kernel, which would be in turn used 
in the posix_spawn(3) implementation. Before even proposing to upstream 
this here, I'll do lots of testing and evaluation, to be sure that 
having such a system call makes sense (there's some research which says 
that it does, while some people think it doesn't).

While hacking on the kernel to actually implement it, though, I've 
encountered one (major?) issue. I'm reusing as much code from the 
existing fork1(9) and execve(2) as possible, and while I'm not having 
issues with fork1(9), execve(2) is puzzling me a bit. The issue is that 
there are a lot of KASSERT(curproc == p) in the code invoked by 
execve(2); while this assumption is true in the classic "fork and exec" 
model, it isn't when a process p1 invokes a single syscall which creates 
an empty p2 process and execs a new program onto it.

I'm not familiar with OpenBSD's kernel internals, so I might be 
misinterpreting the asserts, but: why are they needed? Why can't 
a syscall invoked by a process p1 cause an exec on a newly created 
process p2?

I mean, in a system without spawn(2) this makes sense, but are those 
asserts just checking for consistency in a "fork and exec" model, or is 
the curproc == p condition a hard requirement for the kernel's 
operations?

Thank you for reading this email! Again, excuse my ignorance, and feel 
free to point me to some relevant documentation (if it exists).

Bye :)