Re: CVS commit: src

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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