From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) by sourceware.org (Postfix) with ESMTPS id E74B93858D20 for ; Fri, 5 May 2023 14:14:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E74B93858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ascii.art.br Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ascii.art.br X-Sender-Id: dreamhost|x-authsender|tuliom@ascii.art.br Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 671CC41F39; Fri, 5 May 2023 14:14:24 +0000 (UTC) Received: from pdx1-sub0-mail-a232.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DF0E442865; Fri, 5 May 2023 14:14:23 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1683296063; a=rsa-sha256; cv=none; b=2Sca4BpB6As5PKATUqoGHZoYiphk5Z/0sL86br8lpCVU2ELmAmyDfZAnJn/dy0cYm29zVh 49q4z6TSyj19BJKLUjE6en+sAsadvdcJ6LMIFgLCJ+i0yWhhyeTXW42XC7jUTGw8Iwft7S OyFGMEgRAF9H0Trvy/VWAPu43RGcOk8+gOPpsZ6e7PRVwrB/Tkgotbc3oQIc8W9WpQs0bN +ZlgefB5mYngINhFIBaxI8YLsQtpNXrNR2e9Ok0KT/YonlEjNTWH2xfADUVNCUitxxSUJT uLIWXDp3DVPkA1h7wfzWwdc8HwEM3+vO80apOrUfII9D8JwJewjjxWciXBbbBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1683296063; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IGPDpM2PordryeTSDpFIfiqX9pBEu+SCrrnZpIJx9CY=; b=uuAFaN86WXez6kal8mnme0tZjvcDykRVtbMBcEH4EJCV+4nBGaSUNdJ2arRAvBsWqo68BD N7YYs6iinyQskdmI250ptd1agHRnXx9XSYh7kUn/3rE8hPAUTUr8B/QGaGPr88Fz3GJ8fl owGoDvIFjMUmbyTjb9iwQ2qzfsmfRW3x1UeLzQGthpPUxI2WW+c1mHh+Q4rckbcUcOI/Q6 uuaoNqjraKLnjvrS2XbmSCgvh2tKHrGk8uVYnOPw9uwx5FRCSugUx2OdG6QMzJo6Dq9YRb MpMjK6pCmLoCW0lFpBjkGUO8NgzsTvzv87GC4m7sJ3kAWSr58yddN2kqAXstXw== ARC-Authentication-Results: i=1; rspamd-6bfb6b59b5-564sp; auth=pass smtp.auth=dreamhost smtp.mailfrom=tuliom@ascii.art.br X-Sender-Id: dreamhost|x-authsender|tuliom@ascii.art.br X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|tuliom@ascii.art.br X-MailChannels-Auth-Id: dreamhost X-Cooing-Spot: 03a3d3dc73050cff_1683296064161_2961726126 X-MC-Loop-Signature: 1683296064161:82218131 X-MC-Ingress-Time: 1683296064161 Received: from pdx1-sub0-mail-a232.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.107.49.254 (trex/6.7.2); Fri, 05 May 2023 14:14:24 +0000 Received: from ascii.art.br (unknown [181.225.180.18]) (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) (Authenticated sender: tuliom@ascii.art.br) by pdx1-sub0-mail-a232.dreamhost.com (Postfix) with ESMTPSA id 4QCXk56VM0z31; Fri, 5 May 2023 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ascii.art.br; s=dreamhost; t=1683296062; bh=IGPDpM2PordryeTSDpFIfiqX9pBEu+SCrrnZpIJx9CY=; h=From:To:Cc:Subject:Date:Content-Type:Content-Transfer-Encoding; b=IAD/GwEmoKQQEF0TVFwPAcFGALLEpHIo24/wT1YT7V1Qgf8bCMrr74Hif6Eu8WoQ+ E6H4rEmqMfrRlntL75UAZRLuGwqe4F+iABoutX1FebmW25CM8ehB45JAu3+Zz3XPbW KqCHCt1UdxgLn+j7FUuOYyCt6VBjO0Tqe70sCdBnam/+YEI+a8Y0LlkxjPJHSD+hi1 s9qN3nOsuiBbTkUUKXHxrWAfC0/Q5lTbsYs6YYzPjmsSHixVIav0K3qfIu0VVsSinJ svU/zmHDl1Ugfd56aBWjmzwpwPBy7vq+8HZSl/PmikmxyXEOdEo+7ePrbOmI51EGWz yFB+zBCqtSv2w== From: Tulio Magno Quites Machado Filho To: Manjunath S Matti , Manjunath Matti via Libc-alpha Cc: rajis@linux.ibm.com, Manjunath Matti Subject: Re: [PATCH] powerpc: Use sysconf (_SC_SIGSTKSZ) to set SIGSTKSZ and MINSIGSTKSZ. In-Reply-To: References: <20230424105208.301614-1-mmatti@linux.ibm.com> <874jozevbl.fsf@ascii.art.br> <7620a9b1-fe92-0764-6011-81d3a19e5590@linux.vnet.ibm.com> <871qjxe26c.fsf@ascii.art.br> Date: Fri, 05 May 2023 11:14:18 -0300 Message-ID: <87wn1mdfwl.fsf@ascii.art.br> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: Manjunath S Matti writes: > On 03/05/23 11:18 pm, Tulio Magno Quites Machado Filho wrote: >> Manjunath S Matti writes: >> >>> On 28/04/23 11:35 pm, Tulio Magno Quites Machado Filho wrote: >>>> Manjunath Matti via Libc-alpha writes: >>>> >>>>> +/* Minimum stack size for a signal handler: SIGSTKSZ/4. */ >>>>> +# undef MINSIGSTKSZ >>>>> +# define MINSIGSTKSZ (SIGSTKSZ >> 2) >>>>> +#endif >>>> I didn't understand this part. >>>> Why SIGSTKSZ/4 ? I know this is correct now, but I think the kernel is >>>> allowed to use another value. >>>> Why is this part not using sysconf(_SC_MINSIGSTKSZ)? >>>> I'm not suggesting to use sysconf() here, but I'm trying to understand >>>> why the same source of value for both SIGSTKSZ and MINSIGSTKSZ is not >>>> being used. >>> In file: sysdeps/unix/sysv/linux/sysconf-sigstksz.h >>> >>> =C2=A028=C2=A0=C2=A0 if (minsigstacksize < MINSIGSTKSZ) >>> =C2=A029=C2=A0=C2=A0=C2=A0=C2=A0 minsigstacksize =3D MINSIGSTKSZ; >>> =C2=A030=C2=A0=C2=A0 /* MAX (MINSIGSTKSZ, sysconf (_SC_MINSIGSTKSZ)) = * 4.=C2=A0 */ >>> =C2=A031=C2=A0=C2=A0 long int sigstacksize =3D minsigstacksize * 4; >>> >>> So we are not changing the default implementation. >> I'm not sure I understood you. Are you trying to tell me that you want >> sysconf_sigstksz() to continue to return the same result? > Do you want me to implement a powerpc specific function ? >> If this is the case, be careful with the creation of >> sysdeps/unix/sysv/linux/powerpc/bits/sigstksz.h because it is an >> installed header. That means the values that are being set here will leak >> to user code if __USE_DYNAMIC_STACK_SIZE is defined. >> >> If that happens, user code may end up having >> MINSIGSTKSZ !=3D getauxval(AT_MINSIGSTKSZ) if the kernel decides to chan= ge >> the value of AT_MINSIGSTKSZ. > > My observation is that, MINSIGSTKSZ is not the same as=20 > getauxval(AT_MINSIGSTKSZ). OK. And I'm trying to warn you there is a risk of having MINSIGSTKSZ < getauxval(AT_MINSIGSTKSZ) when __USE_DYNAMIC_STACK_SIZE is defined. I'm afraid we're diverging from the original discussion, which is: the minimum stack size for a signal handler is calculated from the amount of data the kernel needs to save in the stack. The kernel calculates that and provide it via getauxval(AT_MINSIGSTKSZ). AFAIU, calculating the minimum stack size for a signal handler based on getauxval(AT_SIGSTKSZ) may lead to errors because there are no guarantees that getauxval(AT_SIGSTKSZ)/4 > getauxval(AT_MINSIGSTKSZ), even if that is true now, it isn't future proof. Besides that, the test I suggested to implement would guarantee that glibc code remains up-to-date according to the interpretation that is adopted. Thanks for elaborating your explanation! That was really helpful. --=20 Tulio Magno