On Fri, Feb 16, 2024 at 9:18 AM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > On Fri, Feb 16, 2024 at 08:54:08AM -0800, Alexei Starovoitov wrote: > > On Fri, Feb 16, 2024 at 1:31 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > On Thu, Feb 15, 2024 at 12:50:55PM -0800, Alexei Starovoitov wrote: > > > > So, since apply_to_page_range() is available to the kernel > > > > (xen, gpu, kasan, etc) then I see no reason why > > > > vmap_pages_range() shouldn't be available as well, since: > > > > > > In case it wasn't clear before: apply_to_page_range is a bad API to > > > be exported. We've been working on removing it but it stalled. > > > Exposing something that allows a module to change arbitrary page table > > > bits is not a good idea. > > > > I never said that that module should do that. > > > > > Please take a step back and think of how to expose a vmalloc like > > > allocation that grows only when used as a proper abstraction. I could > > > actually think of various other uses for it. > > > > "vmalloc like allocation that grows" is not what I'm after. > > I need 4G+guard region at the start. > > Please read my earlier email and reply to my questions and api proposals. > > Replying to half of the sentence, and out of context, is not a > > productive discussion. > > > 1. The concern here is that this interface, which you would like to add, > exposes the "addr", "end" to upper layer, so fake values can easily be > passed to vmap internals. > > 2. Other users can start using this API/function which is hidden now > and is not supposed to be used outside of vmap code. Because it is a > static helper. I suspect you're replying to the original patch that just makes vmap_pages_range() external. It was discarded already. The request for feedback is for vm_area_map_pages proposal upthread: +int vm_area_map_pages(struct vm_struct *area, unsigned long addr, unsigned int count, + struct page **pages) There is no "end" and "addr" is range checked. > 3. It opens new dependencies which we would like to avoid. As a second > step someone wants to dump "such region(4G+guard region)" over vmallocifo > to see what is mapped what requires a certain tracking. What do you mean by "dump over /proc/vmallocinfo" ? Privileged user space can see the start/end of every region. And if some regions have all pages mapped and others don't, so? vmallocinfo is racy. By the time user space sees the range it can be unmapped already.
