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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
