Thread (64 messages) 64 messages, 10 authors, 2024-08-30

Re: [PATCH v2 06/17] vdso: Change getrandom's generation to unsigned long

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2024-08-26 09:48:16
Also in: linux-arch, linux-fsdevel, linux-kselftest, linux-mm, linuxppc-dev, lkml

On Mon, Aug 26, 2024 at 11:43:39AM +0200, Thomas Gleixner wrote:
quoted hunk ↗ jump to hunk
As explained before, there is no problem with store or load tearing on
32bit systems because the generation counter is only 32bit wide. So the
obvious solution is to only update 32 bits on a 32bit kernel:
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -282,7 +282,7 @@ static void crng_reseed(struct work_stru
 	 * is ordered with the write above to base_crng.generation. Pairs with
 	 * the smp_rmb() before the syscall in the vDSO code.
 	 */
-	smp_store_release(&_vdso_rng_data.generation, next_gen + 1);
+	smp_store_release((unsigned long *)&_vdso_rng_data.generation, next_gen + 1);
 #endif
 	if (!static_branch_likely(&crng_is_ready))
 		crng_init = CRNG_READY;
That seems like a pretty clean fix.
But that's a trivial fix compared to making VM_DROPPABLE work on 32-bit
correclty. :)
My initial response too, and then I noticed he posted this:
https://lore.kernel.org/all/315e3a268b165b6edad7dcb723b0d8a506a56c4e.1724309198.git.christophe.leroy@csgroup.eu/ (local)
If that's correct, maybe it's not so bad, at least here. I haven't yet
looked into the details of it.

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help