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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University