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

[Thomas Weißschuh]

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!