[PATCH] kprobes: Enable tracing for mololithic kernel images
jarkko at kernel.org
jarkko at kernel.org
Wed Jun 15 14:29:18 PDT 2022
On Wed, Jun 15, 2022 at 08:37:07AM +0200, hch at lst.de wrote:
> On Tue, Jun 14, 2022 at 03:32:38PM +0300, jarkko at kernel.org wrote:
> > > Like say for a next step we moved prog pack out of bpf into core code,
> > > gave it it's own copy of module_alloc(), and then made kprobes use it.
> > > Then we would have something with improved W^X guard rails, and kprobes
> > > would not depend on modules anymore. I think maybe it's a step in the
> > > right direction, even if it's not perfect.
> >
> > So you're saying that I should (as a first step) basically clone
> > module_alloc() implementation for kprobes, and future for BPF
> > use, in order to get a clean starting point?
>
> I don't think cloning the code helps anyone. The fact that except
> for the eBPF mess everyone uses module_alloc and the related
> infrastructure is a feature and not a bug. The interface should
> become better than what we have right now, but there is few enough
> users that this can be done in one go.
>
> So assuming we really care deeply enough about fancy tracing without
> modules (and I'm not sure we do, even if you don't use modules it
> doesn't hurt to just build the modules code, I do that all the time
> for my test machines), the general approach in your series is the
> right one.
OK, thanks for the elaboration!
However I bake it, I doubt that next version is going to be the final
version, given all the angles. Therefore, I mostly Christophe's
suggestions on compilation flags, and also split this into per-arch
patches.
That should be at least to the right direction.
BR, Jarkko
More information about the linux-riscv
mailing list