From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id B15F63858C35 for ; Wed, 24 Jan 2024 21:33:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B15F63858C35 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B15F63858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706131986; cv=none; b=K3NhHI45Bhg4rGqJWBqUUiRp+uuNQfbChKjvjPcd0Qzyx9tTO0+j58RllqoemJ0aC6WHVPPJrWnsuO3glgCsO278FFQ+LrO9LBFUX6o2Q1AK6T1pz0/n440l4LcIYeAiWcEiDoJIB4q+k8mWeAGC+3vUsXHwH1ErIzbi8Z7HPSY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706131986; c=relaxed/simple; bh=ziTHwcQqcapg3pVzdE+ZardjAdUN8XTv3xGQCPYdaz4=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=V/QCSmQE7q0HSv7D80qSzXwqHFw1fg3cN00fdnNmdwLBQ8RH+TDFCFS6jghv6JsTsSUV+oVgaZWhA8lWX/1nebl+xjWzPEtoQ+iEJsSm5QGqfEYkvtKjfkZDHuygwkhsuEdzZKbpMYHmo4Lr0eHL/B2zEI1JjY+esFWqNqbqUbU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1706131982; bh=ziTHwcQqcapg3pVzdE+ZardjAdUN8XTv3xGQCPYdaz4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=jmoWAk0qhYPXnrmgEfpUhBIlc9h6qrS2t4yfbrlqa4zq9d2UhFbys18mSH7qZcRsI JzjseQtUzh4MjZZM/bdv10PK5EKZ32QN23xv9KDGZ/og2yUnlR/4Wsw5X8uk99DuKP teJsIFsYgSBB6Bt7d6KvF/fCL++xh0VnHxIQpzkk= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 08FDE66A79; Wed, 24 Jan 2024 16:33:00 -0500 (EST) Message-ID: Subject: Re: Strange EFAULT on mips64el returned by syscall when another thread is forking From: Xi Ruoyao To: Andreas Schwab , Ben Hutchings Cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Jiaxun Yang , Thomas Bogendoerfer , libc-alpha@sourceware.org, Linus Torvalds Date: Thu, 25 Jan 2024 05:32:59 +0800 In-Reply-To: <0be1203c9df55432548c92281c8392dfa2f7d6bf.camel@xry111.site> References: <75e9fd7b08562ad9b456a5bdaacb7cc220311cc9.camel@xry111.site> <9481b6d9d015aea25d8f2563bf7bd6f6462f758f.camel@xry111.site> <0be1203c9df55432548c92281c8392dfa2f7d6bf.camel@xry111.site> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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: > > >=20 > > > > Now I'm suspecting this might be a kernel bug.=C2=A0 Any pointer to= further > > > > triage? > > >=20 > > > Is this a regression? > >=20 > > 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= . > >=20 > > Not sure if this is a kernel regression, I'll try different kernels in > > several hours (once I can physically access the system). >=20 > Not happening with kernel 5.18.1.=C2=A0 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 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 #include #include #include #include #include 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) { pid_t p =3D 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-threa= d and the "interesting" aspects: 1. If I change the third parameter of "read" to any value >=3D 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). --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University