On Tue, May 12, 2020 at 10:51:51AM +0200, Kamil Rytarowski wrote: > On 12.05.2020 02:59, Joerg Sonnenberger wrote: > > On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote: > >> On 19.04.2020 03:06, Joerg Sonnenberger wrote: > >>> Module Name: src > >>> Committed By: joerg > >>> Date: Sun Apr 19 01:06:16 UTC 2020 > >>> > >>> Modified Files: > >>> src/lib/libc/gen: pthread_atfork.c > >>> src/libexec/ld.elf_so: rtld.c rtld.h symbols.map > >>> > >>> Log Message: > >>> Rename __atomic_fork to __locked_fork and give it &errno as argument. > >>> rtld and libc use different storage, so the initial version would > >>> incorrectly report the failure reason for fork(). > >>> > >>> There is still a small race condition inside ld.elf_so as it doesn't use > >>> thread-safe errno internally, but that's a more contained internal > >>> issue. > >>> > >>> > >> > >> > >> Should we add the same logic for clone(2)? > > > > clone only exists for Linux compat. I see no reason to support any fork > > emulation for it. > > > > Joerg > > > > This Linux compat is on the source code level and inside the kernel > clone() shares the same code with fork(). > > clone(2) is a regular syscall available in the NetBSD native ABI syscall > layers. There are also users (I have got one). > > All problems for fork() can be reproduced for clone(). But if we want to > just mitigate some issues of fork() users and fix/ignore promptly > clone() ones, it is fine.
clone(2) already has a huge set of race conditions it will hit in various parts of libc, libpthread etc when it is used to emulate fork. It is a non-standard interface too with no mechanisms for resolving any of those races. I see no reason for pretending that it is anywhere usable. Joerg