Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: Strange EFAULT on mips64el returned by syscall when another thread is forking | From | Xi Ruoyao <> | Date | Thu, 25 Jan 2024 05:32:59 +0800 |
| |
On Thu, 2024-01-25 at 00:13 +0800, Xi Ruoyao wrote: > On Wed, 2024-01-24 at 20:49 +0800, Xi Ruoyao wrote: > > On Wed, 2024-01-24 at 12:59 +0100, Andreas Schwab wrote: > > > On Jan 24 2024, Xi Ruoyao wrote: > > > > > > > Now I'm suspecting this might be a kernel bug. Any pointer to further > > > > triage? > > > > > > Is this a regression? > > > > Initially I guessed it was perhaps a Glibc regression related to the > > newly introduced clone3 usage on MIPS, but it fails with Glibc-2.35 too. > > > > Not sure if this is a kernel regression, I'll try different kernels in > > several hours (once I can physically access the system). > > Not happening with kernel 5.18.1. I can do a bisection but it will take > several days, I guess.
Hmm, not so time-consuming as I expected.
4bce37a68ff884e821a02a731897a8119e0c37b7 is the first bad commit commit 4bce37a68ff884e821a02a731897a8119e0c37b7 Author: Ben Hutchings <ben@decadent.org.uk> Date: Thu Jun 22 18:47:40 2023 +0200
mips/mm: Convert to using lock_mm_and_find_vma()
Re-posting the broken test case for Ben (I also added a waitpid call to prevent PID exhaustion):
#include <stdlib.h> #include <errno.h> #include <pthread.h> #include <unistd.h> #include <fcntl.h> #include <sys/wait.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) { pid_t p = fork (); if (!p) _exit (0); waitpid (p, NULL, 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); }
and the context where this issue was detected:
https://sourceware.org/glibc/wiki/Testing/Tests/stdlib/tst-arc4random-thread
and the "interesting" aspects:
1. If I change the third parameter of "read" to any value >= 8, it no longer fails. But it fails with any integer in [1, 8). 2. It fails no matter if I initialize buf. 3. It does not fail on arm64 (the only other port using lock_mm_and_find_vma I have access to).
-- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
| ![\](/images/icornerr.gif) |