et>, "ebied...@xmission.com" <ebied...@xmission.com>, 
"aneesh.ku...@linux.ibm.com" <aneesh.ku...@linux.ibm.com>, "Edgecombe, Rick P" 
<rick.p.edgeco...@intel.com>, "bris...@redhat.com" <bris...@redhat.com>, 
"wangkefeng.w...@huawei.com" <wangkefeng.w...@huawei.com>, "ker...@esmil.dk" 
<ker...@esmil.dk>, "jniet...@gmail.com" <jniet...@gmail.com>, 
"paul.walms...@sifive.com" <paul.walms...@sifive.com>, "a...@kernel.org" 
<a...@kernel.org>, "w...@kernel.org" <w...@kernel.org>, "masahi...@kernel.org" 
<masahi...@kernel.org>, "Sakkinen, Jarkko" <jar...@profian.com>, 
"samitolva...@google.com" <samitolva...@google.com>, 
"naveen.n....@linux.ibm.com" <naveen.n....@linux.ibm.com>, "el...@google.com" 
<el...@google.com>, "keesc...@chromium.org" <keesc...@chromium.org>, 
"rost...@goodmis.org" <rost...@goodmis.org>, "nat...@kernel.org" 
<nat...@kernel.org>, "rmk+ker...@armlinux.org.uk" <rmk+ker...@armlinux.org.uk>, 
"broo...@kernel.org" <broo...@kernel.org>, "b...@alien8.de" <b...@alien8.de>, 
"egore...@linux.ibm
 .com" <egore...@linux.ibm.com>, "tsbog...@alpha.franken.de" 
<tsbog...@alpha.franken.de>, "linux-par...@vger.kernel.org" 
<linux-par...@vger.kernel.org>, "nathan...@profian.com" 
<nathan...@profian.com>, "dmitry.torok...@gmail.com" 
<dmitry.torok...@gmail.com>, "da...@davemloft.net" <da...@davemloft.net>, 
"kirill.shute...@linux.intel.com" <kirill.shute...@linux.intel.com>, 
"husc...@linux.ibm.com" <husc...@linux.ibm.com>, "pet...@infradead.org" 
<pet...@infradead.org>, "h...@zytor.com" <h...@zytor.com>, 
"sparcli...@vger.kernel.org" <sparcli...@vger.kernel.org>, 
"yangtie...@loongson.cn" <yangtie...@loongson.cn>, "mbe...@suse.cz" 
<mbe...@suse.cz>, "chenzhong...@huawei.com" <chenzhong...@huawei.com>, 
"a...@kernel.org" <a...@kernel.org>, "x...@kernel.org" <x...@kernel.org>, 
"li...@armlinux.org.uk" <li...@armlinux.org.uk>, 
"linux-ri...@lists.infradead.org" <linux-ri...@lists.infradead.org>, 
"mi...@redhat.com" <mi...@redhat.com>, "atom...@redhat.com" 
<atom...@redhat.com>, "a...@eecs.berkeley.edu" <a
 o...@eecs.berkeley.edu>, "h...@linux.ibm.com" <hca@linux
.ibm.com>, "liaocha...@huawei.com" <liaocha...@huawei.com>, 
"ati...@atishpatra.org" <ati...@atishpatra.org>, "jpoim...@kernel.org" 
<jpoim...@kernel.org>, "tmri...@linux.ibm.com" <tmri...@linux.ibm.com>, 
"linux-m...@vger.kernel.org" <linux-m...@vger.kernel.org>, 
"changbin...@intel.com" <changbin...@intel.com>, "pal...@dabbelt.com" 
<pal...@dabbelt.com>, "linuxppc-dev@lists.ozlabs.org" 
<linuxppc-dev@lists.ozlabs.org>, "linux-modu...@vger.kernel.org" 
<linux-modu...@vger.kernel.org>
Errors-To: linuxppc-dev-bounces+archive=mail-archive....@lists.ozlabs.org
Sender: "Linuxppc-dev" 
<linuxppc-dev-bounces+archive=mail-archive....@lists.ozlabs.org>

On Wed, Jun 15, 2022 at 08:37:07AM +0200, h...@lst.de wrote:
> On Tue, Jun 14, 2022 at 03:32:38PM +0300, jar...@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

Reply via email to