On 11/5/2025 9:04 PM, Heiko Carstens wrote:
On Tue, Oct 14, 2025 at 08:49:10AM +0200, Thomas Weißschuh wrote:
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.
Allocate the data pages through the page allocator instead.
Unused pages in the vDSO VMA are still allocated to keep the virtual
addresses aligned.
These pages are used by both the timekeeping, random pool and architecture
initialization code. Introduce a new early initialization step, to make
sure they are available when needed.
Signed-off-by: Thomas Weißschuh <[email protected]>
Tested-by: Andreas Larsson <[email protected]>
Reviewed-by: Andreas Larsson <[email protected]>
---
include/linux/vdso_datastore.h | 6 ++++++
init/main.c | 2 ++
lib/vdso/datastore.c | 44 ++++++++++++++++++++++--------------------
3 files changed, 31 insertions(+), 21 deletions(-)
...
+void __init vdso_setup_data_pages(void)
+{
+ unsigned int order = get_order(VDSO_NR_PAGES * PAGE_SIZE);
+ struct folio *folio = folio_alloc(GFP_KERNEL, order);
I'm seeing random hangs on s390 too with our CI, but unfortunately I cannot
reproduce it manually. But looking at one of the dumps it looks to me like the
vdso time page contains (more or less) random junk at the end. Or in other
words, shouldn't this be:
struct folio *folio = folio_alloc(GFP_KERNEL | __GFP_ZERO, order);
? At least that is a difference to before as far as I can tell.
I was also hitting random hangs with an x86 KVM guest boot on an AMD64
platform. The bisection landed on this commit as the culprit.
I see that v5 has been posted. I am in the process of testing that
version and will reply to the v5 thread with the results.
Thank you
Srikanth Aithal <[email protected]>
