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. It feels to me that a lot of ground work is needed to get to the point where we can use centralized handling of loading text. -- Sincerely yours, Mike.
