From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 06873383D5F6 for ; Tue, 13 Dec 2022 19:25:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06873383D5F6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62c.google.com with SMTP id m18so39068793eji.5 for ; Tue, 13 Dec 2022 11:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1LI9TAb+ERfALf4bOt+3PkuLhLcXLIu3Cf9sDo51PDw=; b=hQXuq6FxU/Bretm0tapqkQ+8h1fFtUyk5bJBKFXLO3mD9zaCnp8i89zRdcUDMhsEZl x4yO/KUoZo2wYkmGmFwY96jkDEN1Jkdcm25Q0ORx0ezFy1UlWfG1lx5tTMYsbgQOCDy0 jxtqZM2JJ6Y8BQLhn/4CMfJrT7lGq+BSoDxnFwOGx6ocCj4NSfZSlcirEuRbTvX/B6Wu MRHc4eIr6v0li15IOyDEEuzw4SPtOYPDifP5PR9F5LnBOkxbA1vPHHIPo7P7W3rfWwPY 8TeORQ6it0BmMZJS2AVXGF+nCA2ljTjl8K4O8WQOWVMejoZcPwa/LpfNPPELJfndSQ/T ceGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1LI9TAb+ERfALf4bOt+3PkuLhLcXLIu3Cf9sDo51PDw=; b=y2Le8Hzph6ocpRZZjQ2JWN9czm7ZIHNNmnBf97mZbhzwWu6cFKwjiVdHm6CyspyEB0 drs0tYk10WbLVrKWMOskOdmJ39algya1FRTw12WER3pY+v6UnpmmSrHunFDBq/XRCoh6 S0teECKdxr/cQB5+ANVSJCAWhUd69gixNVRA9guzuQbwl7fWKfxOgHoA77nttzwo+MGp nmZsP23MHVa5nvNcqaIa6Z/HTT2lV8T6Siw3fW5nY/T7UA9fnA3boAhfQuai7HNWjwVu C2M38FWUIV7I2sVTplMVnxyyLT7kn11XGN9iTxoJl8y7VsE8mDPEKcGd66OcJCQcHqDj MBbQ== X-Gm-Message-State: ANoB5pnnF8H8APqCztneiSGQiq+nR9Ax4TvueAYoPig7xVm27A1nOrS+ DYdqJTE3OZ4v5Wwk0daVS/S840kWUsiTfvjKWinH5NYb274= X-Google-Smtp-Source: AA0mqf786/D9qhF1ODUyI1kijJlD/ZiO8tTvFPI/uiCggRSnLq1s7ZZv3V9xQLCpZkWv1v8iK+Ii6KHRXT4ZVsySJcQ= X-Received: by 2002:a17:906:d211:b0:79d:f5f2:6f55 with SMTP id w17-20020a170906d21100b0079df5f26f55mr61152548ejz.531.1670959556739; Tue, 13 Dec 2022 11:25:56 -0800 (PST) MIME-Version: 1.0 References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <0b2901d90f26$f82b4720$e881d560$@yottadb.com> In-Reply-To: <0b2901d90f26$f82b4720$e881d560$@yottadb.com> From: Noah Goldstein Date: Tue, 13 Dec 2022 11:25:37 -0800 Message-ID: Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change To: Narayanan Iyer Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: On Tue, Dec 13, 2022 at 11:13 AM Narayanan Iyer wrote: > > Noah, > > 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. > > In case it helps, I found in our testing cluster, that a system which uses sysdeps/x86_64/multiarch/memcmp-sse2.S has the bug whereas a system that uses sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S does not have the bug. I wouldn't count on any of the other implementations being hardened to this. > > So it is possible, the issue is only in the sse2 version. I did a quick check of avx2/evex and don't see the same pattern but I think it might be present in the tail of the loops (end of much larger copies so probably comes up less). > > Thanks, > Narayanan. > > -----Original Message----- > From: Noah Goldstein [mailto:goldstein.w.n@gmail.com] > Sent: Tuesday, December 13, 2022 2:08 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:20 AM Narayanan Iyer via Libc-alpha > wrote: > > > > Hi, > > > > I had created a glibc bug report at https://sourceware.org/bugzilla/show_bug.cgi?id=29863 > > > > 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). > > > > 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. > > > > > > The fix: > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-sse2.S;h=afd450d0206d6633da9fbc4607a7fa6aeb4e137c;hb=HEAD#l46 > ``` > -# define SIZE_OFFSET (CHAR_PER_VEC * 2) > +# define SIZE_OFFSET 0 > ``` > > Is this something we have to support? I believe other functions / > implementations > of memcmp will suffer from a similar bug. >