Quoting Daniel Vetter (2017-12-11 17:20:32) > On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Teach lockdep to track the device's internal mmapping separately > > from the generic lockclass over all other inodes. Since this is device > > private we wish to allow a different locking hierarchy than is typified > > by the requirement for the mmap_rwsem being the outermost lock for > > handling pagefaults. By giving the internal mmap_rwsem a distinct > > lockclass, lockdep can identify it and learn/enforce its distinct locking > > requirements. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > I think both the commit message and comment are a bit too fluffy - the > critical bit is that we're biting ourselves on gtt mmaps from > usersptr, and that's explicitly not allowed exactly because it would > deadlock. > > I'm also not sure it's a good idea to implement this in generic code, > since this is a very i915 specific issue, and other drivers (who might > be a lot less sloppy here) will now no longer get reports about this > deadlock. I was thinking that in a more general sense manipulating of the vma_manager's inode is independent of the processes's mappings. As such we do not want to tie the two together and force them to conform to the same rules, because the core mapping semaphore will be held on entry to driver code, but the internal mapping will be used from within driver code. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
