From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 49194385840F for ; Thu, 6 Jan 2022 22:13:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 49194385840F Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 206KGcNc009217; Thu, 6 Jan 2022 22:13:09 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3de4x2vbjg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jan 2022 22:13:09 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 206M884m002993; Thu, 6 Jan 2022 22:13:08 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com with ESMTP id 3de4x2vbja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jan 2022 22:13:08 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 206LvBjJ022540; Thu, 6 Jan 2022 22:13:08 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma03dal.us.ibm.com with ESMTP id 3de4xf5pmt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jan 2022 22:13:08 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 206MD7Wh34930948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Jan 2022 22:13:07 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2947F112065; Thu, 6 Jan 2022 22:13:07 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE6A7112069; Thu, 6 Jan 2022 22:13:06 +0000 (GMT) Received: from linux.ibm.com (unknown [9.65.244.125]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 6 Jan 2022 22:13:06 +0000 (GMT) From: Tulio Magno Quites Machado Filho To: Florian Weimer , libc-alpha@sourceware.org Cc: Szabolcs Nagy Subject: Re: [PATCH] elf: Fix fences in _dl_find_object_update (bug 28745) In-Reply-To: <87tueie1lf.fsf@oldenburg.str.redhat.com> References: <87tueie1lf.fsf@oldenburg.str.redhat.com> User-Agent: Notmuch/0.34.1 (http://notmuchmail.org) Emacs/27.2 (x86_64-redhat-linux-gnu) Date: Thu, 06 Jan 2022 19:13:05 -0300 Message-ID: <871r1k7bta.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 1EMsmHqS7Ta57accxjqfj9XdpIyBDcKE X-Proofpoint-GUID: 45dyPy0Yv6Ajp48k60RzHoTRYd8j1c9q X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-06_10,2022-01-06_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 phishscore=0 mlxscore=0 clxscore=1011 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201060136 X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 22:13:12 -0000 I haven't been able to reproduce the issue after applying this patch. I've found a coding style issue: Florian Weimer via Libc-alpha writes: > diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c > index 721fed50d6..a2f7144a34 100644 > --- a/elf/dl-find_object.c > +++ b/elf/dl-find_object.c > @@ -293,8 +297,20 @@ _dlfo_mappings_end_update_no_switch (void) > static inline bool > _dlfo_read_success (uint64_t start_version) > { > - return _dlfo_read_start_version () == start_version; > -} > + /* See Hans Boehm, Can Seqlocks Get Along with Programming Language > + Memory Models?, Section 4. This is necessary so that loads in > + the TM region are not ordered passed the version check below. */ > + atomic_thread_fence_acquire (); > + > + /* Synchronizes with stores in _dlfo_mappings_begin_update, > + _dlfo_mappings_end_update, _dlfo_mappings_end_update_no_switch. > + It is important that all stores from the last update have been > + visible, and stores from the next updates are not. > + > + Unlike with seqlocks, there is no check for odd versions here > + because we have read the unmodified copy (confirmed to be > + unmodified by the unchanged version). */ > + return _dlfo_read_start_version () == start_version; } ^ Wrong indentation here ^ Closing brackets here Thanks! -- Tulio Magno