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 9E688C25B48 for ; Thu, 26 Oct 2023 08:41:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7C566B033E; Thu, 26 Oct 2023 04:41:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B050A6B033F; Thu, 26 Oct 2023 04:41:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9800B6B0340; Thu, 26 Oct 2023 04:41:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 837956B033E for ; Thu, 26 Oct 2023 04:41:05 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5C72CA01A1 for ; Thu, 26 Oct 2023 08:41:05 +0000 (UTC) X-FDA: 81386967690.24.D3D6389 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id AC9B51C0010 for ; Thu, 26 Oct 2023 08:41:02 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oRC27PQC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698309662; 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=al1h083ly2/rhanagRDpoUvgaJ6/lg4TQMmk4pYLl1Y=; b=RSCMpAW5m5m7K1SMEbNoawxLJMgdKZgCi+yI/IdgaCI9v+1GL9lyVpDu9GaKUUeCH9f4qc kFf6+/y4Et7xgU0m1IZ+UJSbCnFwlNyUNDVmlvmJl6U+k+2iW/zCHNckvfENRcxlhuVQGi sTTQNgtYVSyaSsFWDLs8eiTbr4nKZkc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oRC27PQC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698309662; a=rsa-sha256; cv=none; b=NUSdd7jFUMfNfw1PxyTyXlUFMflY2ee2EVUa57fD7am7k3DqQkb69J05D6gXTJuSC/3FUQ SMWhb4VIKXkVd+I/rb7UgkZwLS5m+H66BiIWjNCYZJLd8BPGQTePwxLHMgCtz8SbtXSXlI 6CJj/k7vTKGjDF8aafgYVg2rp2XNExg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 95C0260959; Thu, 26 Oct 2023 08:41:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F6AFC433C8; Thu, 26 Oct 2023 08:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698309661; bh=CKweGyf2oPo/e/UZLG1WYH3zEQnVvPRR68BdbBl/TGo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oRC27PQC2plQ2QFtxeYNcapuTdKaVmbmEUR0m69y9zSqXieqEvU2U8HaibfItzWZF yERD96v5VwCZUJZD6El6ZorfVxYGGBw2vENxYrzOh3JNxfzIcWV8Hyo/98RmvjYp1O Ink1QwB6gOI9hZMPLodFMqMmfk4UUgDFD2PT2vR0MIfYSLtLLeyvF4ch6/DBDJ+K3Z 0bfW6e3KP7yJWPzCmJpvtwgF2RV+VsKMprb/vimV6IovW84by85aPvP9y1WYUJyow3 BUjvGbMWEhiJ9hRAr+vd5AhVyyu5+qGt0miVwVbaUWHgtUSofxp310DRt0OzuziAvf CCAilLzZ675cA== Date: Thu, 26 Oct 2023 11:40:39 +0300 From: Mike Rapoport To: "Edgecombe, Rick P" Cc: "tglx@linutronix.de" , "mcgrof@kernel.org" , "deller@gmx.de" , "bjorn@kernel.org" , "davem@davemloft.net" , "nadav.amit@gmail.com" , "linux@armlinux.org.uk" , "netdev@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "hca@linux.ibm.com" , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , "kent.overstreet@linux.dev" , "puranjay12@gmail.com" , "linux-s390@vger.kernel.org" , "palmer@dabbelt.com" , "chenhuacai@kernel.org" , "tsbogend@alpha.franken.de" , "x86@kernel.org" , "mark.rutland@arm.com" , "linux-parisc@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , "mpe@ellerman.id.au" , "christophe.leroy@csgroup.eu" , "linux-riscv@lists.infradead.org" , "rostedt@goodmis.org" , "will@kernel.org" , "dinguyen@kernel.org" , "naveen.n.rao@linux.ibm.com" , "sparclinux@vger.kernel.org" , "linux-modules@vger.kernel.org" , "bpf@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "song@kernel.org" , "linux-mm@kvack.org" , "loongarch@lists.linux.dev" , "akpm@linux-foundation.org" Subject: Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module_alloc to execmem Message-ID: <20231026084039.GJ2824@kernel.org> References: <20230918072955.2507221-1-rppt@kernel.org> <20230918072955.2507221-4-rppt@kernel.org> <607927885bb8ca12d4cd5787f01207c256cc8798.camel@intel.com> <00277a3acb36d2309156264c7e8484071bc91614.camel@intel.com> <20231005052622.GD3303@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: d4eiroro8mxxgbzro6hyb9pu1a5sp5sf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AC9B51C0010 X-HE-Tag: 1698309662-593384 X-HE-Meta: U2FsdGVkX1+i2IqFKYIQyCMIk9jE7enmOZDaL4O+puzOxwVxh+xRIJVlo4PVn78PaNw0Av/jnCuupnljVzMufSpyX0/raK7pfcDAYr9BlyGU27vo1Jq0jomwTADHSKURsOLwvaS+9rdWhwkTf5snr0D/TvbmRnmJH/ghA0RlSLsWS8GbNg6+Bku2crMomXv9s5YhZP5sNG35UNALIbqiMkdz7FXauPcpnaL11qlWmcQP/hWe5UVmpc8YbWNL9T2XA3Loz/3a6ZW2OjZriXAK8CHWVOre/6k47XsQEWhuXGNUtUH1DabnfrNcTA3zfBm5UTCj1YJbV9vUAmww7lsy5iXxCtoCSVdgDLK0/rEydpqsOrdoogq/hFe5+Mjmvmyh2GfIY+3SiFlHYR6ZFYRD2w8G/9lPTY72CCKez1ezGdlFLoAQI3AXmMgTU++zSqQTQY6d3EyYkzMlp/YpNYyk9C9nE2Vc2O8DWgCCGRg75w3gpQN/4c0NLV64b8xKPC/EIx2dAz+bIquAvAJSG2YZ2ii30DI8q8bIas0yqnqO7xuXK6U5Lox00SEL6wKGmqTs1Tjb8bQoqJ+Q9W+vSvSsXz0nfmEbSYtVUsUfTznHqmxoYsOrtNAQepov9PtNIENoX3RfzKm4+wEJnEqUgB+5681lEc6vdrpFlFTAps8SFasaRRYCldk/j0lh8tD8bQ2UHCi25p/zBjwyY3F0ovR/8LK6uERhogI2MEBYx9fy4K52pgRYSpOoWoxMiCojacs6XPNznjvvgyb254SAWaaZxNwfSiqq2L83m5uJpr7ODPkeXaDafOOtBdD+zibIzto85kjc7byVBT/SgGqxMyLecz/oNzWbEO2EFISNkvP1NQhuy8xdi4pf6eydfbD3nC41dp2SoO8nYwy+SXXLIoye1KSfv0BZOnMV9bGrdctNCju0V1zOkLM8oqy5yVu/sYfkXYKoH3hezxsqPYjja2l +S9ZxmgE TDBC4pPSIMePhDbLnhNPSjKn4YpbXiDxMYNuubTSc4TnjXbNwLcHcMqpmi05zvVlY8wt4VIHtSi1HoxUjmHnu40WOZhd/xRyg0/uH/53ysw3sdTM+VrUZwGUMJMEbwLeVdQakxsYXYKNgHQiEL7ZZGwbaoXtUnL3RUmNJp45PEGMCD7LYOqQyb0rPXrlyGrUBlqdCHup6xEcrmpKvmqKtmy3BVthcRoYkbEqXGW9gICOlXlgO3fHe/IoXZ6mPnBZvWFjtshZJrQ1Kpyvr0csUOC+YgicgEOSi10CRlSp1gKuLYvBc8QKxdiNGlHW6fCHqJX9/vMqPkZl9+/5TZ04zp5k6a5prMcP1z/Ct X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Rick, Sorry for the delay, I was a bit preoccupied with $stuff. On Thu, Oct 05, 2023 at 06:09:07PM +0000, Edgecombe, Rick P wrote: > On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote: > > On Wed, Oct 04, 2023 at 03:39:26PM +0000, Edgecombe, Rick P wrote: > > > On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote: > > > > It seems a bit weird to copy all of this. Is it trying to be > > > > faster > > > > or > > > > something? > > > > > > > > Couldn't it just check r->start in execmem_text/data_alloc() path > > > > and > > > > switch to EXECMEM_DEFAULT if needed then? The > > > > execmem_range_is_data() > > > > part that comes later could be added to the logic there too. So > > > > this > > > > seems like unnecessary complexity to me or I don't see the > > > > reason. > > > > > > I guess this is a bad idea because if you have the full size array > > > sitting around anyway you might as well use it and reduce the > > > exec_mem_alloc() logic. > > > > That's was the idea, indeed. :) > > > > > Just looking at it from the x86 side (and > > > similar) though, where there is actually only one execmem_range and > > > it > > > building this whole array with identical data and it seems weird. > > > > Right, most architectures have only one range, but to support all > > variants > > that we have, execmem has to maintain the whole array. > > What about just having an index into a smaller set of ranges. The > module area and the extra JIT area. So ->ranges can be size 3 > (statically allocated in the arch code) for three areas and then the > index array can be size EXECMEM_TYPE_MAX. The default 0 value of the > indexing array will point to the default area and any special areas can > be set in the index point to the desired range. > > Looking at how it would do for x86 and arm64, it looks maybe a bit > better to me. A little bit less code and memory usage, and a bit easier > to trace the configuration through to the final state (IMO). What do > you think? Very rough, on top of this series, below. I like your suggestion to only have definitions of actual ranges in arch code and index array to redirect allocation requests to the right range. I'll make the next version along the lines of your patch. > As I was playing around with this, I was also wondering why it needs > two copies of struct execmem_params: one returned from the arch code > and one in exec mem. No actual reason, one copy is enough, thanks for catching this. > And why the temporary arch copy is ro_after_init, > but the final execmem.c copy is not ro_after_init? I just missed it, thanks for pointing out. -- Sincerely yours, Mike.