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 AC353C4345F for ; Mon, 15 Apr 2024 16:53:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FE5A6B00A0; Mon, 15 Apr 2024 12:53:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AED56B00A1; Mon, 15 Apr 2024 12:53:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04EC16B00A2; Mon, 15 Apr 2024 12:53:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DB15A6B00A0 for ; Mon, 15 Apr 2024 12:53:17 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6A0F31A06F0 for ; Mon, 15 Apr 2024 16:53:17 +0000 (UTC) X-FDA: 82012361634.15.BC92ACF Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf27.hostedemail.com (Postfix) with ESMTP id 26EA24000E for ; Mon, 15 Apr 2024 16:53:13 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=n9583Q6y; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713199994; a=rsa-sha256; cv=none; b=yVQv8bmOBo+nT++6T6DH+xVZuBbl4JB6vxkQEc5uTW8BlznTQzsqGruLNHC+2r9BR5xaOF aKdDk2lqeb8PBw0d72uXTO/ByrYn2GjKFkafdGLePRq0eFigok16eoo3HcWeSPzETjpK94 y12sdx8gXDyMxMNPyeBbuzZE4NcnjKY= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=n9583Q6y; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 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=1713199994; 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=5+Vdlxbg9S0GtuzRQiw9eREThE6OizBNpJhbvZ9mLbk=; b=LEGgiZ9Mdj4y0C5cNN63lcs/mu+9Kq1+yL8PmgXtymJDIuugeAn8cpITkTUD5jH/d3I2iu hPrweZARahh+MTplsSWMe2GDkVjh3B8GG/OYOFzLiQgPQVVgGWX7PEXLxQgYsucHIbrFH/ V6xop7Kb6fDYM7Al4BDHM1zFGK68PqU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9732BCE0E42; Mon, 15 Apr 2024 16:53:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57527C113CC; Mon, 15 Apr 2024 16:52:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713199989; bh=xJZBsBz/ovkewwHaqkWgEKUCLl3sCJ9igaEyaiYi248=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n9583Q6y/kVDUsC/Sk35DHsUlzQxomP4brOeJWEqMK5tTGdFfL5yXDBwNh/dc1R8t OnTvm1XERGxz1JxTUG2JWpufMQFhEpCf0upLztHBi97mz83HQzMB81Cj+bMHmQeLrO vdSyDt4foue7u5p0z1MAb6dHJ1a7FzO8x/EelybB33sZUvBK4gAoiim0DQVOThRBq2 3ERPw7wOWw5Nw3DB6b+PtiKpkHgDPedzRaGZsUTWRIfT1yQsmJ+qNm4oAZ/M1rF747 dHBdlhRGfIq7wIyTjPR6B4GdpTUD5V0JGj4lcLZS8oQu4cdKYlcTv5ldjuZ1AicK/r qCFC3y/AMEfuA== Date: Mon, 15 Apr 2024 19:51:52 +0300 From: Mike Rapoport To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Morton , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Donald Dutile , Eric Chanudet , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Song Liu , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() Message-ID: References: <20240411160051.2093261-1-rppt@kernel.org> <20240411160051.2093261-6-rppt@kernel.org> <20240415075241.GF40213@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240415075241.GF40213@noisy.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 26EA24000E X-Stat-Signature: 4fz5wjwiasneppm8jgf96ig7hkx659uw X-HE-Tag: 1713199993-731705 X-HE-Meta: U2FsdGVkX1+3hWj8PdboLecXb0NPWDHTy73iQcckR1aLdOqn2O9TCpTAoU8O8sBPgtijT1sKyxSE+cPwo/mE/FDfZ4ayqtRBfLZzQ9XPzLgM3zpAoKsPP9BrJ/uEBk21CK0LsiH52inEmIMW0p625aetlaaRo1rT8+ISBvONEdQ3t9jJeUYjFDBPqW+SXPtbFgMNQcY+uilDTEamuNH5aoqYcMN50Fsm0oU3kh+jGzDCYchCgekcojm+r+0899CNRefrJ8oevRVJE3CR2ke5Imrak+4fzWoDU3qQ7FPX5LN/TNMJRHgSdl02+Ob4e7PlSikV9YxZKAB7i2pcJgkHI535QGHE651e98YKBYB7oTFA2zXc2sWDfCW2fKEi6w2isBvx7knczsMeuzErNNSeN4I9rMvWZr8cmE7ehwcLNOjSQTb9IA/SygzIAyMZsE4QACR2IybYY2TEf6jaWz54Q2BpAp54PVvH3DUXzOvWVGGuL6vX1W0ud1M/kzj4q1v9bwcNysrYO6hyI7z8hVU4p5FwAprxXpuz30fdyB/WeVXXXzRI5o+GFnq28RGOR44vRmbRCkNFFb46b4hYfgnbtCBPFKkfaNQkTX9IZAoJQ775wxfgxXrDXkruMlUhzOqE8ghYOz4PsC/X//LnpMdf4MDV2JIjTIj0H1Me19cyZ7RhPLWUerJe5bAGu0gnyAKkkdvEKqQrbqb2HT9aCOCxfpt74gEpSADJC89HtIeJoE9cCTQ4DcjQpTzX3HZZuR/wcChfu/GPAaAbUBWbVU8tOR2mCmiEMR6MoeS9TEaS7yJ/1RqMum5Ri5M96xv8AfY+FKJbUJvu/V54x9T8p55+XESrybkby3ueO4jCTtyP3AGJnzGSOJ/usZ0q2w5Hnz0POi27WcV+A6w8w7Px8oEcLSswbGvudh0NLZi9V69ZPGUyot4tK0R9GOA+5pmoWfV5l2WAifTWRJnf703efMF 2mCzEHyX rWB7WLLdGzD1+grn9fge0m1yizqYI1+3YW0QpoEglCYOw8gEhioUYK+hQOoqaleqf6NPoedsZ0uaWE/d+ohxVZ8B/XwyKMmm/xsbDLL+HoQGYhxEfrdfVxCLRpX/vQ6hwdER25Rfz61sqBrdFZwFonmPHvL/Di2AM1cszztKb941WAkNn30F4C1OX1+BMcmK55tQS2pA3l4qyNBPlbzU0IU6rtwX2ykQdlwZxQk6TzDl0M5EUE6p9m+mqq4TVHRZe5z1NfxFC9NwEMoDPGa/6/uRMsrykIlqUV8ujTVBlDU1bbkJAWjdocFw2+Q== 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, Apr 15, 2024 at 09:52:41AM +0200, Peter Zijlstra wrote: > On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote: > > +/** > > + * enum execmem_type - types of executable memory ranges > > + * > > + * There are several subsystems that allocate executable memory. > > + * Architectures define different restrictions on placement, > > + * permissions, alignment and other parameters for memory that can be used > > + * by these subsystems. > > + * Types in this enum identify subsystems that allocate executable memory > > + * and let architectures define parameters for ranges suitable for > > + * allocations by each subsystem. > > + * > > + * @EXECMEM_DEFAULT: default parameters that would be used for types that > > + * are not explcitly defined. > > + * @EXECMEM_MODULE_TEXT: parameters for module text sections > > + * @EXECMEM_KPROBES: parameters for kprobes > > + * @EXECMEM_FTRACE: parameters for ftrace > > + * @EXECMEM_BPF: parameters for BPF > > + * @EXECMEM_TYPE_MAX: > > + */ > > +enum execmem_type { > > + EXECMEM_DEFAULT, > > + EXECMEM_MODULE_TEXT = EXECMEM_DEFAULT, > > + EXECMEM_KPROBES, > > + EXECMEM_FTRACE, > > + EXECMEM_BPF, > > + EXECMEM_TYPE_MAX, > > +}; > > Can we please get a break-down of how all these types are actually > different from one another? > > I'm thinking some platforms have a tiny immediate space (arm64 comes to > mind) and has less strict placement constraints for some of them? loongarch, mips, nios2 and sparc define modules address space different from vmalloc and use that for modules, kprobes and bpf (where supported). parisc uses vmalloc range for everything, but it sets permissions to PAGE_KERNEL_RWX because it's PAGE_KERNEL_EXEC is read only and it lacks set_memory_* APIs. arm has an address space for modules, but it fall back to the entire vmalloc with CONFIG_ARM_MODULE_PLTS=y. arm64 uses different ranges for modules and bpf/kprobes. For kprobes it does vmalloc(PAGE_KERNEL_ROX) and for bpf just plain vmalloc(). For modules arm64 first tries to allocated from 128M below kernel_end and if that fails it uses 2G below kernel_end as a fallback. powerpc uses vmalloc space for everything for some configurations. For book3s-32 and 8xx it defines two ranges that are used for module text, kprobes and bpf and the module data can be allocated anywhere in vmalloc. riscv has an address space for modules, a different address space for bpf and uses vmalloc space for kprobes. s390 and x86 have modules address space and use that space for all executable allocations. The EXECMEM_FTRACE type is only used on s390 and x86 and for now it's there more for completeness rather to denote special constraints or properties. -- Sincerely yours, Mike.