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 C0746EB64DD for ; Fri, 16 Jun 2023 18:19:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C7448E0003; Fri, 16 Jun 2023 14:19:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2776B8E0001; Fri, 16 Jun 2023 14:19:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 166078E0003; Fri, 16 Jun 2023 14:19:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0475D8E0001 for ; Fri, 16 Jun 2023 14:19:00 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B907AA0C6A for ; Fri, 16 Jun 2023 18:18:59 +0000 (UTC) X-FDA: 80909422398.07.617F8E5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id BFC33140004 for ; Fri, 16 Jun 2023 18:18:57 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IzPKo+jK; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686939537; 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=CNrq8QFb1Cfyu9OC2sYtQ7wUbhzc+pKVpneIOOryPnQ=; b=s1oguJndLpRdWvSCR1pQuGghsDFFsDtT42hCWmTg5X4+JKo34LCb1wrDIyq0y1nuI4eMsC tw1u1lOZ056ewvtcg7NAtpdu4d1yCZ7xhUCa/u5JARGhbjkTwGiHiB8hA4s2Z82LO0MxSK oAeM0fZn94KnXEvpVFfufHqVyh6LHtg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IzPKo+jK; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686939537; a=rsa-sha256; cv=none; b=bjDjrL+kg/IsMGZAsEAA9g1SX8GfjQ+f1XiF6oUQ7aWF2kMsJsuXhdfkhnqfADcg47DGOB ICyvwuyMSgD0Qhe30s4Y+qhP6/P2jgmb2eA2A9Qy9lgcwzaLtNN7Ad+7TtZaa/hQIjO8gR 2aj7JY47ra3ds9Cvv62dlkB1IWa5M3Q= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EBAF862A3B for ; Fri, 16 Jun 2023 18:18:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3EE9C433D9 for ; Fri, 16 Jun 2023 18:18:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686939535; bh=JYIeppGROaSwt5RJCAxNQJPfExACzvun2YHFgIEWjL0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IzPKo+jK4luEJPBN0IXaMM9NoBohQwylmyD6SOtRwX+YHgT9pt8MIqbXkSBPR6OVR /VjE3RPenLmbkl9jNPpLgItztd650j/5i4Va33yoTKpPExRZlBgNWOG1So983jlXQF yVTlXF+vQ1OIFfDaYs9xwGLtC0FMaZ8PTvXNpCHGP797MMhtKNhJYcskAyFP4r0ORW jRQGM3yRcA+dWCLV7mIEN2p/2GyNuYsQzdtYWVtVoCRZNrnYvu2dHR+Lw2iUXJxquc FLnychOVPaAoWGd242H5r7TyNYDZiDO+1rDQAW2lvEG/PSv9+R2O/6b7/dZeA4YGtc +8sk6it3T0tMw== Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-4f84d70bf96so1310001e87.0 for ; Fri, 16 Jun 2023 11:18:55 -0700 (PDT) X-Gm-Message-State: AC+VfDyXse5HXrngNbKUBM2bQhtEVyQzAE2VXXPZn8kv4PWH1Af4p9u2 HbsfII0UkG5ps9v4ylQnpNAOJJW2tK4kgXI3eR4= X-Google-Smtp-Source: ACHHUZ6PUs5qG5gEz0Ui+rYTOBYo1CNjp/5QXhNKC7wMrP1gtK8A+svd4/31TT3PuRRLSD+QiqJSaxjJua7jMaFtZ74= X-Received: by 2002:ac2:4c4c:0:b0:4f6:3ef3:13e8 with SMTP id o12-20020ac24c4c000000b004f63ef313e8mr2671938lfk.0.1686939533810; Fri, 16 Jun 2023 11:18:53 -0700 (PDT) MIME-Version: 1.0 References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-3-rppt@kernel.org> In-Reply-To: From: Song Liu Date: Fri, 16 Jun 2023 11:18:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc() To: Kent Overstreet Cc: Mike Rapoport , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@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-Rspamd-Queue-Id: BFC33140004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: kkztnjs577bi9z33p3nybsy3xeo4skqr X-HE-Tag: 1686939537-643059 X-HE-Meta: U2FsdGVkX18RSxjT4lAkTd2CoNdcnODW0JFgP4+4lUZcTKcc/x1GPoaKwE+WrDDcD70RTBZl8td2fqRYahOBrVoAeAxn2XL6HhoEBns8Jhm7tlAtabVyptuOMWv9S9iD2pPhH4FaOpK+ysYJcL4i2Au+zPsMDocSwdRW2HriaKciV8ZpVUNsJF53rWoVyn+VETXk0O7AQoZH4wUuGbWMxmAHZc9Z5Hwo3un6rbBkhdmD+O93jcVZhLlOZJ2rYcpvARB6x0qGh8FFrwp4lA6Qd2ylxFZcIcaDKfa5WSpT1/9R5m+QzlpRcF4XTLSGUGicpYY8Uq89q8y2R8KLpUTOBixw5JEonIHqleA85DFQHKZHR+Cf0Zh1bXL5K+JRB9FaSAUg0kBNZ1PQDW/KBZF16jW/frw7n/gkOtOoSez/eYY9eVhGnA6QE5Chqh4sLRZ2I70ehQfbte4gIfXj8+J85FMqfV5fgNdjYbkuNkB7+CkcS6+W5VIEslEwr6mUtcWflq/bNcmOqzaoFLYaB5iw2U9DAuhgAMGNq49ssiNlnt7wSmr7YA+EuIxcCyZ3LVKQNkZRXC50MomVJNuWqZeepi37vh6+d4ogwUFPOWpFy9LLvVixgVc0JR45P09ViMAAsh3w9bN1kPSBhcS3KLvrf3tztewR3jByka0+W1bsk8tZFFlpYlzxPkciiqMypsODBM855akq7q0crgM4Ddy6VoTf8cfs8ZiOGG6I8Nfg5sbIWaEnGO8QjxaSsKEwFei63o434DX6yRYx8wR+lKRYVdg/SGNCCFefnxJBMDZEZYq9BjDofbK8MtieKUnXnvcf2eF+zta/ZN1u6DffH0AfWs/MhbJjVt51rqtTIw3Isd+ybSMrhv68gHlkOmlNak2/+wUSFELYj6xCj0CA/jrXEDFdD3EacC1b7MVTq2zy6IB7ZbCnMXahaL8pIGloveCwqjXWqmOO698jerLv6r7 /KBdELe7 A3SdOvveuEJ5kmpo+bFQVtL0gVlKIo0hwYsi1TzEt4ofJSr2PD5XTXjYF9J20Ya/J+63AUP3SiPHlxDtFzEkVJXzUBxde9Af4FEQHL7aHwkn3CU04TnhGDE/s5YFAzXA/SmuKxJ87kbUXK/BVtpHIeWXciuSf5vSj9g46HUOUmHW9DucYoNvuKiZaVdHdwrdwnybMKqu9HX0UiZipwlKDpoRW4fV+eoIvLMlwmjb8xw7gE34I19lb974UU0E5FiTjyQPFGQ24d/HIJXsh+pPuIKcEo8JS1xtInw/4NUnQkzi2++zh2eq2dOx0Pra55rju+XN6YETTis7RA1YbEdlqZIIOMNZ2S9gE36IYUYRZV2QrqPrx2pH/AUGQM15wC/2EDM5wIMfH3ch3bi1QwPs5l1R1wxcp7z813cXiSTvvOBM3vy9X+9+TV5ZsidypFX0VqzjMTlNR+gLoRVmIssYuEQnGuibnuLQ/djptDVAsqcwd6SPZGGfGEu5Zbupkmc+/ofu9sw9b9DEM0fC4+qv+h5WHEA== 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: On Fri, Jun 16, 2023 at 9:48=E2=80=AFAM Kent Overstreet wrote: > > On Fri, Jun 16, 2023 at 11:50:28AM +0300, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > module_alloc() is used everywhere as a mean to allocate memory for code= . > > > > Beside being semantically wrong, this unnecessarily ties all subsystems > > that need to allocate code, such as ftrace, kprobes and BPF to modules > > and puts the burden of code allocation to the modules code. > > > > Several architectures override module_alloc() because of various > > constraints where the executable memory can be located and this causes > > additional obstacles for improvements of code allocation. > > > > Start splitting code allocation from modules by introducing > > execmem_text_alloc(), execmem_free(), jit_text_alloc(), jit_free() APIs= . > > > > Initially, execmem_text_alloc() and jit_text_alloc() are wrappers for > > module_alloc() and execmem_free() and jit_free() are replacements of > > module_memfree() to allow updating all call sites to use the new APIs. > > > > The intention semantics for new allocation APIs: > > > > * execmem_text_alloc() should be used to allocate memory that must resi= de > > close to the kernel image, like loadable kernel modules and generated > > code that is restricted by relative addressing. > > > > * jit_text_alloc() should be used to allocate memory for generated code > > when there are no restrictions for the code placement. For > > architectures that require that any code is within certain distance > > from the kernel image, jit_text_alloc() will be essentially aliased t= o > > execmem_text_alloc(). > > > > The names execmem_text_alloc() and jit_text_alloc() emphasize that the > > allocated memory is for executable code, the allocations of the > > associated data, like data sections of a module will use > > execmem_data_alloc() interface that will be added later. > > I like the API split - at the risk of further bikeshedding, perhaps > near_text_alloc() and far_text_alloc()? Would be more explicit. > > Reviewed-by: Kent Overstreet Acked-by: Song Liu