From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by sourceware.org (Postfix) with ESMTPS id 6D2D23858407 for ; Tue, 13 Sep 2022 22:03:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D2D23858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=canonical.com Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 598483F147 for ; Tue, 13 Sep 2022 22:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1663106635; bh=acmcruCgGhxawRKn10NA4KEQTTwPAv9NYM1gL9MpyWY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NCpd3BS+Q5fQvfalKXQYE8egGgQJ2lXfbpYcoT0h7vmyBXkjYOuqUJPP8f7mcuxiU UBkwtjfQnC/jz3VDg/40+juN2WDeSb6RXS3vvhb0XywaznBo3OKBcH6DFVUru7al0U /swJQR9YMs9zFKbDoiCrQFgT3NFY7hcDhsbSoYxztLfJItAaO1c1mpCtGp/Hv2k5iB 1BuWRy1FgDvAG2Wb3DhAIzv48tNBBJA7lSI3ynLRweeEqu51W7fDJ46Z365AjVVdSf hYtQRsdYIIPAVieJLVr1Og+jNkm+SArYnLXB+5cCkvDaC97UEVE0xndaHnRU2hsuq/ JSN9hFe0lHkog== Received: by mail-lj1-f199.google.com with SMTP id d20-20020a2eb054000000b0026c08f42b50so2002884ljl.20 for ; Tue, 13 Sep 2022 15:03:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=acmcruCgGhxawRKn10NA4KEQTTwPAv9NYM1gL9MpyWY=; b=VrYALgzEBa6Uoh/OuSPzyhwCOeD5lLr7LzXl0T4J+cEGfjZgA1lHHNZHA1VvV1qJM1 JCHJmyEEYw81YLpJouBlIDqiDD0nbi69Sk9Vp9jEmeOurPfeP0RozYUCt9nlTyIxVX9t 70ApcrsDFfh4Je7gPNEvCtfhNQyzvA5M9Il0qcelcEAxZSsu26eSGVZd5aYQYUNQOhFW 9+ZKnuC1sx8G+2Ofh0vs04fCC0tn6Su2NiSD8pgz21q4I5GwNJ0K/vJt9fodmxV7iRL6 x/7D8Cx87ajiREheBo65YSfN0Zq67dk00Z5BcJdaioDxbSZd30gAIRyDO0XtcP6KZCUn 5ZhQ== X-Gm-Message-State: ACgBeo2TOgJQL5Esq7jxGEBCPWMfbsOvYO0FGu7nnTSOaKMvOX0faxo5 L92IVxPPF/4JeL65TYW6mzY7+6KKJjL/uwYQbD/MtLaWVXmvWhnj6i6jdFO303t8cWBgHNuEZ31 jttwmQ4a2n3mDruFEM0nF6/xpKfvm4TMI7NyCNACE6pMNCLcCtVZSig== X-Received: by 2002:a05:6512:10cb:b0:48c:e0a6:221b with SMTP id k11-20020a05651210cb00b0048ce0a6221bmr12512210lfg.218.1663106634664; Tue, 13 Sep 2022 15:03:54 -0700 (PDT) X-Google-Smtp-Source: AA6agR7CVg+TcpnjE+lGRtRojmWrUfHNhIZfBI84UrXXRrT2adx5l7B+574xIv+rXtPhaFstsEdj7yQds20GS6cNt9k= X-Received: by 2002:a05:6512:10cb:b0:48c:e0a6:221b with SMTP id k11-20020a05651210cb00b0048ce0a6221bmr12512205lfg.218.1663106634400; Tue, 13 Sep 2022 15:03:54 -0700 (PDT) MIME-Version: 1.0 References: <79dae81f-8e33-4499-a47a-93cc0903be6a@www.fastmail.com> <87fsgvvbwq.fsf@oldenburg.str.redhat.com> In-Reply-To: <87fsgvvbwq.fsf@oldenburg.str.redhat.com> From: Michael Hudson-Doyle Date: Wed, 14 Sep 2022 10:03:42 +1200 Message-ID: Subject: Re: RFC PATCH: Don't use /proc/self/maps to calculate size of initial thread stack To: Florian Weimer Cc: Zack Weinberg via Libc-alpha , Zack Weinberg Content-Type: multipart/alternative; boundary="0000000000002adfaa05e8963080" X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --0000000000002adfaa05e8963080 Content-Type: text/plain; charset="UTF-8" On Tue, 13 Sept 2022 at 21:53, Florian Weimer via Libc-alpha < libc-alpha@sourceware.org> wrote: > * Zack Weinberg via Libc-alpha: > > > When pthread_getattr_np is applied to the initial thread, it has to > > figure out how big the initial thread's stack is. Since the initial > > thread's stack is lazily allocated and the kernel reuses that memory > > region for the "information block" (argv, environ, etc) there are > > several different ways one could define "the size of the initial > > thread's stack"; for many years, the NPTL implementation has said that > > the stack starts at __libc_stack_end, rounded in the opposite > > direction from stack growth to the nearest page boundary, and extends > > for getrlimit(RLIMIT_STACK).rlim_cur bytes, *minus the size of the > > information block*, which is beyond __libc_stack_end. The rationale > > is that the resource limit is enforced against the entire memory area, > > so if we don't subtract the size of the information block, then the > > program will run out of stack a few pages before pthread_attr_getstack > > says it will. > > Do we actually have to subtract the size of the information block? > One could argue that this is just part of the arguments passed to main, > so sort-of-but-not-quite part of main's stack frame. > > process_vm_readv seems quite likely to get blocked by seccomp filters. > > Maybe we can get the kernel to pass the end of the stack in the > auxiliary vector? > I wondered the same when reading the first mail fwiw -- guessing what the kernel did is always going to be more annoying than just having it tell us... Cheers, mwh --0000000000002adfaa05e8963080--