From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id 1D8DD38582AA for ; Wed, 21 Sep 2022 12:41:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D8DD38582AA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AF4FB320090C for ; Wed, 21 Sep 2022 08:41:28 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Wed, 21 Sep 2022 08:41:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1663764088; x=1663850488; bh=TVebTYYEhB uECxDixe1srMKQrDdgb/6inx1mtUrahVI=; b=BH/gu2N4cuTBdg5ML+x6wGG9vi Kg3E2EEAfM2Q37DsKLcSk3cilyGPYLYJFuoE8+6ag13hqjPI1XYa56FlPZH9YqZV eXk5K4EvewgJEn6fNa00x7nes/d32ZFeAlSWEUXgDt+XbJq4koNCBM9v6Mccq71N 6owHNnRsc3OsOtWfpT4sOisv8lAzMmHllEELaJxhRKnEOgqoEBlzAa6c1iz81Gge kbnF9NyEA2K0eaLcvkBV8Dk1s+4zCjWpbo75Moj034dIaRteJgHt/3YRAsN7Q84H BBli2k/0X11V0HNWLlqiZw2+RGBW7aUfEdkKqKlgyKYLEqfLlr//zphp+OiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663764088; x=1663850488; bh=TVebTYYEhBuECxDixe1srMKQrDdg b/6inx1mtUrahVI=; b=iQ70gBsFezq99HiMpEFfE/50EUVnZbFyL0wcdnl1Q9X6 6JFFPobZuRZUFHk1iO7N18AJ2tC06pSV8Nmuck/3QpQjlelHBoV6vGQVEAIjGcPQ ubyXnSmsj5YvCxsBjP5TAzekIxvfgDZ224p3d/bMUymyD7BRxpMv3jBqZbBFjJRD HH3DD6pKr5R7HntBS1TrWiuQrmzS1C85ENUToWbdtR+bqFagoSBLiTPKsHCMxq9f WE9UaQUW2YfqXx2pBR71T5eE62MCy4mlLnKXOFNp5TR9/4FyU2xrBZWETHq9NlsE Vdh1R6fnwPNJX2MaJhd3WEsLfxnpDyIyGkJcF0D5rA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefuddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhuefhveeuffetfffgjeetgfekkeehfedtfeelgfehffffveehkeel fefgheffudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E88042720078; Wed, 21 Sep 2022 08:41:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-935-ge4ccd4c47b-fm-20220914.001-ge4ccd4c4 Mime-Version: 1.0 Message-Id: <354f7066-9b7d-47f2-944f-0512d1437627@www.fastmail.com> In-Reply-To: <87y1uemebf.fsf@oldenburg.str.redhat.com> References: <79dae81f-8e33-4499-a47a-93cc0903be6a@www.fastmail.com> <87fsgvvbwq.fsf@oldenburg.str.redhat.com> <9d232b1b-f123-4189-bf09-dd29aab6486a@www.fastmail.com> <87y1uemebf.fsf@oldenburg.str.redhat.com> Date: Wed, 21 Sep 2022 08:41:07 -0400 From: "Zack Weinberg" To: "GNU libc development" Subject: Re: RFC PATCH: Don't use /proc/self/maps to calculate size of initial thread stack Content-Type: text/plain X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP 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: On Tue, Sep 20, 2022, at 8:16 AM, Florian Weimer via Libc-alpha wrote: >>> Maybe we can get the kernel to pass the end of the stack in the >>> auxiliary vector? >> >> Sure, but then what do we do on older kernels? I'm reluctant to say >> "keep the old code" because we know this is breaking for people right >> now (although honestly "mount /proc earlier" isn't a terrible >> suggestion for a workaround). > > We can keep doing what we are doing on older kernels. I don't think we > should add yet another fallback path for this in case /proc isn't > available and the kernel doesn't provide the (future) AT_* entry. *Two* > fallback paths instead of one seems a bit over the top. Fair enough. I have no experience writing kernel patches, do you know anyone who can make the additional AT entry happen? zw