From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57B05C8C1; Mon, 12 Jun 2023 21:34:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D36BC433EF; Mon, 12 Jun 2023 21:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686605690; bh=h0CRiC60VVAZqmO+EH1iTk5RAONQQFwe4r5bnxWeBYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WWGX6EsmQ2I3j/HZk09nSijqLsLqKh2zR9pZKyLx/B0jIXGPm7WOm6aHPsipPOPiY jbuqr2L5NdxGQ25vQ0efNR0RvVTA/m99hLadgsoxeMr2Yr4F8lHDdx8RspQzi7W43/ mLC5DXypQ1i3u7doi7r5ZuwkTyjLzEfegN8R501cyMOXLvlLRW9VI2Ncve7nqZpdCc NEaiFAjaKVxiKSOlPYg1cGzREgYQilsaa62hJ0h6RiWVYxtKmWXyFXZ0lBGx5e1JWW 26oQT3m1G5nZ691Qq/SnJu3UQtk8Wk6rKOBVtLl9V+SVu1rHNR6YSCJNrSY+wvrhZ3 1QMTS9aeu3yow== Date: Tue, 13 Jun 2023 00:34:11 +0300 From: Mike Rapoport To: Song Liu Cc: Mark Rutland , Kent Overstreet , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , 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 Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: <20230612213411.GP52412@kernel.org> References: <20230601101257.530867-1-rppt@kernel.org> <20230605092040.GB3460@kernel.org> <20230608184116.GJ52412@kernel.org> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jun 09, 2023 at 10:02:16AM -0700, Song Liu wrote: > On Thu, Jun 8, 2023 at 11:41 AM Mike Rapoport wrote: > > > > On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote: > > > On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote: > > > > > > [...] > > > > > > > > > > Can you give more detail on what parameters you need? If the only extra > > > > > > > parameter is just "does this allocation need to live close to kernel > > > > > > > text", that's not that big of a deal. > > > > > > > > > > > > My thinking was that we at least need the start + end for each caller. That > > > > > > might be it, tbh. > > > > > > > > > > Do you mean that modules will have something like > > > > > > > > > > jit_text_alloc(size, MODULES_START, MODULES_END); > > > > > > > > > > and kprobes will have > > > > > > > > > > jit_text_alloc(size, KPROBES_START, KPROBES_END); > > > > > ? > > > > > > > > Yes. > > > > > > How about we start with two APIs: > > > jit_text_alloc(size); > > > jit_text_alloc_range(size, start, end); > > > > > > AFAICT, arm64 is the only arch that requires the latter API. And TBH, I am > > > not quite convinced it is needed. > > > > Right now arm64 and riscv override bpf and kprobes allocations to use the > > entire vmalloc address space, but having the ability to allocate generated > > code outside of modules area may be useful for other architectures. > > > > Still the start + end for the callers feels backwards to me because the > > callers do not define the ranges, but rather the architectures, so we still > > need a way for architectures to define how they want allocate memory for > > the generated code. > > Yeah, this makes sense. > > > > > > > > It sill can be achieved with a single jit_alloc_arch_params(), just by > > > > > adding enum jit_type parameter to jit_text_alloc(). > > > > > > > > That feels backwards to me; it centralizes a bunch of information about > > > > distinct users to be able to shove that into a static array, when the callsites > > > > can pass that information. > > > > > > I think we only two type of users: module and everything else (ftrace, kprobe, > > > bpf stuff). The key differences are: > > > > > > 1. module uses text and data; while everything else only uses text. > > > 2. module code is generated by the compiler, and thus has stronger > > > requirements in address ranges; everything else are generated via some > > > JIT or manual written assembly, so they are more flexible with address > > > ranges (in JIT, we can avoid using instructions that requires a specific > > > address range). > > > > > > The next question is, can we have the two types of users share the same > > > address ranges? If not, we can reserve the preferred range for modules, > > > and let everything else use the other range. I don't see reasons to further > > > separate users in the "everything else" group. > > > > I agree that we can define only two types: modules and everything else and > > let the architectures define if they need different ranges for these two > > types, or want the same range for everything. > > > > With only two types we can have two API calls for alloc, and a single > > structure that defines the ranges etc from the architecture side rather > > than spread all over. > > > > Like something along these lines: > > > > struct execmem_range { > > unsigned long start; > > unsigned long end; > > unsigned long fallback_start; > > unsigned long fallback_end; > > pgprot_t pgprot; > > unsigned int alignment; > > }; > > > > struct execmem_modules_range { > > enum execmem_module_flags flags; > > struct execmem_range text; > > struct execmem_range data; > > }; > > > > struct execmem_jit_range { > > struct execmem_range text; > > }; > > > > struct execmem_params { > > struct execmem_modules_range modules; > > struct execmem_jit_range jit; > > }; > > > > struct execmem_params *execmem_arch_params(void); > > > > void *execmem_text_alloc(size_t size); > > void *execmem_data_alloc(size_t size); > > void execmem_free(void *ptr); > > With the jit variation, maybe we can just call these > module_[text|data]_alloc()? I was thinking about "execmem_*_alloc()" for allocations that must be close to kernel image, like modules, ftrace on x86 and s390 and maybe something else in the future. And jit_text_alloc() for allocations that can reside anywhere. I tried to find a different name for 'struct execmem_modules_range' but couldn't think of anything better than 'struct execmem_close_to_kernel', so I've left modules in the name. > btw: Depending on the implementation of the allocator, we may also > need separate free()s for text and data. > > > > > void *jit_text_alloc(size_t size); > > void jit_free(void *ptr); > > Let's just add jit_free() for completeness even if it will be the same as execmem_free() for now. > [...] > > How should we move ahead from here? > > AFAICT, all these changes can be easily extended and refactored > in the future, so we don't have to make it perfect the first time. > OTOH, having the interface committed (either this set or my > module_alloc_type version) can unblock works in the binpack > allocator and the users side. Therefore, I think we can move > relatively fast here? Once the interface and architecture abstraction is ready we can work on the allocator and the users. We also need to update text_poking/alternatives on architectures that would allocate executable memory as ROX. I did some quick tests and with these patches 'modprobe xfs' takes tens time more than before. > Thanks, > Song -- Sincerely yours, Mike. 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 EF74EC88CB2 for ; Mon, 12 Jun 2023 21:35:01 +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=7GZHOKP4HdYz5goE2c2gqJyuWU/ZqKU1KLUlvl22+MQ=; b=md9+gY/zX+VHFJ 3+eOyHt70iJttfzP9GZUoPvpn0C1wW7lt9/sTzYxWkxTiB/+KS8B5LQ+5uEhkHch0cV/8OusN4luL ygkHYJhbRySbLKrxnDmpT9nlu1I1WEvVHlqk9fQ7FULvrFnYITGfbt7jYwqlyUM38ov3CojXzcMDh IZWuPMeuPJ6TUpl0DRl2PP+gyJjmnmcvYx+lkvdcLQcO0pu/C54zotg46grcHDzJyrYb349X7teon 0GiIsr/+k+bRFWYo7l6H4K8psaEwPt0SARm69xXPMfsMZsTMyRFtfewGw9ZMjovZlNTmYwymj922I 3xw+MyyFhkQZzIup7Rwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q8pBg-005WuZ-1A; Mon, 12 Jun 2023 21:34:56 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q8pBc-005Wt9-1P; Mon, 12 Jun 2023 21:34:54 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5205A62AEB; Mon, 12 Jun 2023 21:34:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D36BC433EF; Mon, 12 Jun 2023 21:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686605690; bh=h0CRiC60VVAZqmO+EH1iTk5RAONQQFwe4r5bnxWeBYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WWGX6EsmQ2I3j/HZk09nSijqLsLqKh2zR9pZKyLx/B0jIXGPm7WOm6aHPsipPOPiY jbuqr2L5NdxGQ25vQ0efNR0RvVTA/m99hLadgsoxeMr2Yr4F8lHDdx8RspQzi7W43/ mLC5DXypQ1i3u7doi7r5ZuwkTyjLzEfegN8R501cyMOXLvlLRW9VI2Ncve7nqZpdCc NEaiFAjaKVxiKSOlPYg1cGzREgYQilsaa62hJ0h6RiWVYxtKmWXyFXZ0lBGx5e1JWW 26oQT3m1G5nZ691Qq/SnJu3UQtk8Wk6rKOBVtLl9V+SVu1rHNR6YSCJNrSY+wvrhZ3 1QMTS9aeu3yow== Date: Tue, 13 Jun 2023 00:34:11 +0300 From: Mike Rapoport To: Song Liu Cc: Mark Rutland , Kent Overstreet , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , 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 Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: <20230612213411.GP52412@kernel.org> References: <20230601101257.530867-1-rppt@kernel.org> <20230605092040.GB3460@kernel.org> <20230608184116.GJ52412@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230612_143452_568230_9292515B X-CRM114-Status: GOOD ( 49.70 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gRnJpLCBKdW4gMDksIDIwMjMgYXQgMTA6MDI6MTZBTSAtMDcwMCwgU29uZyBMaXUgd3JvdGU6 Cj4gT24gVGh1LCBKdW4gOCwgMjAyMyBhdCAxMTo0MeKAr0FNIE1pa2UgUmFwb3BvcnQgPHJwcHRA a2VybmVsLm9yZz4gd3JvdGU6Cj4gPgo+ID4gT24gVHVlLCBKdW4gMDYsIDIwMjMgYXQgMTE6MjE6 NTlBTSAtMDcwMCwgU29uZyBMaXUgd3JvdGU6Cj4gPiA+IE9uIE1vbiwgSnVuIDUsIDIwMjMgYXQg MzowOeKAr0FNIE1hcmsgUnV0bGFuZCA8bWFyay5ydXRsYW5kQGFybS5jb20+IHdyb3RlOgo+ID4g Pgo+ID4gPiBbLi4uXQo+ID4gPgo+ID4gPiA+ID4gPiA+IENhbiB5b3UgZ2l2ZSBtb3JlIGRldGFp bCBvbiB3aGF0IHBhcmFtZXRlcnMgeW91IG5lZWQ/IElmIHRoZSBvbmx5IGV4dHJhCj4gPiA+ID4g PiA+ID4gcGFyYW1ldGVyIGlzIGp1c3QgImRvZXMgdGhpcyBhbGxvY2F0aW9uIG5lZWQgdG8gbGl2 ZSBjbG9zZSB0byBrZXJuZWwKPiA+ID4gPiA+ID4gPiB0ZXh0IiwgdGhhdCdzIG5vdCB0aGF0IGJp ZyBvZiBhIGRlYWwuCj4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+IE15IHRoaW5raW5nIHdhcyB0aGF0 IHdlIGF0IGxlYXN0IG5lZWQgdGhlIHN0YXJ0ICsgZW5kIGZvciBlYWNoIGNhbGxlci4gVGhhdAo+ ID4gPiA+ID4gPiBtaWdodCBiZSBpdCwgdGJoLgo+ID4gPiA+ID4KPiA+ID4gPiA+IERvIHlvdSBt ZWFuIHRoYXQgbW9kdWxlcyB3aWxsIGhhdmUgc29tZXRoaW5nIGxpa2UKPiA+ID4gPiA+Cj4gPiA+ ID4gPiAgICAgICBqaXRfdGV4dF9hbGxvYyhzaXplLCBNT0RVTEVTX1NUQVJULCBNT0RVTEVTX0VO RCk7Cj4gPiA+ID4gPgo+ID4gPiA+ID4gYW5kIGtwcm9iZXMgd2lsbCBoYXZlCj4gPiA+ID4gPgo+ ID4gPiA+ID4gICAgICAgaml0X3RleHRfYWxsb2Moc2l6ZSwgS1BST0JFU19TVEFSVCwgS1BST0JF U19FTkQpOwo+ID4gPiA+ID4gPwo+ID4gPiA+Cj4gPiA+ID4gWWVzLgo+ID4gPgo+ID4gPiBIb3cg YWJvdXQgd2Ugc3RhcnQgd2l0aCB0d28gQVBJczoKPiA+ID4gICAgICBqaXRfdGV4dF9hbGxvYyhz aXplKTsKPiA+ID4gICAgICBqaXRfdGV4dF9hbGxvY19yYW5nZShzaXplLCBzdGFydCwgZW5kKTsK PiA+ID4KPiA+ID4gQUZBSUNULCBhcm02NCBpcyB0aGUgb25seSBhcmNoIHRoYXQgcmVxdWlyZXMg dGhlIGxhdHRlciBBUEkuIEFuZCBUQkgsIEkgYW0KPiA+ID4gbm90IHF1aXRlIGNvbnZpbmNlZCBp dCBpcyBuZWVkZWQuCj4gPgo+ID4gUmlnaHQgbm93IGFybTY0IGFuZCByaXNjdiBvdmVycmlkZSBi cGYgYW5kIGtwcm9iZXMgYWxsb2NhdGlvbnMgdG8gdXNlIHRoZQo+ID4gZW50aXJlIHZtYWxsb2Mg YWRkcmVzcyBzcGFjZSwgYnV0IGhhdmluZyB0aGUgYWJpbGl0eSB0byBhbGxvY2F0ZSBnZW5lcmF0 ZWQKPiA+IGNvZGUgb3V0c2lkZSBvZiBtb2R1bGVzIGFyZWEgbWF5IGJlIHVzZWZ1bCBmb3Igb3Ro ZXIgYXJjaGl0ZWN0dXJlcy4KPiA+Cj4gPiBTdGlsbCB0aGUgc3RhcnQgKyBlbmQgZm9yIHRoZSBj YWxsZXJzIGZlZWxzIGJhY2t3YXJkcyB0byBtZSBiZWNhdXNlIHRoZQo+ID4gY2FsbGVycyBkbyBu b3QgZGVmaW5lIHRoZSByYW5nZXMsIGJ1dCByYXRoZXIgdGhlIGFyY2hpdGVjdHVyZXMsIHNvIHdl IHN0aWxsCj4gPiBuZWVkIGEgd2F5IGZvciBhcmNoaXRlY3R1cmVzIHRvIGRlZmluZSBob3cgdGhl eSB3YW50IGFsbG9jYXRlIG1lbW9yeSBmb3IKPiA+IHRoZSBnZW5lcmF0ZWQgY29kZS4KPiAKPiBZ ZWFoLCB0aGlzIG1ha2VzIHNlbnNlLgo+IAo+ID4KPiA+ID4gPiA+IEl0IHNpbGwgY2FuIGJlIGFj aGlldmVkIHdpdGggYSBzaW5nbGUgaml0X2FsbG9jX2FyY2hfcGFyYW1zKCksIGp1c3QgYnkKPiA+ ID4gPiA+IGFkZGluZyBlbnVtIGppdF90eXBlIHBhcmFtZXRlciB0byBqaXRfdGV4dF9hbGxvYygp Lgo+ID4gPiA+Cj4gPiA+ID4gVGhhdCBmZWVscyBiYWNrd2FyZHMgdG8gbWU7IGl0IGNlbnRyYWxp emVzIGEgYnVuY2ggb2YgaW5mb3JtYXRpb24gYWJvdXQKPiA+ID4gPiBkaXN0aW5jdCB1c2VycyB0 byBiZSBhYmxlIHRvIHNob3ZlIHRoYXQgaW50byBhIHN0YXRpYyBhcnJheSwgd2hlbiB0aGUgY2Fs bHNpdGVzCj4gPiA+ID4gY2FuIHBhc3MgdGhhdCBpbmZvcm1hdGlvbi4KPiA+ID4KPiA+ID4gSSB0 aGluayB3ZSBvbmx5IHR3byB0eXBlIG9mIHVzZXJzOiBtb2R1bGUgYW5kIGV2ZXJ5dGhpbmcgZWxz ZSAoZnRyYWNlLCBrcHJvYmUsCj4gPiA+IGJwZiBzdHVmZikuIFRoZSBrZXkgZGlmZmVyZW5jZXMg YXJlOgo+ID4gPgo+ID4gPiAgIDEuIG1vZHVsZSB1c2VzIHRleHQgYW5kIGRhdGE7IHdoaWxlIGV2 ZXJ5dGhpbmcgZWxzZSBvbmx5IHVzZXMgdGV4dC4KPiA+ID4gICAyLiBtb2R1bGUgY29kZSBpcyBn ZW5lcmF0ZWQgYnkgdGhlIGNvbXBpbGVyLCBhbmQgdGh1cyBoYXMgc3Ryb25nZXIKPiA+ID4gICBy ZXF1aXJlbWVudHMgaW4gYWRkcmVzcyByYW5nZXM7IGV2ZXJ5dGhpbmcgZWxzZSBhcmUgZ2VuZXJh dGVkIHZpYSBzb21lCj4gPiA+ICAgSklUIG9yIG1hbnVhbCB3cml0dGVuIGFzc2VtYmx5LCBzbyB0 aGV5IGFyZSBtb3JlIGZsZXhpYmxlIHdpdGggYWRkcmVzcwo+ID4gPiAgIHJhbmdlcyAoaW4gSklU LCB3ZSBjYW4gYXZvaWQgdXNpbmcgaW5zdHJ1Y3Rpb25zIHRoYXQgcmVxdWlyZXMgYSBzcGVjaWZp Ywo+ID4gPiAgIGFkZHJlc3MgcmFuZ2UpLgo+ID4gPgo+ID4gPiBUaGUgbmV4dCBxdWVzdGlvbiBp cywgY2FuIHdlIGhhdmUgdGhlIHR3byB0eXBlcyBvZiB1c2VycyBzaGFyZSB0aGUgc2FtZQo+ID4g PiBhZGRyZXNzIHJhbmdlcz8gSWYgbm90LCB3ZSBjYW4gcmVzZXJ2ZSB0aGUgcHJlZmVycmVkIHJh bmdlIGZvciBtb2R1bGVzLAo+ID4gPiBhbmQgbGV0IGV2ZXJ5dGhpbmcgZWxzZSB1c2UgdGhlIG90 aGVyIHJhbmdlLiBJIGRvbid0IHNlZSByZWFzb25zIHRvIGZ1cnRoZXIKPiA+ID4gc2VwYXJhdGUg dXNlcnMgaW4gdGhlICJldmVyeXRoaW5nIGVsc2UiIGdyb3VwLgo+ID4KPiA+IEkgYWdyZWUgdGhh dCB3ZSBjYW4gZGVmaW5lIG9ubHkgdHdvIHR5cGVzOiBtb2R1bGVzIGFuZCBldmVyeXRoaW5nIGVs c2UgYW5kCj4gPiBsZXQgdGhlIGFyY2hpdGVjdHVyZXMgZGVmaW5lIGlmIHRoZXkgbmVlZCBkaWZm ZXJlbnQgcmFuZ2VzIGZvciB0aGVzZSB0d28KPiA+IHR5cGVzLCBvciB3YW50IHRoZSBzYW1lIHJh bmdlIGZvciBldmVyeXRoaW5nLgo+ID4KPiA+IFdpdGggb25seSB0d28gdHlwZXMgd2UgY2FuIGhh dmUgdHdvIEFQSSBjYWxscyBmb3IgYWxsb2MsIGFuZCBhIHNpbmdsZQo+ID4gc3RydWN0dXJlIHRo YXQgZGVmaW5lcyB0aGUgcmFuZ2VzIGV0YyBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgc2lkZSByYXRo ZXIKPiA+IHRoYW4gc3ByZWFkIGFsbCBvdmVyLgo+ID4KPiA+IExpa2Ugc29tZXRoaW5nIGFsb25n IHRoZXNlIGxpbmVzOgo+ID4KPiA+ICAgICAgICAgc3RydWN0IGV4ZWNtZW1fcmFuZ2Ugewo+ID4g ICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgICBzdGFydDsKPiA+ICAgICAgICAgICAgICAg ICB1bnNpZ25lZCBsb25nICAgZW5kOwo+ID4gICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcg ICBmYWxsYmFja19zdGFydDsKPiA+ICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICAgZmFs bGJhY2tfZW5kOwo+ID4gICAgICAgICAgICAgICAgIHBncHJvdF90ICAgICAgICBwZ3Byb3Q7Cj4g PiAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50ICAgIGFsaWdubWVudDsKPiA+ICAgICAgICAg fTsKPiA+Cj4gPiAgICAgICAgIHN0cnVjdCBleGVjbWVtX21vZHVsZXNfcmFuZ2Ugewo+ID4gICAg ICAgICAgICAgICAgIGVudW0gZXhlY21lbV9tb2R1bGVfZmxhZ3MgZmxhZ3M7Cj4gPiAgICAgICAg ICAgICAgICAgc3RydWN0IGV4ZWNtZW1fcmFuZ2UgdGV4dDsKPiA+ICAgICAgICAgICAgICAgICBz dHJ1Y3QgZXhlY21lbV9yYW5nZSBkYXRhOwo+ID4gICAgICAgICB9Owo+ID4KPiA+ICAgICAgICAg c3RydWN0IGV4ZWNtZW1faml0X3JhbmdlIHsKPiA+ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZXhl Y21lbV9yYW5nZSB0ZXh0Owo+ID4gICAgICAgICB9Owo+ID4KPiA+ICAgICAgICAgc3RydWN0IGV4 ZWNtZW1fcGFyYW1zIHsKPiA+ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZXhlY21lbV9tb2R1bGVz X3JhbmdlICAgIG1vZHVsZXM7Cj4gPiAgICAgICAgICAgICAgICAgc3RydWN0IGV4ZWNtZW1faml0 X3JhbmdlICAgICAgICBqaXQ7Cj4gPiAgICAgICAgIH07Cj4gPgo+ID4gICAgICAgICBzdHJ1Y3Qg ZXhlY21lbV9wYXJhbXMgKmV4ZWNtZW1fYXJjaF9wYXJhbXModm9pZCk7Cj4gPgo+ID4gICAgICAg ICB2b2lkICpleGVjbWVtX3RleHRfYWxsb2Moc2l6ZV90IHNpemUpOwo+ID4gICAgICAgICB2b2lk ICpleGVjbWVtX2RhdGFfYWxsb2Moc2l6ZV90IHNpemUpOwo+ID4gICAgICAgICB2b2lkIGV4ZWNt ZW1fZnJlZSh2b2lkICpwdHIpOwo+IAo+IFdpdGggdGhlIGppdCB2YXJpYXRpb24sIG1heWJlIHdl IGNhbiBqdXN0IGNhbGwgdGhlc2UKPiBtb2R1bGVfW3RleHR8ZGF0YV1fYWxsb2MoKT8KCkkgd2Fz IHRoaW5raW5nIGFib3V0ICJleGVjbWVtXypfYWxsb2MoKSIgZm9yIGFsbG9jYXRpb25zIHRoYXQg bXVzdCBiZSBjbG9zZSB0byBrZXJuZWwKaW1hZ2UsIGxpa2UgbW9kdWxlcywgZnRyYWNlIG9uIHg4 NiBhbmQgczM5MCBhbmQgbWF5YmUgc29tZXRoaW5nIGVsc2UgaW4gdGhlCmZ1dHVyZS4KCkFuZCBq aXRfdGV4dF9hbGxvYygpIGZvciBhbGxvY2F0aW9ucyB0aGF0IGNhbiByZXNpZGUgYW55d2hlcmUu CgpJIHRyaWVkIHRvIGZpbmQgYSBkaWZmZXJlbnQgbmFtZSBmb3IgJ3N0cnVjdCBleGVjbWVtX21v ZHVsZXNfcmFuZ2UnIGJ1dApjb3VsZG4ndCB0aGluayBvZiBhbnl0aGluZyBiZXR0ZXIgdGhhbiAn c3RydWN0IGV4ZWNtZW1fY2xvc2VfdG9fa2VybmVsJywgc28KSSd2ZSBsZWZ0IG1vZHVsZXMgaW4g dGhlIG5hbWUuCiAKPiBidHc6IERlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhl IGFsbG9jYXRvciwgd2UgbWF5IGFsc28KPiBuZWVkIHNlcGFyYXRlIGZyZWUoKXMgZm9yIHRleHQg YW5kIGRhdGEuCj4gCj4gPgo+ID4gICAgICAgICB2b2lkICpqaXRfdGV4dF9hbGxvYyhzaXplX3Qg c2l6ZSk7Cj4gPiAgICAgICAgIHZvaWQgaml0X2ZyZWUodm9pZCAqcHRyKTsKPiA+CgpMZXQncyBq dXN0IGFkZCBqaXRfZnJlZSgpIGZvciBjb21wbGV0ZW5lc3MgZXZlbiBpZiBpdCB3aWxsIGJlIHRo ZSBzYW1lIGFzCmV4ZWNtZW1fZnJlZSgpIGZvciBub3cuCiAKPiBbLi4uXQo+IAo+IEhvdyBzaG91 bGQgd2UgbW92ZSBhaGVhZCBmcm9tIGhlcmU/Cj4gCj4gQUZBSUNULCBhbGwgdGhlc2UgY2hhbmdl cyBjYW4gYmUgZWFzaWx5IGV4dGVuZGVkIGFuZCByZWZhY3RvcmVkCj4gaW4gdGhlIGZ1dHVyZSwg c28gd2UgZG9uJ3QgaGF2ZSB0byBtYWtlIGl0IHBlcmZlY3QgdGhlIGZpcnN0IHRpbWUuCj4gT1RP SCwgaGF2aW5nIHRoZSBpbnRlcmZhY2UgY29tbWl0dGVkIChlaXRoZXIgdGhpcyBzZXQgb3IgbXkK PiBtb2R1bGVfYWxsb2NfdHlwZSB2ZXJzaW9uKSBjYW4gdW5ibG9jayB3b3JrcyBpbiB0aGUgYmlu cGFjawo+IGFsbG9jYXRvciBhbmQgdGhlIHVzZXJzIHNpZGUuIFRoZXJlZm9yZSwgSSB0aGluayB3 ZSBjYW4gbW92ZQo+IHJlbGF0aXZlbHkgZmFzdCBoZXJlPwoKT25jZSB0aGUgaW50ZXJmYWNlIGFu ZCBhcmNoaXRlY3R1cmUgYWJzdHJhY3Rpb24gaXMgcmVhZHkgd2UgY2FuIHdvcmsgb24gdGhlCmFs bG9jYXRvciBhbmQgdGhlIHVzZXJzLiBXZSBhbHNvIG5lZWQgdG8gdXBkYXRlIHRleHRfcG9raW5n L2FsdGVybmF0aXZlcyBvbgphcmNoaXRlY3R1cmVzIHRoYXQgd291bGQgYWxsb2NhdGUgZXhlY3V0 YWJsZSBtZW1vcnkgYXMgUk9YLiBJIGRpZCBzb21lCnF1aWNrIHRlc3RzIGFuZCB3aXRoIHRoZXNl IHBhdGNoZXMgJ21vZHByb2JlIHhmcycgdGFrZXMgdGVucyB0aW1lIG1vcmUgdGhhbgpiZWZvcmUu CiAKPiBUaGFua3MsCj4gU29uZwoKLS0gClNpbmNlcmVseSB5b3VycywKTWlrZS4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxp bmcgbGlzdApsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZy YWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK 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 76752C7EE2E for ; Mon, 12 Jun 2023 21:47:58 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=WWGX6Esm; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Qg4zw5tpmz3bXM for ; Tue, 13 Jun 2023 07:47:56 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=WWGX6Esm; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=rppt@kernel.org; receiver=lists.ozlabs.org) X-Greylist: delayed 728 seconds by postgrey-1.37 at boromir; Tue, 13 Jun 2023 07:47:02 AEST Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Qg4yt1HJSz2xHb for ; Tue, 13 Jun 2023 07:47:02 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5205A62AEB; Mon, 12 Jun 2023 21:34:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D36BC433EF; Mon, 12 Jun 2023 21:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686605690; bh=h0CRiC60VVAZqmO+EH1iTk5RAONQQFwe4r5bnxWeBYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WWGX6EsmQ2I3j/HZk09nSijqLsLqKh2zR9pZKyLx/B0jIXGPm7WOm6aHPsipPOPiY jbuqr2L5NdxGQ25vQ0efNR0RvVTA/m99hLadgsoxeMr2Yr4F8lHDdx8RspQzi7W43/ mLC5DXypQ1i3u7doi7r5ZuwkTyjLzEfegN8R501cyMOXLvlLRW9VI2Ncve7nqZpdCc NEaiFAjaKVxiKSOlPYg1cGzREgYQilsaa62hJ0h6RiWVYxtKmWXyFXZ0lBGx5e1JWW 26oQT3m1G5nZ691Qq/SnJu3UQtk8Wk6rKOBVtLl9V+SVu1rHNR6YSCJNrSY+wvrhZ3 1QMTS9aeu3yow== Date: Tue, 13 Jun 2023 00:34:11 +0300 From: Mike Rapoport To: Song Liu Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: <20230612213411.GP52412@kernel.org> References: <20230601101257.530867-1-rppt@kernel.org> <20230605092040.GB3460@kernel.org> <20230608184116.GJ52412@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Mark Rutland , x86@kernel.org, Catalin Marinas , linux-mips@vger.kernel.org, linux-mm@kvack.org, 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, netdev@vger.kernel.org, Kent Overstreet , linux-kernel@vger.kernel.org, Dinh Nguyen , Luis Chamberlain , Palmer Dabbelt , bpf@vger.kernel.org, linuxppc-dev@l ists.ozlabs.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" On Fri, Jun 09, 2023 at 10:02:16AM -0700, Song Liu wrote: > On Thu, Jun 8, 2023 at 11:41 AM Mike Rapoport wrote: > > > > On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote: > > > On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote: > > > > > > [...] > > > > > > > > > > Can you give more detail on what parameters you need? If the only extra > > > > > > > parameter is just "does this allocation need to live close to kernel > > > > > > > text", that's not that big of a deal. > > > > > > > > > > > > My thinking was that we at least need the start + end for each caller. That > > > > > > might be it, tbh. > > > > > > > > > > Do you mean that modules will have something like > > > > > > > > > > jit_text_alloc(size, MODULES_START, MODULES_END); > > > > > > > > > > and kprobes will have > > > > > > > > > > jit_text_alloc(size, KPROBES_START, KPROBES_END); > > > > > ? > > > > > > > > Yes. > > > > > > How about we start with two APIs: > > > jit_text_alloc(size); > > > jit_text_alloc_range(size, start, end); > > > > > > AFAICT, arm64 is the only arch that requires the latter API. And TBH, I am > > > not quite convinced it is needed. > > > > Right now arm64 and riscv override bpf and kprobes allocations to use the > > entire vmalloc address space, but having the ability to allocate generated > > code outside of modules area may be useful for other architectures. > > > > Still the start + end for the callers feels backwards to me because the > > callers do not define the ranges, but rather the architectures, so we still > > need a way for architectures to define how they want allocate memory for > > the generated code. > > Yeah, this makes sense. > > > > > > > > It sill can be achieved with a single jit_alloc_arch_params(), just by > > > > > adding enum jit_type parameter to jit_text_alloc(). > > > > > > > > That feels backwards to me; it centralizes a bunch of information about > > > > distinct users to be able to shove that into a static array, when the callsites > > > > can pass that information. > > > > > > I think we only two type of users: module and everything else (ftrace, kprobe, > > > bpf stuff). The key differences are: > > > > > > 1. module uses text and data; while everything else only uses text. > > > 2. module code is generated by the compiler, and thus has stronger > > > requirements in address ranges; everything else are generated via some > > > JIT or manual written assembly, so they are more flexible with address > > > ranges (in JIT, we can avoid using instructions that requires a specific > > > address range). > > > > > > The next question is, can we have the two types of users share the same > > > address ranges? If not, we can reserve the preferred range for modules, > > > and let everything else use the other range. I don't see reasons to further > > > separate users in the "everything else" group. > > > > I agree that we can define only two types: modules and everything else and > > let the architectures define if they need different ranges for these two > > types, or want the same range for everything. > > > > With only two types we can have two API calls for alloc, and a single > > structure that defines the ranges etc from the architecture side rather > > than spread all over. > > > > Like something along these lines: > > > > struct execmem_range { > > unsigned long start; > > unsigned long end; > > unsigned long fallback_start; > > unsigned long fallback_end; > > pgprot_t pgprot; > > unsigned int alignment; > > }; > > > > struct execmem_modules_range { > > enum execmem_module_flags flags; > > struct execmem_range text; > > struct execmem_range data; > > }; > > > > struct execmem_jit_range { > > struct execmem_range text; > > }; > > > > struct execmem_params { > > struct execmem_modules_range modules; > > struct execmem_jit_range jit; > > }; > > > > struct execmem_params *execmem_arch_params(void); > > > > void *execmem_text_alloc(size_t size); > > void *execmem_data_alloc(size_t size); > > void execmem_free(void *ptr); > > With the jit variation, maybe we can just call these > module_[text|data]_alloc()? I was thinking about "execmem_*_alloc()" for allocations that must be close to kernel image, like modules, ftrace on x86 and s390 and maybe something else in the future. And jit_text_alloc() for allocations that can reside anywhere. I tried to find a different name for 'struct execmem_modules_range' but couldn't think of anything better than 'struct execmem_close_to_kernel', so I've left modules in the name. > btw: Depending on the implementation of the allocator, we may also > need separate free()s for text and data. > > > > > void *jit_text_alloc(size_t size); > > void jit_free(void *ptr); > > Let's just add jit_free() for completeness even if it will be the same as execmem_free() for now. > [...] > > How should we move ahead from here? > > AFAICT, all these changes can be easily extended and refactored > in the future, so we don't have to make it perfect the first time. > OTOH, having the interface committed (either this set or my > module_alloc_type version) can unblock works in the binpack > allocator and the users side. Therefore, I think we can move > relatively fast here? Once the interface and architecture abstraction is ready we can work on the allocator and the users. We also need to update text_poking/alternatives on architectures that would allocate executable memory as ROX. I did some quick tests and with these patches 'modprobe xfs' takes tens time more than before. > Thanks, > Song -- Sincerely yours, Mike. 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 9BE11C7EE2E for ; Mon, 12 Jun 2023 21:35:21 +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=EfGLSp5WBS3SOTzlrz2WAKuzeEojPBmcAKkOXkfis2Q=; b=RrylvEdt1SSa2y XnX9G15r+8yk5oJ+APpE9ivVSZ7zKeJqTFH3nPel3IRL2Jc0pDPpeeJ/hDqF0pdqRY2hYlr7xFPNw dKmO7HArYtpOPXHGRCoEA/OklyE5EOcT8fsIOqTO2WohCyXMKGjvKMg5EFzIX9AYQcgt4pdHfSiy7 d/AFtswUD2hj0WpWyQHsVuoMihOpZpeDY/zU5Defbs+u5xE/eV9H1TuMl2tJT6WhJm2+6UWqRIMCm ZK/ZWJM3/p0lwKdimRkJb1Bw+FWmHENK9HoaJCRfWH74dOcUXnohGYB3k9HbyonobLdJodxx3yFEb oE/SsyAlrh1NDljQGZ3g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q8pBf-005WuD-2R; Mon, 12 Jun 2023 21:34:55 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q8pBc-005Wt9-1P; Mon, 12 Jun 2023 21:34:54 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5205A62AEB; Mon, 12 Jun 2023 21:34:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D36BC433EF; Mon, 12 Jun 2023 21:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686605690; bh=h0CRiC60VVAZqmO+EH1iTk5RAONQQFwe4r5bnxWeBYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WWGX6EsmQ2I3j/HZk09nSijqLsLqKh2zR9pZKyLx/B0jIXGPm7WOm6aHPsipPOPiY jbuqr2L5NdxGQ25vQ0efNR0RvVTA/m99hLadgsoxeMr2Yr4F8lHDdx8RspQzi7W43/ mLC5DXypQ1i3u7doi7r5ZuwkTyjLzEfegN8R501cyMOXLvlLRW9VI2Ncve7nqZpdCc NEaiFAjaKVxiKSOlPYg1cGzREgYQilsaa62hJ0h6RiWVYxtKmWXyFXZ0lBGx5e1JWW 26oQT3m1G5nZ691Qq/SnJu3UQtk8Wk6rKOBVtLl9V+SVu1rHNR6YSCJNrSY+wvrhZ3 1QMTS9aeu3yow== Date: Tue, 13 Jun 2023 00:34:11 +0300 From: Mike Rapoport To: Song Liu Cc: Mark Rutland , Kent Overstreet , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Luis Chamberlain , Michael Ellerman , "Naveen N. Rao" , Palmer Dabbelt , 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 Subject: Re: [PATCH 00/13] mm: jit/text allocator Message-ID: <20230612213411.GP52412@kernel.org> References: <20230601101257.530867-1-rppt@kernel.org> <20230605092040.GB3460@kernel.org> <20230608184116.GJ52412@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230612_143452_568230_9292515B X-CRM114-Status: GOOD ( 49.70 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gRnJpLCBKdW4gMDksIDIwMjMgYXQgMTA6MDI6MTZBTSAtMDcwMCwgU29uZyBMaXUgd3JvdGU6 Cj4gT24gVGh1LCBKdW4gOCwgMjAyMyBhdCAxMTo0MeKAr0FNIE1pa2UgUmFwb3BvcnQgPHJwcHRA a2VybmVsLm9yZz4gd3JvdGU6Cj4gPgo+ID4gT24gVHVlLCBKdW4gMDYsIDIwMjMgYXQgMTE6MjE6 NTlBTSAtMDcwMCwgU29uZyBMaXUgd3JvdGU6Cj4gPiA+IE9uIE1vbiwgSnVuIDUsIDIwMjMgYXQg MzowOeKAr0FNIE1hcmsgUnV0bGFuZCA8bWFyay5ydXRsYW5kQGFybS5jb20+IHdyb3RlOgo+ID4g Pgo+ID4gPiBbLi4uXQo+ID4gPgo+ID4gPiA+ID4gPiA+IENhbiB5b3UgZ2l2ZSBtb3JlIGRldGFp bCBvbiB3aGF0IHBhcmFtZXRlcnMgeW91IG5lZWQ/IElmIHRoZSBvbmx5IGV4dHJhCj4gPiA+ID4g PiA+ID4gcGFyYW1ldGVyIGlzIGp1c3QgImRvZXMgdGhpcyBhbGxvY2F0aW9uIG5lZWQgdG8gbGl2 ZSBjbG9zZSB0byBrZXJuZWwKPiA+ID4gPiA+ID4gPiB0ZXh0IiwgdGhhdCdzIG5vdCB0aGF0IGJp ZyBvZiBhIGRlYWwuCj4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+IE15IHRoaW5raW5nIHdhcyB0aGF0 IHdlIGF0IGxlYXN0IG5lZWQgdGhlIHN0YXJ0ICsgZW5kIGZvciBlYWNoIGNhbGxlci4gVGhhdAo+ ID4gPiA+ID4gPiBtaWdodCBiZSBpdCwgdGJoLgo+ID4gPiA+ID4KPiA+ID4gPiA+IERvIHlvdSBt ZWFuIHRoYXQgbW9kdWxlcyB3aWxsIGhhdmUgc29tZXRoaW5nIGxpa2UKPiA+ID4gPiA+Cj4gPiA+ ID4gPiAgICAgICBqaXRfdGV4dF9hbGxvYyhzaXplLCBNT0RVTEVTX1NUQVJULCBNT0RVTEVTX0VO RCk7Cj4gPiA+ID4gPgo+ID4gPiA+ID4gYW5kIGtwcm9iZXMgd2lsbCBoYXZlCj4gPiA+ID4gPgo+ ID4gPiA+ID4gICAgICAgaml0X3RleHRfYWxsb2Moc2l6ZSwgS1BST0JFU19TVEFSVCwgS1BST0JF U19FTkQpOwo+ID4gPiA+ID4gPwo+ID4gPiA+Cj4gPiA+ID4gWWVzLgo+ID4gPgo+ID4gPiBIb3cg YWJvdXQgd2Ugc3RhcnQgd2l0aCB0d28gQVBJczoKPiA+ID4gICAgICBqaXRfdGV4dF9hbGxvYyhz aXplKTsKPiA+ID4gICAgICBqaXRfdGV4dF9hbGxvY19yYW5nZShzaXplLCBzdGFydCwgZW5kKTsK PiA+ID4KPiA+ID4gQUZBSUNULCBhcm02NCBpcyB0aGUgb25seSBhcmNoIHRoYXQgcmVxdWlyZXMg dGhlIGxhdHRlciBBUEkuIEFuZCBUQkgsIEkgYW0KPiA+ID4gbm90IHF1aXRlIGNvbnZpbmNlZCBp dCBpcyBuZWVkZWQuCj4gPgo+ID4gUmlnaHQgbm93IGFybTY0IGFuZCByaXNjdiBvdmVycmlkZSBi cGYgYW5kIGtwcm9iZXMgYWxsb2NhdGlvbnMgdG8gdXNlIHRoZQo+ID4gZW50aXJlIHZtYWxsb2Mg YWRkcmVzcyBzcGFjZSwgYnV0IGhhdmluZyB0aGUgYWJpbGl0eSB0byBhbGxvY2F0ZSBnZW5lcmF0 ZWQKPiA+IGNvZGUgb3V0c2lkZSBvZiBtb2R1bGVzIGFyZWEgbWF5IGJlIHVzZWZ1bCBmb3Igb3Ro ZXIgYXJjaGl0ZWN0dXJlcy4KPiA+Cj4gPiBTdGlsbCB0aGUgc3RhcnQgKyBlbmQgZm9yIHRoZSBj YWxsZXJzIGZlZWxzIGJhY2t3YXJkcyB0byBtZSBiZWNhdXNlIHRoZQo+ID4gY2FsbGVycyBkbyBu b3QgZGVmaW5lIHRoZSByYW5nZXMsIGJ1dCByYXRoZXIgdGhlIGFyY2hpdGVjdHVyZXMsIHNvIHdl IHN0aWxsCj4gPiBuZWVkIGEgd2F5IGZvciBhcmNoaXRlY3R1cmVzIHRvIGRlZmluZSBob3cgdGhl eSB3YW50IGFsbG9jYXRlIG1lbW9yeSBmb3IKPiA+IHRoZSBnZW5lcmF0ZWQgY29kZS4KPiAKPiBZ ZWFoLCB0aGlzIG1ha2VzIHNlbnNlLgo+IAo+ID4KPiA+ID4gPiA+IEl0IHNpbGwgY2FuIGJlIGFj aGlldmVkIHdpdGggYSBzaW5nbGUgaml0X2FsbG9jX2FyY2hfcGFyYW1zKCksIGp1c3QgYnkKPiA+ ID4gPiA+IGFkZGluZyBlbnVtIGppdF90eXBlIHBhcmFtZXRlciB0byBqaXRfdGV4dF9hbGxvYygp Lgo+ID4gPiA+Cj4gPiA+ID4gVGhhdCBmZWVscyBiYWNrd2FyZHMgdG8gbWU7IGl0IGNlbnRyYWxp emVzIGEgYnVuY2ggb2YgaW5mb3JtYXRpb24gYWJvdXQKPiA+ID4gPiBkaXN0aW5jdCB1c2VycyB0 byBiZSBhYmxlIHRvIHNob3ZlIHRoYXQgaW50byBhIHN0YXRpYyBhcnJheSwgd2hlbiB0aGUgY2Fs bHNpdGVzCj4gPiA+ID4gY2FuIHBhc3MgdGhhdCBpbmZvcm1hdGlvbi4KPiA+ID4KPiA+ID4gSSB0 aGluayB3ZSBvbmx5IHR3byB0eXBlIG9mIHVzZXJzOiBtb2R1bGUgYW5kIGV2ZXJ5dGhpbmcgZWxz ZSAoZnRyYWNlLCBrcHJvYmUsCj4gPiA+IGJwZiBzdHVmZikuIFRoZSBrZXkgZGlmZmVyZW5jZXMg YXJlOgo+ID4gPgo+ID4gPiAgIDEuIG1vZHVsZSB1c2VzIHRleHQgYW5kIGRhdGE7IHdoaWxlIGV2 ZXJ5dGhpbmcgZWxzZSBvbmx5IHVzZXMgdGV4dC4KPiA+ID4gICAyLiBtb2R1bGUgY29kZSBpcyBn ZW5lcmF0ZWQgYnkgdGhlIGNvbXBpbGVyLCBhbmQgdGh1cyBoYXMgc3Ryb25nZXIKPiA+ID4gICBy ZXF1aXJlbWVudHMgaW4gYWRkcmVzcyByYW5nZXM7IGV2ZXJ5dGhpbmcgZWxzZSBhcmUgZ2VuZXJh dGVkIHZpYSBzb21lCj4gPiA+ICAgSklUIG9yIG1hbnVhbCB3cml0dGVuIGFzc2VtYmx5LCBzbyB0 aGV5IGFyZSBtb3JlIGZsZXhpYmxlIHdpdGggYWRkcmVzcwo+ID4gPiAgIHJhbmdlcyAoaW4gSklU LCB3ZSBjYW4gYXZvaWQgdXNpbmcgaW5zdHJ1Y3Rpb25zIHRoYXQgcmVxdWlyZXMgYSBzcGVjaWZp Ywo+ID4gPiAgIGFkZHJlc3MgcmFuZ2UpLgo+ID4gPgo+ID4gPiBUaGUgbmV4dCBxdWVzdGlvbiBp cywgY2FuIHdlIGhhdmUgdGhlIHR3byB0eXBlcyBvZiB1c2VycyBzaGFyZSB0aGUgc2FtZQo+ID4g PiBhZGRyZXNzIHJhbmdlcz8gSWYgbm90LCB3ZSBjYW4gcmVzZXJ2ZSB0aGUgcHJlZmVycmVkIHJh bmdlIGZvciBtb2R1bGVzLAo+ID4gPiBhbmQgbGV0IGV2ZXJ5dGhpbmcgZWxzZSB1c2UgdGhlIG90 aGVyIHJhbmdlLiBJIGRvbid0IHNlZSByZWFzb25zIHRvIGZ1cnRoZXIKPiA+ID4gc2VwYXJhdGUg dXNlcnMgaW4gdGhlICJldmVyeXRoaW5nIGVsc2UiIGdyb3VwLgo+ID4KPiA+IEkgYWdyZWUgdGhh dCB3ZSBjYW4gZGVmaW5lIG9ubHkgdHdvIHR5cGVzOiBtb2R1bGVzIGFuZCBldmVyeXRoaW5nIGVs c2UgYW5kCj4gPiBsZXQgdGhlIGFyY2hpdGVjdHVyZXMgZGVmaW5lIGlmIHRoZXkgbmVlZCBkaWZm ZXJlbnQgcmFuZ2VzIGZvciB0aGVzZSB0d28KPiA+IHR5cGVzLCBvciB3YW50IHRoZSBzYW1lIHJh bmdlIGZvciBldmVyeXRoaW5nLgo+ID4KPiA+IFdpdGggb25seSB0d28gdHlwZXMgd2UgY2FuIGhh dmUgdHdvIEFQSSBjYWxscyBmb3IgYWxsb2MsIGFuZCBhIHNpbmdsZQo+ID4gc3RydWN0dXJlIHRo YXQgZGVmaW5lcyB0aGUgcmFuZ2VzIGV0YyBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgc2lkZSByYXRo ZXIKPiA+IHRoYW4gc3ByZWFkIGFsbCBvdmVyLgo+ID4KPiA+IExpa2Ugc29tZXRoaW5nIGFsb25n IHRoZXNlIGxpbmVzOgo+ID4KPiA+ICAgICAgICAgc3RydWN0IGV4ZWNtZW1fcmFuZ2Ugewo+ID4g ICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgICBzdGFydDsKPiA+ICAgICAgICAgICAgICAg ICB1bnNpZ25lZCBsb25nICAgZW5kOwo+ID4gICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcg ICBmYWxsYmFja19zdGFydDsKPiA+ICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICAgZmFs bGJhY2tfZW5kOwo+ID4gICAgICAgICAgICAgICAgIHBncHJvdF90ICAgICAgICBwZ3Byb3Q7Cj4g PiAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50ICAgIGFsaWdubWVudDsKPiA+ICAgICAgICAg fTsKPiA+Cj4gPiAgICAgICAgIHN0cnVjdCBleGVjbWVtX21vZHVsZXNfcmFuZ2Ugewo+ID4gICAg ICAgICAgICAgICAgIGVudW0gZXhlY21lbV9tb2R1bGVfZmxhZ3MgZmxhZ3M7Cj4gPiAgICAgICAg ICAgICAgICAgc3RydWN0IGV4ZWNtZW1fcmFuZ2UgdGV4dDsKPiA+ICAgICAgICAgICAgICAgICBz dHJ1Y3QgZXhlY21lbV9yYW5nZSBkYXRhOwo+ID4gICAgICAgICB9Owo+ID4KPiA+ICAgICAgICAg c3RydWN0IGV4ZWNtZW1faml0X3JhbmdlIHsKPiA+ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZXhl Y21lbV9yYW5nZSB0ZXh0Owo+ID4gICAgICAgICB9Owo+ID4KPiA+ICAgICAgICAgc3RydWN0IGV4 ZWNtZW1fcGFyYW1zIHsKPiA+ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZXhlY21lbV9tb2R1bGVz X3JhbmdlICAgIG1vZHVsZXM7Cj4gPiAgICAgICAgICAgICAgICAgc3RydWN0IGV4ZWNtZW1faml0 X3JhbmdlICAgICAgICBqaXQ7Cj4gPiAgICAgICAgIH07Cj4gPgo+ID4gICAgICAgICBzdHJ1Y3Qg ZXhlY21lbV9wYXJhbXMgKmV4ZWNtZW1fYXJjaF9wYXJhbXModm9pZCk7Cj4gPgo+ID4gICAgICAg ICB2b2lkICpleGVjbWVtX3RleHRfYWxsb2Moc2l6ZV90IHNpemUpOwo+ID4gICAgICAgICB2b2lk ICpleGVjbWVtX2RhdGFfYWxsb2Moc2l6ZV90IHNpemUpOwo+ID4gICAgICAgICB2b2lkIGV4ZWNt ZW1fZnJlZSh2b2lkICpwdHIpOwo+IAo+IFdpdGggdGhlIGppdCB2YXJpYXRpb24sIG1heWJlIHdl IGNhbiBqdXN0IGNhbGwgdGhlc2UKPiBtb2R1bGVfW3RleHR8ZGF0YV1fYWxsb2MoKT8KCkkgd2Fz IHRoaW5raW5nIGFib3V0ICJleGVjbWVtXypfYWxsb2MoKSIgZm9yIGFsbG9jYXRpb25zIHRoYXQg bXVzdCBiZSBjbG9zZSB0byBrZXJuZWwKaW1hZ2UsIGxpa2UgbW9kdWxlcywgZnRyYWNlIG9uIHg4 NiBhbmQgczM5MCBhbmQgbWF5YmUgc29tZXRoaW5nIGVsc2UgaW4gdGhlCmZ1dHVyZS4KCkFuZCBq aXRfdGV4dF9hbGxvYygpIGZvciBhbGxvY2F0aW9ucyB0aGF0IGNhbiByZXNpZGUgYW55d2hlcmUu CgpJIHRyaWVkIHRvIGZpbmQgYSBkaWZmZXJlbnQgbmFtZSBmb3IgJ3N0cnVjdCBleGVjbWVtX21v ZHVsZXNfcmFuZ2UnIGJ1dApjb3VsZG4ndCB0aGluayBvZiBhbnl0aGluZyBiZXR0ZXIgdGhhbiAn c3RydWN0IGV4ZWNtZW1fY2xvc2VfdG9fa2VybmVsJywgc28KSSd2ZSBsZWZ0IG1vZHVsZXMgaW4g dGhlIG5hbWUuCiAKPiBidHc6IERlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhl IGFsbG9jYXRvciwgd2UgbWF5IGFsc28KPiBuZWVkIHNlcGFyYXRlIGZyZWUoKXMgZm9yIHRleHQg YW5kIGRhdGEuCj4gCj4gPgo+ID4gICAgICAgICB2b2lkICpqaXRfdGV4dF9hbGxvYyhzaXplX3Qg c2l6ZSk7Cj4gPiAgICAgICAgIHZvaWQgaml0X2ZyZWUodm9pZCAqcHRyKTsKPiA+CgpMZXQncyBq dXN0IGFkZCBqaXRfZnJlZSgpIGZvciBjb21wbGV0ZW5lc3MgZXZlbiBpZiBpdCB3aWxsIGJlIHRo ZSBzYW1lIGFzCmV4ZWNtZW1fZnJlZSgpIGZvciBub3cuCiAKPiBbLi4uXQo+IAo+IEhvdyBzaG91 bGQgd2UgbW92ZSBhaGVhZCBmcm9tIGhlcmU/Cj4gCj4gQUZBSUNULCBhbGwgdGhlc2UgY2hhbmdl cyBjYW4gYmUgZWFzaWx5IGV4dGVuZGVkIGFuZCByZWZhY3RvcmVkCj4gaW4gdGhlIGZ1dHVyZSwg c28gd2UgZG9uJ3QgaGF2ZSB0byBtYWtlIGl0IHBlcmZlY3QgdGhlIGZpcnN0IHRpbWUuCj4gT1RP SCwgaGF2aW5nIHRoZSBpbnRlcmZhY2UgY29tbWl0dGVkIChlaXRoZXIgdGhpcyBzZXQgb3IgbXkK PiBtb2R1bGVfYWxsb2NfdHlwZSB2ZXJzaW9uKSBjYW4gdW5ibG9jayB3b3JrcyBpbiB0aGUgYmlu cGFjawo+IGFsbG9jYXRvciBhbmQgdGhlIHVzZXJzIHNpZGUuIFRoZXJlZm9yZSwgSSB0aGluayB3 ZSBjYW4gbW92ZQo+IHJlbGF0aXZlbHkgZmFzdCBoZXJlPwoKT25jZSB0aGUgaW50ZXJmYWNlIGFu ZCBhcmNoaXRlY3R1cmUgYWJzdHJhY3Rpb24gaXMgcmVhZHkgd2UgY2FuIHdvcmsgb24gdGhlCmFs bG9jYXRvciBhbmQgdGhlIHVzZXJzLiBXZSBhbHNvIG5lZWQgdG8gdXBkYXRlIHRleHRfcG9raW5n L2FsdGVybmF0aXZlcyBvbgphcmNoaXRlY3R1cmVzIHRoYXQgd291bGQgYWxsb2NhdGUgZXhlY3V0 YWJsZSBtZW1vcnkgYXMgUk9YLiBJIGRpZCBzb21lCnF1aWNrIHRlc3RzIGFuZCB3aXRoIHRoZXNl IHBhdGNoZXMgJ21vZHByb2JlIHhmcycgdGFrZXMgdGVucyB0aW1lIG1vcmUgdGhhbgpiZWZvcmUu CiAKPiBUaGFua3MsCj4gU29uZwoKLS0gClNpbmNlcmVseSB5b3VycywKTWlrZS4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwg bWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8v bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK