all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH 3/6] daemon: On aarch64, use increments of 16 on the stack.
Date: Sat, 05 Aug 2017 02:21:55 -0400	[thread overview]
Message-ID: <874ltm5ybg.fsf@netris.org> (raw)
In-Reply-To: <87r331xiot.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 14 Feb 2017 09:47:30 +0100")

Reviving a very old thread...

ludo@gnu.org (Ludovic Courtès) writes:

> Efraim Flashner <efraim@flashner.co.il> skribis:
>
>> man2 clone: EINVAL: ... on aarch64, child_stack must be a multiple of 16.
>>
>> * nix/libstore/build.cc (DerivationGoal::startBuilder): When on aarch64,
>> when calling clone(), increment the stack by 16.
>> ---
>>  nix/libstore/build.cc | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
>> index cebc404d1..362b2d91d 100644
>> --- a/nix/libstore/build.cc
>> +++ b/nix/libstore/build.cc
>> @@ -2008,7 +2008,12 @@ void DerivationGoal::startBuilder()
>>  	char stack[32 * 1024];
>>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
>>  	if (!fixedOutput) flags |= CLONE_NEWNET;
>> -	pid = clone(childEntry, stack + sizeof(stack) - 8, flags, this);
>> +// if statements are hard, fix this
>> +//#if __AARCH64__
>> +	pid = clone(childEntry, stack + sizeof(stack) - 16, flags, this);
>> +//#else
>> +//	pid = clone(childEntry, stack + sizeof(stack) - 8, flags, this);
>> +//#endif
>
> I think we can make it unconditional.  Could you test whether the
> attached patch works for aarch64?
>
> Thanks!
>
> Ludo’.
>
> diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
> index cebc404d1..9b7bb5391 100644
> --- a/nix/libstore/build.cc
> +++ b/nix/libstore/build.cc
> @@ -26,6 +26,7 @@
>  #include <errno.h>
>  #include <stdio.h>
>  #include <cstring>
> +#include <stdint.h>
>  
>  #include <pwd.h>
>  #include <grp.h>
> @@ -2008,7 +2009,11 @@ void DerivationGoal::startBuilder()
>  	char stack[32 * 1024];
>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
>  	if (!fixedOutput) flags |= CLONE_NEWNET;
> -	pid = clone(childEntry, stack + sizeof(stack) - 8, flags, this);
> +
> +	/* Ensure proper alignment on the stack.  On aarch64, it has to be 16
> +	   bytes.  */
> +	pid = clone(childEntry, (char *)(((uintptr_t)stack + 16) & ~0xf),
> +		    flags, this);
>  	if (pid == -1)
>  	    throw SysError("cloning builder process");
>      } else

This patch, applied in February, contains a serious error.  The stack
address passed to 'clone' is supposed to be near the end of the memory
block allocated for the stack, and that's how it was before this patch
was applied.  Since this patch was applied, it now passes an address
very close to the *start* of the memory block.

This broke the daemon on mips64el in a subtle way that was rather
difficult to debug.  After about six months of being too busy with other
things to investigate properly, I finally tracked it down to this
change.

I reverted this commit.  Let's try again to find a proper fix for this
issue on aarch64.

     Thanks,
       Mark

  parent reply	other threads:[~2017-08-05  6:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 18:45 [PATCH 0/6] WIP aarch64 support Efraim Flashner
2017-02-09 18:45 ` [PATCH 1/6] gnu: %static-inputs: Use 'grep' without custom phase Efraim Flashner
2017-02-14  8:30   ` Ludovic Courtès
2017-02-14 19:53     ` Efraim Flashner
2017-02-09 18:45 ` [PATCH 2/6] gnu: %bootstrap-coreutils&co: Patch egrep/fgrep to work regardless of $PATH Efraim Flashner
2017-02-14  8:35   ` Ludovic Courtès
2017-02-14 19:46     ` Efraim Flashner
2017-02-09 18:45 ` [PATCH 3/6] daemon: On aarch64, use increments of 16 on the stack Efraim Flashner
2017-02-14  8:47   ` Ludovic Courtès
2017-02-14 20:11     ` Efraim Flashner
2017-08-05  6:21     ` Mark H Weaver [this message]
2017-08-05 18:24       ` Efraim Flashner
2017-08-05 21:32         ` Mark H Weaver
2017-08-05 21:41           ` Mark H Weaver
2017-08-06 14:53             ` Efraim Flashner
2017-08-09 20:22               ` Mark H Weaver
2017-08-05 21:12       ` Ludovic Courtès
2017-02-09 18:45 ` [PATCH 4/6] gnu: Add bootstrap-binaries for 'aarch64-linux' Efraim Flashner
2017-02-14  8:51   ` Ludovic Courtès
2017-02-14 20:05     ` Efraim Flashner
2017-02-09 18:45 ` [PATCH 5/6] gnu: gcc: Force Aarch64 to use /lib Efraim Flashner
2017-02-11 16:03   ` Danny Milosavljevic
2017-02-14  8:51     ` Ludovic Courtès
2017-02-14 19:51       ` Efraim Flashner
2017-02-22 19:42         ` Efraim Flashner
2017-02-25 19:04           ` Efraim Flashner
2017-03-06  9:24             ` Ludovic Courtès
2017-02-09 18:45 ` [PATCH 6/6] hydra: Add "aarch64-linux-gnu" as a cross-compilation target Efraim Flashner
2017-02-14  8:52   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874ltm5ybg.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.