On Wed, Feb 03, 2021 at 10:12:22AM +0100, Michal Hocko wrote: > On Tue 02-02-21 21:10:40, Mike Rapoport wrote: > > > > Let me reiterate to make sure I don't misread your suggestion. > > > > If we make secretmem an opt-in feature with, e.g. kernel parameter, the > > pooling of large pages is unnecessary. In this case there is no limited > > resource we need to protect because secretmem will allocate page by page. > > Yes. > > > Since there is no limited resource, we don't need special permissions > > to access secretmem so we can move forward with a system call that creates > > a mmapable file descriptor and save the hassle of a chardev. > > Yes, I assume you implicitly assume mlock rlimit here. Yes. > Also memcg accounting should be in place. Right, without pools memcg accounting is no different from other unevictable files. > Wrt to the specific syscall, please document why existing interfaces are > not a good fit as well. It would be also great to describe interaction > with mlock itself (I assume the two to be incompatible - mlock will fail > on and mlockall will ignore it). The interaction with mlock() belongs more to the man page, but I don't mind adding this to changelog as well. -- Sincerely yours, Mike.
