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 7B71AEB64DB for ; Mon, 19 Jun 2023 11:34:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC80E8D0002; Mon, 19 Jun 2023 07:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A785B8D0001; Mon, 19 Jun 2023 07:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9405A8D0002; Mon, 19 Jun 2023 07:34:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 856638D0001 for ; Mon, 19 Jun 2023 07:34:38 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5E150C07DD for ; Mon, 19 Jun 2023 11:34:38 +0000 (UTC) X-FDA: 80919289836.26.39BB1F9 Received: from out-47.mta0.migadu.com (out-47.mta0.migadu.com [91.218.175.47]) by imf12.hostedemail.com (Postfix) with ESMTP id 535FC40004 for ; Mon, 19 Jun 2023 11:34:34 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i+cENnWb; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.47 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687174475; a=rsa-sha256; cv=none; b=tmr0VS4gsjQQYOuPCOEYadGoR2cbVWP/J3UCZrIeIKKS/j0s8c7MccVWlJ60jUIjBblYix LiJ3Shrr/r/HjpJz2n3lY7EBDfMuMFMSPSnwWDN2yglRhZxWV7/aNwRPirLIqnXQ6tXRDj 5xrsRdMuqSMEv242anFGVwfbPBN6W3o= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i+cENnWb; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.47 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687174475; 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=Tt3RWh8BEKoqLhK86LDh7llJ14l6KCTXk/okAyPXAzA=; b=pUh7KhS+Rq4S2lu6rFzjKt7K49lgAwmfSgu1yAJRIE3DQ3KBx1yR5uSzFfa53+UN/7zD35 u0QboPnsmG1cubHMjVuIFINcgQsjRE50F17Ra5q2rd8MmZxeJsK2/4QwQKpz7dCIzZTRUv /ysmtiO8wZ+7n4ZmGT6JI6Vyv0hZl5I= Date: Mon, 19 Jun 2023 07:34:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1687174472; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Tt3RWh8BEKoqLhK86LDh7llJ14l6KCTXk/okAyPXAzA=; b=i+cENnWbA17Y+F/fishc8UmKkX2d11aFrfbkEA/RSeJGs8DaK+pP54Vf1C7aoZ8NsEj74R cXaE50KWXHIuXWZXVuGC783hgIjWLesjrEEDAYhwTaqLKdCoI85w4n4+GuOUgBvzA2QigP oa1A17/zsm0VN2UgH6YNfjC3Cc/g4gI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Andy Lutomirski Cc: Mike Rapoport , Linux Kernel Mailing List , 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 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: <20230619113426.c37bpwvdagbzyevn@moria.home.lan> 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-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 535FC40004 X-Stat-Signature: oy1ea8bz9f7ix9yj9gdxez9zp1kzgtzk X-Rspam-User: X-HE-Tag: 1687174474-295761 X-HE-Meta: U2FsdGVkX1+3IR+/9y0hc1F3o1Be7J3Il0jc8+dIIWzdIVTYABonTAgrkN1NyhXXpOQ9g0VD+UdfbVCsf209a5NEhch9ePu8wSpr5E3ptxd8ZwmA3q9zaP9wSB2TmUNTC2KlonXQCa0eco3UDXm+O9xLh4TbWD+i2B7ncUXBVwnR+/AGCC47SiDBs2q70GwaCr8DpHB/4CWLd9T/bvZ4w+3CoWcMI8bQbnelW7phQbOhrcgHoGKelbr8NcMu0wiYdvjZBzoDt/TqJGPUkEZ/9OKX+NHjS/FmaJQN3wRBaaHxKZ75f/GRxxg0uZ+tKDj+IYMPVlYYrnKhPDUNy6ZooYq2UpyhWEDgvYjTNsrHgWnDGXe5dDJUv3bfCbse998eeQn4aq6CS5kCMLu1izN4h1K+GLFtLtMjJ0A+B3D49iJi9YS6CAMXTxmjgLhzK6q/wBE4A1Ra8Y0xDiIsN2e81Fnm1L3XBCXv64pMCr8V5//TUga2lmQBMdQH0tj6m1mEUhNYL9nW6QergNahGOaAPpOTAmUJiFKS8VY9hYr315IGTGbLlUYNpf8IVli6ty+Fn8Vldr5f+UAdILJQYqmqIv7VxU+d0iORh07EGD8EsM5VY6DM1XMxoByOSfZS7gLEGg5FmvCE+KbyV0OzUxhDNYRht0Bam7hGAralLO8euTMrMgIZjgQVle4w/4LRaIUTjGsTOxrFTyq17Trec7Luq3aQAgh1acnlFS60k5MrkKEjA5UdH2XFk6OEEFU9k5jIhrVsZm8kJ7GSIuXDFkJOIFey1D5AemM42AOgTv19Sf3Gob2LWTRrRr4oJzA0dbSB1UiBak3paQFzb5A8GkTPtcY056C5EaYq2BOWNszeD4+ZhY0/eZ/BjRb6TLO5WeJXAg9gQoE+v3p9o0Gldd2qTgzNGd7TTiV6xRniPqqXVYkmMrGr96jXSbnScMfO08eB+fs/q6bcn6QfNWOA68a 9Ep4NeH5 +b0vvnTmNFZ8M/qcpoAn/Ehp3+XLWtakJYHqLME/9ayuCuS01UWz+tKsDNqEmEifiJojdVf/i4xaqq0sr24e9JcEw4Fhf+74IBfQxNoy5y7T0h/aE7hS4PUzAM96i0KYJ1x4cdaWhxPkVAsJR5UVQKgAQgF/oVRuIL3f/EQzYFBnZPv6YJ81jopTFmF1Sb2VQsGcagncm5WbShALIwqU6z0/LQOfta8HHgjZ1mXCpQoDH4e1VEmiQmPXuiXob8f7BkEev3Y+Gil6YzNdjot4HyKuACfLFETUUNkIJml2oHNQ5VY5kIGcJ2yT8karFMv2ZfEmsQ1jsg1XTbpC5o+wVZ2AUog== 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: > > https://lore.kernel.org/linux-fsdevel/cb6533c6-cea0-4f04-95cf-b8240c6ab405@app.fastmail.com/T/#u We're still in need of an arch independent text_poke() api.