From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47AEDCA9EC4 for ; Tue, 29 Oct 2019 16:04:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2764420717 for ; Tue, 29 Oct 2019 16:04:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390281AbfJ2QET (ORCPT ); Tue, 29 Oct 2019 12:04:19 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:45794 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389940AbfJ2QES (ORCPT ); Tue, 29 Oct 2019 12:04:18 -0400 Received: from [91.217.168.176] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iPTyg-00083F-6G; Tue, 29 Oct 2019 16:04:14 +0000 Date: Tue, 29 Oct 2019 17:04:13 +0100 From: Christian Brauner To: Florian Weimer Cc: Jann Horn , Michael Kerrisk-manpages , lkml , linux-man , Kees Cook , Oleg Nesterov , Arnd Bergmann , David Howells , Pavel Emelyanov , Andrew Morton , Adrian Reber , Andrei Vagin , Linux API Subject: Re: For review: documentation of clone3() system call Message-ID: <20191029160412.jfnwlgaxhyvqpqga@wittgenstein> References: <20191028172143.4vnnjpdljfnexaq5@wittgenstein> <20191029112706.p5dd5yzpcgouo6n5@wittgenstein> <20191029142622.jxmssu4s4ndui7bw@wittgenstein> <87wocn39fu.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87wocn39fu.fsf@oldenburg2.str.redhat.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 29, 2019 at 03:36:37PM +0100, Florian Weimer wrote: > * Christian Brauner: > > > @Florian, do you have an opinion about always passing the stack from the > > lowest address with clone3()? > > Do you mean that the stack extends from stack to stack_size? I guess Specifically, that userspace doesn't need to know whether it needs to pass stack or stack + stack_size. The kernel will just do the stack + stack_size if the architecture has a downwards growing stack. So for _all_ architectures, ia64 or not, you'd always pass: void *p[PAGE_SIZE]; struct clone_args args = { .stack = p, .stack_size = PAGE_SIZE, }; > that makes sense. What about architectures which need two stacks (I > think ia64 is one)? I don't think ia64 needs any special treament. ia64 requires you to pass the lowest address of the stack and the kernel does the additon to reach the top of the stack and the alignemnt too. So ia64 _in the kernel_ currently does: arch/ia64/kernel/entry.S:sys_clone2() - setup stack and stack size and call into do_fork() -> kernel/fork.c:do_fork() -> copy_thread_tls() -> arch/ia64/kernel/process.c:copy_thread(): if (user_stack_base) { child_ptregs->r12 = user_stack_base + user_stack_size - 16; child_ptregs->ar_bspstore = user_stack_base; child_ptregs->ar_rnat = 0; child_ptregs->loadrs = 0; } > There is also the matter whose responsibility is the alignment of the > initial stack pointer. Hm, probably also a detail that userspace shouldn't need to know about? Christian