Thread (27 messages) 27 messages, 7 authors, 2024-03-25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help