luxnic.net" <n...@fluxnic.net>, "ebied...@xmission.com" <ebied...@xmission.com>, "aneesh.ku...@linux.ibm.com" <aneesh.ku...@linux.ibm.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" <egorenar@linux.i bm.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...@eecs.berkeley.edu>, "h...@linux.ibm.com" <h...@linux.ibm.com>, "liaochang1@ 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 Thu, Jun 09, 2022 at 06:41:36PM +0000, Edgecombe, Rick P wrote: > On Thu, 2022-06-09 at 06:24 -0700, Luis Chamberlain wrote: > > On Thu, Jun 09, 2022 at 05:48:52AM +0200, Christoph Hellwig wrote: > > > On Wed, Jun 08, 2022 at 01:26:19PM -0700, Luis Chamberlain wrote: > > > > No, that was removed because it has only one user. > > > > > > That is only part of the story. The other part is that the overall > > > kernel simply does not have any business allocating exutable > > > memory. > > > Executable memory is a very special concept for modules or module- > > > like > > > code like kprobes, and should not be exposed as a general concept. > > > > It is not just modules and kprobes, it is also ftrace and bpf too > > now. > > So while it should not be used everywhere calling it module_alloc() > > is just confusing at this point. Likewise, module_alloc_huge() is > > being proposed too and I'd rather we deal with this properly in > > aligment > > of taking care of the rename as well. > > > > If the concern is to restrict access we can use the module namespace > > stuff > > so to ensure only intended users get access to it. > > BPF even has multiple uses for text allocation. It has its own > trampoline feature that puts different type of text in the allocation, > with its own allocation routine. I looks like there are even more > little allocators in there. > > So yea, there seems to be a lot of the kernel in the business of > dynamically generated text, for better or worse. I agree that it needs > to be done carefully. However, these usages always seem to have the > same problems (W^X, arch eccentricities, etc). So I don't think we > should hide away the pieces. Instead we should have something with > guard rails on it, so they can't get the allocation part wrong. > > But I guess the question here is: what should we do in the meantime? It > is kind of similar to the questions that came up around the bpf prog > pack allocator. Should we hold up allocator related work until > underlying problems are resolved and there is some mature core > solution? > > Personally I had thought we would need to do some clean switch to a > much different interface. I still think someday it will be required, > but it seems to be evolving naturally for the time being. > > 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? BR, Jarkko
