linux-kernel - Re: [PATCH v2 08/13] sparc64: vdso: Switch to the generic vDSO library

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: <20250829154636-bed204b6-1014-427d-9615-ee79b24b57f9@linutronix.de>
Date: Fri, 29 Aug 2025 15:51:15 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Andreas Larsson <andreas@...sler.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>, 
	Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.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>, linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH v2 08/13] sparc64: vdso: Switch to the generic vDSO
 library

On Fri, Aug 29, 2025 at 03:41:22PM +0200, Andreas Larsson wrote:
> On 2025-08-29 12:37, Thomas Weißschuh wrote:
> > On Fri, Aug 29, 2025 at 12:02:39PM +0200, Andreas Larsson wrote:
> >> On 2025-08-28 17:38, Andreas Larsson wrote:
> >>> and with all of them applied I got: 
> >>>
> >>> ----------------%<----------------
> >>> [    1.849344] Run /init as init process
> >>> [    1.851309] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >>> [    1.851339] CPU: 4 UID: 0 PID: 1 Comm: init Not tainted 6.17.0-rc1+ #3 VOLUNTARY
> >>> [    1.851363] Call Trace:
> >>> [    1.851374] [<0000000000436524>] dump_stack+0x8/0x18
> >>> [    1.851400] [<00000000004291f4>] vpanic+0xdc/0x320
> >>> [    1.851420] [<000000000042945c>] panic+0x24/0x30
> >>> [    1.851437] [<00000000004844a4>] do_exit+0xac4/0xae0
> >>> [    1.851458] [<0000000000484684>] do_group_exit+0x24/0xa0
> >>> [    1.851476] [<0000000000494c60>] get_signal+0x900/0x940
> >>> [    1.851495] [<000000000043ecb8>] do_notify_resume+0xf8/0x600
> >>> [    1.851514] [<0000000000404b48>] __handle_signal+0xc/0x30
> >>> [    1.852291] Press Stop-A (L1-A) from sun keyboard or send break
> >>> [    1.852291] twice on console to return to the boot prom
> >>> [    1.852310] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >>> ----------------%<----------------
> >>>
> >>> but given that I don't have the kernel anymore I'm starting to
> >>> question myself if that run was really with the same base
> >>> commit. I'll do a rebuild and see.
> >>
> >> I found out that my previous kernel installation for the kernel with the first 8
> >> patches was a broken mess. Sorry about the confusion. With that sorted out and a
> >> rebuilt kernel with all patches, the failure above is the one I get for both 8
> >> and 13 patches, and it is repeatable.
> > 
> > This splat means that init got killed by SIGSEGV, so that makes some sense in
> > the context of the code being touched. Then let's focus on patch 8 for now.
> > 
> > In the meantime I installed a full Debian, but the bug is still not
> > reproducible in QEMU.
> > 
> > * Did you use the SMP or UP kernel config from Debian?
> 
> I based my config on the SMP config that was in use on the system.
> Produces an tremendous amount of modules unfortunately, so I'll have
> to cut down in the config. Right now the turnaround time for testing
> a new kernel with this setup for this system is quite bad.

Ack. I am aware :-(

> > * Can the fixed up kernel now run on QEMU?
> 
> No, there is something else going on with my QEMU setup, unrelated to
> these patches.

Ack. FWIW for me it works (for sun4u) with my distro's QEMU 10.0.3.

> > * Which toolchain are you using?
> 
> A toolchain built in Buildroot with GCC 13.2.0. Old kernel headers, but
> I only use it to build kernels. Do you think the kernel headers of the
> toolchain would play a role for vDSO?

No, the headers from the toolchain are not used. It could have been that you are
using a wildly different compiler. But I am also using GCC 13.2.0, although from
the kernel.org crosstools.

> > * This is a 64-bit userland?
> 
> Yes.

Ack.

> > What difference does the following change make:

(...)

> I will check.

Thanks!