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 91E2EC54E65 for ; Wed, 28 Aug 2024 16:24:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 270E26B0083; Wed, 28 Aug 2024 12:24:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 220BE6B0085; Wed, 28 Aug 2024 12:24:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E8336B0088; Wed, 28 Aug 2024 12:24:08 -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 E2D7F6B0083 for ; Wed, 28 Aug 2024 12:24:07 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 626AFA03AF for ; Wed, 28 Aug 2024 16:24:07 +0000 (UTC) X-FDA: 82502176134.20.23914E9 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by imf18.hostedemail.com (Postfix) with ESMTP id 923231C0016 for ; Wed, 28 Aug 2024 16:24:04 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of segher@kernel.crashing.org designates 63.228.1.57 as permitted sender) smtp.mailfrom=segher@kernel.crashing.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724862224; 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: in-reply-to:in-reply-to:references:references; bh=DHfvUMFhpYQy9mAn0IMqRDOSXQkdCSygfrSJESi6GUw=; b=VQhDaeQ66WfALj0llyJJLvnH8z1EHFjY82qwUU1FveXf8IluYx8g6BmRMuyCdPTltglOCO f0/iIsyPhqm+7SCn3uMa4q8JnBWiCdKE9Y/mCkqBmafyJWJDfeW8rAvvaG2u4sqhKNqZze zFT/1iTTkhrfDe0709mysRmbz7Y7qPg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of segher@kernel.crashing.org designates 63.228.1.57 as permitted sender) smtp.mailfrom=segher@kernel.crashing.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724862224; a=rsa-sha256; cv=none; b=sRCTcQpdxLaDmqTax2w2nQToyb1DmqORmUi/JXvhRqKA3YLVH6poLMRUWUyVCtP/c4HFFx s1aI2Y1qB8hiKCfgZ80ZQUADMMRqbYqxCLVQNnWYdHmxJ4p+OPXT9TR5GXd9fL4Qv4TUQg rBPRozwAIdxgkb6M/oTd1Injs5mmf34= Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 47SGKT1D008844; Wed, 28 Aug 2024 11:20:29 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 47SGKPkx008843; Wed, 28 Aug 2024 11:20:25 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 28 Aug 2024 11:20:25 -0500 From: Segher Boessenkool To: Ard Biesheuvel Cc: Arnd Bergmann , "Jason A . Donenfeld" , Eric Biggers , Christophe Leroy , Michael Ellerman , Nicholas Piggin , Naveen N Rao , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Theodore Ts'o" , Andrew Morton , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Vincenzo Frascino , shuah , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linux-Arch , linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 05/17] vdso: Avoid call to memset() by getrandom Message-ID: <20240828162025.GG29862@gate.crashing.org> References: <5deb67090b214f0e6eae96b7c406546d1a16f89b.1724309198.git.christophe.leroy@csgroup.eu> <20240827180819.GB2049@sol.localdomain> <20240827225330.GC29862@gate.crashing.org> <20240828124519.GE29862@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Rspam-User: X-Stat-Signature: ekarm3cnqp5wsqww8zd78zzy39k7zskc X-Rspamd-Queue-Id: 923231C0016 X-Rspamd-Server: rspam11 X-HE-Tag: 1724862244-3782 X-HE-Meta: U2FsdGVkX1/Aj40HKOVM2uJt35uQYFjGu9gLmWwmH0HoqpcGQKNgeQZLnWGGVmd7dmMDG5Y1XXHWIsYlXPdn7BP1ym89OwsxAk1WNoXvIS99iKZsBr8T1dMw5si3iXo+ymUouazQSXS9TGijivqaE3poY7aTPLlE6NQW2qoTgpTV5fm1gU841ckfGpLwutrG38vf5Imw4TTZtnTvWuUbnjuQzXZpNM7Lnlgwlu9+1pBGvm+nZlTtjuC36MEHiWYBilv+pz1QKynaj3mJYyoo+StIPF+GIuxZnSmQ7d35MVXO8z9QLbiU5Ara7WpmafsF7xRxH6y5LYeEJCoaDarvzeRXuKPRxhEiXJrpMbolTDyM4lJ0isEmfBqqcMU4gmr5pDEATu2SHlxdAnNVwmgOINZEhHSc1O4+3c4cicFij9vCxoxkEfr+B6ISOVuFfrBtLzLx+3nMZ74S4YVGFwnYWdC7dWuMBd+nHSM0ZNPxC6q7HeXJTznNIY67yf0LiWjzZf1pJV7B3CsBVgNRQjzghqA2yV+/G+jDgqz4K3vUwn46y3Rd+ef6xKz4TjkkfIzdUdE3oyRyjI3FDibGjU45jFD6gs8wHvFutWjMCOtze//B61oM1dJWoaHKm93RCUfSxlsiQToKHQUHld/v6mdNxNlQebuOmmAw54dKqz+mGGxMcf6VLb5LGqyaa2K2N7+YxnAyV4aMP301ZI6SmbCGuteNJ1o9fk6LBgYyad4pKYcXJbo1/06j+RTLbQXnm0Ec2OmwHMpNDhCE3wJvx6ZweZIhOxWnBxxxIV8tnLMjyTC7wdJPryqZBWrEKp/jlVUU8LDrXN7kT4o4h8Qwm017KybY7YxUGSOFk8OD1ocdZOM32QBsTv0h98Z0K2BSiqQcCWz4X0W1Umw2Vil5Vq+YlwrntLAC7gak6H+z3lj8QG/wXccNNurf1QpeWyU04gDfF6rmO4gbMI6UWYPNoD5 TaPuWJBF nBXADbdHHlT88INOfC3ofweN7eonh5ecsyr81gyJEyeeZVx1Z3qva/cB80SvzCyPc+bWYya1SZMJSr2tbNKEj7gfTCdJc0F1oE8gdkl7Ui+2uh8QuJ8P9F/lH7hwNu93z9E3yErEbuhY9o7FJhF3sBFvhrG2IQNQ8yA8f 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: Hi! On Wed, Aug 28, 2024 at 05:40:23PM +0200, Ard Biesheuvel wrote: > On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool > wrote: > > > > On Wed, Aug 28, 2024 at 12:24:12PM +0000, Arnd Bergmann wrote: > > > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote: > > > > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote: > > > >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote: > > > >> > > > > >> > Is there a compiler flag that could be used to disable the generation of calls > > > >> > to memset? > > > >> > > > >> -fno-tree-loop-distribute-patterns . But, as always, read up on it, see > > > >> what it actually does (and how it avoids your problem, and mostly: learn > > > >> what the actual problem *was*!) > > > > > > > > This might help with various loops, but it doesn't help with the matter > > > > that this patch fixes, which is struct initialization. I just tried it > > > > with the arm64 patch to no avail. > > > > > > Maybe -ffreestanding can help here? That should cause the vdso to be built > > > with the assumption that there is no libc, so it would neither add nor > > > remove standard library calls. Not sure if that causes other problems, > > > e.g. if the calling conventions are different. > > > > "GCC requires the freestanding > > environment provide 'memcpy', 'memmove', 'memset' and 'memcmp'." > > > > This is precisely to implement things like struct initialisation. Maybe > > we should have a "-ffreeerstanding" or "-ffreefloating" or think of > > something funnier still environment as well, this problem has been there > > since the -ffreestanding flag has existed, but the problem is as old as > > the night. > > > > -fno-builtin might help a bit more, but just attack the problem at > > its root, like I suggested? > > > > In my experience, this is likely to do the opposite: it causes the > compiler to 'forget' the semantics of memcpy() and memset(), so that > explicit trivial calls will no longer be elided and replaced with > plain loads and stores (as it can no longer guarantee the equivalence) No, the compiler will never forget those semantics. But if you tell it your function named memset() is not the actual standard memset -- via -fno-builtin-memset for example -- the compiler won't optimise things involving it quite as much. You told it so eh? You can also tell it not to have a __builtin_memset function, but in this particular case that won;t quite work, since the compiler does need to have that builtin available to do struct and array initialisations and the like. > > (This isn't a new problem, originally it showed up as "GCC replaces > > (part of) my memcpy() implementation by a (recursive) call to memcpy()" > > and, well, that doesn't quite work!) > > > > This needs to be fixed for Clang as well, so throwing GCC specific > flags at it will at best be a partial solution. clang says it is a 100% plug-in replacement for GCC, so they will have to accept all GCC flags. And in many cases they do. Cases where they don't are bugs. > It is not a complete solution, unfortunately, and I guess there may be > other situations (compiler/arch combinations) where this might pop up > again. Why do mem* not work in VDSOs? Fix that, and all these problems disappear, and you do not need workrarounds :-) Segher