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 DEA66EB64DC for ; Sun, 18 Jun 2023 08:01:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FD726B0071; Sun, 18 Jun 2023 04:01:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2845D6B0072; Sun, 18 Jun 2023 04:01:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FEC36B0075; Sun, 18 Jun 2023 04:01:19 -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 F1EE36B0071 for ; Sun, 18 Jun 2023 04:01:18 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7FD04C03FF for ; Sun, 18 Jun 2023 08:01:18 +0000 (UTC) X-FDA: 80915123436.07.C8D7693 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id B91521A0018 for ; Sun, 18 Jun 2023 08:01:16 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=sRSVsUz+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.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=1687075276; 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=KVnHRZvbtYsZRHFOmwAX/PwESPT50BQhipa0iGaLtWg=; b=hh9fG5yIAYGDenHvhWc4rb8XcW14JnSFsIoHjCxvdWpK5vG9q92mSygHvC5chDg0SZ2FG+ Ll0vDBzAVQBFlEJ1bsLURmOXeJls+Lg9iC9yZb6/9Ffcy9nlf+LMbqXw46IabOZWoQnKgj WKamzZABA9omY5G+Kzq6Nm602V66kII= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=sRSVsUz+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.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=1687075276; a=rsa-sha256; cv=none; b=oOF5z2SZg1y+uEaduxbYzBrOTNe57sR8y+X5PYk+T39KkRb7uVRIdVZEeJG/KG8Z1amozJ a65OICzDhN4W72+OdZ7gj4l1P/V8QZkLkwIPYekwILwSLqihji976tDwTE76KhPlA5S/iu KCafONyO4iGZDmqEm7JVXaQidp2qcLE= 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 ADABC60F01; Sun, 18 Jun 2023 08:01:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DA1EC433C0; Sun, 18 Jun 2023 08:01:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687075275; bh=JOdF7gdXvqBjASqKs6SWBkQKDgB3N69nrNaZPukvaeM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sRSVsUz+8qwPDTD+DbQ8ZGj3oxWbs6Q2yclpQ5oA01FgfO3x99AMq57vy9vTmKGCz zxsNFAk2tsVXc2/ZMKN5WrqHKwwq7cFYa5f3HPOYIxlAVh8JcIK7E8a/4ukOQRZ4nx MkY7brx+YmsqJJOWjKI+esA6758vzynczNeZM28mb8D2036W2Ac3dVaBq4RYIRm2lO UwBKETxVcKwPW5jcSjXTb+3J9p7JSrJABXAw2lEoobsEXKewtbcSu8Iyl/ROefguVb JB6NowqZPjsvgPvrW3+OErG+qxYX7mjk/nhQmoo1FPg/indEYGUiochf7rWuDn85yN s8jpvUG70jw+A== Date: Sun, 18 Jun 2023 11:00:27 +0300 From: Mike Rapoport To: Andy Lutomirski Cc: Linux Kernel Mailing List , Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick P Edgecombe , "Russell King (Oracle)" , Song Liu , 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, the arch/x86 maintainers Subject: Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc() Message-ID: <20230618080027.GA52412@kernel.org> References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B91521A0018 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: mcm3c7r65wh7hfntbq7fzcgq61k131qw X-HE-Tag: 1687075276-981966 X-HE-Meta: U2FsdGVkX1/yLLPrNooszk3wOEfa+GyS7kzP8LgvRGgEWhU9TpUjvCotr5wdMrQO9/ctWXz1UdSIMrPB7qOopXU96o4igmrgYTS0NvDhXr6eAs8cU0MPQUDk6277TT/jPJBG63J3gZ21U7FuzYFM2R5bAsrlEDwAjG6N62R/mr9TNT330X0BTgFN8wXI3ArM/508AtgkNeA0tHnJIdzgdeCjwmbvSkBFzw/8NJHw7HcEOCcNs1mbURNLHYNrZS7oNvWxnSeMAtA7ga4hMxi93e6Uf0n68oA4u/w+fd3d6o/FkOMHK7l1UHj97Jt/AGqJ5f7FSrOwKyN69AC/LBV8QdyQvCZima3WZqQGzCFzdmLfv8wwklyV8HAMiguv7SxCxfXh9I6mznvNTP6qU0rSy/bkGYeUWDYMPEFiVRVtSPRvK5mSa4ZpkHtgR/kqBfbllNn7kK9k3/y62Fxb+OyGzI6SqS+Z9N9mGLFetAjvkeG9gH1MCtmkXboWWmGILGkfAOxNsH7KOrG/8HH2Oc3nJcZicU2MiBRxZU9dCCwXHO49UGk01aMa6WhKLIgE1i2pAEeXInrfIygj/WjY5tzmu4e7AbZ+L95sy/4N+rBKJhImKXH9CUu2OUDK2CbT9HiO166U9MK67sTwDqtX5lTXufKzp8RVsmM+xFeEoItI4JbJx2MqFD+c4a4B1ZwgPZr+2QoCTP942OhQBariDZvSDx/e1QAWYE77Fht/Q/eFU67+3doqPNIz8hB7jQW7Apu0YQcl6TkwXADRh3vHxlZBiLo2qs/FmLsWwamFn8BUwUvRQhuERDU9XXr1oqx/bb19n51Ziogo6n536R5ecIytzoFYFSZlQD69zpgxXzVLfioAfPHwqmhfPfjK1oR0rSuQjb3ed6IFgF0CooQ40hU2j5jECtfEGBKfHk+6fcsSiVFCD5Sa0LrGv2bORjJQgNoWy5z/p3IisdCPRevOovd aoD9yM7b csThbJapAMNUfVuwpnqTf8CDoGR3GovRJ2DoZSIwKNfCY9AkKYAZmaOk+0pjxbjn2JY2d3Ih7vssZDtnJ2DKl0ZiYFaqnlVFEFCA/8ztWByaDrg3Y2Re8bNA6+tFBehFOW52OMv2S+I+n8DiC1oA35XwJAoTVoP9B79X9wOYl9MSPhL1zCbTZJ9+yGlWuZVPjwR1GX9Q/Lz8ptj5uOcJLFgxn0E/c/HRd/5HjvOxiEVim6Qp+x6vnNRI9aMZIqbBDfJ9e3A7vLNGp21FyWOrhTTmiJNhEcrGvQ/A/5zhUjP+i9Ff/UqAsmOlWicf4nFUMKKO7VCSU8JTitkZ0PSifXXe1sQupW0T+T6HfIb66i5arp/EYYHJ68rOzC53dVt9VskRxWIRZ3FVp6Pa6SlCdfYffqc3krBf6icurxlqMhYRn0XKRCI51NCpQnO7QAH7gFz8IuiMPaOlLLKVLaEQ0JuOEbjuewIDRXhs+nNjv2MbPMT9uc6mKnYM3vFgLvNtxa0bnWBuiPuXPmyCi5Z3u/qGf5h/1OuJL4qhu8lVT2BUNQaCKOEi/ty2RMwM4EJS33INB 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 Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote: > On Fri, Jun 16, 2023, at 1:50 AM, 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 reside > > 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 to > > execmem_text_alloc(). > > > > Is there anything in this series to help users do the appropriate > synchronization when the actually populate the allocated memory with > code? See here, for example: This series only factors out the executable allocations from modules and puts them in a central place. Anything else would go on top after this lands. > https://lore.kernel.org/linux-fsdevel/cb6533c6-cea0-4f04-95cf-b8240c6ab405@app.fastmail.com/T/#u -- Sincerely yours, Mike.