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

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

Hi Andreas,

thaks for testing!

On Mon, Aug 25, 2025 at 05:55:20PM +0200, Andreas Larsson wrote:
> On 2025-08-15 12:41, Thomas Weißschuh wrote:
> > The generic vDSO provides a lot common functionality shared between
> > different architectures. SPARC is the last architecture not using it,
> > preventing some necessary code cleanup.
> > 
> > Make use of the generic infrastructure.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  arch/sparc/Kconfig                         |   4 +-
> >  arch/sparc/include/asm/clocksource.h       |   9 --
> >  arch/sparc/include/asm/vdso/clocksource.h  |  10 ++
> >  arch/sparc/include/asm/vdso/gettimeofday.h |  58 ++++++++--
> >  arch/sparc/include/asm/vdso/vsyscall.h     |  10 ++
> >  arch/sparc/include/asm/vvar.h              |  75 -------------
> >  arch/sparc/kernel/Makefile                 |   1 -
> >  arch/sparc/kernel/time_64.c                |   6 +-
> >  arch/sparc/kernel/vdso.c                   |  69 ------------
> >  arch/sparc/vdso/Makefile                   |   6 +-
> >  arch/sparc/vdso/vclock_gettime.c           | 169 ++++-------------------------
> >  arch/sparc/vdso/vdso-layout.lds.S          |   7 +-
> >  arch/sparc/vdso/vma.c                      |  70 +++---------
> >  13 files changed, 119 insertions(+), 375 deletions(-)
> 
> With the first seven patches (applied on v6.17-rc1) I don't run into any
> problems, but from this patch (and onwards) things do not work properly.
> With patches 1-8 applied, Debian running on a sun4v (in a Solaris LDOM)
> stops being able to mount the root filesystem with the patches applied
> up to and including this patch.

Could you give me the kernel log of the failures? Is there any chance to get
access to the machine? Can you reproduce this issue on sun4u? sun4v in QEMU is
"work in progress" and instantly crashes for me. Can you provide me your Debian
image?

> As an aside, with all patches applied, it panics when the kernel
> attempts to kill init.

It is suprising that the error changes between patches.
The later patches don't change any lowlevel stuff, so if rootfs mounting
was broken earlier I don't see how it could go on to start init later.
Are these results repeatable?


Thomas