From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id E8DA93858D1E for ; Thu, 1 Sep 2022 15:30:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E8DA93858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32e.google.com with SMTP id h20-20020a056830165400b00638ac7ddba5so12615575otr.4 for ; Thu, 01 Sep 2022 08:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date; bh=cLv9K7Bv+WtKl0uWDkhuW0qej3HHLbFHQsmr5zBvAiY=; b=Jkrlc04HU0R5J/rjDkpPrxEGdr9yY9q73kEp1C7x6q79Y8FSztyoUE/7cbb7gz7LgH pqOVsuN8QXSea1RoWh1OZ5L2bBXJ8h/2jBQwEm2SiXBpZ5EYrYg6elHfjbdjUOiziapd LXg6P7FHjynMM/Jp4dxh7h8TbfUPDniCTZBSeCia8c6mRCSpgOKMx8NIkUWoJ05niUqS qAWkWzDACKu8Q1w7cfGvLhRK0zsiw/NUtFzO+6R4/sFvSutJCaBlLw3Z4N+oNckt8NJg 5HEA90D2c6g5Lh+OnkoQYQo4lwhwfOdrwvTgM5E1p02foHpT6yxSnBrQH2jl4rfu/Z3N +3+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=cLv9K7Bv+WtKl0uWDkhuW0qej3HHLbFHQsmr5zBvAiY=; b=XLPHeej7ZFYaNkZiZqMzhbW9Jp+Y82381U//yG1arydbyTBuDY2P+qR1PvKLEWjkoI zjE5kejrcATDvvD+vrItzY7gUj3cJBTX/685S/8xQq1DlrM4MJ3ihxE/aO4GSJ9TuyRt Ln2H8FijBAD6uTKylNOKTYO6DG75x1Aq+QLi8+1lWeEr8mP1p5vuw/MWVSdSZ+3vXSVJ WqVDhaKIN1GndkqXN4x+7ewlFyOvSJG3K41FIEVI1sVsD6SaV/MzwwI1jNKUGUCQjo6/ t47172/Gd3kjZYEp/1Ggti1h/ZtPFUVrXdgtN2OuUVc8ubyKROLSTAWlcaeTXB/HJqpo R07w== X-Gm-Message-State: ACgBeo3h2zBmyPCeJdlMAnUYAz8PzxRZnFLJauBZ3KHzDZqNM2QuqE9Q mu3UYV2NOV4dFfT+3TFV5NNhPdvd1Ui8SQ== X-Google-Smtp-Source: AA6agR7ZyQp9MRava6nFrjg0A3KRZ11qks6bWVUev2ojIYfuNgCzJwvvwOoGgaxutLPlK2S89wuz+Q== X-Received: by 2002:a9d:6389:0:b0:637:70f:3478 with SMTP id w9-20020a9d6389000000b00637070f3478mr13182087otk.322.1662046239176; Thu, 01 Sep 2022 08:30:39 -0700 (PDT) Received: from [192.168.15.31] ([187.34.212.254]) by smtp.gmail.com with ESMTPSA id j19-20020acaeb13000000b003432bb4322esm8463768oih.40.2022.09.01.08.30.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 08:30:38 -0700 (PDT) Message-ID: <5fd88725-8bef-2e26-420a-1216ebfa5cec@linaro.org> Date: Thu, 1 Sep 2022 12:30:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] elf: Use C11 like atomics on _dl_mcount Content-Language: en-US To: Wilco Dijkstra Cc: 'GNU C Library' References: <59b9367c-08f1-4f38-7273-b5eca48be60e@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 01/09/22 11:19, Wilco Dijkstra wrote: > Hi Adhemerval, > >> Right, I was not trying to be clever here and acquire might be a more >> strict memory order. >> >> And I haven't replied yet to you atomic refactor, but I also think changing >> step by step is indeed better than changing all the atomic altogether. > > Well that's what I did, I split into about 15-20 patches rather than a single one. Is the https://patchwork.sourceware.org/project/glibc/list/?series=10727 right? I think it has failed CI, could you submit again? > >> Do you think using relaxed on all atomic is suffice here? > > Indeed, adding acquire on these counters will not ensure correct memory ordering. > > Note this particular code looks very unsafe - it is not clear to me how it blocks > other threads from accessing new elements before they are properly initialized. > Also the counters that are being updated atomically are read without atomic > accesses, so may get a cached value or something newer - you don't know. > I thinking we are tracking two different issues, although they are correlated. My take is to first try to map the current code to a C11-like atomic, so we can always use compiler builtins where applicable (there are couple of architecture that we might avoid using libgcc for performance reasons), and then check if the atomic usage does make sense.