On Thu, Jun 06, 2019 at 03:44:27PM -0300, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg@xxxxxxxxxxxx> > > For hmm.git: > > 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. > > This v2 incorporates alot of the good off list changes & feedback Jerome had, > and all the on-list comments too. However, now that we have the shared git I > have kept the one line change to nouveau_svm.c rather than the compat > funtions. > > I believe we can resolve this merge in the DRM tree now and keep the core > mm/hmm.c clean. DRM maintainers, please correct me if I'm wrong. > > It is on top of hmm.git, and I have a git tree of this series to ease testing > here: > > https://github.com/jgunthorpe/linux/tree/hmm > > There are still some open locking issues, as I think this remains unaddressed: > > https://lore.kernel.org/linux-mm/20190527195829.GB18019@xxxxxxxxxxxx/ > > I'm looking for some more acks, reviews and tests so this can move ahead to > hmm.git. AMD Folks, this is looking pretty good now, can you please give at least a Tested-by for the new driver code using this that I see in linux-next? Thanks, Jason _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
