public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] vdso/datastore: Zero out newly allocated datastore pages
@ 2026-04-09 11:14 Thomas Weißschuh
  2026-04-09 11:17 ` Thomas Weißschuh
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Weißschuh @ 2026-04-09 11:14 UTC (permalink / raw)
  To: Andy Lutomirski, Thomas Gleixner, Vincenzo Frascino,
	Christophe Leroy (CS GROUP)
  Cc: linux-kernel, Thomas Weißschuh

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>


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] vdso/datastore: Zero out newly allocated datastore pages
  2026-04-09 11:14 [PATCH] vdso/datastore: Zero out newly allocated datastore pages Thomas Weißschuh
@ 2026-04-09 11:17 ` Thomas Weißschuh
  2026-04-09 20:21   ` Thomas Gleixner
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Weißschuh @ 2026-04-09 11:17 UTC (permalink / raw)
  To: Andy Lutomirski, Thomas Gleixner, Vincenzo Frascino,
	Christophe Leroy (CS GROUP)
  Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] vdso/datastore: Zero out newly allocated datastore pages
  2026-04-09 11:17 ` Thomas Weißschuh
@ 2026-04-09 20:21   ` Thomas Gleixner
  0 siblings, 0 replies; 3+ messages in thread
From: Thomas Gleixner @ 2026-04-09 20:21 UTC (permalink / raw)
  To: Thomas Weißschuh, Andy Lutomirski, Vincenzo Frascino,
	Christophe Leroy (CS GROUP)
  Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-04-09 20:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-09 11:14 [PATCH] vdso/datastore: Zero out newly allocated datastore pages Thomas Weißschuh
2026-04-09 11:17 ` Thomas Weißschuh
2026-04-09 20:21   ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox