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 A5D51C83F07 for ; Mon, 7 Jul 2025 09:33:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F6BD6B0123; Mon, 7 Jul 2025 05:33:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A75C6B0127; Mon, 7 Jul 2025 05:33:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 195EF6B012B; Mon, 7 Jul 2025 05:33:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0439D6B0123 for ; Mon, 7 Jul 2025 05:33:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BB87510AB7B for ; Mon, 7 Jul 2025 09:33:48 +0000 (UTC) X-FDA: 83636956536.20.3953313 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf24.hostedemail.com (Postfix) with ESMTP id B606218000A for ; Mon, 7 Jul 2025 09:33:46 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NCKLy5D4; spf=pass (imf24.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751880826; 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=UEoWclVLK++zsUvQUzM3zXvfPrVju0AfI+dssMdXZbw=; b=MutXaPJ8DgXDIH2I8OObEpiWz7XwHEXcJwXQFMe0LaXsU9Rqt/2DUK6G5Wcre0VDMK4jx+ QrGrKzbIENOYemf9S23llzKs4uVKGcxTUy3K0GfSyLGNEW+LGOLSJd+Uzu+5n5AdLr837p X6zs6y6Q3RYZUtMLq1xlMWEUq2df0qg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NCKLy5D4; spf=pass (imf24.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751880826; a=rsa-sha256; cv=none; b=MVc8y9XsgFpQs2fDy5NdyZiionqru324lFRBWAZSvJk6uZLgeG+b2YHuZrcVRN7WDoDZFs 1scknIlceSzdVsUa3eNp+nHK5XQ04clSobhPyPO9YGtAjewuM+OeOxT9Jhz/xJZudaG52s EV50CSg/Q9TzZjT/3yuUR2MNK9Zqi40= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-453643020bdso21467875e9.1 for ; Mon, 07 Jul 2025 02:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751880825; x=1752485625; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=UEoWclVLK++zsUvQUzM3zXvfPrVju0AfI+dssMdXZbw=; b=NCKLy5D4/X5K+WhVh9MNaba4m7Oah+biZiODN6wwRB5TSmZZJhe05kZv6VmscZ8FuJ bNtZ5bmAoT4Hv6du5D7hl16QaOtXmwY8NLfP6mKeTj05JUCoPPLXn2/o5LrYPHgEwlCL +viyekQvkDYFUO7gLsuXapu8vPKnRKLegwq78HLd4yNho4wF/Nsk+BZxnS19lL93W0u5 3BsQq+AWCMweKnsOIC3uIZJdX7UW2EONid/X/of6pd7bkeDv9XZz+7grcYZxe739ePT1 X72ON9xuKmmRw2t0+NGRPDu77tsbtkggtJAJCZuntjoYPo4astU24LN7YL/jsbJrzVF1 cf5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751880825; x=1752485625; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UEoWclVLK++zsUvQUzM3zXvfPrVju0AfI+dssMdXZbw=; b=grcleMRULCISeuuFSlV3o4YwQ4kC6HI0VmMp6PdRV5gDbDprE8XHay6GZqGELVUX6F nXUUCrH+6xm/BHg3i+0Ncn5JPN8zOdtO2ltaOLrwulskKLfqPxNv4pAL4825kHqfEE1F 6O5IobHkOflTbJLnWCgIWXZdDXSuDfCFOicWWPVcnMwsumxI65F2vef+247a7fuR/d4K PRUKoo0AYXtLke3PlpdawAYR+0eekLtK/Lt+xN5gygTDawzw4dA+DwPdq4aYTFN3uFmJ jRYycKgN7gneKvWxX1qoyRJP2chfqL5tkOYjoTAE/9sHwLyauWHJC2BDDi7FJKyuW0O8 r8/w== X-Forwarded-Encrypted: i=1; AJvYcCVfwYjzqmrN87ljM4P9oQGXsTqp1hWm5jsCUe27zrd5/Nkh0aIML8qZ5mcYd7YVHq96sgv8pxv3JQ==@kvack.org X-Gm-Message-State: AOJu0Yx2zDzrNIFo99KvhBsxPJ3KnErl0Pl22KamhOdyMUe84d5RRroX Iln07x5G1MtPliSd+UE1ml64Auj5c4eYsXXaxIdZ+Pp6Ct7a6Oyp5XlBeMMfuQ== X-Gm-Gg: ASbGncvrc7g16Yy0C3HRM2T/r7ouo8lef47GCTLcnbzkoguakX4WJyUF/tgL2N2djA0 XEX1LCq9T5itkaGktrBcOU34pv9nh3AX6yjEY7qoAmkubFalJMQoL2bPaeRHRXDSTC4aiNGKsNG Vu1wollR5hw8LbSsFdWgrWN701H8l0MrTl3ZNI3aPPELGQBQ/79e9tWZX4DEN55OvbYVFzQpHS8 xt1KSaLH6qa39BgnP6b4QINS2VHqtVNwqT7hV7Kn6XnjlKGjejlSsHPUxX72yt/CDcUug8f5yoW 23kBcBfBdwdMRmLSYAspCDUQjWVyRHClEByobJkFiqzc43g+AAXQO5+ShpuHNY+N4zIHjXFmJyt dqO4cnj+lPOpUmRCcMg== X-Google-Smtp-Source: AGHT+IHF0gd8h6xxh8ABQxf8dvl1fyJrOmaLW4qZUtyuz1wiG1CAh6xJm3NrUh0NSfp36G2rhnaGbg== X-Received: by 2002:a05:600c:4f4f:b0:453:23fe:ca86 with SMTP id 5b1f17b1804b1-454c1ff149emr38396685e9.4.1751880825029; Mon, 07 Jul 2025 02:33:45 -0700 (PDT) Received: from pumpkin (host-92-21-58-28.as13285.net. [92.21.58.28]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-454adc71aadsm124445815e9.25.2025.07.07.02.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jul 2025 02:33:44 -0700 (PDT) Date: Mon, 7 Jul 2025 10:33:41 +0100 From: David Laight To: "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin , Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv8 02/17] x86/asm: Introduce inline memcpy and memset Message-ID: <20250707103341.62934795@pumpkin> In-Reply-To: References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-3-kirill.shutemov@linux.intel.com> <49f7c370-1e28-494b-96a9-f45e06ed4631@intel.com> <20250706101342.069b5068@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B606218000A X-Rspam-User: X-Stat-Signature: 497s8y1sjnch8ddft5osshw7zque398t X-HE-Tag: 1751880826-514207 X-HE-Meta: U2FsdGVkX1+gzjf1yHPwizJC23mByP+TCiQoKn3xtpY0qrVyloEo9fVz+J84cVh36uy9GYy/9RETmD8dsOQWPMcZyCwQyzw5GmOoxtwwX7HBhdbsXkvyb/7qt7NBpiE0WYco6JQa6DhQfs4plY+vc5l3K//PEz8Sgt43biY4yaEj1dWSZoddvlICionYDfMiMHdlZYoH4BM0nx58uA4JVaMPpAz6bjEsWtfWbhtAm+gzhTSED7lENIckYTn4if+FtBTqcChD3UatRTiAoqV4T3PlBTbuAfTQc5U8Vq09IAaGudcY0/B298Lc7/jbC+IGP6a5Uw/YMGD1VmjbtN95jQ/GIobtU+zCBQTPaMMvBoJTAY4Im1zYip6CLtfso7LAV2iUwdFp9JKn1Yvlhe0vt1S24ksAoGjPwysjKBYHkLxYCQoK01KNa09sNOuu7W2u6oAPq0rP6BGGyFHW22Cz/2Vs/faQB1mKs1xLM6HMRlCLTiYP4vJwBPDmIaOr/TcCpv/SlA3BhGYvKAYWpV6Q1z992qx6WVJQvUTsf/E8PojYyEMp1raSL8MLFOCmEfoHDiKiCDenVBiMhMYas0h9UROGtF56m5sGabkB+NVgkibcDazkWZ256lFJobQZykP+eezrJslr6HLCDAHukwpRO0vqyd6DswTxinuLmVAAfvZYmBxKrG53ZjpZ/0IToUttGobjCVZEAn0XO8R8U0Nc8TXuLwvk13avobGUMvtFlEjZrO9j8ITFTDNQQ3wGMR2gXyXrhKK4y3QcoswKqMcB21TQtItLRlrAcy3+FnTxcqp/eYRrxjfPDPjsYNhmx1mxHIK7qkwtNJynFcVwIe3MwNUMQGoSumyD7mG76le34oYxKHRfuOggYnYvJ3t7MO00ODF/nbEugbtfHo/kk7BHCvoJ6xHT82ni9TanqBf+r8islYIIhW/czSi8koGqx3dF7vZ4rEjnn3BpDP0Yttx PDhkPlFf O5DKWRI3u23SOVVBkTMp75Okk6ZWuxLL3jdi0rnQXsOuyVE66DYVh9aEBe6p5z4p+u7cW7+7KLfDgbQHNIkq6aBwno3mvtsssbPNthDF2a4ysuuOlcLCSxv91XYzD9kFcBfKvmkePBlb7TlPPFQ6aWVbWHOvGMLY6ae6aE9ROZTIkK6Q7s4KCghOaDYD/Ss70n1FZMzKTkCJtHqqpdpyWki9Xt7qKpB46IHJRiQe5HS46+v2BzCS4eLBmkE4m3t8YDekypuSgyM37dI5VPEpjFMB+XbAIZM9CaBVVnn2bbKVWj+THgAw86mI/ZfGrPOtZZ7BpTaapzf9+Rmi2pHptOUJxJE2N5P9NJkDqo/jrhKHrRu5RtZffRbO6GFtP09qtdn7BuLP0EpgAYc7Ct6zTIbKte69NugyNyU4InsJEBEzw7rOhf6DrYMcFbnqg7McggmCP2eFZepF43EIWjOAtMtdRID7EwE3LqAgc2QiaszaC0an850zF2pmc3rJo8L7HTgtZn0L0NBtv4xL4ZaDcuVtf7d4ndIStGAcx5ukpTkRtk+47Dx9t+PAZT9m/cdncapt8YUp5USEeu9I= 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, 7 Jul 2025 11:02:06 +0300 "Kirill A. Shutemov" wrote: > On Sun, Jul 06, 2025 at 10:13:42AM +0100, David Laight wrote: > > On Thu, 3 Jul 2025 10:13:44 -0700 > > Dave Hansen wrote: > > > > > On 7/1/25 02:58, Kirill A. Shutemov wrote: > > > > Extract memcpy and memset functions from copy_user_generic() and > > > > __clear_user(). > > > > > > > > They can be used as inline memcpy and memset instead of the GCC builtins > > > > whenever necessary. LASS requires them to handle text_poke. > > > > > > Why are we messing with the normal user copy functions? Code reuse is > > > great, but as you're discovering, the user copy code is highly > > > specialized and not that easy to reuse for other things. > > > > > > Don't we just need a dirt simple chunk of code that does (logically): > > > > > > stac(); > > > asm("rep stosq..."); > > > clac(); > > > > > > Performance doesn't matter for text poking, right? It could be stosq or > > > anything else that you can inline. It could be a for() loop for all I > > > care as long as the compiler doesn't transform it into some out-of-line > > > memset. Right? > > > > > > > It doesn't even really matter if there is an out-of-line memset. > > All you need to do is 'teach' objtool it isn't a problem. > > PeterZ was not fan of the idead; > > https://lore.kernel.org/all/20241029113611.GS14555@noisy.programming.kicks-ass.net/ > > > Is this for the boot-time asm-alternatives? > > Not only boot-time. static_branches are switchable at runtime. > > > In that case I wonder why a 'low' address is being used? > > With LASS enabled using a low address on a life kernel would make it > > harder for another cpu to leverage the writable code page, but > > that isn't a requirement of LASS. > > Because kernel side of address space is shared across all CPU and we don't > want kernel code to be writable to all CPUs So, as I said, it isn't a requirement for LASS. Just something that LASS lets you do. Although I'm sure there will be some odd effect of putting a 'supervisor' page in the middle of 'user' pages. Isn't there also (something like) kmap_local_page() that updates the local page tables but doesn't broadcast the change? > > > If it is being used for later instruction patching you need the > > very careful instruction sequences and cpu synchronisation. > > In that case I suspect you need to add conditional stac/clac > > to the existing patching code (and teach objtool it is all ok). > > STAC/CLAC is conditional in text poke on LASS presence on the machine. So just change the code to use byte copy loops with a volatile destination pointer and all will be fine. David