From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B5C52382FADE for ; Wed, 14 Dec 2022 12:07:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5C52382FADE Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671019624; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uItVGZ4QGgIAYbd5ZHe1nJ1C/xIN+J/Tec8YrXVTgd4=; b=ZzVLX8/LCR6iZyTcd7hpNNJ29wf0+ECYbuWRSLi8MErbCNRMysa+1agID51XEfCSyz4GT/ yq0Gfc7gFVNTrbw6Yyfo+iEcjO6p6DGjJfNi57BaD7y3brRkOgoujkrb/aRuRnQ4g0ysCD 7qDinMn6KoXC1GinQGoBrKl5wxqynn4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-656-yc_3EQdSN5qLs0vRdgoIzg-1; Wed, 14 Dec 2022 07:07:00 -0500 X-MC-Unique: yc_3EQdSN5qLs0vRdgoIzg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9B03A811E9C; Wed, 14 Dec 2022 12:07:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 92EC614171BE; Wed, 14 Dec 2022 12:06:59 +0000 (UTC) From: Florian Weimer To: Noah Goldstein Cc: Noah Goldstein via Libc-alpha , Narayanan Iyer Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <871qp380hp.fsf@oldenburg.str.redhat.com> Date: Wed, 14 Dec 2022 13:06:56 +0100 In-Reply-To: (Noah Goldstein's message of "Tue, 13 Dec 2022 14:59:32 -0800") Message-ID: <87o7s6mbof.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * Noah Goldstein: > On Tue, Dec 13, 2022 at 1:20 PM Florian Weimer wrote: >> >> * Noah Goldstein via Libc-alpha: >> >> > Is this something we have to support? I believe other functions / >> > implementations of memcmp will suffer from a similar bug. >> >> Of course the crash is by no means deterministic, so I'm not sure how >> useful it is to detect application bugs. Maybe papering over the >> application bug is the right approach here. >> >> On the other hand, I really don't see how such a racing memcmp call >> could deliver any useful information whatsoever. The result will always >> be arbitrary in practice. So I hope such application bugs are really >> rare. > > The usecase in the bugzilla is optimistic reads in concurrent > databases. So what happens is that whatever the result is, it is still validated with some separate mechanism (e.g., a seqlock or some other form of TM)? That does not seem unreasonable at all, so I'd be in favor of supporting this, given that the cost is so low. Thanks, Florian