From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6981542500 for ; Thu, 1 Jun 2023 16:12:19 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 525171063; Thu, 1 Jun 2023 09:12:58 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.140]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C47623F663; Thu, 1 Jun 2023 09:12:06 -0700 (PDT) Date: Thu, 1 Jun 2023 17:12:03 +0100 From: Mark Rutland To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , Russell King , 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, x86@kernel.org Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: References: <20230601101257.530867-1-rppt@kernel.org> Precedence: bulk X-Mailing-List: loongarch@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230601101257.530867-1-rppt@kernel.org> Hi Mike, On Thu, Jun 01, 2023 at 01:12:44PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystmes > that need to allocate code, such as ftrace, kprobes and BPF to modules > and puts the burden of code allocation to the modules code. I agree this is a problem, and one key issue here is that these can have different requirements. For example, on arm64 we need modules to be placed within a 128M or 2G window containing the kernel, whereas it would be safe for the kprobes XOL area to be placed arbitrarily far from the kernel image (since we don't allow PC-relative insns to be stepped out-of-line). Likewise arm64 doesn't have ftrace trampolines, and DIRECT_CALL trampolines can safely be placed arbitarily far from the kernel image. For a while I have wanted to give kprobes its own allocator so that it can work even with CONFIG_MODULES=n, and so that it doesn't have to waste VA space in the modules area. Given that, I think these should have their own allocator functions that can be provided independently, even if those happen to use common infrastructure. > 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. > > This set splits code allocation from modules by introducing > jit_text_alloc(), jit_data_alloc() and jit_free() APIs, replaces call > sites of module_alloc() and module_memfree() with the new APIs and > implements core text and related allocation in a central place. > > Instead of architecture specific overrides for module_alloc(), the > architectures that require non-default behaviour for text allocation must > fill jit_alloc_params structure and implement jit_alloc_arch_params() that > returns a pointer to that structure. If an architecture does not implement > jit_alloc_arch_params(), the defaults compatible with the current > modules::module_alloc() are used. As above, I suspect that each of the callsites should probably be using common infrastructure, but I don't think that a single jit_alloc_arch_params() makes sense, since the parameters for each case may need to be distinct. > The new jitalloc infrastructure allows decoupling of kprobes and ftrace > from modules, and most importantly it enables ROX allocations for > executable memory. > > A centralized infrastructure for code allocation allows future > optimizations for allocations of executable memory, caching large pages for > better iTLB performance and providing sub-page allocations for users that > only need small jit code snippets. This sounds interesting, but I think this can be achieved without requiring a single jit_alloc_arch_params() shared by all users? Thanks, Mark. > > patches 1-5: split out the code allocation from modules and arch > patch 6: add dedicated API for data allocations with constraints similar to > code allocations > patches 7-9: decouple dynamic ftrace and kprobes form CONFIG_MODULES > patches 10-13: enable ROX allocations for executable memory on x86 > > Mike Rapoport (IBM) (11): > nios2: define virtual address space for modules > mm: introduce jit_text_alloc() and use it instead of module_alloc() > mm/jitalloc, arch: convert simple overrides of module_alloc to jitalloc > mm/jitalloc, arch: convert remaining overrides of module_alloc to jitalloc > module, jitalloc: drop module_alloc > mm/jitalloc: introduce jit_data_alloc() > x86/ftrace: enable dynamic ftrace without CONFIG_MODULES > arch: make jitalloc setup available regardless of CONFIG_MODULES > kprobes: remove dependcy on CONFIG_MODULES > modules, jitalloc: prepare to allocate executable memory as ROX > x86/jitalloc: make memory allocated for code ROX > > Song Liu (2): > ftrace: Add swap_func to ftrace_process_locs() > x86/jitalloc: prepare to allocate exectuatble memory as ROX > > arch/Kconfig | 5 +- > arch/arm/kernel/module.c | 32 ------ > arch/arm/mm/init.c | 35 ++++++ > arch/arm64/kernel/module.c | 47 -------- > arch/arm64/mm/init.c | 42 +++++++ > arch/loongarch/kernel/module.c | 6 - > arch/loongarch/mm/init.c | 16 +++ > arch/mips/kernel/module.c | 9 -- > arch/mips/mm/init.c | 19 ++++ > arch/nios2/include/asm/pgtable.h | 5 +- > arch/nios2/kernel/module.c | 24 ++-- > arch/parisc/kernel/module.c | 11 -- > arch/parisc/mm/init.c | 21 +++- > arch/powerpc/kernel/kprobes.c | 4 +- > arch/powerpc/kernel/module.c | 37 ------- > arch/powerpc/mm/mem.c | 41 +++++++ > arch/riscv/kernel/module.c | 10 -- > arch/riscv/mm/init.c | 18 +++ > arch/s390/kernel/ftrace.c | 4 +- > arch/s390/kernel/kprobes.c | 4 +- > arch/s390/kernel/module.c | 46 +------- > arch/s390/mm/init.c | 35 ++++++ > arch/sparc/kernel/module.c | 34 +----- > arch/sparc/mm/Makefile | 2 + > arch/sparc/mm/jitalloc.c | 21 ++++ > arch/sparc/net/bpf_jit_comp_32.c | 8 +- > arch/x86/Kconfig | 2 + > arch/x86/kernel/alternative.c | 43 ++++--- > arch/x86/kernel/ftrace.c | 59 +++++----- > arch/x86/kernel/kprobes/core.c | 4 +- > arch/x86/kernel/module.c | 75 +------------ > arch/x86/kernel/static_call.c | 10 +- > arch/x86/kernel/unwind_orc.c | 13 ++- > arch/x86/mm/init.c | 52 +++++++++ > arch/x86/net/bpf_jit_comp.c | 22 +++- > include/linux/ftrace.h | 2 + > include/linux/jitalloc.h | 69 ++++++++++++ > include/linux/moduleloader.h | 15 --- > kernel/bpf/core.c | 14 +-- > kernel/kprobes.c | 51 +++++---- > kernel/module/Kconfig | 1 + > kernel/module/main.c | 56 ++++------ > kernel/trace/ftrace.c | 13 ++- > kernel/trace/trace_kprobe.c | 11 ++ > mm/Kconfig | 3 + > mm/Makefile | 1 + > mm/jitalloc.c | 185 +++++++++++++++++++++++++++++++ > mm/mm_init.c | 2 + > 48 files changed, 777 insertions(+), 462 deletions(-) > create mode 100644 arch/sparc/mm/jitalloc.c > create mode 100644 include/linux/jitalloc.h > create mode 100644 mm/jitalloc.c > > > base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 > -- > 2.35.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BCF9FC77B7E for ; Thu, 1 Jun 2023 16:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qNnmoepdk+77EHPq6HTH+Wm1IAe+McLnCHuNUUtpkd0=; b=jVrXqJvcj+P/Kw xTFXn7TwTRYyrDvri0rUrenRj8WsXtzpRxx7Mw6ynJhps7UAlxGXewVKdycTmFNw9q80cJghewylI wBY5uEzCN9UQOxQnucvXWcs2mzbVnn27HiHkryQHzdJpNB1rhIJsHhzv/5oAzKLx/SDRh9QcER0iN KU4Ilmsg1CxabxHpHBmkWs3eCDAPJ9ZiVkUFXTWGpGz8oUienvZ3D37Tk3fEE0ffpYI+eis8yyFdc +N1SbpJ7xdudNFA6Gm8vofUpsnPjeP2PB4Xcp8PVYLzKFMi8zIkV7Nvd9zX+sZjvDTvHnWKjiBn23 48bZtDjKrghiFWTb8Qiw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q4lMF-004Hpj-1q; Thu, 01 Jun 2023 16:41:03 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q4lMC-004HpN-2m; Thu, 01 Jun 2023 16:41:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=l7x37BGg/ngYVQw8b7oQYLv+/IDPAQbOtTwdo2GYI4g=; b=nBJS850GdjslE5ahSrVJDOXcI5 ni8q2VdFk9LCuyGiLgRe4Pv1ks/bX4JSQBhhqVYrDZb98RsWHD+g5S2zr3NsYBjD1eclXGS5fNpAS A8dwnuN12NjbLSdFCCXcgMAl5F2K8BFjV87bGdDlKilRj0o8k2Io3obSDJhaVGvLAztEz+z9Al4z0 VDXacYZrsC1+nAQ7CPx4qWkSdLVnf/VA2yQSiPWVpDGlZv8wQJO2sZnYzHnwO93XEMNf/TSCb8X/G XmyudD8nA6CS7HbfoS+wVKYVueBMHBUZ2UKmGdu9kG3kQQIBZM5ZIspHMGUtmMd2V0m2lXn61gOxn z5luAL6A==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q4kuN-00HC3Z-1y; Thu, 01 Jun 2023 16:12:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 525171063; Thu, 1 Jun 2023 09:12:58 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.140]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C47623F663; Thu, 1 Jun 2023 09:12:06 -0700 (PDT) Date: Thu, 1 Jun 2023 17:12:03 +0100 From: Mark Rutland To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , Russell King , 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, x86@kernel.org Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: References: <20230601101257.530867-1-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230601101257.530867-1-rppt@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230601_171216_012965_2854584F X-CRM114-Status: GOOD ( 35.47 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Hi Mike, On Thu, Jun 01, 2023 at 01:12:44PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystmes > that need to allocate code, such as ftrace, kprobes and BPF to modules > and puts the burden of code allocation to the modules code. I agree this is a problem, and one key issue here is that these can have different requirements. For example, on arm64 we need modules to be placed within a 128M or 2G window containing the kernel, whereas it would be safe for the kprobes XOL area to be placed arbitrarily far from the kernel image (since we don't allow PC-relative insns to be stepped out-of-line). Likewise arm64 doesn't have ftrace trampolines, and DIRECT_CALL trampolines can safely be placed arbitarily far from the kernel image. For a while I have wanted to give kprobes its own allocator so that it can work even with CONFIG_MODULES=n, and so that it doesn't have to waste VA space in the modules area. Given that, I think these should have their own allocator functions that can be provided independently, even if those happen to use common infrastructure. > 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. > > This set splits code allocation from modules by introducing > jit_text_alloc(), jit_data_alloc() and jit_free() APIs, replaces call > sites of module_alloc() and module_memfree() with the new APIs and > implements core text and related allocation in a central place. > > Instead of architecture specific overrides for module_alloc(), the > architectures that require non-default behaviour for text allocation must > fill jit_alloc_params structure and implement jit_alloc_arch_params() that > returns a pointer to that structure. If an architecture does not implement > jit_alloc_arch_params(), the defaults compatible with the current > modules::module_alloc() are used. As above, I suspect that each of the callsites should probably be using common infrastructure, but I don't think that a single jit_alloc_arch_params() makes sense, since the parameters for each case may need to be distinct. > The new jitalloc infrastructure allows decoupling of kprobes and ftrace > from modules, and most importantly it enables ROX allocations for > executable memory. > > A centralized infrastructure for code allocation allows future > optimizations for allocations of executable memory, caching large pages for > better iTLB performance and providing sub-page allocations for users that > only need small jit code snippets. This sounds interesting, but I think this can be achieved without requiring a single jit_alloc_arch_params() shared by all users? Thanks, Mark. > > patches 1-5: split out the code allocation from modules and arch > patch 6: add dedicated API for data allocations with constraints similar to > code allocations > patches 7-9: decouple dynamic ftrace and kprobes form CONFIG_MODULES > patches 10-13: enable ROX allocations for executable memory on x86 > > Mike Rapoport (IBM) (11): > nios2: define virtual address space for modules > mm: introduce jit_text_alloc() and use it instead of module_alloc() > mm/jitalloc, arch: convert simple overrides of module_alloc to jitalloc > mm/jitalloc, arch: convert remaining overrides of module_alloc to jitalloc > module, jitalloc: drop module_alloc > mm/jitalloc: introduce jit_data_alloc() > x86/ftrace: enable dynamic ftrace without CONFIG_MODULES > arch: make jitalloc setup available regardless of CONFIG_MODULES > kprobes: remove dependcy on CONFIG_MODULES > modules, jitalloc: prepare to allocate executable memory as ROX > x86/jitalloc: make memory allocated for code ROX > > Song Liu (2): > ftrace: Add swap_func to ftrace_process_locs() > x86/jitalloc: prepare to allocate exectuatble memory as ROX > > arch/Kconfig | 5 +- > arch/arm/kernel/module.c | 32 ------ > arch/arm/mm/init.c | 35 ++++++ > arch/arm64/kernel/module.c | 47 -------- > arch/arm64/mm/init.c | 42 +++++++ > arch/loongarch/kernel/module.c | 6 - > arch/loongarch/mm/init.c | 16 +++ > arch/mips/kernel/module.c | 9 -- > arch/mips/mm/init.c | 19 ++++ > arch/nios2/include/asm/pgtable.h | 5 +- > arch/nios2/kernel/module.c | 24 ++-- > arch/parisc/kernel/module.c | 11 -- > arch/parisc/mm/init.c | 21 +++- > arch/powerpc/kernel/kprobes.c | 4 +- > arch/powerpc/kernel/module.c | 37 ------- > arch/powerpc/mm/mem.c | 41 +++++++ > arch/riscv/kernel/module.c | 10 -- > arch/riscv/mm/init.c | 18 +++ > arch/s390/kernel/ftrace.c | 4 +- > arch/s390/kernel/kprobes.c | 4 +- > arch/s390/kernel/module.c | 46 +------- > arch/s390/mm/init.c | 35 ++++++ > arch/sparc/kernel/module.c | 34 +----- > arch/sparc/mm/Makefile | 2 + > arch/sparc/mm/jitalloc.c | 21 ++++ > arch/sparc/net/bpf_jit_comp_32.c | 8 +- > arch/x86/Kconfig | 2 + > arch/x86/kernel/alternative.c | 43 ++++--- > arch/x86/kernel/ftrace.c | 59 +++++----- > arch/x86/kernel/kprobes/core.c | 4 +- > arch/x86/kernel/module.c | 75 +------------ > arch/x86/kernel/static_call.c | 10 +- > arch/x86/kernel/unwind_orc.c | 13 ++- > arch/x86/mm/init.c | 52 +++++++++ > arch/x86/net/bpf_jit_comp.c | 22 +++- > include/linux/ftrace.h | 2 + > include/linux/jitalloc.h | 69 ++++++++++++ > include/linux/moduleloader.h | 15 --- > kernel/bpf/core.c | 14 +-- > kernel/kprobes.c | 51 +++++---- > kernel/module/Kconfig | 1 + > kernel/module/main.c | 56 ++++------ > kernel/trace/ftrace.c | 13 ++- > kernel/trace/trace_kprobe.c | 11 ++ > mm/Kconfig | 3 + > mm/Makefile | 1 + > mm/jitalloc.c | 185 +++++++++++++++++++++++++++++++ > mm/mm_init.c | 2 + > 48 files changed, 777 insertions(+), 462 deletions(-) > create mode 100644 arch/sparc/mm/jitalloc.c > create mode 100644 include/linux/jitalloc.h > create mode 100644 mm/jitalloc.c > > > base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 > -- > 2.35.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 42CD2C77B7A for ; Thu, 1 Jun 2023 16:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZUkhOlcOD18zr5YhviQ/jAOOz8oiFd83HlF4Ehgco6U=; b=ra3xkPz/MSa2un roSzFqVyu5Kc43acOHWzqlyblavgjrlTJ+k3kwOprrFMLl7oT7WsL6Q5/ZuklnPe5aCNrgb5Ci21K oJf7wUG7zGNWccCUubk4Mlpfd71rL4dvRVAXCQ4iSa80/jg8XOEOwhZsK25BeICyh3YuMEcQw6xG6 LCfOQfSoSQQXDTrLxrA0dN4v8g10yvAZjGu0pW9+miGhna8C4HipqRMhKOCRg+//2tZzt6JbhncXD YZaJv+6NWNA2R6cHVe1jE35i6EGAsPHpD2f6c+r7SYidoUbtx1H7GV1rTwcNz3kH/xfsWIrKcVvN/ KVFDcW4yaIEmOVl2L5vQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q4lMF-004Hpb-0E; Thu, 01 Jun 2023 16:41:03 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q4lMC-004HpN-2m; Thu, 01 Jun 2023 16:41:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=l7x37BGg/ngYVQw8b7oQYLv+/IDPAQbOtTwdo2GYI4g=; b=nBJS850GdjslE5ahSrVJDOXcI5 ni8q2VdFk9LCuyGiLgRe4Pv1ks/bX4JSQBhhqVYrDZb98RsWHD+g5S2zr3NsYBjD1eclXGS5fNpAS A8dwnuN12NjbLSdFCCXcgMAl5F2K8BFjV87bGdDlKilRj0o8k2Io3obSDJhaVGvLAztEz+z9Al4z0 VDXacYZrsC1+nAQ7CPx4qWkSdLVnf/VA2yQSiPWVpDGlZv8wQJO2sZnYzHnwO93XEMNf/TSCb8X/G XmyudD8nA6CS7HbfoS+wVKYVueBMHBUZ2UKmGdu9kG3kQQIBZM5ZIspHMGUtmMd2V0m2lXn61gOxn z5luAL6A==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q4kuN-00HC3Z-1y; Thu, 01 Jun 2023 16:12:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 525171063; Thu, 1 Jun 2023 09:12:58 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.140]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C47623F663; Thu, 1 Jun 2023 09:12:06 -0700 (PDT) Date: Thu, 1 Jun 2023 17:12:03 +0100 From: Mark Rutland To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , Russell King , 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, x86@kernel.org Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: References: <20230601101257.530867-1-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230601101257.530867-1-rppt@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230601_171216_012965_2854584F X-CRM114-Status: GOOD ( 35.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mike, On Thu, Jun 01, 2023 at 01:12:44PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystmes > that need to allocate code, such as ftrace, kprobes and BPF to modules > and puts the burden of code allocation to the modules code. I agree this is a problem, and one key issue here is that these can have different requirements. For example, on arm64 we need modules to be placed within a 128M or 2G window containing the kernel, whereas it would be safe for the kprobes XOL area to be placed arbitrarily far from the kernel image (since we don't allow PC-relative insns to be stepped out-of-line). Likewise arm64 doesn't have ftrace trampolines, and DIRECT_CALL trampolines can safely be placed arbitarily far from the kernel image. For a while I have wanted to give kprobes its own allocator so that it can work even with CONFIG_MODULES=n, and so that it doesn't have to waste VA space in the modules area. Given that, I think these should have their own allocator functions that can be provided independently, even if those happen to use common infrastructure. > 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. > > This set splits code allocation from modules by introducing > jit_text_alloc(), jit_data_alloc() and jit_free() APIs, replaces call > sites of module_alloc() and module_memfree() with the new APIs and > implements core text and related allocation in a central place. > > Instead of architecture specific overrides for module_alloc(), the > architectures that require non-default behaviour for text allocation must > fill jit_alloc_params structure and implement jit_alloc_arch_params() that > returns a pointer to that structure. If an architecture does not implement > jit_alloc_arch_params(), the defaults compatible with the current > modules::module_alloc() are used. As above, I suspect that each of the callsites should probably be using common infrastructure, but I don't think that a single jit_alloc_arch_params() makes sense, since the parameters for each case may need to be distinct. > The new jitalloc infrastructure allows decoupling of kprobes and ftrace > from modules, and most importantly it enables ROX allocations for > executable memory. > > A centralized infrastructure for code allocation allows future > optimizations for allocations of executable memory, caching large pages for > better iTLB performance and providing sub-page allocations for users that > only need small jit code snippets. This sounds interesting, but I think this can be achieved without requiring a single jit_alloc_arch_params() shared by all users? Thanks, Mark. > > patches 1-5: split out the code allocation from modules and arch > patch 6: add dedicated API for data allocations with constraints similar to > code allocations > patches 7-9: decouple dynamic ftrace and kprobes form CONFIG_MODULES > patches 10-13: enable ROX allocations for executable memory on x86 > > Mike Rapoport (IBM) (11): > nios2: define virtual address space for modules > mm: introduce jit_text_alloc() and use it instead of module_alloc() > mm/jitalloc, arch: convert simple overrides of module_alloc to jitalloc > mm/jitalloc, arch: convert remaining overrides of module_alloc to jitalloc > module, jitalloc: drop module_alloc > mm/jitalloc: introduce jit_data_alloc() > x86/ftrace: enable dynamic ftrace without CONFIG_MODULES > arch: make jitalloc setup available regardless of CONFIG_MODULES > kprobes: remove dependcy on CONFIG_MODULES > modules, jitalloc: prepare to allocate executable memory as ROX > x86/jitalloc: make memory allocated for code ROX > > Song Liu (2): > ftrace: Add swap_func to ftrace_process_locs() > x86/jitalloc: prepare to allocate exectuatble memory as ROX > > arch/Kconfig | 5 +- > arch/arm/kernel/module.c | 32 ------ > arch/arm/mm/init.c | 35 ++++++ > arch/arm64/kernel/module.c | 47 -------- > arch/arm64/mm/init.c | 42 +++++++ > arch/loongarch/kernel/module.c | 6 - > arch/loongarch/mm/init.c | 16 +++ > arch/mips/kernel/module.c | 9 -- > arch/mips/mm/init.c | 19 ++++ > arch/nios2/include/asm/pgtable.h | 5 +- > arch/nios2/kernel/module.c | 24 ++-- > arch/parisc/kernel/module.c | 11 -- > arch/parisc/mm/init.c | 21 +++- > arch/powerpc/kernel/kprobes.c | 4 +- > arch/powerpc/kernel/module.c | 37 ------- > arch/powerpc/mm/mem.c | 41 +++++++ > arch/riscv/kernel/module.c | 10 -- > arch/riscv/mm/init.c | 18 +++ > arch/s390/kernel/ftrace.c | 4 +- > arch/s390/kernel/kprobes.c | 4 +- > arch/s390/kernel/module.c | 46 +------- > arch/s390/mm/init.c | 35 ++++++ > arch/sparc/kernel/module.c | 34 +----- > arch/sparc/mm/Makefile | 2 + > arch/sparc/mm/jitalloc.c | 21 ++++ > arch/sparc/net/bpf_jit_comp_32.c | 8 +- > arch/x86/Kconfig | 2 + > arch/x86/kernel/alternative.c | 43 ++++--- > arch/x86/kernel/ftrace.c | 59 +++++----- > arch/x86/kernel/kprobes/core.c | 4 +- > arch/x86/kernel/module.c | 75 +------------ > arch/x86/kernel/static_call.c | 10 +- > arch/x86/kernel/unwind_orc.c | 13 ++- > arch/x86/mm/init.c | 52 +++++++++ > arch/x86/net/bpf_jit_comp.c | 22 +++- > include/linux/ftrace.h | 2 + > include/linux/jitalloc.h | 69 ++++++++++++ > include/linux/moduleloader.h | 15 --- > kernel/bpf/core.c | 14 +-- > kernel/kprobes.c | 51 +++++---- > kernel/module/Kconfig | 1 + > kernel/module/main.c | 56 ++++------ > kernel/trace/ftrace.c | 13 ++- > kernel/trace/trace_kprobe.c | 11 ++ > mm/Kconfig | 3 + > mm/Makefile | 1 + > mm/jitalloc.c | 185 +++++++++++++++++++++++++++++++ > mm/mm_init.c | 2 + > 48 files changed, 777 insertions(+), 462 deletions(-) > create mode 100644 arch/sparc/mm/jitalloc.c > create mode 100644 include/linux/jitalloc.h > create mode 100644 mm/jitalloc.c > > > base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 > -- > 2.35.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 00364C77B7A for ; Thu, 1 Jun 2023 16:13:19 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QXB4t3DKcz3f1S for ; Fri, 2 Jun 2023 02:13:18 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4QXB4K3JZmz3cdK for ; Fri, 2 Jun 2023 02:12:46 +1000 (AEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 525171063; Thu, 1 Jun 2023 09:12:58 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.140]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C47623F663; Thu, 1 Jun 2023 09:12:06 -0700 (PDT) Date: Thu, 1 Jun 2023 17:12:03 +0100 From: Mark Rutland To: Mike Rapoport Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: References: <20230601101257.530867-1-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230601101257.530867-1-rppt@kernel.org> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: x86@kernel.org, Catalin Marinas , linux-mips@vger.kernel.org, Song Liu , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Will Deacon , linux-s390@vger.kernel.org, Helge Deller , Huacai Chen , Russell King , "Naveen N. Rao" , linux-trace-kernel@vger.kernel.org, Heiko Carstens , Steven Rostedt , loongarch@lists.linux.dev, Thomas Gleixner , Andrew Morton , linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , linux-parisc@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Kent Overstreet , linux-kernel@vger.kernel.org, Dinh Nguyen , Luis Chamberlain , Palmer Dabbelt , bpf@vger.kernel.org, linuxppc-dev@lists.ozla bs.org, "David S. Miller" , linux-modules@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Mike, On Thu, Jun 01, 2023 at 01:12:44PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystmes > that need to allocate code, such as ftrace, kprobes and BPF to modules > and puts the burden of code allocation to the modules code. I agree this is a problem, and one key issue here is that these can have different requirements. For example, on arm64 we need modules to be placed within a 128M or 2G window containing the kernel, whereas it would be safe for the kprobes XOL area to be placed arbitrarily far from the kernel image (since we don't allow PC-relative insns to be stepped out-of-line). Likewise arm64 doesn't have ftrace trampolines, and DIRECT_CALL trampolines can safely be placed arbitarily far from the kernel image. For a while I have wanted to give kprobes its own allocator so that it can work even with CONFIG_MODULES=n, and so that it doesn't have to waste VA space in the modules area. Given that, I think these should have their own allocator functions that can be provided independently, even if those happen to use common infrastructure. > 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. > > This set splits code allocation from modules by introducing > jit_text_alloc(), jit_data_alloc() and jit_free() APIs, replaces call > sites of module_alloc() and module_memfree() with the new APIs and > implements core text and related allocation in a central place. > > Instead of architecture specific overrides for module_alloc(), the > architectures that require non-default behaviour for text allocation must > fill jit_alloc_params structure and implement jit_alloc_arch_params() that > returns a pointer to that structure. If an architecture does not implement > jit_alloc_arch_params(), the defaults compatible with the current > modules::module_alloc() are used. As above, I suspect that each of the callsites should probably be using common infrastructure, but I don't think that a single jit_alloc_arch_params() makes sense, since the parameters for each case may need to be distinct. > The new jitalloc infrastructure allows decoupling of kprobes and ftrace > from modules, and most importantly it enables ROX allocations for > executable memory. > > A centralized infrastructure for code allocation allows future > optimizations for allocations of executable memory, caching large pages for > better iTLB performance and providing sub-page allocations for users that > only need small jit code snippets. This sounds interesting, but I think this can be achieved without requiring a single jit_alloc_arch_params() shared by all users? Thanks, Mark. > > patches 1-5: split out the code allocation from modules and arch > patch 6: add dedicated API for data allocations with constraints similar to > code allocations > patches 7-9: decouple dynamic ftrace and kprobes form CONFIG_MODULES > patches 10-13: enable ROX allocations for executable memory on x86 > > Mike Rapoport (IBM) (11): > nios2: define virtual address space for modules > mm: introduce jit_text_alloc() and use it instead of module_alloc() > mm/jitalloc, arch: convert simple overrides of module_alloc to jitalloc > mm/jitalloc, arch: convert remaining overrides of module_alloc to jitalloc > module, jitalloc: drop module_alloc > mm/jitalloc: introduce jit_data_alloc() > x86/ftrace: enable dynamic ftrace without CONFIG_MODULES > arch: make jitalloc setup available regardless of CONFIG_MODULES > kprobes: remove dependcy on CONFIG_MODULES > modules, jitalloc: prepare to allocate executable memory as ROX > x86/jitalloc: make memory allocated for code ROX > > Song Liu (2): > ftrace: Add swap_func to ftrace_process_locs() > x86/jitalloc: prepare to allocate exectuatble memory as ROX > > arch/Kconfig | 5 +- > arch/arm/kernel/module.c | 32 ------ > arch/arm/mm/init.c | 35 ++++++ > arch/arm64/kernel/module.c | 47 -------- > arch/arm64/mm/init.c | 42 +++++++ > arch/loongarch/kernel/module.c | 6 - > arch/loongarch/mm/init.c | 16 +++ > arch/mips/kernel/module.c | 9 -- > arch/mips/mm/init.c | 19 ++++ > arch/nios2/include/asm/pgtable.h | 5 +- > arch/nios2/kernel/module.c | 24 ++-- > arch/parisc/kernel/module.c | 11 -- > arch/parisc/mm/init.c | 21 +++- > arch/powerpc/kernel/kprobes.c | 4 +- > arch/powerpc/kernel/module.c | 37 ------- > arch/powerpc/mm/mem.c | 41 +++++++ > arch/riscv/kernel/module.c | 10 -- > arch/riscv/mm/init.c | 18 +++ > arch/s390/kernel/ftrace.c | 4 +- > arch/s390/kernel/kprobes.c | 4 +- > arch/s390/kernel/module.c | 46 +------- > arch/s390/mm/init.c | 35 ++++++ > arch/sparc/kernel/module.c | 34 +----- > arch/sparc/mm/Makefile | 2 + > arch/sparc/mm/jitalloc.c | 21 ++++ > arch/sparc/net/bpf_jit_comp_32.c | 8 +- > arch/x86/Kconfig | 2 + > arch/x86/kernel/alternative.c | 43 ++++--- > arch/x86/kernel/ftrace.c | 59 +++++----- > arch/x86/kernel/kprobes/core.c | 4 +- > arch/x86/kernel/module.c | 75 +------------ > arch/x86/kernel/static_call.c | 10 +- > arch/x86/kernel/unwind_orc.c | 13 ++- > arch/x86/mm/init.c | 52 +++++++++ > arch/x86/net/bpf_jit_comp.c | 22 +++- > include/linux/ftrace.h | 2 + > include/linux/jitalloc.h | 69 ++++++++++++ > include/linux/moduleloader.h | 15 --- > kernel/bpf/core.c | 14 +-- > kernel/kprobes.c | 51 +++++---- > kernel/module/Kconfig | 1 + > kernel/module/main.c | 56 ++++------ > kernel/trace/ftrace.c | 13 ++- > kernel/trace/trace_kprobe.c | 11 ++ > mm/Kconfig | 3 + > mm/Makefile | 1 + > mm/jitalloc.c | 185 +++++++++++++++++++++++++++++++ > mm/mm_init.c | 2 + > 48 files changed, 777 insertions(+), 462 deletions(-) > create mode 100644 arch/sparc/mm/jitalloc.c > create mode 100644 include/linux/jitalloc.h > create mode 100644 mm/jitalloc.c > > > base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 > -- > 2.35.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel