Re: Strange EFAULT on mips64el returned by syscall when another thread is forking

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
Date: Fri, 26 Jan 2024 12:33:38 +0000	[thread overview]
Message-ID: <4b715c9f-6a9e-4496-8810-670080cb715a@app.fastmail.com> (raw)
In-Reply-To: <75e9fd7b08562ad9b456a5bdaacb7cc220311cc9.camel@xry111.site>

在2024年1月24日一月 上午10:42，Xi Ruoyao写道：
> 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] = {};
>   int fd = open("/dev/zero", O_RDONLY);
>   while (1)
>     {
>       ssize_t ret = read (fd, buf, 7);
>       if (ret == -1 && errno == 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. 
> 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?
>
> -- 
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University

-- 
- Jiaxun