From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 9896E3858412 for ; Thu, 3 Nov 2022 16:22:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9896E3858412 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x22c.google.com with SMTP id l127so2481768oia.8 for ; Thu, 03 Nov 2022 09:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=/+e5SYT+MFwkuOgf8ubnQMIdjhg5BS6i+AloyFRLVBM=; b=fIg/vrKaLbi/me33jhpIZPkn2y/90druk/5OfD93cE3hscy0oz+ngXhw+G7igA0HT+ 2rDNcz3ZdKpX7vovE6L828w+9PHws1NRFg9L3ke+UeykvOdMhmVkOIfX+P/RSqgp83ly 15s3QL8si8zCUmRBQL5XAdAO2UeGfR92SGHezyLN+lk+srvEBsXW1KYkn030RMwZ442H NwEcCU4irWcxLgf8fCirxCEPlmFtKbuBUBNdQJj4rL7fvOYP+DspDYXwNA3sQ1V/2Ose EYVu2ao+5QBRIj7StWKXUS2iReZZnwWuXzlYfLUAgiBPvK6Iyh7huYUnCnISbuAuM0pC ljDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/+e5SYT+MFwkuOgf8ubnQMIdjhg5BS6i+AloyFRLVBM=; b=aHur5mSoAcKay+RnHlSyeh7mLjDF8cyEzH62KY8HsFpg4Mrt3pUzx7uzVqLQnzJUSf CbIGBzl4HxaLjvtJLYjO5hqAYNQRknth08Y389jOjLdfyZC34YDJI2HtaTSdXNL7w0xI QFwEQEgrGjg9MsF0eKZNHohi+GKeK9vpWKlgRNJ0/VzFrJ3+oFeiV5m98nSsSNj0a2TZ VjYLRNrQ/2sNTs2ITmk+4+N1mTjEtJShgjKDswmpe2cOOIeZCmma8QV0iyb05cIUrLEL Kl8zk/r4910AgJp238kG3C/ZiM/AHRFGkIn5jU706+V1jdoWPo0v69PCQXO4p4S/Z5KL SqWQ== X-Gm-Message-State: ACrzQf2KY79fziUBGlL6LNyB97GPoYcsWiAlHfCBoxOTeCyV9PVa5BeM z8Uf1MhKQJGzVHWYtRYxlS9t6lbj7RKI7HMc X-Google-Smtp-Source: AMsMyM7yTP2o77LaY2q5d5ZutGURQun2VpQIQ9kLbzpeBzo1Zrzxevwq+qyxoG+AMzIOyzi9497q/g== X-Received: by 2002:a05:6808:2104:b0:35a:5e9:a411 with SMTP id r4-20020a056808210400b0035a05e9a411mr13071778oiw.168.1667492576818; Thu, 03 Nov 2022 09:22:56 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:a9f4:4405:8c19:a65e:e640? ([2804:1b3:a7c0:a9f4:4405:8c19:a65e:e640]) by smtp.gmail.com with ESMTPSA id o3-20020a544783000000b00342ded07a75sm540159oic.18.2022.11.03.09.22.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 09:22:56 -0700 (PDT) Message-ID: <8a3dc5d9-b731-4c45-7252-8157ba0be6c2@linaro.org> Date: Thu, 3 Nov 2022 13:22:52 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v2 4/9] aarch64: Add the clone3 wrapper Content-Language: en-US To: Szabolcs Nagy Cc: libc-alpha@sourceware.org, Christian Brauner , "H.J. Lu" References: <20220930192613.3491147-1-adhemerval.zanella@linaro.org> <20220930192613.3491147-5-adhemerval.zanella@linaro.org> <1d4ce210-2b28-b061-9780-f643eaa80a27@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 03/11/22 11:01, Szabolcs Nagy wrote: > The 11/03/2022 10:15, Adhemerval Zanella Netto wrote: >> On 02/11/22 09:12, Szabolcs Nagy wrote: >>> The 09/30/2022 16:26, Adhemerval Zanella via Libc-alpha wrote: >>>> It follow the internal signature: >>>> >>>> extern int clone3 (struct clone_args *__cl_args, size_t __size, >>>> int (*__func) (void *__arg), void *__arg); >>>> >>>> And x86_64 semantics to return EINVAL if either cl_args or func >>>> is NULL. The stack is 16-byte aligned prior executing func. >>> >>> "x86_64 semantics" sounds wrong: maybe this should be documented? >>> i'd expect 0 cl_args/func to be UB like in most posix apis. >> >> Right, I think it is worth to document the function semantic >> properly at least on its internal header (include/clone_internal.h). >> H.J also added a new clone3.h headers, which is not currently installed >> that I am inclined to just remove it from now. We might reinstate >> if/when we decide to provide the clone3 as an ABI. >> >> And returning EINVAL for 0 cl_args/func aligns with our exported clone >> interface, where EINVAL is also returned for 0 function argument. > > ok. > >>> >>> and aligning sp in the child fails if signals are allowed there >>> (pthreads does not allow signals now, direct callers might). >>> i dont know if that's a concert (or if unaligned stack is >>> something we should fix up in clone3). >> >> It was overlooked on initial x86_64 clone3 implementation as well. I >> think it better to just return EINVAL for unaligned stacks and avoid >> to change the stack pointer in the created thread. > > long time ago linux did that on aarch64, but it was removed: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6d9a52543338603e25e71e0e4942f05dae0dd8a > > i think in clone3 the kernel should have aligned (it knows > the bounds now), doing it in the userspace wrapper is weird > (should we adjust the stack size?). and not doing it at all > makes clone3 hard to use portably (user has to know target > specific pcs requirements). > > not sure what's the best way forward. I think the stack size won't matter much here, at least not from kernel point of view (the resulting stack size will most likely be page aligned anyway). But I think this kernel commit makes a good point that silently adjusting the stack in userland is not the correct approach, I think H.J has done to make it consistent with glibc clone implementation which does it. IMHO the best approach would to just remove the stack alignment, since it incurs the signal handling issue.