From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E49FD1F66F for ; Wed, 18 Nov 2020 18:09:36 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D95373894C23; Wed, 18 Nov 2020 18:09:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D95373894C23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605722975; bh=Tfv12ImXITyjadAhy4ag56tjS+NokepnPELWGTMOFoM=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=iMJ6iIPjvv+rCM7TkGZ1iSVB8ihKuOFtdYzEMblprJbK9AB84XkB/RhvUVSyvMODg aNxStagLk07iMp9va74Xq57YMdQr4bKH51mgXxnHvQ+Q0RmbERmDUfNYpDQYcAq8Kp 7sDDo0Jr4luN6u6IKPjE9RU/NQXEds+5Zjjd1cyM= Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 96C613858012 for ; Wed, 18 Nov 2020 18:09:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 96C613858012 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2885811D4; Wed, 18 Nov 2020 10:09:32 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 943EA3F718; Wed, 18 Nov 2020 10:09:31 -0800 (PST) Date: Wed, 18 Nov 2020 18:09:27 +0000 To: Florian Weimer Subject: Re: PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] Message-ID: <20201118180927.GI6882@arm.com> References: <20201104165018.GE6882@arm.com> <87lfeyvghf.fsf@mid.deneb.enyo.de> <20201118170434.GF6882@arm.com> <873616va9n.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873616va9n.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: , From: Dave Martin via Libc-alpha Reply-To: Dave Martin Cc: "H.J. Lu via Libc-alpha" , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Wed, Nov 18, 2020 at 06:35:00PM +0100, Florian Weimer wrote: > * Dave Martin: > > > Having _GNU_SOURCE enable this feature will break existing source code. > > Does this matter? > > The code is already broken on a quickly increasing number of machines, > so it needs fixing anyway. A compile-time error is probably > preferable to an obscure run-time failure. Fair point, but I didn't want to be the one making it :) If people are happy to go this way, I don't see a problem with it. Distro maintainers may shout a bit while they deal with the fallout of that glibc upgrade though. > > It probably should go under _GNU_SOURCE in the long term, but is there > > usually a transitional period when the change is opt-in via some feature > > macro? > > Not always. See the iszero and other macros in , that also > broke existing sources (largely C++, so we worked around it by using > C++ features instead of macros). There are also many older examples. I see. Well, I guess that's not my call. > > I have some thoughts on what a better interface might look like -- > > basically separating the signal ucontext_t type from the setcontext()/ > > getcontext() etc. type, and providing accessors for the architectural > > register state rather than just having a fixed struct definition for > > mcontext_t. > > > > But, there also may not be a lot of appetite for such a change, and > > I can't see how it could be backwards compatible. > > > > I can elaborate if people think it's worth discussing. > > I think Rich Felker wants to copy signal contexts around to implement > critical sections that can't be interrupted by a signal handler, I > think that would need this fully fixed. Is rseq a more suitable way to do that sort of thing on new-ish Linux? I guess a fallback may be needed for older / other kernels though. I'm happy to follow up on here with my ucontext proposal, but it's quite a big change. I wasn't sure people would really be up for it... > But this is somewhat separate from fixing stack sizes to accomodate > kernel and hardware needs. I was wondering whether we could feed in ucontext changes on the back of the MINSIGSTKSZ stuff, so that if people want one they must adopt both. Probably best to deal with it independently though -- as you say, the ucontext breakage already exists. > By the way, something that I tried to raise in the past, but wasn't > good at it: In the future, we may need a mechanism to reduce the > kernel stack size usage for legacy binaries, perhaps using > virtualization. The last time I looked at this, the signal context > did not actually reduce when AVX-512 support was masked in a guest, I > think. (Okay, this is largely for H.J.'s benefit.) This also applies > to ld.so and its context save operation. Fortunately, not many people > have run into this compatibility issue so far. The case I remember > was an application that broke because it assumed zeros on the stack, > and the XSAVE trampoline wrote some non-zero bits there because it > reached much deeper into the stack. But the user was happy when we > found the root cause and was able to add the missing initializer to > their code, so all was good. For aarch64 an explicit prctl()/sysctl opt-in is needed to enable jumbo vector registers before you see oversized signal frames, though I don't think there is a similar control for AVX-512. Even on aarch64, this interface is not very friendly though. It might be better to have some ELF attribute that ld.so or the libc startup can arbitrate on and twiddle the appropriate switches. Cheers ---Dave