From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 50CB2383A0C2 for ; Wed, 14 Dec 2022 02:30:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 50CB2383A0C2 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 compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 195165C0166; Tue, 13 Dec 2022 21:30:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 13 Dec 2022 21:30:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding: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=1670985023; x= 1671071423; bh=TN6VfaK+F/5PHW3DAz2WkC/edz5i9Nv0B/memDrtjz8=; b=e H9ei5QUC9dTuVZYitwKDHSGI1qmd3/8EOpKvpHZzF3O1VlEyKAFBDDmRDyqgyc7D KnqZd+juhGdGn3F8c6d8d5FHdTmiJbF78jnAVKBNMhZQ4VwFV579PlwVvV27AfwF 3i+sM5jQ/Jkw9QhWur2GMQoiGmOkn/xSiv4gomCzD8Q2XsW2+PmHO0dI5kMJHj88 13nkXjrrpivCVkGf+kH0wnVdvikE1ylkSz2rDFySZ4sulWnZwgs3tJ5mNTHMkFDR vJynsOi8uJEkPGLmAVh0uOu1PPvOFe1kWyrkSHxXm8g1+nVipW+Q0EQiEWr4zfXb By/z3MnAXKG5Ax+29rWiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=1670985023; x= 1671071423; bh=TN6VfaK+F/5PHW3DAz2WkC/edz5i9Nv0B/memDrtjz8=; b=c MX47Ko9GY63O63WOApoMf5dBRaVLTdUXXV4cfD1Ux4t2MqGkORZaT7opsz+ZPxZe IN/lPTR+MQIsh60corRh8hBkr8cwNhvoc+VJth7U1OHDIgZU8k3XIoT0Y9DrLKwK Puxrscc0uVbaql5+KUbE4eiOcrQKwlR4XEoJozEtl1nPOuDQI5xiAgwFuEJdkOlF IxjXSarwgSLoSjW0KmR67i/eJ7ct6H5o12AxoB5ublDkhl7eDqrInMXJfWPo7ITP 7ZK6wmBdaSwVlsLyW/Mhaj/0uAQlrK4HyadaPlUqq3Ec6CKtcxMJYKeyTszofPF1 zrrdLPsHO1oOs11VDDc7g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedvgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufhfffgjkfgfgggtgfesthhqredttderjeenucfhrhhomhepkggrtghk ucghvghinhgsvghrghcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtffrrg htthgvrhhnpefhvdevuefgjeeuheegfeejhefhheegkeejhfejhffgveduhfehjefggfel fffgheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe iirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Dec 2022 21:30:22 -0500 (EST) 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 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: Tue, 13 Dec 2022 21:28:37 -0500 In-Reply-To: <736bb5b6-f9d5-b541-f983-1e5026aaacfa@redhat.com> (Carlos O'Donell's message of "Tue, 13 Dec 2022 18:29:52 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.1 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_H3,RCVD_IN_MSPIKE_WL,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: Carlos O'Donell writes: > On 12/13/22 15:56, Zack Weinberg via Libc-alpha wrote: >> I think it would be reasonable for glibc to make the following weaker gu= arantee: >> 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* indeter= minate. >> Also, memcmp will never access memory outside the bounds [a, a+n) and [b= , b+n), >> no matter what. > > I disagree strongly. I=E2=80=99m really surprised to hear you say that. To me this is a natural guarantee for memcmp =E2=80=94 in fact, for *all* of the mem* functions =E2= =80=94 to make, to the point where my reaction was *of course* this is our bug! > These are advanced lockless techniques. > They should be hidden behind new APIs that provide the required guarantee= s. That the application was doing =E2=80=9Cadvanced lockless techniques=E2=80= =9D is, to me, not relevant in the slightest. The important thing to me is that the memory regions `memcmp` is allowed to access are wholly specified by the mathematical values of its three arguments, and *not* by the data pointed to by the first two arguments. Nothing any other thread does can change the fact that memcmp has no business touching bytes at addresses outside [a, a+n) and [b, b+n). Why do you think it is important for the C library to have latitude to break that aspect of the mem* functions=E2=80=99 API contract? Even if only under exotic circumstances? zw