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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 655763857C40 for ; Tue, 11 May 2021 02:56:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 655763857C40 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-391-2Eymhjt4NN6_rJlVO7i9pQ-1; Mon, 10 May 2021 22:56:05 -0400 X-MC-Unique: 2Eymhjt4NN6_rJlVO7i9pQ-1 Received: by mail-qv1-f71.google.com with SMTP id d21-20020a0caa150000b02901e2ed83f922so6952860qvb.4 for ; Mon, 10 May 2021 19:56:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ehIn3+QMZLJAM+IlaA6U7+vkoEUT2jb37HQxpdD7xjA=; b=IVN4qtvCDewfBNzhD1dD+nHA+zYRXVND5CWpYWWbPmRCeimj8JpsF8ZahL5ikrwYAG hXivrCDsXe6yyEjMZdP3o6Z/GOet4orjP8WcWuoREFyGm5Wb/WkcwAkG5erx1h33eHQf Is4NvRUpeXAHgtbp4NeNa5OExNFa5mg3pwpY3OvdDjKwtfdmON6suS6dokP+rJ7J/pgp ovvIDiRnziKRV9YYRri84hrIAYWWIy7cSsH8CmyFskcMp1YlZSGtv9sA7njx+lcBCdWY 255ziFXwR2DMNRDcI7+VUcCwRnRHBsAhnSBmtrBOE+2ok+2gpbF8AOOEXTuzXhVER8V0 LOLw== X-Gm-Message-State: AOAM5327QqrGq1GmppN1hfkMDacoqRPNPM4Vmezj4lLRmIaAXPgc9heN Hf68oOvDlYtpQCXrqdC88Jyrl12Ns5fBmuKcvPqgudmBEqUYts2Vl0F7jIuj/6uhibGZ9IyO55f b12Tq3ziNEGa7SacaBzgD+Jh6Fu6BWe5xk0I2hjSifvAytcgtgk7QqLGuy6D8GZKwPryODA== X-Received: by 2002:a05:620a:4494:: with SMTP id x20mr11362449qkp.478.1620701765035; Mon, 10 May 2021 19:56:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRDRRdMpI8yJ2PGI9twydW0rqNvfZt103yZ3KaZZhlX9jRFSX0J6WyxJRi9vPWvrL4psUkNQ== X-Received: by 2002:a05:620a:4494:: with SMTP id x20mr11362438qkp.478.1620701764804; Mon, 10 May 2021 19:56:04 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id a189sm12664362qkd.46.2021.05.10.19.56.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 19:56:03 -0700 (PDT) Subject: Re: [PATCH v2 06/14] elf: Use relaxed atomics for racy accesses [BZ #19329] To: Szabolcs Nagy , Adhemerval Zanella Cc: libc-alpha@sourceware.org References: <10fb15a36b3f6bc3e5ca62cda081c86512f47d32.1618301209.git.szabolcs.nagy@arm.com> <37965321-dec2-f901-325c-ac4bad72484f@linaro.org> <20210416091256.GA30290@arm.com> From: Carlos O'Donell Organization: Red Hat Message-ID: <0a69a61e-5500-8e01-658d-c5e4896c6489@redhat.com> Date: Mon, 10 May 2021 22:56:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210416091256.GA30290@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 11 May 2021 02:56:09 -0000 On 4/16/21 5:12 AM, Szabolcs Nagy via Libc-alpha wrote: > The 04/15/2021 15:21, Adhemerval Zanella wrote: >> On 13/04/2021 05:19, Szabolcs Nagy via Libc-alpha wrote: >>> This is a follow up patch to the fix for bug 19329. This adds >>> relaxed MO atomics to accesses that are racy, but relaxed MO is >>> enough. >> >> Could you extend a bit why relaxed MO should be suffice? > > is it ok to change the commit message to: > > This is a follow up patch to the fix for bug 19329. This adds relaxed > MO atomics to accesses that are racy, but relaxed MO is enough. Suggest: This is a follow up patch to the fix for bug 19329. This adds relaxed MO atomics to accesses that were previously data races but are now race conditions, and where relaxed MO is sufficient. > The racy accesses all follow the pattern that the write is behind the s/racy accesses/race conditions/g > dlopen lock, but a read can happen concurrently (e.g. during tls access) > without holding the lock. For slotinfo entries the read value only > matters if it reads from a synchronized write in dlopen or dlclose, > otherwise the related dtv entry is not valid to access so it is fine to > leave it in inconsistent state. Same for GL(dl_tls_max_dtv_idx) and s/it in/it in an/g s/Same/The same applies for/g > GL(dl_tls_generation), but there we rely on the read value being larger > than the last written value that was synchronized. Do you mean to imply that the synchronized writes all increase the generation counter, and so any out of order reads rely on the value to be increasing? Suggested: The same applies for GL(dl_tls_max_dtv_idx) and GL(dl_tls_generation), but there the algorithm relies on the fact that the read of the last synchronized write is an increasing value. -- Cheers, Carlos.