On Fri, Apr 14, 2023, Michal Hocko wrote: > On Fri 14-04-23 00:11:49, Ackerley Tng wrote: > > 3. A more generic fbind(): it seems like this new functionality is > > really only needed for restrictedmem files, hence a separate, > > specific syscall was proposed to avoid complexities with handling > > conflicting policies that may be specified via other syscalls like > > mbind() > > I do not think it is a good idea to make the syscall restrict mem > specific. +1. IMO, any uAPI that isn't directly related to the fundamental properties of restricted memory, i.e. isn't truly unique to restrictedmem, should be added as generic fd-based uAPI. > History shows that users are much more creative when it comes > to usecases than us. I do understand that the nature of restricted > memory is that it is not mapable but memory policies without a mapping > are a reasonable concept in genereal. After all this just tells where > the memory should be allocated from. Do we need to implement that for > any other fs? No, you can safely return EINVAL for anything but > memfd_restricted fd for now but you shouldn't limit usecases upfront. I would even go a step further and say that we should seriously reconsider the design/implemenation of memfd_restricted() if a generic fbind() needs explicit handling from the restricted memory code. One of the goals with memfd_restricted() is to rely on the underlying backing store to handle all of the "normal" behaviors.
