On Mon, Nov 14, 2022 at 12:30:49PM -0800, Song Liu wrote:
> On Sun, Nov 13, 2022 at 2:35 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> >
> > On Wed, Nov 09, 2022 at 05:04:25PM +0000, Edgecombe, Rick P wrote:
> > > On Wed, 2022-11-09 at 13:17 +0200, Mike Rapoport wrote:
> > > > On Tue, Nov 08, 2022 at 04:51:12PM +0000, Edgecombe, Rick P wrote:
> > >
> > > > How the caching of large pages in vmalloc can be made useful for use
> > > > cases like secretmem and PKS?
> > >
> > > This part is easy I think. If we had an unmapped page allocator it
> > > could just feed this.
> >
> > The unmapped page allocator could be used by anything that needs
> > non-default permissions in the direct map and knows how to map the pages
> > elsewhere. E.g it would have been a oneliner to switch x86::module_alloc()
> > to use unmapped allocations. But ...
> >
> > > Do you have any idea when you might pick up that stuff again?
> >
> > ... unfortunately I don't see it happening anytime soon.
> >
> > > To answer my own question, I think a good first step would be to make
> > > the interface also work for non-text_poke() so it could really be cross
> > > arch, then use it for everything except modules. The benefit to the
> > > other arch's at that point is centralized handling of loading text.
> >
> > My concern is that the proposed execmem_alloc() cannot be used for
> > centralized handling of loading text. I'm not familiar enough with
> > modules/ftrace/kprobes/BPF to clearly identify the potential caveats, but
> > my gut feeling is that the proposed execmem_alloc() won't be an improvement
> > but rather a hindrance for moving to centralized handling of loading text.
>
> I don't follow why this could ever be a hindrance. Luis is very excited about
> this, and I am very sure it works for ftrace, kprobe, and BPF.
The main hurdles for modules are:
* x86 needs support for CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
to use this properly
* in light of lack of support for CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
we need a fallback
* today module_alloc() follows special hanky panky open coded semantics for
special page permissions, a unified way to handle this would be
ideal instead of expecting everyone to get it right.
Other than this there are probably odd corner cases which would likely
only come up during testing. I see Song's efforts striving towards these
objectives, and because of the new ARCH_WANTS_MODULES_DATA_IN_VMALLOC, it
should be possible to get us there.
Luis
