On Wed, Mar 13, 2019 at 01:01:40PM -0700, Mike Kravetz wrote: > On 3/13/19 11:52 AM, Andrea Arcangeli wrote: > > > > hugetlbfs is more complicated to detect, because even if you inherit > > it from fork(), the services that mounts the fs may be in a different > > container than the one that Oracle that uses userfaultfd later on down > > the road from a different context. And I don't think it would be ok to > > allow running userfaultfd just because you can open a file in an > > hugetlbfs file system. With /dev/kvm it's a bit different, that's > > chmod o-r by default.. no luser should be able to open it. > > > > Unless somebody suggests a consistent way to make hugetlbfs "just > > work" (like we could achieve clean with CRIU and KVM), I think Oracle > > will need a one liner change in the Oracle setup to echo into that > > file in addition of running the hugetlbfs mount. > > I think you are suggesting the DB setup process enable uffd for all users. > Correct? Yes. In addition of the hugetlbfs setup, various apps requires to also increase fs.inotify.max_user_watches or file-max and other tweaks, this would be one of those tweaks. > This may be too simple, and I don't really like group access, but how about > just defining a uffd group? If you are in the group you can make uffd > system calls. Everything is possible, I'm just afraid it gets too complex. So you suggest to echo a gid into the file?
