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: <e7f05748-a11c-47eb-b1fa-cdc9dc6d05e0@samsung.com>
Date: Tue, 4 Nov 2025 09:44:38 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Mark Brown <broonie@...nel.org>, Thomas Weißschuh
	<thomas.weissschuh@...utronix.de>
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 03.11.2025 16:24, Mark Brown wrote:
> On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:
>
>> An upcoming change will allocate the datapages dynamically instead of as
>> part of the kernel image. Such pages can only be mapped through
>> 'struct page' and not through PFNs.
> I'm seeing some boot failures on some arm64 platforms in -next which are
> bisecting to this patch in -next.  Unfortunately the diagnostics aren't
> super useful, we seem to just stop making progress in userspace with no
> obvious output.  One sample log from the FVP is:
>
>     https://lava.sirena.org.uk/scheduler/job/2036229#L1268
>
> which isn't super instructive.  Not all platforms seem to be affected,
> I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
> Elite.  The diagnostics aren't very clear here but given that I'm seeing
> the same issue and bisect result on multiple platforms it seemed worth
> mentioning.  Some platforms do seem fine.
>
> 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:

...

[   10.199852] devtmpfs: mounted
[   10.205013] Freeing unused kernel image (initmem) memory: 1024K
[   10.210086] Run /sbin/init as init process

INIT: version 2.88 booting

(no more messages)

The only difference is that bisecting on ARM32bit lead me to the next 
patch (10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically") 
/ [PATCH v4 24/35]).

Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
following panic on 6a011a228293 ("vdso/datastore: Map pages through 
struct page") commit:

VFS: Mounted root (ext4 filesystem) on device 179:3. Trying to move old 
root to /initrd ... okay devtmpfs: mounted Freeing unused kernel memory: 
12672K Run /sbin/init as init process Unable to handle kernel paging 
request at virtual address ffffffffc20b5d48 Mem abort info: ESR = 
0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, 
FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data 
abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 
0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 
swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000230b000 
[ffffffffc20b5d48] pgd=0000000000000000, p4d=0000000003618403, 
pud=0000000003619403, pmd=0000000000000000 Internal error: Oops: 
0000000096000006 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 1 Comm: 
init Tainted: G W 6.18.0-rc1+ #16136 PREEMPT Tainted: [W]=WARN Hardware 
name: Raspberry Pi 3 Model B (DT) pstate: 80000005 (Nzcv daif -PAN -UAO 
-TCO -DIT -SSBS BTYPE=--) pc : vvar_fault+0x7c/0x17c lr : 
vvar_fault+0x24/0x17c ... Call trace: vvar_fault+0x7c/0x17c (P) 
special_mapping_fault+0x24/0xd0 __do_fault+0x3c/0x238 
__handle_mm_fault+0xaa0/0x19e0 handle_mm_fault+0xcc/0x384 
do_page_fault+0x1a0/0x720 do_translation_fault+0x60/0x6c 
do_mem_abort+0x44/0x94 el0_da+0x54/0x230 el0t_64_sync_handler+0xd0/0xe4 
el0t_64_sync+0x198/0x19c Code: f2d83fe0 8b010063 d34cfc63 8b031803 
(f9400461) ---[ end trace 0000000000000000 ]--- Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x0000000b SMP: stopping 
secondary CPUs Kernel Offset: disabled CPU features: 
0x000000,00180000,40004000,0400421b Memory Limit: none ---[ end Kernel 
panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Reverting "clocksource: Remove ARCH_CLOCKSOURCE_DATA", "vdso/datastore: 
Allocate data pages dynamically" and "vdso/datastore: Map pages through 
struct page" on top of linux-next fixes booting on all tested boards.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ