From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1809F142633; Wed, 28 Aug 2024 17:32:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=63.228.1.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724866353; cv=none; b=nLXAjrUDuJoFTbpBk7ZI6QV8oiBf8G8w6RJoCBe4zEFj1gxDR7jrmDE0eBadB4qAUvRTgMX08FBcJowxNE61uLiLf5gLLaJva7fRK3M/oeejIsUDOm9lIL2hh3WSLCauQk0AF3Um/qnMAnzyxDdCIl9K7LE39J6sHvBMiCuTS88= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724866353; c=relaxed/simple; bh=oxW2+MTjMrJ+ZeeK8Liz6ctDws6qsgf5Ch9PI4RjS2M=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:Content-Disposition:In-Reply-To; b=tip5iUbohSgFAXsqTbsZHvRNF9f2zcI7uexSQ5rRqywz82a9XM5ZuBBVjeJjmcPuLH4EM0JNbLQLO/GDGK5tvffo+8WPznJ4seh65/TbvDGXVrIF5DprV8YwBLbXuFSH1yciMp9DRWiYn4+1nrH54s8A+71GF41QOtQrTtfQdqA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org; spf=pass smtp.mailfrom=kernel.crashing.org; arc=none smtp.client-ip=63.228.1.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 47SHPeo9010804; Wed, 28 Aug 2024 12:25:40 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 47SHPc5F010803; Wed, 28 Aug 2024 12:25:38 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 28 Aug 2024 12:25:38 -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: <20240828172538.GI29862@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> <20240828162025.GG29862@gate.crashing.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i On Wed, Aug 28, 2024 at 07:12:55PM +0200, Ard Biesheuvel wrote: > On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool > wrote: > > > 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? > > That is exactly the point I am making. So how would this help in this case? I think we agree? :-) > > > 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. > > Even if this were true, we support Clang versions today that do not > support -fno-tree-loop-distribute-patterns so my point stands. It is true. Yes, this cause problems for their users. > > > 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 :-) > > Good point. We should just import memcpy and memset in the VDSO ELF metadata. Yeah. In many cases GCC will replace such calls by (faster and/or smaller) inline code anyway, but when it does leave a call, there needs to be an external function implementing it :-) > Not sure about static binaries, though: do those even use the VDSO? With "static binary" people usually mean "a binary not using any DSOs", I think the VDSO is a DSO, also in this respect? As always, -static builds are *way* less problematic (and faster and smaller :-) ) Segher