On Tue, May 09, 2023 at 05:29:10PM -0400, Kent Overstreet wrote: > On Tue, May 09, 2023 at 02:12:41PM -0700, Lorenzo Stoakes wrote: > > On Tue, May 09, 2023 at 01:46:09PM -0700, Christoph Hellwig wrote: > > > On Tue, May 09, 2023 at 12:56:32PM -0400, Kent Overstreet wrote: > > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > > > This is needed for bcachefs, which dynamically generates per-btree node > > > > unpack functions. > > > > > > No, we will never add back a way for random code allocating executable > > > memory in kernel space. > > > > Yeah I think I glossed over this aspect a bit as it looks ostensibly like simply > > reinstating a helper function because the code is now used in more than one > > place (at lsf/mm so a little distracted :) > > > > But it being exported is a problem. Perhaps there's another way of acheving the > > same aim without having to do so? > > None that I see. > > The background is that bcachefs generates a per btree node unpack > function, based on the packed format for that btree node, for unpacking > keys within that node. The unpack function is only ~50 bytes, and for > locality we want it to be located with the btree node's other in-memory > lookup tables so they can be prefetched all at once. > > Here's the codegen: > > https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/bkey.c#n727 Well, it's a cool trick, but it's not clear that it actually belongs in production kernel code. What else in the kernel actually does dynamic codegen? Just BPF, I think? Among other issues, this is entirely architecture-specific, and it may cause interoperability issues with various other features, including security features. Is it really safe to leave a W&X page around, for example? What seems to be missing is any explanation for what we're actually getting from this extremely unusual solution that cannot be gained any other way. What is unique about bcachefs that it really needs something like this? - Eric
