On Wed, Jun 25, 2025 at 01:12:11PM -0400, Peter Xu wrote: > After I read the two use cases, I mostly agree. Just one trivial thing to > mention, it may not be direct map but vmap() (see io_region_init_ptr()). If it is vmapped then this is all silly, you should vmap and mmmap using the same cache colouring and, AFAIK, pgoff is how this works for purely userspace. Once vmap'd it should determine the cache colour and set the pgoff properly, then everything should already work no? > It already does, see (io_uring_get_unmapped_area(), of parisc): > > /* > * Do not allow to map to user-provided address to avoid breaking the > * aliasing rules. Userspace is not able to guess the offset address of > * kernel kmalloc()ed memory area. > */ > if (addr) > return -EINVAL; > > I do not know whoever would use MAP_FIXED but with addr=0. So failing > addr!=0 should literally stop almost all MAP_FIXED already. Maybe but also it is not right to not check MAP_FIXED directly.. And addr is supposed to be a hint for non-fixed mode so it is weird to -EINVAL when you can ignore the hint?? > Going back to the topic of this series - I think the new API would work for > io_uring and parisc too if I can return phys_pgoff, here what parisc would > need is: The best solution is to fix the selection of normal pgoff so it has consistent colouring of user VMAs and kernel vmaps. Either compute a pgoff that matches the vmap (hopefully easy if it is not uABI) or teach the kernel vmap how to respect a "pgoff" to set the cache colouring just like the user VMA's do (AFIACR). But I think this is getting maybe too big and I'd just introduce the new API and not try to convert this hard stuff. The above explanation how it could be fixed should be enough?? Jason
