The data pages need to be zeroed initially, as garbage data can break
the vDSO userspace logic.

Fixes: 05988dba1179 ("vdso/datastore: Allocate data pages dynamically")
Link: https://lore.kernel.org/lkml/aQjJNmwniQwwjeBR@finisterre.sirena.org.uk/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
I messed up and dropped __GFP_ZERO again when switching from folio_alloc() to
alloc_pages() in v6 of "sparc64: vdso: Switch to the generic vDSO library"
Previously the missing __GFP_ZERO triggered boot-failures in -next, but
apparently with alloc_pages() we got "lucky" so far.

This could also be merged into the originally broken commit.
---
 lib/vdso/datastore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
index cf5d784a4a5a..55f1654624e0 100644
--- a/lib/vdso/datastore.c
+++ b/lib/vdso/datastore.c
@@ -42,7 +42,7 @@ void __init vdso_setup_data_pages(void)
 	 * Do not use folios. In time namespaces the pages are mapped in a different order
 	 * to userspace, which is not handled by the folio optimizations in finish_fault().
 	 */
-	pages = alloc_pages(GFP_KERNEL, order);
+	pages = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
 	if (!pages)
 		panic("Unable to allocate VDSO storage pages");
 

---
base-commit: 7138a8698a39e81eb153e05500823fff76d5b3bd
change-id: 20260409-vdso-datastore-zero-87f0d2d482d6

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Hi,

please disregard this patch...

On Thu, Apr 09, 2026 at 01:14:05PM +0200, Thomas Weißschuh wrote:
> The data pages need to be zeroed initially, as garbage data can break
> the vDSO userspace logic.
> 
> Fixes: 05988dba1179 ("vdso/datastore: Allocate data pages dynamically")
> Link: https://lore.kernel.org/lkml/aQjJNmwniQwwjeBR@finisterre.sirena.org.uk/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> I messed up and dropped __GFP_ZERO again when switching from folio_alloc() to
> alloc_pages() in v6 of "sparc64: vdso: Switch to the generic vDSO library"
> Previously the missing __GFP_ZERO triggered boot-failures in -next, but
> apparently with alloc_pages() we got "lucky" so far.

... I panicked a bit after looking at the code again and not seeing the
explicit zeroing.  The actually works fine, as the memcpy() from the static
vdso_initdata will do the zeroing.

Sorry for the noise.


Thomas

On Thu, Apr 09 2026 at 13:17, Thomas Weißschuh wrote:
>> The data pages need to be zeroed initially, as garbage data can break
>> the vDSO userspace logic.
>> 
>> Fixes: 05988dba1179 ("vdso/datastore: Allocate data pages dynamically")
>> Link: https://lore.kernel.org/lkml/aQjJNmwniQwwjeBR@finisterre.sirena.org.uk/
>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>> ---
>> I messed up and dropped __GFP_ZERO again when switching from folio_alloc() to
>> alloc_pages() in v6 of "sparc64: vdso: Switch to the generic vDSO library"
>> Previously the missing __GFP_ZERO triggered boot-failures in -next, but
>> apparently with alloc_pages() we got "lucky" so far.
>
> ... I panicked a bit after looking at the code again and not seeing the
> explicit zeroing.  The actually works fine, as the memcpy() from the static
> vdso_initdata will do the zeroing.
>
> Sorry for the noise.

Happens to all of us. Better safe than sorry six weeks down the road.