From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender4-op-o10.zoho.com (sender4-op-o10.zoho.com [136.143.188.10]) by sourceware.org (Postfix) with ESMTPS id EAD74385B53E for ; Tue, 13 Dec 2022 18:39:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EAD74385B53E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yottadb.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yottadb.com ARC-Seal: i=1; a=rsa-sha256; t=1670956752; cv=none; d=zohomail.com; s=zohoarc; b=MN9vU9GycRpP+mNET8XRwg/UuxSM+qVxAZFDmTmszhFjvOSvIWGH4Cw4T77VaKEw26rEsFr75BWlDuC+6CCaSfXKeUgAww6RcQmVC7G2BJ7uwesbMgSD9ya8SDEIbQy5gmp7anLSDQE3OeL5/DRtpG7x/jQyLMuUz/OVekngh5M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1670956752; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=3Sutzg7Ae4wQ3sOzuQjJxg8QqV1Cz3xZJYIOEQFmFrs=; b=NSdWIkERH1sh8jcCN9Hty6L5kJGIC5+6vq//jbH6HiMsxHhzyj+cDJDz5u406MvH8WC9x3a0nW5lgDQKSf/TkbgEhMEh2V1seBz1uQ9VppuFyDbc/wF4OZF++YO4UlArS5kfC3RFZtt+wxsPXlBcVAVPSGXuXD22iL6CQkPOsZ0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=yottadb.com; spf=pass smtp.mailfrom=nars@yottadb.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1670956752; s=bam5eec4; d=yottadb.com; i=nars@yottadb.com; h=From:From:To:To:Cc:Cc:References:In-Reply-To:Subject:Subject:Date:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=3Sutzg7Ae4wQ3sOzuQjJxg8QqV1Cz3xZJYIOEQFmFrs=; b=X6rUZmHdk6QJNKoHdf9UV26lwIJ2/0/TBgHx7uBZM3NbcPmwQ9LBgvux2kAZgpSK 8T2tVg1mHaozya5zuA0V0e9MuCnUWP3IoTcM92xHVcuV+klJO+Sqe8JGcSIDHMaFDJa rt5PXCkcJMJBcq3gikKo1JiUORalcHPf4iQgS6Vk= Received: from NARSWIN10 (static-71-162-243-192.phlapa.fios.verizon.net [71.162.243.192]) by mx.zohomail.com with SMTPS id 1670956751152380.7976359156569; Tue, 13 Dec 2022 10:39:11 -0800 (PST) From: "Narayanan Iyer" To: "'Andrew Pinski'" Cc: References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> In-Reply-To: Subject: RE: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change Date: Tue, 13 Dec 2022 13:39:08 -0500 Message-ID: <0a6401d90f22$306dfec0$9149fc40$@yottadb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKROsKQEAZD5rTjp9SCqSDmRSA/8wJWvJHRrOkYF6A= Content-Language: en-us X-Antivirus: Avast (VPS 221213-2, 12/13/2022), Outbound message X-Antivirus-Status: Clean X-ZohoMailClient: External X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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: As I also mentioned at = https://sourceware.org/bugzilla/show_bug.cgi?id=3D29863#c3, it might not = be a well defined test case. But memcmp() is never expected to SIG-11 in = any circumstance as long as the buffers it is passed in are accessible = from start to finish. In the same bug report, I had also provided a timeline of the = instructions that I believe got executed in the crash case and pointed = to the failing assembly instruction. The test case was just a easy way = for you to see the problem yourself. Even if you don't accept the test = case, can you take a look at the rest of my bug report to see if you = agree with the finding. Thanks, Narayanan. -----Original Message----- From: Andrew Pinski [mailto:pinskia@gmail.com]=20 Sent: Tuesday, December 13, 2022 1:32 PM To: Narayanan Iyer Cc: libc-alpha@sourceware.org Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory = contents can concurrently change On Tue, Dec 13, 2022 at 10:21 AM Narayanan Iyer via Libc-alpha wrote: > > Hi, > > I had created a glibc bug report at = https://sourceware.org/bugzilla/show_bug.cgi?id=3D29863 > > And have included the title of that report in the email subject as = well. > > It has been a week since I created the issue and I did not hear = anything back. I believe this is a regression in glibc 2.36 and have = provided enough information in the bug report (along with the commit = that caused the regression). I don't see how this is a valid well defined testcase. Changing memory without barriers in both threads is not well defined. memcmp is not guaranteed to be atomic or have any atomicity either. So you just happen to work before and now your undefined code does not = work. Thanks, Andrew Pinski > > Given the upcoming glibc 2.37 release, I was asked (by Carlos O'Donell = ) to raise it on this mailing list to get the = attention of the glibc developers. > > I am hoping one of you could take a quick look at the bug report and = see if it is worth fixing it in time for glibc 2.37. > > Thanks, > Narayanan. > >