Hi Chris, On Wednesday, February 19, 2020 1:17:12 PM CET Chris Wilson wrote: > Quoting Janusz Krzysztofik (2020-02-19 12:09:44) > > The purpose of userptr MMU notifier is to invalidate object pages as > > soon as someone unpins them from memory. While doing that, > > obj->mm.lock is acquired. If the notifier was called with obj->mm.lock > > already held, a lockdep loop would be triggered. That scenario is > > believed to be possible in several cases, one of which is when the > > userptr object is created from an mmap-offset mapping of another i915 > > GEM object. This patch tries to address this case. > > > > Even if creating a userptr object on an mmap-offset mapping succeeds, > > trying to pin pages of the mapping in memory always fails because of > > them having a VM_PFNMAP flag set. However, the notifier can be > > activated for a userptr object even before required pages are found > > already pinned in memory, as soon as a worker expected to get missing > > pages is scheduled successfully. If the worker then fails to collect > > the pages, it deactivates the notifier. However, a time window exists > > when the notifier can be called for an object even with no pages set > > yet. > > You mean something like > https://patchwork.freedesktop.org/patch/275514/?series=54869&rev=2 > to avoid lockdep cross-contamination. Yes, the purpose of both seems the same. How could I help to get your preferred one merged? Thanks, Janusz > -Chris > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
