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.129.124]) by sourceware.org (Postfix) with ESMTPS id 9D6583858407 for ; Fri, 14 Jan 2022 22:30:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D6583858407 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-453-SPtPtICCMhu0H2uEIWrtwA-1; Fri, 14 Jan 2022 17:30:13 -0500 X-MC-Unique: SPtPtICCMhu0H2uEIWrtwA-1 Received: by mail-qk1-f198.google.com with SMTP id m21-20020a05620a24d500b004780f869883so8490312qkn.17 for ; Fri, 14 Jan 2022 14:30:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=Hn3SFZQ7FvwC+4ImJ9g7JJxIIP82yPIv84hcSJyMKdY=; b=A7qBrq5Q5SahyqW4VB4bAIM+5gXweF2tEhts1CWi2lyagIr3EKpdIb0O07uVPLtADA YE4nkUewDvBuqgQvNyYKAQL1RS6Co8hiB6lYJpFx8R1yi3RjXgHk3B961Hdw7Kaqynfa RxzaNjFf9XBeYH871/r6lzDh+Jvg5xyyCOYJlpcyBtedESA8cdxSVbgrJFqeDhwJ9cDL zJefQkaIRUp0ZY7twRg9KgJFO2KcfdpPCeFJ4PKF0qLXA+E7uE7KkOKRFaTxQPGfRX+g sLEBIj/u6979XHf6ugTiSmcrqzC78WShH9z3p09VyvBdLyqtRoO6hCwVggMHsyacnoNa Jp8Q== X-Gm-Message-State: AOAM530BO5RY5h/ZKaTm3lny17eLpkQID0MlYJwNf3T6OfHEgyQpYN8k 0ylCzIhtCPFadRc4guakVXNDacG2r3BHsuLoMVMaTXD/OMPUynBoSEBb49X5+Plrg3/Zn2EvoMn j8pNZ5oTAoU9Wqvio9yQs X-Received: by 2002:ac8:5dd0:: with SMTP id e16mr1773874qtx.597.1642199412236; Fri, 14 Jan 2022 14:30:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJy61nOwHukgeUn2e8iFjamR/dAfk7A9VvtpqbYm9zmNu2nrkyKUYCr/MW4KlMHDdU0TlOtY0w== X-Received: by 2002:ac8:5dd0:: with SMTP id e16mr1773865qtx.597.1642199412049; Fri, 14 Jan 2022 14:30:12 -0800 (PST) Received: from [192.168.0.241] (135-23-175-80.cpe.pppoe.ca. [135.23.175.80]) by smtp.gmail.com with ESMTPSA id c7sm4378272qtd.62.2022.01.14.14.30.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 14:30:11 -0800 (PST) Message-ID: Date: Fri, 14 Jan 2022 17:30:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: glibc 2.35 failures in elf/tst-cpu-features-cpuinfo-static. To: Florian Weimer Cc: "H.J. Lu" , Carlos O'Donell via Libc-alpha References: <056482b8-d413-2e24-a546-98ea46e68710@redhat.com> <87ee5aqmla.fsf@oldenburg.str.redhat.com> <87tue6p4n6.fsf@oldenburg.str.redhat.com> <51c4a93d-ab7d-f56d-0ac3-0c0a2b287e9a@redhat.com> <87ilumowe8.fsf@oldenburg.str.redhat.com> <5b072214-bd50-9316-536f-4dd9e0ed9d79@redhat.com> <87y23ineha.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <87y23ineha.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 14 Jan 2022 22:30:15 -0000 On 1/14/22 17:23, Florian Weimer wrote: > * Carlos O'Donell: > >> On 1/14/22 16:11, Florian Weimer wrote: >>> * Carlos O'Donell: >>> >>>> Can we make our testing detect this and mark the test XFAIL? >>> >>> If we treat this as our bug, we'd have to run CPUID on *all* CPUs during >>> glibc startup. The bug is visible to applications as well. I don't >>> think this is feasible. >> >> I thought we already ran cpuid at startup for all cpus? >> >> In cpu-features.c (init_cpu_features) we call __cpuid() unconditionally, and that >> is called via ARCH_INIT_CPU_FEATURES() in LIBC_START_MAIN (static), and >> DL_PLATFORM_INIT in ld.so (shared). >> >> In fact we might call cpuid five or six times during startup? > > It runs on a random CPU. It could be CPU 0 or another CPU. We pretend > that it doesn't matter. Ah! I see what you mean now by "all CPUs." Thank you. >>>> Or as HJ say, blacklist the CPU from the test e.g. UNSUPPORTED? >>> >>> I think the bug isn't CPU-specific. >> >> Could you expand in this a bit more? > > Maybe I was mistaken. Siddhesh has an i7-8665U. I must have mixed up > my timelines. That CPU was released in 2019. I have exactly the same CPU. >> My concern is that testing should be robust and not return false >> positives to the extent that we can prevent that. False positives, >> regardless of who is at fault, call into question the validity of the >> test infrastructure. There is a cost to such prevention of false >> positives, for certain, there is a practical limit to the work we can >> do. > > It's a true positive in the sense that the glibc detection (in > ) does not work correctly. Now that might not be > useful information to us as glibc developers because it's realistically > not our problem, but we as Red Hat (or other distributions) should > actually work towards fixing this issue. Because this could be a kernel 5.15 resume issue or another issue? Yes, fixing it correctly would be best. -- Cheers, Carlos.