Re: [PATCH bpf-next v4 0/6] execmem_alloc for BPF programs

[Song Liu <song@kernel.org>]

On Mon, Nov 21, 2022 at 1:12 PM Luis Chamberlain <mcgrof@kernel.org> 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