On Thu, Nov 6, 2025, at 2:01 AM, 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. > > Follow-up to and replacement for Arnd's SPARC vDSO removal patches: > https://lore.kernel.org/lkml/[email protected]/ > > SPARC64 can not map .bss into userspace, so the vDSO datapages are > switched over to be allocated dynamically. This requires changes to the > s390 and random subsystem vDSO initialization as preparation. > The random subsystem changes in turn require some cleanup of the vDSO > headers to not end up as ugly #ifdef mess. >
I hate to say it, but this patch series seems like a step backwards. You're adding a whole lot of complexity and opportunity for screwups (boot failure? corruption?) to support SPARC, where other architectures have no problem with the existing code. And this complexity appears to infect basically every kernel subsystem that supplies data to the vDSO. Can you at least explain what the problem is and maybe give some discussion of why SPARC has no workaround available? The closest I found was this bit from "[PATCH v4 24/35] vdso/datastore: Allocate data pages dynamically": > Allocating the datapages as part of the kernel image does not work on SPARC. It is also problematic with regards to dcache aliasing as there is no guarantee that the virtual addresses used by the kernel are compatible with those used by userspace. Now I'm not an expert on any architecture that has these aliasing (coloring?) issues, but from my limited understanding, it ought to be possible to choose a correctly colored address to map the vdso data given where it's being mapped from. If there's an issue with gathering a bunch of basically arbitrarily relatively positioned physical pages into their necessary arrangement in usermode, you could presumably fix it either with some linker script magic or by rearranging the C code to stick everything into a multipage structure. Or maybe you could arrange to allocate all these pages during early boot and to fudge up some relocation to get all the existing generic code to find them. Or create some pointers that all the generic code will use that, on non-sparc architectures, will be statically populated with the right addresses by the linker. IOW, conceptually, struct the_type some_vdso_thing; could change to: const struct the_type some_vdso_thing = &the_actual_data; and SPARC could fix up the initialization of the pointer. And generic code would use the pointer instead of the_actual_data. If you really really really need to have non-arch-specific kernel C code running before the vdso data is allocated, can you give a very clear explanation of what, exactly, is wrong on sparc? And maybe put that explanation into an appropriate comment somewhere so that future kernel programmers don't look at the headers and the code and think "wow, what I mess -- I bet I can clean this up by using statically allocated data". (Can SPARC really not map things that existed during early boot into userspace?) --Andy
