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 E8997C4345F for ; Wed, 17 Apr 2024 23:33:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 169196B007B; Wed, 17 Apr 2024 19:33:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 119226B0082; Wed, 17 Apr 2024 19:33:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFBEF6B0083; Wed, 17 Apr 2024 19:33:30 -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 D219F6B007B for ; Wed, 17 Apr 2024 19:33:30 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 557CC1A0DD7 for ; Wed, 17 Apr 2024 23:33:30 +0000 (UTC) X-FDA: 82020627780.12.61F49EC Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf27.hostedemail.com (Postfix) with ESMTP id B618340007 for ; Wed, 17 Apr 2024 23:33:27 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rjB6vmEu; spf=pass (imf27.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@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=1713396808; 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=4LmtTAfZeYaBGvOk76CDIjrm4R5Q0BNANtrWFn5DZnw=; b=7UIfeeHg1wrgXXPnDGPtKst++kjNPkGWYzug2L+ojWEX/xeY3d/Aq06MyaznjZv2a2ZGHR 9L7Kk+U1P6Umf4PZkRfzgP3J48gfjvxrQ/sHZ4VH3/8xaQnDcipXEZdvVySyaDFw96lQoU ukcqr3MyeoVYcNPk1qBdu998H/n6rbk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713396808; a=rsa-sha256; cv=none; b=LloPIsSqCXBFTpsVmsa97rp8eudeGqDCUC+7EbzrBR5ularFmtGdZq2KsX7v5GMC+7Erc5 BAAMs7N67Qg6BePyVEb8aZJy5yu/9Bpfv5z9hT+qgQe9Wq3h49EpA7yM/sucB4yk4vSdh2 rb42li3dA1uSPI8wYkoDXYKvR0/fH7U= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rjB6vmEu; spf=pass (imf27.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 80065CE1408 for ; Wed, 17 Apr 2024 23:33:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE533C2BD11 for ; Wed, 17 Apr 2024 23:33:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713396802; bh=UVEJ59zmDjoboUO24xHkWUbtsfOaV4nMW96i+du0QWo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rjB6vmEuetONe18hKTsn5+HJjhJMpyiX9HOcxJfZjVMUBr4HS/b8Qk0b+NvQ1SPoy 6+U9ERhx0yAL/f6syVMyH0tvCiwAqehHRdXPWB291uyc1cWB1Lj6SX69GppWO+2Zt+ FVEhm3i2wE/Ef/XXI5ZIpEkHAgVYWXqZNQXNL+NmfX6Z+SeoXJZSkwotWq6QnU2VU1 mlsup2LG6VX8kIop/HOQwiR9Qpz5L8GpSSeIxq3M0f0Pzo+vgVVgLVSg0npsWRBkuf eL40HYDNQxEkhjMIk/FzBlsJxrfsmyLxH/OVNZCSGMq/fL0AyGNTQBlwE9GQVY/UQJ IQQItlG25afRA== Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a51ddc783e3so19831566b.0 for ; Wed, 17 Apr 2024 16:33:22 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWCt76Kok8w2yyc5cV1WRd8HIWickilQ/J0sJqZUqQmgmZxkn9D6zD/q5k10Rb3mlEefmbnVIJa23prXZp3Z8BrF5M= X-Gm-Message-State: AOJu0YzQ3y3GMZWXEKpXX5cdTYr8fWlXCw6E8XEpbRM02Y7JOW4ukf8B +eR9sbPY1cq2WXlKk5HYaUm+4r5WzTptWwuhrmo5W3SWf9cwsGlEDiJI79tqgXtzT7BFlPiq5f2 iGRcuEMo3s078ki/5LLVCCDiUgG0= X-Google-Smtp-Source: AGHT+IEHuhOgcI3i5xgKWDt/RXWKyZ/pV78ei3ikSzZKT8X4nbojHe59GGn0FqOU5qFFQVvC8y10X+N0SPB8sxHbE0Q= X-Received: by 2002:a05:6512:3184:b0:519:b95:22b5 with SMTP id i4-20020a056512318400b005190b9522b5mr446945lfe.51.1713396780753; Wed, 17 Apr 2024 16:33:00 -0700 (PDT) MIME-Version: 1.0 References: <20240411160051.2093261-1-rppt@kernel.org> <20240411160051.2093261-6-rppt@kernel.org> <20240415075241.GF40213@noisy.programming.kicks-ass.net> In-Reply-To: From: Song Liu Date: Wed, 17 Apr 2024 16:32:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() To: Mike Rapoport 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B618340007 X-Stat-Signature: uz1kb3ty9tn8sj53d66ku4ofgagcqgcn X-HE-Tag: 1713396807-679618 X-HE-Meta: U2FsdGVkX18OB0gkKAKK9ZExt0XPw8jkFy5e2KdYDNsyxPYhms0vDL2Rj8EFGldbx4WDqFD1ohpP/EFGB3B9fNE/1Tz/9QfYn8zda4hlQbsoYsMyiAPTG9x0w7EhuOXy58w2tFjE78Dn8frtZ+rqX1VENuXFZEHZGqgd4KFGEYLTwu9aa5G+VgbcaL3/14aj03kFf8QT8KKv/nzRmqQrAzqobtBRNuXKfYOVMWl9XoxvLpsu7J3JwwNxoqP/pcrXlOpxr7M5W2uWzF1LOybc388Skel5pmwrsCdLrJrbkc+GWxcRHqTYE4Psh7eBruYrHQNG0r7xV7tOvY3zVfj2Jw65aHSh8QLfgZ9VYW7l2BTuet9M1xL7fcu3geztslYHUWlDlY8b2WrPrVeai4CRJCsfhNKwlyQUv08/Oh2+m93gipC4VYIm0FRqK6Z3exZYQ0hjPKvp/EN7mQwEZr7ki5iL/fd4KdKJTM2c+W7mnZKMJS9BvhFv9q+rik6mqnf6DBNMf0Z/7J0AGxS7EP45TBC03xN6EqJyaAE9o80OTGwowkxgIGBLHZIlwRKUeJMxwtACHyl+gDjwjlRYV4Xh81tvO4G+d4bM+ZpQKECbbL5+jsJ+6N3wJmKaCaMPRq5OEixUs0+h9KAz0/PMu/YfAbTTPBT1VNHw/l+YeYz26woZqEmSDiv9MRKUIOrRKeeUBJxQAJY+Mpb/tnQQ81pLEfdoX5ovQJaPjjQa/CsBOu2MSEMqP93R/6O0W0HXSImaRFdTqt6ep42ryMREDSYgW35Up/JZs0Tj13hhjh03+/dUxVYvI+C1QW2De6x9QJTHk+8lU/YUn6gy9JrycHGoLntGDWFOXBTDMvelxPt728y4V6mbwnzFwTwOj1UltTEu9fdkkNDWnDlJyePr4qGJ3j0IUyZNkYsqUw4B8bAzON74jOach+A6HJacmfmpR3fq1DdbTYsGcMziEo0vblN EdtxMsdq pn+sQlsF0H9I8dVjdOIiy9qZqOKz3KDn/k5+KOGriirQkt2RqkcaQmINojmTY43rSqSLp9IyvKSulhe9XofO6qTwbLrqTqIkTn8+j7ovfJ7RvPyfKYZ1lUV1N4MV40L3OMmxPGMTPNlsS5s/N1+ibyV8YKlgQRjMPD4dDCUFPx2HXVuF4jz6yUh7cpbRN9TTWXbhESu4IHGBKZmBSZg67xSr/e6P8sVaEZX6RGbLF3Y80Pdc/wwOJmD8PdWbs8b+T2ftWaFHdE04jvmWLRTlrFeqUm6wPQYvDqi8msR3UWClvrcyYkTya5rNn43hJnzCIdf1fbY6FHkZ5YsSZO8gB9Jnn+c/h+eFwkaNhTPjYnmfIRh5L1lLXu7/BOxh8TrWx+x8MHQ01icq/xQQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000067, 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 Tue, Apr 16, 2024 at 12:23=E2=80=AFAM Mike Rapoport wr= ote: > > On Mon, Apr 15, 2024 at 06:36:39PM +0100, Mark Rutland wrote: > > 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 typ= es 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 =3D 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? > > > > Yeah, and really I'd *much* rather deal with that in arch code, as I ha= ve said > > several times. > > > > For arm64 we have two bsaic restrictions: > > > > 1) Direct branches can go +/-128M > > We can expand this range by having direct branches go to PLTs, at a > > performance cost. > > > > 2) PREL32 relocations can go +/-2G > > We cannot expand this further. > > > > * We don't need to allocate memory for ftrace. We do not use trampoline= s. > > > > * Kprobes XOL areas don't care about either of those; we don't place an= y > > PC-relative instructions in those. Maybe we want to in future. > > > > * Modules care about both; we'd *prefer* to place them within +/-128M o= f all > > other kernel/module code, but if there's no space we can use PLTs and= expand > > that to +/-2G. Since modules can refreence other modules, that ends u= p > > actually being halved, and modules have to fit within some 2G window = that > > also covers the kernel. Is +/- 2G enough for all realistic use cases? If so, I guess we don't really need EXECMEM_ANYWHERE below? > > > > * I'm not sure about BPF's requirements; it seems happy doing the same = as > > modules. > > BPF are happy with vmalloc(). > > > So if we *must* use a common execmem allocator, what we'd reall want is= our own > > types, e.g. > > > > EXECMEM_ANYWHERE > > EXECMEM_NOPLT > > EXECMEM_PREL32 > > > > ... and then we use those in arch code to implement module_alloc() and = friends. > > 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? IOW, we have enum execmem_type { EXECMEM_DEFAULT, EXECMEM_TEXT, EXECMEM_KPROBES =3D EXECMEM_TEXT, EXECMEM_FTRACE =3D EXECMEM_TEXT, EXECMEM_BPF =3D 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? Thanks, Song