Re: glibc 2.35 failures in elf/tst-cpu-features-cpuinfo-static.

[Carlos O'Donell <carlos@redhat.com>]

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
> <sys/platform/x86.h>) 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.