lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251104162009-8cffa62d-e95b-466b-9a27-c51b0f5257cd@linutronix.de>
Date: Tue, 4 Nov 2025 16:43:34 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Mark Brown <broonie@...nel.org>, 
	Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Andy Lutomirski <luto@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	Arnd Bergmann <arnd@...db.de>, "David S. Miller" <davem@...emloft.net>, 
	Andreas Larsson <andreas@...sler.com>, Nick Alcock <nick.alcock@...cle.com>, 
	John Stultz <jstultz@...gle.com>, Stephen Boyd <sboyd@...nel.org>, 
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Shuah Khan <shuah@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Theodore Ts'o <tytso@....edu>, 
	"Jason A. Donenfeld" <Jason@...c4.com>, Russell King <linux@...linux.org.uk>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>, 
	Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, 
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Heiko Carstens <hca@...ux.ibm.com>, 
	Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev <agordeev@...ux.ibm.com>, 
	Christian Borntraeger <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, 
	Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.com>, Shannon Nelson <sln@...main.com>, linux-kernel@...r.kernel.org, 
	sparclinux@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev, 
	linux-mips@...r.kernel.org, linux-s390@...r.kernel.org, Aishwarya.TCV@....com
Subject: Re: [PATCH v4 23/35] vdso/datastore: Map pages through struct page

On Tue, Nov 04, 2025 at 01:14:03PM +0000, Mark Brown wrote:
> On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> > On 03.11.2025 16:24, Mark Brown wrote:
> 
> > > We do have some other serious breakage affecting arm64 in -next which
> > > are making it hard to get a clear picture of which platforms are
> > > affected, at least the FVP and O6 are unaffected by those other issues
> > > (due to using MTE on platforms that don't have it, those platforms do
> > > have MTE).
> 
> > I got almost the same result while bisecting on ARM 32bit Exynos-based 
> > boards, so the issue with this patchset is not fully ARM64 specific. For 
> > some reasons it also doesn't affect all systems though. It is even 
> > worse, because it affected only a subset of boards, but different for 
> > each tested commit. The observed failure looks exactly the same:
> 
> I've now got the results for this specific commit, it looks like every
> single arm64 system is failing.  I didn't test any other architectures.

Which one do you mean exactly with "this specific commit"?

6a011a228293 ("vdso/datastore: Map pages through struct page")
10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically")

> > Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
> > following panic on 6a011a228293 ("vdso/datastore: Map pages through 
> > struct page") commit:
> 
> I'm seeing the same thing on at least some of the systems - this is with
> arm64 defconfig (I suspect that's what Marek is doing too).  For
> example:

I can now reproduce this issue, too. Even on QEMU. But it goes away,
as soon as the second commit is applied. The two commits should be merged.
That could also explain the weird bisection results, landing on either one
of the commits. However I can't reproduce the "silent freeze" issue on commit
10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically") on my
Raspberry Pi 3b+.

Any chance I could get remote access to one of your test machines?
I don't have access to the exact machines and that should reduce the chance
of chasing down dead ends.


Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ