From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9414C5321D for ; Mon, 26 Aug 2024 09:43:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DD186B03CF; Mon, 26 Aug 2024 05:43:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48CB96B03DA; Mon, 26 Aug 2024 05:43:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 305D46B03DB; Mon, 26 Aug 2024 05:43:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0A1996B03CF for ; Mon, 26 Aug 2024 05:43:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B6380A0E77 for ; Mon, 26 Aug 2024 09:43:43 +0000 (UTC) X-FDA: 82493909526.23.B29000A Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf08.hostedemail.com (Postfix) with ESMTP id D08A416001C for ; Mon, 26 Aug 2024 09:43:41 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=bmPESgmv; dkim=pass header.d=linutronix.de header.s=2020e header.b=ZbN8bFkN; spf=pass (imf08.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724665338; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SWCfkFVrFX69lQNtUh8BUdPXl70d8BgaQObUYTFPILY=; b=ypWsikzAxXthH3eSdWZrXti+aVi8gLOgHlklpeZ8pa+Qym49FN/+doOlbYFRSjDJL1ZocM eo2q2sa0mYaPQDTSsVewf3l5dHkfHTnGb0Jjj0DE12f6WnU7mcpjUFVFEaYIl/PyL0XITy WJwt2XLjiCDTGPsJSxhwj0q1F3W8lfs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724665338; a=rsa-sha256; cv=none; b=SnBTb6U3E36hNYbGKFwX5EAkBlZqZbPKYwCvB5h4+/3KrKqE+dOyChFVq0jpMRuDOsV1iz HhjlXs8ejvU1T8h6ZHg2NJIYn+KBhaRMtnr4f0v2rYi4Gl2fGgwx8xFHseh2YETGPm52RR w49rcDuFJG8JIrpf7M0/Z2ftKag9Jlg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=bmPESgmv; dkim=pass header.d=linutronix.de header.s=2020e header.b=ZbN8bFkN; spf=pass (imf08.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1724665419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SWCfkFVrFX69lQNtUh8BUdPXl70d8BgaQObUYTFPILY=; b=bmPESgmvVam6uU5EAujJz26OEz8vzU03VRka4i/NIHfcO0tvLgMQav7QZ5wjTdfWFsNZH9 m/gcxCTXSaKrbFiJAtNTWkcCn1a4ZunRuUUoasin6t7EouB8Eg23E4cfndiKovgeCSQBYz azCmo6HpVRPPD0uWfpN6UMp4NrWbg+2sai7ZfHfA28PTcveLz6HognVZljULJOMHYICWRp VlNJmgDeTme9YI6usDRrT/0HoBj4xWY9nfw/nLeYCWL6cVZ/si5qxe+gtgS5GjTf0oU+vX STEm/BzYUg4sR/eJdC/VhwDD25Hbdt9UUcQHMGTfQYacZgFTJvpW65ZPJ3hWzA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1724665419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SWCfkFVrFX69lQNtUh8BUdPXl70d8BgaQObUYTFPILY=; b=ZbN8bFkNzXf9ozXai8sskpGXdUYpkAo5Nk+tQIsKhxqftJyTPMZ0uuNnAKau3plmtS1IaZ Iofyp0/mQc8sPZBw== To: Christophe Leroy , "Jason A. Donenfeld" Cc: Michael Ellerman , Nicholas Piggin , Naveen N Rao , Andy Lutomirski , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Theodore Ts'o , Arnd Bergmann , Andrew Morton , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Vincenzo Frascino , Shuah Khan , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 06/17] vdso: Change getrandom's generation to unsigned long In-Reply-To: <7d58be73-a8e5-4ec7-bbdc-238b0c25c77b@csgroup.eu> References: <525b48eb79978ddba2d1b8ee23b27bd6c5b0b4ee.1724309198.git.christophe.leroy@csgroup.eu> <7d58be73-a8e5-4ec7-bbdc-238b0c25c77b@csgroup.eu> Date: Mon, 26 Aug 2024 11:43:39 +0200 Message-ID: <87v7znd3g4.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D08A416001C X-Stat-Signature: 1kaiensn1t8ae8fesjd5eadguwgj8hqa X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724665421-725902 X-HE-Meta: U2FsdGVkX18DmIkhsxDPv83X/fXYN9CVTbke19pGIXy0X76gtwKxOp/QJxrRwiz1wP7tnLOQmB3jV5Xx7FngC1Fp+S8zHGciLiq0gPAJOsBBoamqHTjEL9Zm+DGtriM4pjYk64IWva9oevOy0RL6y2mxdntbYBew/SL8hGu/qNQ6WBkAY8dHh/d8yhoHB96Wz59AX3YfBTTGWAAYfNN8gm7O6jjEuX4X05mmJoWHYQzQs9goojnvPCEwRcFCDid7xdO9iX0cQK18PNxtxZqyD/1CtXY7xnzlCcFgPpsNIb9l2OuH6JLNPm62triJunoSmmTlPhKGp6J0J+njsE6a4hf/4ZmP4ekEQALCXFGLlytRHgLV+SzU3ajQrR9BIxk/JLHMsowEH9PQ78zM2PSeyDJujbZ+FEC/DYwHyKYDI2vjQzJBKFIhkm5drixkc64l0/3HfU2qXD+Wjiy9C1g4RnsRFk0fM3mSb8JmiVz9AkPs3EQEARdvGhD3gdJ2OjtJC+ACqGVpO4eMSHNVP5KjpaaDIWSbR51F4kCb81U3zJrajKXdNzE11DZItuzQYSLs7uXE2xxN5nJJmn5Qh2GbAHe821jU5jWsC4t3h12Dbs8PqL5agu+vBj+AL+SjAnAXsmFoyILbZ+GqWmLPDkw8RSQlJq+cJ+zlB1wNJCcFpaf9Sn8tKsKAaEDdSURvSebkuYHxnx2sHKKCvoVdblN/5ZG7QVGXSSr3BB1InrDUfkuxjKivzukk6Ka6biYm68qa/l5FRxPbhiVTK9q6S9B9/wPUfAfkmLqPfSb+3U6/D3bq9PGv2zoXg9a41lt407bMKruyUrKznxMPBVV73QuM2AMiZxrLlJJ14H10JUcnDwYch9AW89M/FBqfXbtUOD4YR4JGjb+ZUZeVeF9FISEN73rANvne337qVDXduR1AnuRnruCmScF0C3rKhUYjZR9PusngJftTNaALSGppmmo sELyInOB 2Z4k+Y8gh+yWstwbGDGynS6IxHOpnmhV7VxjXiMskAv43navjQFCVN97zM48JMXkVPoLhrg8qBIYIPE4PwO3Q7kfhBtnmT3dG83s8FnYsdtn5XNk7h/5RVMGkKn0qQahhWY8P8nSjHyHdnyCsUsdAPTzbBOemU7DAb9T2TzUeZXPD+gcc7nK/ifiPYw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote: > Le 26/08/2024 =C3=A0 09:50, Jason A. Donenfeld a =C3=A9crit=C2=A0: >> But tglx pointed out in that thread that this actually isn't necessary: >>=20 >> | All of this is pointless because if a 32-bit application runs on a >> | 64-bit kernel it has to use the 64-bit 'generation'. So why on earth do >> | we need magic here for a 32-bit kernel? >> | >> | Just use u64 for both and spare all this voodoo. We're seriously not >> | "optimizing" for 32-bit kernels. >> | >> | All what happens on a 32-bit kernel is that the RNG will store the >> | unsigned long (32bit) generation into a 64bit variable: >> | >> | smp_store_release(&_vdso_rng_data.generation, next_gen + 1); >> | >> | As the upper 32bit are always zero, there is no issue vs. load store >> | tearing at all. So there is zero benefit for this aside of slightly >> | "better" user space code when running on a 32-bit kernel. Who cares? >>=20 >> So I just got rid of it and used a u64 as he suggested. >>=20 >> However, there's also an additional reason why it's not worth churning >> further over this - because VM_DROPPABLE is 64-bit only (due to flags in >> vma bits), likely so is vDSO getrandom() for the time being. So I think >> it makes more sense to retool this series to be ppc64, and then if you >> really really want 32-bit and can convince folks it matters, then all of >> these parts (for example, here, the fact that the smp helper doesn't >> want to tear) can be fixed up in a separate series. > > So yes I really really want it on ppc32 because this is the only type of= =20 > boards I have and this is really were we need getrandom() to be=20 > optimised, For nostalgic reasons? > indeed ppc64 was sherry-on-the-cake in my series, I just added it > because it was easy to do after doing ppc32. The rng problem for ppc32 seems to be: smp_store_release(&_vdso_rng_data.generation, next_gen + 1); right?=20 Your proposed type change creates inconsistency for 32-bit userspace running on 64-bit kernels because the data struct layout changes. 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 =3D CRNG_READY; Which is perfectly fine on 32-bit independent of endianess because the user space side does READ_ONCE(data->generation) and the read value is solely used for comparison so it does not matter at all whether the generation information is in the upper or the lower 32bit of the u64. No? But that's a trivial fix compared to making VM_DROPPABLE work on 32-bit correclty. :) Thanks, tglx