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 8ED08C4345F for ; Thu, 18 Apr 2024 17:54:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0705C6B0085; Thu, 18 Apr 2024 13:54:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F22F66B0088; Thu, 18 Apr 2024 13:54:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEA406B0089; Thu, 18 Apr 2024 13:54:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BF2276B0087 for ; Thu, 18 Apr 2024 13:54:02 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7464F40DCB for ; Thu, 18 Apr 2024 17:54:02 +0000 (UTC) X-FDA: 82023401124.13.4DF25AB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id C2AF14001E for ; Thu, 18 Apr 2024 17:54:00 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="qitx/umw"; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713462840; 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=Lse3YhwWM5DK5PMnBud5E/PGVFTuuMDuvIhRXfKR7vk=; b=XewNszbzZQClJ6JP4OaPCgz9EZRnPj5V5uQ8k+15YhzuQMRqvVJT6gwD+8nnXx6csQ1JTj h/f5+pH2TTC/HpUcyGLYh1MAHb4NOxAg8I/yWYJQhnBeYmIPrZGGO3rcy7SGmWdx5UDZZ2 /wvIEsQFFQM5bK1PfNrgI+PmOPOUmII= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="qitx/umw"; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713462840; a=rsa-sha256; cv=none; b=31fwuBG4TehJvQh+5yS5tIfxinNmhcR7xTqXQXGg38NOxrYQ6KoHl8OGL0RZPO70igSbA/ b+JTCRQJiJJuSyQaS895iAsJ1QWVBk0RL+GdF2/X2lXy861iYCfFXsDfKlyvh+FEhsgUTA BSSvKpPPkgRjo239SSlN2LfIy9PcfNM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 80D62618A3; Thu, 18 Apr 2024 17:53:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F12DC3277B; Thu, 18 Apr 2024 17:53:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713462839; bh=GVKHg9/GMb+Q7svthQO5bm+rPzNDL6zXlQZOsDeKWL0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qitx/umwjvXDKNme47QxvztrUiipBcKV2Lg0Yvd1RXezrm9EMN+zfFrxXb923+dxO AxZ6KgXvjlorR3mUIjvBXST4+3n8nelthPynguxJTOQoS9rNBrqZ+3MIlU37kTQ9FA a4e+nx+8unMMLT17+KcFFJ93DVlkbK2eXc4Av0nU3f2Yxj+rBXrkR0WI95IANr/7qX uZj4q1Xb4qjUIP87QNJk+Jgy4oid7eW9FtvEPOx7D0x1Tt1iXSqSWNLPcTP4XbQ2OW z8BEya9Rxr0dlQHlDm5T4jpRs2aqcA2Iy8EkKuiv4ehWjUKDt48ywWZ7K+xjdgeN4d Qxf4CJCyjHkiA== Date: Thu, 18 Apr 2024 20:52:39 +0300 From: Mike Rapoport To: Song Liu Cc: Mark Rutland , Peter Zijlstra , linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Morton , Bjorn Topel , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Donald Dutile , Eric Chanudet , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , Nadav Amit , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: C2AF14001E X-Stat-Signature: uoq6e38qpfako4pt6tuayfihr4phdo1i X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1713462840-699262 X-HE-Meta: U2FsdGVkX1/5Li7kQ9gM0/NX5bPba1qWA1a9g7xfU/hugxa5McHQ9HwYOrJOjmkFMf4vV9ngy0ZDw/st+iFvwsWi0lciZRaELjfgvlaXHQg9LZRJnkmjIA4IVh3ht8/ZhcIAJSrm7LX14CCKzqMxIH+fUHhuLTiC8vMGIXczJXG+52s1R98+swnlJefBwyWPshmX9cYbQlHA0tf3hJaHS4sTgryWpt9MnyCY1hEzG4twMSq4segUd/JTQPAunbyMbTsB1MN5T96Ed9r2CF+C9l8Fkh7erct2o4+yllhwX8ZmmpookNoOGDLjpQJJPQFBP1uhheYWe6z6pb5VQMM8ESxe4zLX9AAmsqZy5NfZMI7dTNgQSaf/OBiOFrWCkmcaViQDVEeaSX9qptitYfLkXI8Yu53Gg1gLbWYhTNfvCXNtT0rWzzfC8VsnSXFKxCx0nPSfSONv5JIbYDeXh7CKyTFEpZTqjo9T+Bh0sCb0edpdxmMdd0xz+RSylCu5I1R2Ecw08jO+tTNhEtO/o/vvQ0q8UVMt6gRqkQ5jpOfbT0Bs+Ts9JKKKsSqU06If0IljjvMYwk6bMNckqHK/EPCKJtXaKPKT3QGK0pyagqXrTZSr0+VqmuplxbN590SMwyLhTYJhPHWSrbIQ13CXr493oCYceUE3jELr+6n+4UphXgBQ3AEz4Of/VI3lIqumI3chTy/LdKWjLKPsQOSoPYVAMLj7aaTo6kyJfPiacf+UCh5IcyfcZ6QZ7jIRdnjpegdCEVWbewXXWQF/0gTDNpBODZmaUkIcniekamW9RvPfAJwnIcDPUdUFD5Bk/krrEcN4D/R9TzvuVRW65Q8k9ZngIh5XEFIYBlUmY6iU9FQNhDCZcGyXC46CjMY2IfzRhuXqc4n+YRfP6xB8D16IWM59Q+EYjS90QuETgAEU8JWQ71SknwAxlXcXtol0Xh1xR8kGtbb95NzxQYEx/oH8aqg 8Q9druJY OZoyGZLE4panWWbl8k46zb7YsZGB3BV7eIFEeGp2V/mBnpsAY7+t1BqGoA9aAhZMi/AgQZDKjd3GBnyiMy6evZWz5VtCv30E2lDU4rmBdSBnt1O4PPH6ZKEnOMkeB3Xge4n+XQbuGPMeVXlx2oCf5aRzQ93xAqj3bHiCJls3rQR8mNwZz8ChLx4Rhvg5ObWI1zWFFyJjlDjkdk4au1dVynDmi2nLoI/3p0sbF3hKDou58qfnc8+HO6VFvZ2jSTJFfebxSfNBGMhXQGkXrR/pufv3sJh8VxDapKTOHJqq63eBYnEJ0oODI9Pl3jnSKtj76VbvY5b5rLqtJ3v9HCfTbkZe3fAw1QIJ20SihsqlETnnfraVDkkuHn1+ndsfqlNx5Wue22ZmbZhhwDa4= 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 Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote: > On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport wrote: > > > > > > > > I'm looking at execmem_types more as definition of the consumers, maybe I > > > > should have named the enum execmem_consumer at the first place. > > > > > > I think looking at execmem_type from consumers' point of view adds > > > unnecessary complexity. IIUC, for most (if not all) archs, ftrace, kprobe, > > > and bpf (and maybe also module text) all have the same requirements. > > > Did I miss something? > > > > It's enough to have one architecture with different constrains for kprobes > > and bpf to warrant a type for each. > > AFAICT, some of these constraints can be changed without too much work. But why? I honestly don't understand what are you trying to optimize here. A few lines of initialization in execmem_info? What is the advantage in forcing architectures to have imposed limits on kprobes or bpf allocations? > > Where do you see unnecessary complexity? > > > > > IOW, we have > > > > > > enum execmem_type { > > > EXECMEM_DEFAULT, > > > EXECMEM_TEXT, > > > EXECMEM_KPROBES = EXECMEM_TEXT, > > > EXECMEM_FTRACE = EXECMEM_TEXT, > > > EXECMEM_BPF = EXECMEM_TEXT, /* we may end up without > > > _KPROBE, _FTRACE, _BPF */ > > > EXECMEM_DATA, /* rw */ > > > EXECMEM_RO_DATA, > > > EXECMEM_RO_AFTER_INIT, > > > EXECMEM_TYPE_MAX, > > > }; > > > > > > Does this make sense? > > > > How do you suggest to deal with e.g. riscv that has separate address spaces > > for modules, kprobes and bpf? > > IIUC, modules and bpf use the same address space on riscv Not exactly, bpf is a subset of modules on riscv. > while kprobes use vmalloc address. The whole point of using the entire vmalloc for kprobes is to avoid pollution of limited modules space. > Thanks, > Song -- Sincerely yours, Mike.