Received-SPF: pass (google.com: domain of linux-kernel+bounces-40096-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Feedback-ID: ifd894703:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-119-ga8b98d1bd8-fm-20240108.001-ga8b98d1b
Precedence: bulk
MIME-Version: 1.0
Message-Id: <4b715c9f-6a9e-4496-8810-670080cb715a@app.fastmail.com>
In-Reply-To: <75e9fd7b08562ad9b456a5bdaacb7cc220311cc9.camel@xry111.site>
References: <75e9fd7b08562ad9b456a5bdaacb7cc220311cc9.camel@xry111.site>
Date: Fri, 26 Jan 2024 12:33:38 +0000
From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Xi Ruoyao" <xry111@xry111.site>,
 "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Cc: linux-kernel@vger.kernel.org,
 "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>, libc-alpha@sourceware.org,
 regressions@lists.linux.dev
Subject: Re: Strange EFAULT on mips64el returned by syscall when another thread is
 forking
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable


=E5=9C=A82024=E5=B9=B41=E6=9C=8824=E6=97=A5=E4=B8=80=E6=9C=88 =E4=B8=8A=E5=
=8D=8810:42=EF=BC=8CXi Ruoyao=E5=86=99=E9=81=93=EF=BC=9A
> Hi,
>
> When I'm testing Glibc master branch for upcoming 2.39 release, I
> noticed an alarming test failure on mips64el:

So apparently it should be tracked as a regression.

#regzbot ^introduced 4bce37a68ff884e821a02a731897a8119e0c37b7

Should we revert it for now?

Thanks
- Jiaxun

>
> FAIL: stdlib/tst-arc4random-thread
>
> I've gathered some info about it and pasted my findings into
> https://sourceware.org/glibc/wiki/Testing/Tests/stdlib/tst-arc4random-=
thread.
>
> Finally I was able to reduce the test case into:
>
> #include <stdlib.h>
> #include <errno.h>
> #include <pthread.h>
> #include <unistd.h>
> #include <fcntl.h>
>
> void *
> test_thread (void *)
> {
>   char buf[16] =3D {};
>   int fd =3D open("/dev/zero", O_RDONLY);
>   while (1)
>     {
>       ssize_t ret =3D read (fd, buf, 7);
>       if (ret =3D=3D -1 && errno =3D=3D EFAULT)
> 	abort ();
>     }
> }
>
> void *
> fork_thread (void *)
> {
>   while (1)
>     {
>       if (!fork ())
> 	_exit (0);
>     }
> }
>
> int
> main (void)
> {
>   pthread_t test_th;
>   pthread_t fork_th;
>
>   pthread_create (&test_th, NULL, test_thread, NULL);
>   pthread_create (&fork_th, NULL, fork_thread, NULL);
>   pthread_join (test_th, NULL);
>   pthread_join (fork_th, NULL);
> }
>
> When running this on the mainline kernel (revision 6.8.0-rc1+-
> g7ed2632ec7d72e926b9e8bcc9ad1bb0cd37274bf) it fails in milliseconds.=20
> Some "interesting" aspects:
>
> 1. This is related to the size parameter passed to read ().  When it's
> less than 8 it fails, but when it's 8 or greater there is no failure.
> 2. This is not related to if "buf" is initialized or not.
>
> Now I'm suspecting this might be a kernel bug.  Any pointer to further
> triage?
>
> --=20
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University

--=20
- Jiaxun