From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by sourceware.org (Postfix) with ESMTPS id DC7063883F26 for ; Wed, 14 Dec 2022 14:16:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC7063883F26 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 1C7F032005B5; Wed, 14 Dec 2022 09:16:55 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Wed, 14 Dec 2022 09:16:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc: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=1671027414; x=1671113814; bh=L0kh+gmk9M cVeN5MpQmhNGjDTugturFO1ZGf3H8oAKU=; b=ie9R08H51bj9cMdiX2H9Wz/6fD UA+ScxY0UJupRzMEM5KeGh0TBcf1ftIWh1zYzgU1p4UxpkrEvVuaAeH9ckVzjlu5 SWV9iUNopzfkqcpOhHMwb1DntV9NiluJtGWV9VBWX9hHR+fBnPN38Y+V22pjw9I1 lGRUEem8XulqOECI4EkIaQ64YxhQjMsDBJ3i+5JRvIgDnFxmOazGaHgknBbzmsRf lWH79MPyfhI7tP9nGmE9a4V4uGpEMyOfD08DNwweczew1LTkZJU9AeN/yjjeIO2Q 6Q65m6LdreOyTSQrqFtnn7Y+35wD45WaVVk5MFdMIxmVEveuxgxNCJv+5CkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1671027414; x=1671113814; bh=L0kh+gmk9McVeN5MpQmhNGjDTugt urFO1ZGf3H8oAKU=; b=gwFlsIsTro+1gEAQPCaBQ4Dt/40ibzwp8+emawBxU9SR XM8K7pGde57vbC/1gi/cyEoWwMKfHhY78g/ISUAcs/QBOnSPwUVo/i1X3k3bU878 sCWfhF5yFoJLBB2e0ox37LLQngEabJlVXshHOkfrrEt9Q3E2hNi7fXcrFyFpYBKz lrrgE/v/hO6PqFBR6PHC5wMIJdwimMp8vy3dOHii+K9jXcEJqP2gP6A0TzZP5uzY ar1uW5syXhgpLQaQySCgpGunh5bdtKdQS+DrwrefeerMvCYojpiyYFQITtyI2WCy ufrYnRPEeRzwnfkbT5omIYDcTONBWxutf8dBjwR35g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhleefheduhfelgeehgeejveehueeihedvgfeuueetteelieeiteeh fefhleduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6CA79272007A; Wed, 14 Dec 2022 09:16:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <663fab35-0f08-4b36-a653-0145c36ca7f8@app.fastmail.com> In-Reply-To: References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <0b2901d90f26$f82b4720$e881d560$@yottadb.com> <38450ca5-599d-4e5d-b2db-be01856680cb@app.fastmail.com> <736bb5b6-f9d5-b541-f983-1e5026aaacfa@redhat.com> Date: Wed, 14 Dec 2022 09:16:16 -0500 From: "Zack Weinberg" To: "Carlos O'Donell" Cc: "GNU libc development" Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,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: I'll respond to this at more length later, but I want to point out that this statement ... On Tue, Dec 13, 2022, at 11:16 PM, Carlos O'Donell wrote: > The standards are in no way prescriptive in saying that memcmp shall not read or > write to memory outside of the input domain. ... is (as I read it) contradicted by 7.1.4p5 (N1570) "A library function shall not directly or indirectly access objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's arguments." There is more wiggle room in this wording than I'd ideally like, but since memcmp has no way of knowing whether any particular piece of data outside the ranges supplied as arguments is "accessible by threads other than the current thread", it needs to be conservative and not touch any of it. zw