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.