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 486613861802 for ; Mon, 21 Dec 2020 13:00:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 486613861802 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-37-rKMRuK8tPWaJHkJam2-7Tw-1; Mon, 21 Dec 2020 08:00:17 -0500 X-MC-Unique: rKMRuK8tPWaJHkJam2-7Tw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6E7E3800D53; Mon, 21 Dec 2020 13:00:16 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-120.ams2.redhat.com [10.36.112.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF6635D9CA; Mon, 21 Dec 2020 13:00:15 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org Subject: Compatibility issues around Date: Mon, 21 Dec 2020 14:00:14 +0100 Message-ID: <875z4vxqjl.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, 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: Mon, 21 Dec 2020 13:00:20 -0000 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. (c) The COMMON_CPUID_INDEX_MAX handshake does not work. __x86_get_cpu_features returns NULL if its argument is too large. This effectively disables *all* feature bits, not just those beyond COMMON_CPUID_INDEX_MAX. This means that if you build with a header that is too new, an application may fail due to the lack of detected features when running on an older glibc version. Ideally, only the newly added CPU features would be detected as missing in this scenario. Simply recompiling an application with a newer header should not result in any detection changes. Not quite a major concern is that this feature is not usable from IFUNC resolvers with BIND_NOW, which I consider an important use of CPU feature selection. I do not have a good solution here that can be implemented in time for glibc 2.33. I expect that a proper solution will require some binutils work. I'm going to work on this with priority this week and hope to have patches posted by the 24th. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill