On Wed, Feb 7, 2024 at 1:10 PM Lorenzo Stoakes <lstoakes@xxxxxxxxx> wrote: > > I don't know what conventions you bpf guys follow, but it's common courtesy > in the rest of the kernel to do a get_maintainers.pl check and figure out > who the maintainers/reviews of a part of the kernel you change are, > and include them in your mailing list. linux-mm and Johannes was cc-ed. > On Tue, Feb 06, 2024 at 02:04:28PM -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > The next commit will introduce bpf_arena which is a sparsely populated shared > > memory region between bpf program and user space process. > > It will function similar to vmalloc()/vm_map_ram(): > > - get_vm_area() > > - alloc_pages() > > - vmap_pages_range() > > This tells me absolutely nothing about why it is justified to expose this > internal interface. You need to put more explanation here along the lines > of 'we had no other means of achieving what we needed from vmalloc because > X, Y, Z and are absolutely convinced it poses no risk of breaking anything'. Full motivation and details are in the cover letter and in the next commit as commit log of this patch says. Everyone subscribed to linux-mm has all patches in their mailboxes. The commit log also mentioned that the next patch does pretty much what vm_map_ram() does. Any further details you're looking for? What 'risk of breaking' are you talking about? > I mean I see a lot of checks in vmap() that aren't in vmap_pages_range() > for instance. We good to expose that, not only for you but for any other > core kernel users? I could have overlooked something. What specific checks do you have in mind?
