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 2B31BC5AE5A for ; Wed, 28 Aug 2024 15:40:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D07A6B0082; Wed, 28 Aug 2024 11:40:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9806C6B0083; Wed, 28 Aug 2024 11:40:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86F246B0085; Wed, 28 Aug 2024 11:40:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 633136B0082 for ; Wed, 28 Aug 2024 11:40:42 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1D372A8E90 for ; Wed, 28 Aug 2024 15:40:42 +0000 (UTC) X-FDA: 82502066724.10.872D48B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id 2E83A180008 for ; Wed, 28 Aug 2024 15:40:40 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="hDdad5/I"; spf=pass (imf06.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=1724859570; 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=klIv7pWG9BE2EusGcZ3vs44rN7czUHKrTo3cjwQ3jKs=; b=mlPwcmjs+LOegmDMlfOq0q3Xff+eZIX0lQlHbOSK1ioxVvncwyUqwPekaRP/HT9OFV2xF9 aZYwyJoo3Nv8HkfW/PAFW0IeHSmP6mv/eq+IUUFthNkuXTBQjcqkaawqPcXv6E5V2JBgmy GEgnp9Lrjlzf1y0f5oMD+it2JZJZe+s= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="hDdad5/I"; spf=pass (imf06.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724859570; a=rsa-sha256; cv=none; b=dwji3AcwBKfaXiQmN2H19w1TWaLyZanfi8BMTCyYtWNW+GPXgX686D3SPCJRK1RuFw7uXZ EYSODop2whAOZgcNX48r+/KbfuAbuhSd6M0rWGXSGtwr1+Bz1eKwP5kZqLo8rnM666jsw9 ljBSykJ0+RFZeKEjUNrD0c3fiIKhCCo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 468DBA41A61 for ; Wed, 28 Aug 2024 15:40:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9FE8C51AAD for ; Wed, 28 Aug 2024 15:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724859637; bh=+z7/VLAc5zAKqxwt9kQI0vxm8x7sulgvUDeMTRfB+wo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hDdad5/IY68zkrft/92YWfFtjDz6TFndSmnpp5pqAtaDdhgaQHXnMYujF2CwZtAvo s1dVBctohqByWUo15KsHC1yXOsb3CsxrVYgXiTlMrxSNBqKSRHb2u/dgFnWDlyP45P kmzBzCQlLYmgzPMvmTlIEcYXhkLufuTJDpchreYUAd0yoHp8hJGCENnAbHqZR1NUMB 63ZyNil+E22vWl4w+ZhugE7V8Y5RiBnHkIJ248WfFc80AZtPJMZpvtsLhvJEQmQQ7b rjS4mie2g2VPxttgup163SLxFXlpDbWSy4ple6kkn/VZnDNkSEFpYi5cJmSqRwT5Qa F/BVlj/jrU5iw== Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2f029e9c9cfso82872511fa.2 for ; Wed, 28 Aug 2024 08:40:37 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXQrVhfqjQ3YMaIRk9FZ3GNQBrBAq710Hi5wze0Day6DGZofPZOYEXRJK5X+dw6KIda9/nuPUohUw==@kvack.org X-Gm-Message-State: AOJu0YxyHn3WNgpH358kNbY9uui/e9gm8aoEcB+0X5uoa/OWR3OdlIKp y9IygIP3CQRHG+XL3VN7hdCfRDm1KIRMVc7ivCBL5IC8YlaAYcuTIi94b2kfEHsDSpFmq8q0hCq /jy191KbAQ8YpfxveETLn4g59DkE= X-Google-Smtp-Source: AGHT+IHIXIHDcxvkoioWarqDfEAwvoOHHvvDveL69dLtIdivksLO7ybL0XqtoFeExKbS+796rHsbT/SXItR1tBLUGxI= X-Received: by 2002:a2e:461a:0:b0:2f3:f182:49f3 with SMTP id 38308e7fff4ca-2f6106e36e6mr594741fa.22.1724859635743; Wed, 28 Aug 2024 08:40:35 -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> In-Reply-To: <20240828124519.GE29862@gate.crashing.org> From: Ard Biesheuvel Date: Wed, 28 Aug 2024 17:40:23 +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: 4bjxf7wq6r1ysreicf6uzpsxywqzarmd X-Rspam-User: X-Rspamd-Queue-Id: 2E83A180008 X-Rspamd-Server: rspam02 X-HE-Tag: 1724859640-485730 X-HE-Meta: U2FsdGVkX19277KeEhbDRYamXSk8xm+HmtDpS6Hldnh5X767RB60USARyg5Tp49+Xl2UpYJ2cIv7/hg1OhTWSKTbdCXw5sM4ZGCIDwfEzmPRcCFFLovJxDEkgCu+2mwNZ9OzInHR8yikHm7pYPZwydri5/AxSUQ4Q/BuE1bx7+fDWRFU2goqvzgNmRjjrNkf0bDUu2wF1bcBo5VuUIx7G84hq6Rrwl/shvmtpUwFSar0L/HiTS5gsYjiKyp8bTeV8jc1iYHiDRX/BROsNw3eLIuIbX4iekm48BMHqNi/u7Lb0BQ3Ney3fxSt/A7UsyJGkd6f/cqD+J7VHaIOcQqNh0aXsUULH4ZQPa/NO4TMsZ3qOp+ECp2xNgVw5CInp/0tBBYfeTjMUYiLZZszNeIkFzjNkHvzWuhWcB/tXPBLq5Bt7HeDvjfFl/zxZUd2JJgcik1/lejQyxdOoZqMUN8iWYCwdL7mDJbEfpNS2h2OXhWwL5n9jdewgGuqwnQ5JVPG9kN2i1+jawER7Di5vZvtENLkX+Jkhy7NRZwk2vf9Nlds6t4w8zVwigk9qs1LwfHUhhhAF+fN7qYiRoEIgkaZmFDcKwLFdZ9j6M8vMPkbjcQicM7JIosXgECxT+dc8FysbFPHE1CYNHDf0v1YXW8UKcpBXWsTns1ei/0lDvCe2qgCLYUMazPCwV8Wf6Kus2jLTGE53Ba+M08fzgjBgOGvUWLrEBRnwsk1QAEc+dEpKvp8GfBDp/vxXAZ9cYDEMH0jEhzohC57+RocezwN7O9ypVmis/kzBp/4HULGErdi5KPLBYEQmZx8u2cgWQwQy7heOgFspkzDu/RvnDODq+NBVpXF4L/Inh4GSVER6HY1DQWmqMLGj1yuzxZCMY6GeSuTzfwCCyUSL9IgeV8m1FilIfFlm50Rj5mcYmoTqmldmNgBzowqZrcUgNrCjS7itndyTtxF9KoncYFrc5eauFl uHFRqTAh 5QNzibForipKAYnvs+1Qf/6x6jPN41vFSUDr0oPZ9+KMYY4Lx1X4Wc1V5+okRkqPhujy+l1AIqVnPDmX6OUynJZDWx4wyQmytg85MmPQjBmhoktMN76AY1kEzh7Fax61klAZHZCG8FmINf/mHqgaC249AiTyGVvBUCgcM5205wsY2XnPBOu79U4lMIm9pv9yUGfQCG2JmUU32x+ZwM2UDyHJlWXnTsvIhRe04vnvLdHqxfChRfZmKl1E4UE6z5x1VJYaYVzAkOjXD+KyDhLCgwKqpMdTgQ+uLf6Yw+r+pV4Nt7aIxSkJu1ozsIOAJxYpQceThcW2lzA97VnRIxQt2Ah/iZE9dtGW2Y/PsByyX1FEI59+bg/Qw6CsMlXxyTDMux7Y6N7c1X1sRVW7v0FWeEkakNQ== 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 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) > (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. Omitting the struct assignment is a reasonable way to reduce the likelihood that a memset() will be emitted, so for this patch Acked-by: Ard Biesheuvel It is not a complete solution, unfortunately, and I guess there may be other situations (compiler/arch combinations) where this might pop up again.