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 E9248C83F0F for ; Tue, 8 Jul 2025 08:22:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FD436B0149; Tue, 8 Jul 2025 04:22:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 339F16B0143; Tue, 8 Jul 2025 04:22:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B3336B013B; Tue, 8 Jul 2025 04:22:50 -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 009E78D0001 for ; Tue, 8 Jul 2025 04:22:49 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A7E59B8C27 for ; Tue, 8 Jul 2025 08:22:49 +0000 (UTC) X-FDA: 83640406458.29.EA1840D Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf07.hostedemail.com (Postfix) with ESMTP id D29984000D for ; Tue, 8 Jul 2025 08:22:47 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u5arvs8f; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@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=1751962968; 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=I4xfO7kcO3WnmdYCnAOwBLGngmmHE09ZPZRTz4uab6c=; b=lkxExMcMKgdMLfkEldkKsLTzGuZ43IkQFPK7aXA/FyO1GD5NAjckQe3BzpSmLh3EnMthKB 9WdlnWEV6acieQyl7PBsAsRNamn1Fvc5oNYzQ1UXzCeVawYoCie7Z+nOTkv/WK4ZkwsgM0 DEku4hGudzjv5oQE2ToVL50/xLbsIbY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u5arvs8f; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751962968; a=rsa-sha256; cv=none; b=mqzuxzFDqdivYBk3xEkhn4Nl2N5UmH4upYlw9egb0KjGLOYvhJx6k8T5YJ4rV7C3oQ9ZMb lhzzdYGq/DMEIJulJWZyvW6K5en7jkEA8WXjXV/a92faBWvxFHoQBXVXDL6EDMQBDeV5xS e8gPzCDB0eY1XhohZs+2r7jRPwJxPc8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id AA256466B4; Tue, 8 Jul 2025 08:22:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9065C4CEF0; Tue, 8 Jul 2025 08:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751962966; bh=oRwqOe1brAYvYekojKVNvxAmK4Lubg+YWxdejVSPic8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u5arvs8fUGa2VSSCCCZx+qpZf75PEDkfi/z0yr7IfzJRPNZ+Dv8qZa9/AmQiF15xA VZFsERmwXeI2iXyxDcdvbS5uM7Mb1rHNs2UyVpQJgTLP6Xmb/VmNlFhACZuYJZxvx5 xgnJpeI4vR1D2QlyjmJGtqPkXK4hfZwAQt+ekDYlz2OQaawYMFKxwqtDOKabBE/E1C TbjFUsJsSMLvgtMr2mXGwb2UrjFB6SnEd2jYHgM+qmNivLYnOktUUB+JgCSeAsCVYn /E/v4Qjo+poQCiUa01PnM53uioAU2+QpmJAOfHjsCmyG+Pkub7MQeuBuuQ+hdVk6fz a8dQTTNzqW/dg== Date: Tue, 8 Jul 2025 11:22:37 +0300 From: Mike Rapoport To: Christophe Leroy Cc: Andrew Morton , Andy Lutomirski , Borislav Petkov , Daniel Gomez , Dave Hansen , Ingo Molnar , Luis Chamberlain , Mark Rutland , Masami Hiramatsu , "H. Peter Anvin" , Peter Zijlstra , Petr Pavlu , Sami Tolvanen , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 1/8] execmem: drop unused execmem_update_copy() Message-ID: References: <20250704134943.3524829-1-rppt@kernel.org> <20250704134943.3524829-2-rppt@kernel.org> <7e52f721-1d8e-4c50-af33-bee3f0d2ac6e@csgroup.eu> <2ea9c28f-c3d1-4837-b000-10eccaa2775b@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2ea9c28f-c3d1-4837-b000-10eccaa2775b@csgroup.eu> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D29984000D X-Stat-Signature: 8wztp3c57marzai5x9cpb6py7an9dihx X-Rspam-User: X-HE-Tag: 1751962967-341294 X-HE-Meta: U2FsdGVkX1+Syv1KzFHU7WVxFeL1xtuVaSPhXZWSazw1N9VAGry0B6trd/+a8XGGpEtmdn1F4/YiA05cjj0blvlYlKBLdzqZPIE4/i5D1huuAc22UhgHb8si2fx5AF+0egP/8odNeyG02OFSc3I8N7uldN9vs/4Hv7notdaZA9l51gPwC6PPMuC7mnwOBi9jyJw4o4irGPIVYqptqrySeZUi6lm2mtmiLNIGorKActxFRrRW65KwvOleXEuTJlKAYFrzZRo63nE7iopLoRrwOXvbbOYWPZFsSd+j0Y2WeMOuiSn84bWANkXNaCX5ZlPVLJpdQkYPC1ZjJkMJC5GfR9aznFDZUqfGGaOwpKzQwkWTjCUHBrGyphZTDxSAlPlxc6OjyK8TlULKu+TxSfI2GkTWLA3aloDRE/Y51SnQJl2GgSHl1jnFsjcpaaQaVN+YJoalu6KXIFEtbgCbUGjX0H8QJjRwJnFAKBlaj6GGKxmMFqc640/cb4hCkgZRoEnBFIzhRQ3gI77YJQsUuwp9TaKu68LpihNbkMYuJxWX5tAucgdJ4dzFo4gjf2L6njxXJUQc74JBDzuDdQRFTdDU6HCsTaF8sfzkW3slYN2ULeOSAXoZZxcyHY/IE5LlHAyK1b9dzR5ogtgnlt2yb91TfdZ251vest5qlOZAIGTxbRbSPEQe4L2adxreDQJx0sl+WdO7emUPf7FClXoAgV8qjFjsO/EfISjZvsnvIPfHglY5REElJ5InWJVpVUYYHxeO0wusB//2W4+3l2laEJeKamDp2Wf/X4ePqZLL+QLgnDcvAuaNRWWQO24mdyQ9cBFGTuz7u/aG/IIPCAvFKAr5VELigno6X36c55g/UQ0PYopQG1jfrd9A9rcxPXd3UNmMD040LD/aGmRxG6GDiKrDbqqb8cduVH1UF/v/YE+pbbzhXnLt5TAgVQ7+xdxj7vROKFRA8ufiFjLDJQGYI/o xDVVKf0g ZZaTS9VkozV347ZJ7qMrD10MhwzAn2qOeeU0pdNbTiZHsHCwogUAf8GVMQA7njYV5ZAfxFiLjsuJLkboGzned3ewo3bINdaW8YNVYtqOcjIRLUN8sTU5ZKnvhKKWBZaN6hxCNSMIj7VMtW1ukZmLVQMskUh8rLE1FpUywdsNj1Z2H+cQfj82KZRJ77X2L4mxgsWSLiFs/G9dHZ1FyF8BJsU+yc/LHJECBPCFJ+ef4KnmRB9QjL1ceEtKzwzaZp/5ZDohEOgcNyzI4NhIhDtaKlh/KCs/qO33BWJC9nVE/VXAk8C2/5NG3P2ZPUZxoshnIG2xoPd8SS3Njy3HVSDJaSKai0ixtdFxzCVhz 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, Jul 07, 2025 at 03:02:15PM +0200, Christophe Leroy wrote: > > > Le 07/07/2025 à 13:49, Mike Rapoport a écrit : > > On Mon, Jul 07, 2025 at 12:10:43PM +0200, Christophe Leroy wrote: > > > > > > Le 04/07/2025 à 15:49, Mike Rapoport a écrit : > > > > From: "Mike Rapoport (Microsoft)" > > > > > > > > The execmem_update_copy() that used text poking was required when memory > > > > allocated from ROX cache was always read-only. Since now its permissions > > > > can be switched to read-write there is no need in a function that updates > > > > memory with text poking. > > > > > > Erm. Looks like I missed the patch that introduced this change. > > > > > > On some variant of powerpc, namely book3s/32, this is not feasible. > > > > The only user of EXECMEM_ROX_CACHE for now is x86-64, we can always revisit > > when powerpc book3s/32 would want to opt in to cache usage. > > > > And it seems that [MODULES_VADDR, MODULES_END] is already mapped with > > "large pages", isn't it? > > I don't think so. It uses execmem_alloc() which sets VM_ALLOW_HUGE_VMAP only > when using EXECMEM_ROX_CACHE. And book3s/32 doesn't have large pages. > > Only 8xx has large pages but they are not PMD aligned (PMD_SIZE is 4M while > large pages are 512k and 8M) so it wouldn't work well with existing > execmem_vmalloc(). The PMD_SIZE can be replaced with one of arch_vmap size helpers if needed. Or even parametrized in execmem_info. > > > The granularity for setting the NX (non exec) bit is 256 Mbytes sections. > > > So the area dedicated to execmem [MODULES_VADDR; MODULES_END[ always have > > > the NX bit unset. > > > > > > You can change any page within this area from ROX to RWX but you can't make > > > it RW without X. If you want RW without X you must map it in the VMALLOC > > > area, as VMALLOC area have NX bit always set. > > > > So what will happen when one callse > > > > set_memory_nx() > > set_memory_rw() > > > > in such areas? > > Nothing will happen. It will successfully unset the X bit on the PTE but > that will be ignored by the HW which only relies on the segment's NX bit > which is set for the entire VMALLOC area and unset for the entire MODULE > area. And set_memory_rw() will essentially make the mapping RWX if it's in MODULE area? > Christophe > -- Sincerely yours, Mike.