Re: [PATCH] build: container: Use the same clone flags as fork(3).

[Thompson, David]

On Mon, Sep 7, 2015 at 12:13 PM, Ludovic Courtès <address@hidden> wrote:
> David Thompson <address@hidden> skribis:
>
>> This patch resolves an issue I was having when working with containers
>> at the REPL, which means it probably presented undetected issues
>> elsewhere.
>
> Calling ‘primitive-fork’ at the REPL is not very useful anyway since you
> end up with two Guiles trying to read from the same tty.

Yes, this is true, but it made it glaringly obvious that something was wrong.

    (match (primitive-fork) (0 (primitive-exit 0)) (pid pid))  ; OK
since it exits immediately

    (match (clone (logior CLONE_NEWUSER SIGCHLD)) (0 (primitive-exit
0)) (pid pid)) ; Broken REPL!

>> From 61ebbe55f7f6d4d4eb42db957d6fc7b4eaf282a6 Mon Sep 17 00:00:00 2001
>> From: David Thompson <address@hidden>
>> Date: Sat, 5 Sep 2015 14:10:08 -0400
>> Subject: [PATCH] build: container: Use the same clone flags as fork(3).
>>
>> The intent is to make 'clone' behave a lot more like 'primitive-fork', which
>> calls clone(2) with SIGCHLD, CLONE_CHILD_CLEARTID, and CLONE_CHILD_SETTID
>> flags.  Notably, running 'clone' at the REPL without these flags would break
>> the REPL beyond repair.
>>
>> * guix/build/syscalls.scm (CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID): New
>>   variables.
>> * gnu/build/linux-container.scm (namespaces->bit-mask): Add
>>   CLONE_CHILD_CLEARTID and CLONE_CHILD_SETTID to bit mask.
>
> Looking at clone(2) and libc, I’m guessing that without these flags, the
> child would have a wrong idea of its thread ID, which in turn may cause
> all sorts of problems, right?

Yes, that seems to be the case.  I was always a little suspicious
about not using the same clone flags as fork, and I finally ran into a
case where it made a difference.

> LGTM.

Pushed, thanks!

- Dave