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 ESMTP id 06BE43853834 for ; Wed, 12 May 2021 20:33:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 06BE43853834 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-460-Q2v6SegvPFWqlHjUnIVNYg-1; Wed, 12 May 2021 16:33:44 -0400 X-MC-Unique: Q2v6SegvPFWqlHjUnIVNYg-1 Received: by mail-qt1-f197.google.com with SMTP id k13-20020ac8140d0000b02901bad0e39d8fso16560017qtj.6 for ; Wed, 12 May 2021 13:33:44 -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=w7CfKIBe9jxq7hw0zI/+HjfCpKTszduAXm7Snbxk6lk=; b=PDDx1ll7Bnq8BKOym/9Dl2jkyqnka7TcKPhWs6uAhLMiy2fhts4vfbYODhnNj7sWiQ obEQ84VoDu3w3I2KOxeKy/miB9WwisaNhcgjNyRn7amNKLboYXlcXuVpA2SHiKsEa9oC 0F5XQySd+QpmavwJSelakguCiMkYgqFKL5t6I4MxLWG0R58hb1Q3YoKYUl7Z7qUCSW3x E4odIXqjhL2hSJOmacn18CGBFgdZd1N6rNoGxfGYKiah8rJQTp26Vsdl8WolEJHbd9lB 6aFhoqKGntuPsO0/6m4JQmbhV+3pE9V+BIFH46OZtU8rnzG3KvzgRJgF7Aab+o2eQ/Tu ZYtg== X-Gm-Message-State: AOAM530jgw8yAv7Q9Kwlw+z1J18qpcXwAxID9nnzGLfa3eZ9V5Xic3v/ v9+sVAo4E3kcKPmlVHLflKRFff+VtRi4bQojFHuUJqcskMgFJHTVRpuQ5rXVbeVpwTyfNRyWvsU zTeXG7PpGoBzWX6hfHwanhcQfwu8EVknm7tun+8xKBNQwWXTAYqhLFodJlWhtXiV3easoxA== X-Received: by 2002:ac8:594a:: with SMTP id 10mr2737757qtz.293.1620851623581; Wed, 12 May 2021 13:33:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1wVujLMbYEyYFebVzZcPA0ZqxugQ9j7eX1g6rTLK4kZOAs9QD+WIgxRaNQtc4z1H1eL6YeA== X-Received: by 2002:ac8:594a:: with SMTP id 10mr2737736qtz.293.1620851623345; Wed, 12 May 2021 13:33:43 -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 o189sm879889qkd.60.2021.05.12.13.33.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 13:33:42 -0700 (PDT) Subject: Re: [PATCH v2 06/14] elf: Use relaxed atomics for racy accesses [BZ #19329] To: Szabolcs Nagy Cc: Adhemerval Zanella , libc-alpha@sourceware.org References: <10fb15a36b3f6bc3e5ca62cda081c86512f47d32.1618301209.git.szabolcs.nagy@arm.com> <37965321-dec2-f901-325c-ac4bad72484f@linaro.org> <20210416091256.GA30290@arm.com> <0a69a61e-5500-8e01-658d-c5e4896c6489@redhat.com> <20210511093105.GH9028@arm.com> From: Carlos O'Donell Organization: Red Hat Message-ID: <09940a6d-8db7-9ef7-cc69-244c2b9d8031@redhat.com> Date: Wed, 12 May 2021 16:33:41 -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: <20210511093105.GH9028@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: Wed, 12 May 2021 20:33:47 -0000 On 5/11/21 5:31 AM, Szabolcs Nagy wrote: > The 05/10/2021 22:56, Carlos O'Donell wrote: >> 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? > > yes, if the current thread is synchronized with a dlopen and reads > GL(dl_tls_genertion) with relaxed MO then either the gen of the > dlopened module is read or a larger value. So we can use relaxed MO > value to see if the dtv needs update at tls access. > > (This is the difficult bit in fixing bug 19924: we can use relaxed > MO because we update the dtv upto the gen of the module. slotinfo > entries with larger gen are ignored, but if we want to update upto > the global gen then we need additional synchronization.) > >> 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. > > Thanks for the review, i attached the fixed patch i plan to commit > later today if there are no further comments. Thanks. I saw you commited this and it looked good to me! Thanks for working through these issues! -- Cheers, Carlos.