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 C53863858D28 for ; Wed, 3 May 2023 17:48:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C53863858D28 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 424D46416F4; Wed, 3 May 2023 17:48:49 +0000 (UTC) Received: from pdx1-sub0-mail-a213.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8AC5964226F; Wed, 3 May 2023 17:48:48 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1683136128; a=rsa-sha256; cv=none; b=D0A11LWplSICr8VE+yXp/c4TCPqCOKKCxKlpz4ye3PtVK7yYKnPXcpTXPYWJoz3vWGTKhV 1wRhhmIPfTgHuTFPlA/JyvcEkjEh+xvFXCY9SAjNJQtv1iFL5vbHY+2pm3O47Ka0Bq8Dg6 73nSIIVMOMyQHkIc2GMt6CSFwLAS7sRlgFirNHaNVCGEwjGB9kXBtp/9LbdXyYxpWxSSRK NCo2bIFXwIXlMx+cqDeGQ3animpOi9jV3PtU+hln10/dlPRUVfGR49bwAe3gbdN9Wlll4r yQG1NyxyseazqJAN/icrctjCIoOZ+wW9J4sx+NG6OwTIqZHP/Ww44zcOdOjmJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1683136128; 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=0GGvBp59PJvFO4Sc1zOE+mKL6IQUqYmNh+oS2FfzP7A=; b=UQQ6CuTtH9u8RxNZaltgcvDnu1t1Q+MLnIgPzmeggV05qpjFfnxDBzEcUCqIATzLL5zZM2 jOI02rggtIs2CsHrlc+3jh1ggni6cEGmLYW/eA9rXhZEs0Flc6GXTud4Bpc3jTPc17HrD1 y9rfL/5OI8bAcNvfbNOEy70WE2AzCPS4m7za5U9vZ9LBu3FwLhgZ6Jk+WVZctgUoHX2S09 bI0F+Rp+lKcK2WZtjbEFRx8K0o1gKqAiCbzHifhp1Vi9+ldAEZFsxEYbWoccAPbS6GyKBx DGDA6wNF8XffbGI7inVOqDWQ7jOokygtjr2Or5debzZO5wdF2jjvYvJiDS130Q== ARC-Authentication-Results: i=1; rspamd-5c4597ccb8-4vfbp; 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-Descriptive-Stupid: 3c7bcfa93cd76d7b_1683136128846_2926821906 X-MC-Loop-Signature: 1683136128846:3721090486 X-MC-Ingress-Time: 1683136128846 Received: from pdx1-sub0-mail-a213.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.217.248 (trex/6.7.2); Wed, 03 May 2023 17:48:48 +0000 Received: from ascii.art.br (ip-187-73-3-200.isp.valenet.com.br [187.73.3.200]) (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-a213.dreamhost.com (Postfix) with ESMTPSA id 4QBPZR5MRvzFg; Wed, 3 May 2023 10:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ascii.art.br; s=dreamhost; t=1683136128; bh=G4asmL3j+Rl8GFKr6oyaY+8Dt3xBNf2uISfYl8O4pFI=; h=From:To:Cc:Subject:Date:Content-Type:Content-Transfer-Encoding; b=ClfwICdmFfB1nO2j0NmO08fX5zvDtV1CVctI+y6zaSTuq8WCXmspjpNF0u7gyDbzF d8EUkK8T6c/pcOXlz1g+HkxwbdnlDokwVC+YQiut/tqtTCxv8543021bne8u6aOd8Z MiLueZ0caimoydnrXTbwOiawSZjpgaDdMACvu2a91qckGT2aiYKBdydaW++6docYJq yIoW5i4LH3VzNQX/yErLcmDDFmbm+0hpztGbXtZY1O9BcoLwdZPz4/u6hvdwNiMD2D kAwyGG6i82gzIEMDUkERZgVxLpqV3cba9nju/dl5IOYW2rVaqu7sDsTSwsb13Icl58 ygnC27rL8so7Q== 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: <7620a9b1-fe92-0764-6011-81d3a19e5590@linux.vnet.ibm.com> References: <20230424105208.301614-1-mmatti@linux.ibm.com> <874jozevbl.fsf@ascii.art.br> <7620a9b1-fe92-0764-6011-81d3a19e5590@linux.vnet.ibm.com> Date: Wed, 03 May 2023 14:48:43 -0300 Message-ID: <871qjxe26c.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_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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? 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 change the value of AT_MINSIGSTKSZ. >> If we reach consensus that both macros in this file can have values set >> at runtime, then I it might be worth adding a test in order to check that >> dl_minsigstacksize, MINSIGSTKSZ and AT_MINSIGSTKSZ passed by the kernel >> are identical. >> > There are testcases which already use MINSIGSTKSZ > > sysdeps/pthread/tst-signal6.c > > signal/tst-minsigstksz-5.c AFAICS none of these tests are checking if dl_minsigstacksize, MINSIGSTKSZ = and AT_MINSIGSTKSZ have identical values. AFAIU, at least on powerpc, they should always be identical. Having such a test would help: - to signal if the kernel changes it without a warning. - if another commit changed one of them by mistake. AFAIU, the tests you pointed out help to identify if the current sizes are indeed enough to handle signals, which is also very important. --=20 Tulio Magno