On Thu, 2021-01-28 at 14:01 +0100, Michal Hocko wrote: > On Thu 28-01-21 11:22:59, Mike Rapoport wrote: [...] > > I like the idea to have a pool as an optimization rather than a > > hard requirement but I don't see why would it need a careful access > > control. As the direct map fragmentation is not necessarily > > degrades the performance (and even sometimes it actually improves > > it) and even then the degradation is small, trying a PMD_ORDER > > allocation for a pool and then falling back to 4K page may be just > > fine. > > Well, as soon as this is a scarce resource then an access control > seems like a first thing to think of. Maybe it is not really > necessary but then this should be really justified. The control for the resource is effectively the rlimit today. I don't think dividing the world into people who can and can't use secret memory would be useful since the design is to be usable for anyone who might have a secret to keep; it would become like the kvm group permissions: something which is theoretically an access control but which in practise is given to everyone on the system. > I am also still not sure why this whole thing is not just a > ramdisk/ramfs which happens to unmap its pages from the direct > map. Wouldn't that be a much more easier model to work with? You > would get an access control for free as well. The original API was a memfd which does have this access control as well. However, the decision was made after much discussion to go with a new system call instead. Obviously the API choice could be revisited but do you have anything to add over the previous discussion, or is this just to get your access control? James
