Re: [RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
From: Luis Chamberlain <mcgrof@kernel.org>
Date: 2024-03-08 02:56:09
Also in:
bpf, lkml
On Thu, Mar 7, 2024 at 6:50 PM Masami Hiramatsu [off-list ref] wrote:
On Wed, 6 Mar 2024 17:58:14 -0800 Song Liu [off-list ref] wrote:quoted
Hi Calvin, It is great to hear from you! :) On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens [off-list ref] wrote:quoted
On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:quoted
On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:quoted
Hello all, This patchset makes it possible to use bpftrace with kprobes on kernels built without loadable module support.This is a step in the right direction for another reason: clearly the module_alloc() is not about modules, and we have special reasons for it now beyond modules. The effort to share a generalize a huge page for these things is also another reason for some of this but that is more long term. I'm all for minor changes here so to avoid regressions but it seems a rename is in order -- if we're going to all this might as well do it now. And for that I'd just like to ask you paint the bikeshed with Song Liu as he's been the one slowly making way to help us get there with the "module: replace module_layout with module_memory", and Mike Rapoport as he's had some follow up attempts [0]. As I see it, the EXECMEM stuff would be what we use instead then. Mike kept the module_alloc() and the execmem was just a wrapper but your move of the arch stuff makes sense as well and I think would complement his series nicely.I apologize for missing that. I think these are the four most recent versions of the different series referenced from that LWN link: a) https://lore.kernel.org/all/20230918072955.2507221-1-rppt@kernel.org/ (local) b) https://lore.kernel.org/all/20230526051529.3387103-1-song@kernel.org/ (local) c) https://lore.kernel.org/all/20221107223921.3451913-1-song@kernel.org/ (local) d) https://lore.kernel.org/all/20201120202426.18009-1-rick.p.edgecombe@intel.com/ (local) Song and Mike, please correct me if I'm wrong, but I think what I've done here (see [1], sorry for not adding you initially) is compatible with everything both of you have recently proposed above. How do you feel about this as a first step?I agree that the work here is compatible with other efforts. I have no objection to making this the first step.quoted
For naming, execmem_alloc() seems reasonable to me? I have no strong feelings at all, I'll just use that going forward unless somebody else expresses an opinion.I am not good at naming things. No objection from me to "execmem_alloc".Hm, it sounds good to me too. I think we should add a patch which just rename the module_alloc/module_memfree with execmem_alloc/free first.
I think that would be cleaner, yes. Leaving the possible move to a secondary patch and placing the testing more on the later part. Luis