Re: [PATCH v6 07/19] kernel/user: Allow user::locked_vm to be usable for iommufd

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 29, 2022 at 03:42:23PM -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 29, 2022 at 04:29:30PM -0400, Jason Gunthorpe wrote:
> > Following the pattern of io_uring, perf, skb, and bpf, iommfd will use
> > user->locked_vm for accounting pinned pages. Ensure the value is included
> > in the struct and export free_uid() as iommufd is modular.
> > 
> > user->locked_vm is the good accounting to use for ulimit because it is
> > per-user, and the security sandboxing of locked pages is not supposed to
> > be per-process. Other places (vfio, vdpa and infiniband) have used
> > mm->pinned_vm and/or mm->locked_vm for accounting pinned pages, but this
> > is only per-process and inconsistent with the new FOLL_LONGTERM users in
> > the kernel.
> > 
> > Concurrent work is underway to try to put this in a cgroup, so everything
> > can be consistent and the kernel can provide a FOLL_LONGTERM limit that
> > actually provides security.
> > 
> > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > Tested-by: Yi Liu <yi.l.liu@intel.com>
> > Tested-by: Lixiao Yang <lixiao.yang@intel.com>
> > Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
> > Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> > Reviewed-by: Eric Auger <eric.auger@redhat.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> 
> Just curious: why does the subject say "user::locked_vm"? As opposed to
> user->locked_vm? Made me think it's somehow related to rust in kernel or
> whatever.

:: is the C++ way to say "member of a type", I suppose it is a typo
and should be user_struct::locked_vm

The use of -> otherwise was to have some clarity about mm vs user
structs.

Jason