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 62448C636E5 for ; Wed, 28 Aug 2024 17:13:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4EB36B0082; Wed, 28 Aug 2024 13:13:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD78E6B0083; Wed, 28 Aug 2024 13:13:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 976B46B0085; Wed, 28 Aug 2024 13:13:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 771FC6B0082 for ; Wed, 28 Aug 2024 13:13:14 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 251F9C052C for ; Wed, 28 Aug 2024 17:13:14 +0000 (UTC) X-FDA: 82502299908.19.1991B89 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id 3A6E44003A for ; Wed, 28 Aug 2024 17:13:11 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SFar5KJc; spf=pass (imf11.hostedemail.com: domain of ardb@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724865102; 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:dkim-signature; bh=AxP5p6vD8WoRT4fDcBhmPqf4pYQ9KeCD5eFFIS2JcQM=; b=7V/NV4wJm9Ryrx5Mg+MdkBgCApM/j8MC/VAkrLLBh2tAswAEV8fLgKBFrTNmHvETKAlMvb kls9kqYf7iKjd+TNg6bk5S8hE62vFmh8I4BYpVm0LzEgQ9er2XYIcus0dj4VFgHZdsv5oP tbO4lY6iiVSXU5nP4MpjI4z77UdXku4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724865102; a=rsa-sha256; cv=none; b=M+5RPXWuAdNLXH1dnQ+LcrmuLng2/ZoXkkBileEMCdxA7UQviKeTG8o1/E/QC1zEE0ymQZ nJQdU16C8F7unJkGOGNuf4HKuBFsX81WqTtlr74xM6PPh7WmL8S/QRbZGwn2L21y50G2X1 VumwvhI84gYxSb6DpCtnYjr1r0M0+ik= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SFar5KJc; spf=pass (imf11.hostedemail.com: domain of ardb@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 3F16EA426E7 for ; Wed, 28 Aug 2024 17:13:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9C33C4CEC9 for ; Wed, 28 Aug 2024 17:13:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724865188; bh=wTRLnPlAZutCpvLR9R0pglZtR1qgqcPfis4YRXDGlYs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SFar5KJcyOOqLxwhcaGjzk/s+2JLgrGwjQyRUqMnq6qFBlWFPPLW87QI6cfGTmo/s kTVZAokZ2cisPjdcnUa3o49tV1Mw1SpGBGSGUcYilXuMO9Efm1NJJ5zCWyc1Tt2Hzm lNCW48SmTnuXeiI0kQ7hshKa57+I34WmOj4Hs7S81TVeAqFWJ+xVjZqUuI0mSAO995 Iq9KaCwlEo1MddLN2KZngqRFwoh2+BZIWdXuoIxh32ggUPof8YLd8aatTgjH5SX1m+ 77gnG1IU3Jm1Xrpe8VgMpb4xQNmxAy8A/Nn9dhjj9hgXea2lYFDEJuJm/71JAeV9HL rP2cvKtthC9KQ== Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2f3f68dd44bso79393101fa.3 for ; Wed, 28 Aug 2024 10:13:08 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX/sbtsYV6wuDz2eGQmCD8MrkCAEPWIVrt5gYQCZtBgI26mF7v00x3/aFet0DIxwNzFgWVxYmLxoQ==@kvack.org X-Gm-Message-State: AOJu0YwnZw0ThWZ9SBF6aC7djW1LhEFkenuU7Kgxx0vKB1CEKQgekqjX 8JtwUB5MF6y0SR7g8R9tDeMbd2oAYBjirCxmDjpu6V5swrPRaM0+M1das755EN+tGrU64xtmRXt N+uA6gTxRp/IH4uSbW4N4+UTnjMY= X-Google-Smtp-Source: AGHT+IGT9a5qWQBtajQWghZ5b1FsgrYGjXl26AJMqNqo5EHBiRSmkhizffOxvoPuUqVl91lIQUxQnoyI/1L7KXA3rkA= X-Received: by 2002:a05:6512:131e:b0:533:4689:9750 with SMTP id 2adb3069b0e04-5346c626565mr2097762e87.26.1724865187012; Wed, 28 Aug 2024 10:13:07 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20240828162025.GG29862@gate.crashing.org> From: Ard Biesheuvel Date: Wed, 28 Aug 2024 19:12:55 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 05/17] vdso: Avoid call to memset() by getrandom To: Segher Boessenkool 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: gby5katr3551t18itb9k4fpw3y5eii3q X-Rspamd-Queue-Id: 3A6E44003A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724865191-153860 X-HE-Meta: U2FsdGVkX1/7Cp9ZC2xtVfJRgi6u4Qt7I9LzgkKHMt0cr0v16Tp59g0ur04yM0zT9RBOpdWhC8yVDTt9jt5b3ds971nCa+iO5lc9UGlz9ppZQMx/Mpa4QLEh2nLh22XL4s15kC03y/+cT64ps/0mmqlsVR6TmnG7YW3EfXo+CXlkvw8Z5FkIlx/Qpz5jJTjoQoqB1FonBDJ739hNLAF91sFRlz64LIhPnGM11KsvJlqdqk5OnWRoaa3VIrq9jXLSIw5fAOur5OxCjMgdKBOhIaKZQ/uDFHoKJbYFi1udJc8kh8A9yONU3ehL2Nq4QI8ZTuss+ySDNdiy/XBKJGKaI4AjH7gXIOyjf0PEv4W4/5lsqg7q/TdcilFCOT/eDvaNrqX/xUfgaFNggI1pP5c6tAb+LcHAe8beBY3HlA6SDCeG3yyrJMUlK9mP8l6+w9sryUBe2ZKZrkTJJANNLAQUfmqPCdLNMNaqVze6TTLEEM25LtTNfjhSC/iN93AJZchtL1qDa8rrtxs8Rwf1WpkUSTYwNT1V1Lj52lib0345ReJwh04T0XSxSYGgbygQWNYod3BbzVcvrTIH3GAoSfCMPaZCQooy9p/mnBVMROrpa/NMawYandMh/zxTtY7ytKq5X6VxexR2gjT3lAIsKdyolRE5HLXiHblAnDIPJscspecdDsqmhGDx7oeqTGGH32OyMK1nPtrL7SG9xqxkTVFk8GS1kd/uzTbHuOrZpOfB7hsXo17QIOysZ3sRd+PujgW8gPFurGA8fGEvqJY6OYKCVYFGxMapc1WXj3pi0f4rCqEC/eTe5cjvCpBTW5G4UM9MDWfYELb3dRDyHpVrRAm6HaKkTGc6DnM6ragrI6zt7Bf8HQNRYi8OzNNM7sK25DbnApRojtuBtd+0GUjtS16shCVu5OgkNDXVhCdm8emmYCW2qQmw/SMypVexnvxt83m9RgtiAkrgXQ21t4SiEiv O+7OHtyT U54aRaZJ69NmoJzLbano+mPkB3GouUpZ+iBmwiewe1NDgl5n1kJKuK1sOfC6gTzYAZDlPjqJTVXxO3LAzr+5qIHWMfwv4cmIcyHbmW1AjL3WxUIzj4L5Mk/8FG6QwDdm8tQVdk6OwvzNI7aZbY8pGMYdRY5FGxUISQM7eOYLkdt/L4Fldvsk6ydbqs8bMo3j8HP+32EJ2jGhZb5FdgxCmuQETq1068wF6yap1JnM9t6GYpaFVmJD5MLRfNii2awlMjstrWAAU3asPo6XfWIG1m0OqUaOdvk+44VQJ/PeHF7/lJe75EJ3GSxLArDWsxOjg8/hd 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 Wed, 28 Aug 2024 at 18:24, Segher Boessenkool wrote: > > 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? > That is exactly the point I am making. So how would this help in this case? > 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. > 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 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. Not sure about static binaries, though: do those even use the VDSO?