From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id EB793383EB01 for ; Tue, 13 Dec 2022 20:56:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB793383EB01 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 27E4232002FB for ; Tue, 13 Dec 2022 15:56:49 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Tue, 13 Dec 2022 15:56:49 -0500 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=1670965008; x=1671051408; bh=NkIyCjULHZ Ggyt6pkOQUV69XSVpyVo2sWkm3PuiPd5s=; b=O37R93MvVGb1knhgncNH6loSKJ OTVTHmE6Cg27BSxCVBrOY1x4zLM3eNqTZM8uDaJsi4uu8ssT5Z/J85aXMLtsyHiV mNtHSSlGQF7BQsB2nSHytsQ/1IzYz6QjV1UomKQ3F3enKdxgjG/w8Xki/4Ar1bik Xb5T6l08wNTFlX4AcDzvDOAYRbFXIcz2Mtf2wJC/HIMogFRqwOZnOCFTpVc4B5Ut Dkhr56BufyKDMhqpDN6NDw+YJzdrTvYAsTkz9qICdwtygVW+Tq2A59Mbju0/b9/p G2G+J1tQSnedkJBRJgw2yalg+csJ/AXcw1i3I+EH9owOBLOXlodHrPd6d5hA== 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=1670965008; x=1671051408; bh=NkIyCjULHZGgyt6pkOQUV69XSVpy Vo2sWkm3PuiPd5s=; b=UlJ2o89k/MrgkPzp59j/YWM5juJCt86uVNXYJwWpgZiG M/5KCIxlFjfvso75LOxwDSnqvKuoKQGoNFF9m5WXjYdW4PCuYrpoJjcYy8wS1EPX 11nAwlRWDsCT2y6FR1B47JZJsJLOBJphintj3ihsSO/YqiWsibC40LnpEXtMGZP1 gXINXfgwmE/QNnyOrpNETB0QpW3x+/OubQsnSGWaAS1ij7sh6fPFxQJ8UbDMx6MF f9qr9buQW7JmkdWwmUfz3yAaw0egs7EQicykkr+Rhnun3kdf3aeM2Ox0NzFaxiDH rwZos3wYb29SAf6gitkUTpPeTEME+zGX5Ccxatrp3Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedugdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfkggrtghk ucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecuggftrf grthhtvghrnhephfeuhfevueffteffgfejtefgkeekheeftdeflefgheffffevheekleef gfehffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A349272007A; Tue, 13 Dec 2022 15:56:48 -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: <38450ca5-599d-4e5d-b2db-be01856680cb@app.fastmail.com> In-Reply-To: References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <0b2901d90f26$f82b4720$e881d560$@yottadb.com> Date: Tue, 13 Dec 2022 15:56:26 -0500 From: "Zack Weinberg" To: "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=-3.4 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, Dec 13, 2022, at 2:25 PM, Noah Goldstein via Libc-alpha wrote: > On Tue, Dec 13, 2022 at 11:13 AM Narayanan Iyer wrote: >> Thank you for acknowledging that it is a bug. > I'm not sure this is a bug, I'm just saying to avoid this behavior you can > make that change. > > I think we all agree supporting a correct non-atomic memcmp when the values > in memory can change during execution is not reasonable. > I think SIG11 is not a great outcome (of the many possible behaviors when its > incorrect), but am not sure it's worth fixing. I think it would be reasonable for glibc to make the following weaker guarantee: for any call `memcmp(a, b, n)`, if the data pointed to by `a` and/or `b` is being concurrently modified, the return value is unspecified but *not* indeterminate. Also, memcmp will never access memory outside the bounds [a, a+n) and [b, b+n), no matter what. This would, I believe, be sufficient to prevent a crash under the conditions described by Narayanan Iyer. zw