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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id AAA653848415 for ; Tue, 25 May 2021 08:41:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AAA653848415 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-599-yoxre3bZP_mKs1S9vCKzGw-1; Tue, 25 May 2021 04:41:26 -0400 X-MC-Unique: yoxre3bZP_mKs1S9vCKzGw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8580B107ACFB; Tue, 25 May 2021 08:41:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-228.ams2.redhat.com [10.36.113.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78EE05D9FC; Tue, 25 May 2021 08:41:24 +0000 (UTC) From: Florian Weimer To: Bruno Haible Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 3/3] Misc: Add and the cstack_* family of functions References: <73724441.XAIsEQcG03@omega> Date: Tue, 25 May 2021 10:41:22 +0200 In-Reply-To: <73724441.XAIsEQcG03@omega> (Bruno Haible's message of "Mon, 24 May 2021 16:58:20 +0200") Message-ID: <87fsyb19zh.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 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 08:41:31 -0000 * Bruno Haible: > In reply to : > >> These functions are expected to be used with sigaltstack and >> coroutines. > > What is the added value of these functions, compared to what existing > programs already do? > > I did a small survey of how a couple of single-threaded programs allocate > their alternate stack: > - The majority allocate it statically. > - Some use malloc(). > - Some use mmap(). > - Some use alloca(), i.e. a portion of the already-allocated stack in > the program's main() function. > The size that these programs use are: > - some use SIGSTKSZ, > - some use 16 KiB, > - some use 64 KiB. > > We know that 16 KiB is too small on some platforms, and that a static > allocation of SIGSTKSZ bytes leads to a compilation error now. > > Therefore the implemented added value is: > > * The ability to use SIGSTKSZ without a compilation error. And we can more easily tweak stack allocations in glibc, perhaps using configuration values, to get old applications working on newer hardware. We don't quite now how an application might use SIGSTKSZ, so tweaking that value is harder. > Other added value that would be useful in some cases are: > > * The ability to have a guard page at the stack top. > This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE) > is missing after the __mmap call. > > * The ability to have a guard page at the stack bottom. > This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE) > is missing after the __mmap call. Sorry, this is what I fixed in version 2. > * A verification that the allocated size is not larger than > getrlimit(RLIMIT_STACK). If the system or the user has set a maximum > stack size of, say, 8 MB, should the program be able to allocate a > stack of 1 GB size, in this way? Sure, why not? It could be used as an escape hatch if the configured stack size is too small. > * Support for GCC nested functions, when they need an executable stack. > GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to > support this, even from dynamically loaded shared libraries. (See the > attached test cases.) It is poor if this facility does not support it. I can try to add this. It's reasonably straightforward for Linux. It may be a little bit harder on Hurd. > * Automatic deallocation when the current thread exits. > In those cases where a thread allocated a cstack_t for its own use, > it is welcome if it can say "clean it up automatically when the thread > exits". Otherwise some programmers will still prefer the "use alloca()" > approach, which has this automatic cleanup property. Do you think it's sufficient to specify this at thread creation time? An interface that does this at a later stage may have to deal with the case where a new alternate stack is installed while the code is running on the alternate stack previously assigned to the current thread. Thanks, Florian