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

["Thomas Weißschuh" <thomas.weissschuh@linutronix.de>]

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?
* Can the fixed up kernel now run on QEMU?
* Which toolchain are you using?
* This is a 64-bit userland?

What difference does the following change make:

diff --git a/arch/sparc/vdso/vma.c b/arch/sparc/vdso/vma.c
index 38a664d69782..efc3fef8f9bc 100644
--- a/arch/sparc/vdso/vma.c
+++ b/arch/sparc/vdso/vma.c
@@ -25,7 +25,7 @@
 #include <vdso/datapage.h>
 #include <asm/vdso/vsyscall.h>
 
-unsigned int __read_mostly vdso_enabled = 1;
+unsigned int __read_mostly vdso_enabled = 0;
 
 #ifdef CONFIG_SPARC64
 static struct vm_special_mapping vdso_mapping64 = {


Or this one, independently from the one above:


diff --git a/arch/sparc/vdso/vdso.lds.S b/arch/sparc/vdso/vdso.lds.S
index f3caa29a331c..a4669f7feada 100644
--- a/arch/sparc/vdso/vdso.lds.S
+++ b/arch/sparc/vdso/vdso.lds.S
@@ -16,10 +16,7 @@
 VERSION {
        LINUX_2.6 {
        global:
-               clock_gettime;
-               __vdso_clock_gettime;
-               gettimeofday;
-               __vdso_gettimeofday;
+               __nothing;
        local: *;
        };
 }


Or this one, independently from the ones above:

diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index 02ea19f67164..ae87888fef8a 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -318,6 +318,8 @@ __cvdso_clock_gettime_common(const struct vdso_time_data *vd, clockid_t clock,
        const struct vdso_clock *vc = vd->clock_data;
        u32 msk;
 
+       return false;
+
        if (!vdso_clockid_valid(clock))
                return false;