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 E6590C83F0C for ; Mon, 7 Jul 2025 13:02:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73CC96B03F9; Mon, 7 Jul 2025 09:02:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EDA16B03FA; Mon, 7 Jul 2025 09:02:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6031F6B03FB; Mon, 7 Jul 2025 09:02:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4F5F56B03F9 for ; Mon, 7 Jul 2025 09:02:22 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 94860128904 for ; Mon, 7 Jul 2025 13:02:21 +0000 (UTC) X-FDA: 83637482082.20.C4E0FBB Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf10.hostedemail.com (Postfix) with ESMTP id 5D34AC0017 for ; Mon, 7 Jul 2025 13:02:19 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.236.30 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751893339; 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; bh=p7Ngg5NABt0BnigxkLZ9IKz6Ux4XTQy6nMXbl9FLDq0=; b=oPMMEGDaKvgej9p43+vip3EMzyluPCgOQxEyU0c9bwQMbLyM0JcgFA/Lh09FyfgbjYpqWV URP+SY3GVvmC2W7WxXl2VgH+4FJxa7MvKfM07D9BL4cEjXpMJirxipGj/uoyIkkr4VVKza Eqc96Q61508uvB/+wnDpCi4xAxHcAnc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.236.30 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751893339; a=rsa-sha256; cv=none; b=OwI5ivUR6ngFLFxA8VkgK+cMz/phlmK9uwTI3DpiYDcKJuBV8mxTockQ5FTSEz7rX1pnet 29ZFCysUUJIEOy6DpEY+gu5OB8z9XvNNudTzzGjgxu2sNH/OG29E/aVuMsL230Nk7Rkfg0 N/lQyITA9qC92gyTL+mmnwNz3p3/9Ko= Received: from localhost (mailhub3.si.c-s.fr [192.168.12.233]) by localhost (Postfix) with ESMTP id 4bbPXT2Pk5z9sHR; Mon, 7 Jul 2025 15:02:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x54AqpKF2bFd; Mon, 7 Jul 2025 15:02:17 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4bbPXT1Wqrz9sCk; Mon, 7 Jul 2025 15:02:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2AC538B767; Mon, 7 Jul 2025 15:02:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QYGnrCvnMDzJ; Mon, 7 Jul 2025 15:02:17 +0200 (CEST) Received: from [192.168.235.99] (unknown [192.168.235.99]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3F5A48B763; Mon, 7 Jul 2025 15:02:16 +0200 (CEST) Message-ID: <2ea9c28f-c3d1-4837-b000-10eccaa2775b@csgroup.eu> Date: Mon, 7 Jul 2025 15:02:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/8] execmem: drop unused execmem_update_copy() To: Mike Rapoport 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 References: <20250704134943.3524829-1-rppt@kernel.org> <20250704134943.3524829-2-rppt@kernel.org> <7e52f721-1d8e-4c50-af33-bee3f0d2ac6e@csgroup.eu> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: 3pnjj3yfanw1xxqnqp8q66hotdaq1gtj X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5D34AC0017 X-HE-Tag: 1751893339-618145 X-HE-Meta: U2FsdGVkX1+V2epH8Rsyb6uZhszl+/eVU6hDEsgmMe9n60tIPDKIWXtp4pJGg4J4AIYgqyZ62U3U7yM6RVFmD15mc7jxENzE4gFnyAbTUiHfoo+8Dbsm1t21lBr6FImwtzKFn3bo4O1MkqLOMhgVSHX9UoQeHSkluRfJ3FVDFbgrVTaEoN+6SXYMSp3R5K+VEgMBIfl4pDe3XOj+M9amSOz6Qk3IIsNLHYl0FpYdm/ZSlGmgPKs6RgaDgJrpDzAHT1jxWBferWvrxsdozWEw6D9dolLr0NeZOKcZd3m0NPJ021ZFrO7YWoLaUgDEitpJfdSB+ch6wjVgCjtR5YHpzr9lIN4nFjERuhJR1cx51gmPl1sAWThm1XgvXEW5Y9idv7zvYqstsVL+JJbui8IgdGEfPl+ohvy2iEn5Q6bNxCQGOwos2qnsOWNwBalrIhu9jTbOb1MA7Q0YTraxDDB5cohLHsdwVPn9tSQC8V6ep1oJr5nukXuGTaCOyLmyOk5qiSVZuKnMxVVK+dAr2JWSH5rglZm/5u8OXQbEdtXoj1xZ6CBq2aO0BhaKQRCGM8mY5WUSqA3DWsyE1col5gGZNvGprD7mw7YjkmWpEMe6DBGy8zrO1piettZibYuBIFELq91VmpC5ewkek3YSa4j8SxJXR9BJCriAM4sTIGpqm5+lzSEQo7v7UC9fClUI+9Z4b/TMsdm6vIKiSPDb6sLCU5sqKs7nzfml6Z//hZQozJrxdNKCQBT2Zzr6D8AJHsHXnkTlrNuDYKZazNOzlpl2ROmxW9y2SPwyV+BTFbfHBtZNFvJaVZoSFBY9L+I8ml9U46/r8ulynjXVQltfhny18KNNMQMMuEWxcqyENGkbYFUh9o6UgUziBogrThvlFTXQDoqfF8+WkJF90/UCLsU4MiSseIXiljgO32n1ac54WiwKFKUrGsSiHd2vBrh6q6T+KcMGBZZVxzfg4zrMH8q SsZ0SF6F tDXSLXhPrVce87YUR828aeIvnYBMMkC3d4/ffgmKzmujKwAhCoXJaPyvVavzrcVMOu+BjsCsHHGuxJick2zjnkEp6z5CC1hc52/C4rwaXLetsGlbTq39gzqqym6wMYc8/AaZVkin3AviJgCYymBb4k/npXVvhZMOi0FY8MxTIGtznt8fbDnnBZjs1eqoAeGLBKQG4k+fdxra4yq8xEwk5OLbDuPgvfU+6acov1irEzfL5AfiJZBYUM6io7Mr7e5cNRz0S 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: 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 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. That's one of the reasons why it has CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC , to make sure text is allocated in exec area and data in no-exec area. Christophe