How does linux kernel lockdep record lock-class dependency? - debugging

Question

I got a warning as below which is a AB-BA deadlock issue. But I don't understand how the 'existing dependency' happened.
It looks like: kvm_read_guest() held (&mm->mmap_sem), then reading userspace memory (which is not ready yet) caused page_fault() invoked, then in i915_gem_fault() it tries to hold lock class (&dev->struct_mutex) which only has one instance.
But this sequence must haven't happened. Otherwise, double-lock already happed, since intel_vgpu_create_workload() has held (&dev->struct_mutex) already:
(&dev->struct_mutex)->(&mm->mmap_sem)->(&dev->struct_mutex)
So how could lockdep find such 'existing dependency'?
Another question is '#0 (&mm->mmap_sem)' is held by __might_fault()->might_lock_read(). But might_lock_read() only temporarily accquire the lock. Then why there is a lock sequence "(&mm->mmap_sem)->(&dev->struct_mutex)"?
[ 113.934800] ======================================================
[ 113.940963] WARNING: possible circular locking dependency detected
[ 113.947131] 4.16.0-rc5+ #44 Tainted: G U
[ 113.952257] ------------------------------------------------------
[ 113.958424] qemu-system-x86/4298 is trying to acquire lock:
[ 113.963983] (&mm->mmap_sem){++++}, at: [<0000000052776050>] __might_fault+0x36/0x80
[ 113.971716]
but task is already holding lock:
[ 113.977542] (&dev->struct_mutex){+.+.}, at: [<000000002a25c66b>] intel_vgpu_create_workload+0x3d1/0x550 [i915]
[ 113.987643]
which lock already depends on the new lock.
[ 113.995801]
the existing dependency chain (in reverse order) is:
[ 114.003268]
-> #1 (&dev->struct_mutex){+.+.}:
[ 114.009113] i915_mutex_lock_interruptible+0x66/0x170 [i915]
[ 114.015301] i915_gem_fault+0x1d0/0x620 [i915]
[ 114.020273] __do_fault+0x19/0xed
[ 114.024108] __handle_mm_fault+0x9fa/0x1140
[ 114.028806] handle_mm_fault+0x1a7/0x390
[ 114.033240] __do_page_fault+0x286/0x530
[ 114.037677] page_fault+0x45/0x50
[ 114.041503]
-> #0 (&mm->mmap_sem){++++}:
[ 114.046901] __might_fault+0x60/0x80
[ 114.051008] __kvm_read_guest_page+0x3d/0x80 [kvm]
[ 114.056319] kvm_read_guest+0x47/0x80 [kvm]
[ 114.061024] kvmgt_rw_gpa+0x9d/0x110 [kvmgt]
[ 114.065833] copy_gma_to_hva+0x71/0x100 [i915]
[ 114.070818] intel_gvt_scan_and_shadow_ringbuffer+0xc4/0x210 [i915]
[ 114.077617] intel_gvt_scan_and_shadow_workload+0xc7/0x480 [i915]
[ 114.084240] intel_vgpu_create_workload+0x3d9/0x550 [i915]
[ 114.090258] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
[ 114.096190] elsp_mmio_write+0xcb/0x140 [i915]
[ 114.101170] intel_vgpu_mmio_reg_rw+0x250/0x4f0 [i915]
[ 114.106845] intel_vgpu_emulate_mmio_write+0xaa/0x240 [i915]
[ 114.113014] intel_vgpu_rw+0x200/0x250 [kvmgt]
[ 114.117972] intel_vgpu_write+0x164/0x1f0 [kvmgt]
[ 114.123188] __vfs_write+0x33/0x170
[ 114.127192] vfs_write+0xc5/0x1c0
[ 114.131022] SyS_pwrite64+0x90/0xb0
[ 114.135025] do_syscall_64+0x70/0x1c0
[ 114.139203] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 114.144765]
other info that might help us debug this:
[ 114.152754] Possible unsafe locking scenario:
[ 114.158664] CPU0 CPU1
[ 114.163185] ---- ----
[ 114.167714] lock(&dev->struct_mutex);
[ 114.171541] lock(&mm->mmap_sem);
[ 114.177449] lock(&dev->struct_mutex);
[ 114.183790] lock(&mm->mmap_sem);
[ 114.187186]
*** DEADLOCK ***
[ 114.193095] 3 locks held by qemu-system-x86/4298:
[ 114.197789] #0: (&gvt->lock){+.+.}, at: [<0000000087b40252>] intel_vgpu_emulate_mmio_write+0x64/0x240 [i915]
[ 114.207792] #1: (&dev->struct_mutex){+.+.}, at: [<000000002a25c66b>] intel_vgpu_create_workload+0x3d1/0x550 [i915]
[ 114.218314] #2: (&kvm->srcu){....}, at: [<00000000e49701e8>] kvmgt_rw_gpa+0x4c/0x110 [kvmgt]
[ 114.226913]
stack backtrace:
[ 114.231263] CPU: 0 PID: 4298 Comm: qemu-system-x86 Tainted: G U 4.16.0-rc5+ #44
[ 114.239771] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
[ 114.247155] Call Trace:
[ 114.249600] dump_stack+0x7c/0xbe
[ 114.252909] print_circular_bug.isra.33+0x21b/0x228
[ 114.257781] __lock_acquire+0xf7d/0x1470
[ 114.261698] ? lock_acquire+0xec/0x1e0
[ 114.265440] lock_acquire+0xec/0x1e0
[ 114.269008] ? __might_fault+0x36/0x80
[ 114.272749] __might_fault+0x60/0x80
[ 114.276317] ? __might_fault+0x36/0x80
[ 114.280066] __kvm_read_guest_page+0x3d/0x80 [kvm]
[ 114.284856] kvm_read_guest+0x47/0x80 [kvm]
[ 114.289042] kvmgt_rw_gpa+0x9d/0x110 [kvmgt]
[ 114.293333] copy_gma_to_hva+0x71/0x100 [i915]
[ 114.297797] intel_gvt_scan_and_shadow_ringbuffer+0xc4/0x210 [i915]
[ 114.304091] intel_gvt_scan_and_shadow_workload+0xc7/0x480 [i915]
[ 114.310206] intel_vgpu_create_workload+0x3d9/0x550 [i915]
[ 114.315709] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
[ 114.321140] elsp_mmio_write+0xcb/0x140 [i915]
[ 114.325596] intel_vgpu_mmio_reg_rw+0x250/0x4f0 [i915]
[ 114.330746] intel_vgpu_emulate_mmio_write+0xaa/0x240 [i915]
[ 114.336396] intel_vgpu_rw+0x200/0x250 [kvmgt]
[ 114.340833] intel_vgpu_write+0x164/0x1f0 [kvmgt]
[ 114.345533] __vfs_write+0x33/0x170
[ 114.349016] ? common_file_perm+0x68/0x250
[ 114.353104] ? security_file_permission+0x36/0xb0
[ 114.357803] vfs_write+0xc5/0x1c0
[ 114.361113] SyS_pwrite64+0x90/0xb0
[ 114.364597] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 114.369293] do_syscall_64+0x70/0x1c0
[ 114.372950] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 114.377994] RIP: 0033:0x7f0ca8a29da3
[ 114.381562] RSP: 002b:00007f0c98dc96c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000012
[ 114.389121] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ca8a29da3
[ 114.396240] RDX: 0000000000000004 RSI: 00007f0c98dc96f0 RDI: 0000000000000019
[ 114.403362] RBP: 00007f0c98dc9710 R08: 0000000000000004 R09: 00000000ffffffff
[ 114.410484] R10: 0000000000002230 R11: 0000000000000293 R12: 0000000000000000
[ 114.417605] R13: 00007ffdd628d02f R14: 00007f0c98dca9c0 R15: 0000000000000000
in function intel_vgpu_create_workload:
mutex_lock(&dev_priv->drm.struct_mutex);
ret = intel_gvt_scan_and_shadow_workload(workload);
mutex_unlock(&dev_priv->drm.struct_mutex);