From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C9D03385843D for ; Tue, 13 Sep 2022 09:52:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9D03385843D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663062777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bObocM74UBQ9W1iegcXqHhO0ynisOULhf3wP19TwzmU=; b=ZKUPf0C8S5WJHo9pESzku47xCE4qa1+GtjYewOEkQGB/mJdDJJCxwRBSNawYcevXQZd6Gy xfy1rpMWJbKsP4sTwABKZ42QLLS4sYOPokSZ8ufdSsyRoUF+WfD+PKNZBNBKMTZu/kZOr9 oaBY/P0buWjiJWUBF8BqJ16LhSiXdqE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-Sm-FSA1hOr-vOzt2ouxePw-1; Tue, 13 Sep 2022 05:52:56 -0400 X-MC-Unique: Sm-FSA1hOr-vOzt2ouxePw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0481D3801F59; Tue, 13 Sep 2022 09:52:56 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.210]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D4EF40C6EC2; Tue, 13 Sep 2022 09:52:54 +0000 (UTC) From: Florian Weimer To: Zack Weinberg via Libc-alpha Cc: Zack Weinberg Subject: Re: RFC PATCH: Don't use /proc/self/maps to calculate size of initial thread stack References: <79dae81f-8e33-4499-a47a-93cc0903be6a@www.fastmail.com> Date: Tue, 13 Sep 2022 11:52:53 +0200 In-Reply-To: <79dae81f-8e33-4499-a47a-93cc0903be6a@www.fastmail.com> (Zack Weinberg via Libc-alpha's message of "Fri, 09 Sep 2022 17:03:32 -0400") Message-ID: <87fsgvvbwq.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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: * 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? Thanks, Florian