FAILING nptl/tst-robust8pi

[Xi Ruoyao]

On Fri, 2024-01-19 at 15:16 +0100, Stefan Liebler wrote:
> On 19.01.24 13:26, Florian Weimer wrote:
> > * Stefan Liebler:
> > 
> > > In the meanwhile I also retested with glibc 2.38 release tag to be sure
> > > there was no glibc change in between. => same test error.
> > > 
> > > I also created a kvm-guest on my x86_64 machine with fedora 39 and used
> > > this kernel from copr-repository:
> > > Linux fedora 6.7.0-0.rc8.20240107gt52b1853b.366.vanilla.fc39.x86_64 #1
> > > SMP PREEMPT_DYNAMIC Sun Jan  7 06:17:30 UTC 2024 x86_64 GNU/Linux
> > > => Now I also see the EINVAL on x86_64
> > > 
> > > @Florian / @Carlos: Have you already saw this on fedora side?
> > 
> > There has been a refactor of the futex code in the kernel.  The initial
> > version was buggy:
> > 
> >   Re: Several tst-robust* tests time out with recent Linux kernel
> >   <https://lore.kernel.org/all/20231114201402.GA25315@noisy.programming.kicks-ass.net/>
> > 
> > Maybe there are more issues remaining?
> > 
> > Thanks,
> > Florian
> > 
> Thanks for the hint.
> Yes, this thread contains my observed issue. I've answered there:
> "Re: Several tst-robust* tests time out with recent Linux kernel"
> link on glibc list:
> https://sourceware.org/pipermail/libc-alpha/2024-January/154170.html
> link on kernel list:
> https://lore.kernel.org/all/fc3fd07a-218d-406c-918b-e7f701968eb0@linux.ibm.com/

As the reporter of the linked kernel bug: I don't think this is the same
issue you are encountering.  The tst-robust* timeouts I found were
highly deterministic, i.e. they *always* failed, no "sometimes".  And
IIRC the failures I observed were deadlock-alike, i.e. the futex syscall
just hangs indefinitely w/o returning EINVAL or something.

As a Glibc machine tester: I've tested Glibc about a dozen times
recently on several different architectures and I've not seen any tst-
robust8pi failure.

As a Linux From Scratch maintainer: there had been some complains about
additional Glibc failures from people building LFS in virtual machines
for a long time.  I cannot recall if the VMM they used was QEMU/KVM
though.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University