On Wed, Apr 08, 2020 at 04:49:01PM -0700, Fenghua Yu wrote: > > > Isn't the idea of mmu_notifier is to avoid holding the mm reference and > > > rely on the notifier to tell us when mm is going away? > > > > The notifier only holds a mmgrab(), not a mmget() - this allows > > exit_mmap to proceed, but the mm_struct memory remains. > > > > This is also probably why it is a bad idea to tie the lifetime of > > something like a pasid to the mmdrop as a evil user could cause a > > large number of mm structs to be released but not freed, probably > > defeating cgroup limits and so forth (not sure) > > The max number of processes can be limited for a user. PASID is per > address space so the max number of PASID can be limited for the user. > So the user cannot exhaust PASID so easily, right? With the patch Jacob pointed to the PASID lifetime is tied to mmdrop, and I think (but did not check) that the cgroup accounting happens before mmdrop. > Binding the PASID to the mm and freeing the PASID in __mmdrop() can get > ride of the complexity. This is a much more reasonable explanation and should be in the patch commit instead of what is there. However, it still seems unnecessary to reach for arch code - the singleton notifier can be arranged to live until exit_mmap or fd release, whichever is longer by putting a mmu_notififer_put() in the release() method Jason
