On Thu, May 23, 2019 at 12:04:16PM -0700, John Hubbard wrote: > On 5/23/19 8:34 AM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxxxx> > > > > This patch series arised out of discussions with Jerome when looking at the > > ODP changes, particularly informed by use after free races we have already > > found and fixed in the ODP code (thanks to syzkaller) working with mmu > > notifiers, and the discussion with Ralph on how to resolve the lifetime model. > > > > Overall this brings in a simplified locking scheme and easy to explain > > lifetime model: > > > > If a hmm_range is valid, then the hmm is valid, if a hmm is valid then the mm > > is allocated memory. > > > > If the mm needs to still be alive (ie to lock the mmap_sem, find a vma, etc) > > then the mmget must be obtained via mmget_not_zero(). > > > > Locking of mm->hmm is shifted to use the mmap_sem consistently for all > > read/write and unlocked accesses are removed. > > > > The use unlocked reads on 'hmm->dead' are also eliminated in favour of using > > standard mmget() locking to prevent the mm from being released. Many of the > > debugging checks of !range->hmm and !hmm->mm are dropped in favour of poison - > > which is much clearer as to the lifetime intent. > > > > The trailing patches are just some random cleanups I noticed when reviewing > > this code. > > > > I expect Jerome & Ralph will have some design notes so this is just RFC, and > > it still needs a matching edit to nouveau. It is only compile tested. > > > > Thanks so much for doing this. Jerome has already absorbed these into his > hmm-5.3 branch, along with Ralph's other fixes, so we can start testing, > as well as reviewing, the whole set. We'll have feedback soon. Yes, I looked at Jerome's v2's and he found a few great fixups. My only dislike is re-introducing a READ_ONCE(mm->hmm) when a major point of this seris was to remove that use-after-free stuff. But Jerome says it is a temporary defect while he works out some cross tree API stuff. Jason
