From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id EF2FC2D509 for ; Thu, 29 Aug 2024 14:57:41 +0200 (CEST) Received: (qmail 29771 invoked by uid 550); 29 Aug 2024 12:57:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29730 invoked from network); 29 Aug 2024 12:57:36 -0000 Date: Thu, 29 Aug 2024 08:57:27 -0400 From: Rich Felker To: psykose Cc: musl@lists.openwall.com Message-ID: <20240829125727.GK10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix MINSIGSTKSZ and SIGSTKSZ for powerpc64 On Thu, Aug 29, 2024 at 05:38:42AM +0200, psykose wrote: > since kernel commit 2f82ec19757f58549467db568c56e7dfff8af283 > (https://github.com/torvalds/linux/commit/2f82ec19757f58549467db568c56e7dfff8af283) > the kernel has updated these minimum values. having these small values breaks > sysconf(_SC_MINSIGSTKSZ) too; it returns 4224 in musl currently which ends up > returning ENOMEM from the syscall made in sigaltstack. > > raising these to match the kernel fixes sigaltstack use on powerpc64(le). > caught by glib's 2.82 testsuite I don't follow how you're claiming sysconf(_SC_MINSIGSTKSZ) is broken. It will just return the kernel-provided value on new kernels that insist on having a larger stack. In particular I don't see where the value 4224 is supposed to be coming from. If there's something I'm missing, please explain. Changing the macros is ABI breakage, perhaps minor, but still not nice. My leaning if any change is made would be to remove them, but unfortunately the Austin Group didn't seem to have gotten the sysconf stuff (and making these macros optional) into Issue 8, so they're still mandatory. So I'm not sure what is best to do. Ultimately, due to kernel bad behavior ignoring the "don't break userspace" rule and ignoring POSIX, we're in a situation where the macros are required but necessarily don't actually work, and the only way to make a reliably working application is to use the not-yet-standard sysconf() lookups instead. Regardless of how MINSIGSTKSZ is handled, increasing SIGSTKSZ from 10k to 32k makes no sense. At most it needs to be increased by the increase in MINSIGSTKSZ, or perhaps twice that if the goal is to allow for 2 signal frames (but we currently don't do that in sysconf, so if that's desirable it should be proposed as its own thing not a special-case jacking up of the value for one arch). Rich