Hi Andy, sorry for the long delay.
On Fri, Nov 07, 2025 at 04:17:14PM -0800, Andy Lutomirski wrote: > 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. Ack. > 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. After I wrote that commit message it turned out to probably not be an aliasing issue. Even with matching alignments the error would persist. The real reason is unknown. Nobody came up with an explanatin so far. But another advantage of this dynamic allocation is to enable mlockall() on these VMAs. This avoids unexpected page faults and latency spikes for realtime applications. > 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. These pointers alread exist and are used by the generic code: vdso_k_time_data, vdso_k_rng_data, vdso_k_arch_data. As proposed elsewhere in this thread, these can point to statically allocated memory at first so they can be accessed by the other kernel subsystems. Then they after the dynamic allocation we do a mempcy from the static storage to the dynamic one and update the pointer. I have the code for that which does work nicely. While we could limit this treatment to SPARC, I prefer to keep the code aligned between the different architectures. Otherwise we would need duplicate implementations as one uses PFN maps and the other 'struct page' maps. Also the mlockall() usecase is architecture-agnostic. Does this sound acceptable? > 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". Ack, will do. But as I mentioned, I do not have an actual root cause. > (Can SPARC really not map things that existed during early boot into > userspace?) It looks like it. Thomas
