[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e8583a3ab0522b4e75ba0ada47b6f093b186fa81.camel@xry111.site>
Date: Thu, 25 Jan 2024 05:32:59 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Andreas Schwab <schwab@...e.de>, Ben Hutchings <ben@...adent.org.uk>
Cc: linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org, Jiaxun Yang
<jiaxun.yang@...goat.com>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
libc-alpha@...rceware.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Strange EFAULT on mips64el returned by syscall when another
thread is forking
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@...adent.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@...111.site>
School of Aerospace Science and Technology, Xidian University
Powered by blists - more mailing lists