From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 1BDD5385702E for ; Tue, 22 Dec 2020 12:58:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1BDD5385702E Received: by mail-oi1-x22f.google.com with SMTP id q205so14588058oig.13 for ; Tue, 22 Dec 2020 04:58:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S0qQmD4drfADaZoDPWeEcj9mi9i/SGNwlhOLl/Q0FFc=; b=R0ch40QwZHOXkVnhEIQ6NAY3qB4x0qc5iyqtuhuAqMnZnqt5pKrnJe1yBJZGPqLdNs dxlQrs5HT/0+JQpnfnyDuOyJcHx0ykurg/45KAV1nhBdWlnAyHjW3C+U4KQEWduAYdI1 LsFJEqapV9qWkaeJTzBa7E4oqZeCUeTCLvv0Cfe/rmAEt0VkUqZTAMJD+5HLoQNURiGl bX2eo9G1lX5UHPMIR0soohalIsnlvtnspCu8xfAWdf1TplMXAJbTTAYFXY2NpvG5hr97 d1GzHk/JlEVIpShXWKCft4HgfOpIxDCg9dKdwF+lPkKHsK4VNFYXrryAyDRwKxW6LCwM CZgg== X-Gm-Message-State: AOAM531zdCYYOpwOFHfPfEmCht3hjZ99hUPXmDn/PXKLq9JQedlceqd2 IKF8ovdWumGCKu4umQQwiHTv1HvcuQdQaDi3z/aAgtNaopk= X-Google-Smtp-Source: ABdhPJwjsmInL694gQlTPhjmH281lCg5p1s4KdmuIfgbp/OxOCR75TuVHET3V0zJWTDKwRRtrwKhtPKZgBNv9WBInL0= X-Received: by 2002:aca:f456:: with SMTP id s83mr14028246oih.58.1608641905597; Tue, 22 Dec 2020 04:58:25 -0800 (PST) MIME-Version: 1.0 References: <875z4vxqjl.fsf@oldenburg2.str.redhat.com> <3eef8d18-97c0-c811-7563-94345e8bb3df@linaro.org> In-Reply-To: From: "H.J. Lu" Date: Tue, 22 Dec 2020 04:57:49 -0800 Message-ID: Subject: Re: Compatibility issues around To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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, 22 Dec 2020 12:58:27 -0000 On Tue, Dec 22, 2020 at 4:43 AM Adhemerval Zanella wrote: > > > > On 22/12/2020 08:42, H.J. Lu wrote: > > On Mon, Dec 21, 2020 at 9:16 AM Adhemerval Zanella via Libc-alpha > > wrote: > >> > >> > >> > >> On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote: > >>> On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer wrote: > >>>> > >>>> I finally had some time to review the interface. > >>>> > >>>> I have two major concerns: > >>>> > >>>> (a) Placement of struct cpu_features in _rtld_global_ro > >>>> > >>>> This means that backporting new feature support changes the internal > >>>> GLIBC_PRIVATE ABI. Consequently, there's a race condition during > >>>> in-place updates where loading binaries can fail in obscure ways, due to > >>>> the change in _rtld_global_ro offsets. We should really avoid this. > >>> > >>> This applies to all members in _rtld_global_ro. > >> > >> Couldn't it be mitigated by adding member solely at the end of the struct > >> and making sure the backport uses the same offset? > > > > What if we need to extend a member in the middle? > > > > My question also extends if we would need to do so. Do we plan to extend > the cpu_features indefinitely or can we pre-allocate a large space now > for future extensions? cpu_features will grow a bit. But I don't know by how much. -- H.J.