On Mon, Nov 21, 2022 at 1:12 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > On Thu, Nov 17, 2022 at 12:23:16PM -0800, Song Liu wrote: [...] > > 5. Introduce a unified API to allocate memory with special permissions. > > > > This will help get rid of set_vm_flush_reset_perms calls from users of > > vmalloc, module_alloc, etc. > > And *this* is one of the reasons I'm so eager to see a proper solution > drawn up. This would be a huge win for modules, however since some of > the complexities in special permissions with modules lies in all the > cross architecture hanky panky, I'd prefer to see this through merged > *iff* we have modules converted as well as it would give us a clearer > picture if the solution covers the bases. And we'd get proper testing > on this. Rather than it being a special thing for BPF. Module code is clearly the most difficult to migrate. (It has to work on almost all archs, and it contains 3 allocations: core, data, init.) If we want actionable path towards fixing all these, I don't think we should use module code as the bar for the very first set. (Of course, if Andrew or Linus insists that way, I will rethink about this). PS: I don't quite understand why there is a strong concern in adding this to core mm API, especially that there is also an argument that this is only for BPF. IIUC, the real concern comes for a core API that is 1. easy to use, and have many users; 2. has a horrible internal implementation (maybe bpf_prog_pack falls in here, but it is not easy to use). Such API will cause a lot of problems, and it is also so hard to remove. execmem_* APIs are quite the opposite. It is hard to use, and it has a decent internal implementation (at least better than bpf_prog_pack). In 4/5 of the set, we easily reverted all the code bpf_prog_pack and used execmem_* instead. If execmem_* turn out to be horrible, and only useful for BPF, we can easily migrate it to the next good API, right? Thanks, Song