Quoting Chris Wilson (2019-04-02 13:54:11) > Quoting Matthew Auld (2019-04-02 13:39:20) > > On Mon, 1 Apr 2019 at 14:39, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > If the user passes in a pointer to a GGTT mmaping of the same buffer > > > being written to, we can hit a deadlock in acquiring the shmemfs page > > > (once as the write destination and then as the read source). > > > > And also shmem_fault, so cpu mmaping? > > Possibly if I reorder the test to not deadlock on the mmap_gtt first :) > Let's find out! Very similar stack trace, as one would expect: [<0>] io_schedule+0xd/0x30 [<0>] __lock_page+0x105/0x1b0 [<0>] find_lock_entry+0x55/0x90 [<0>] shmem_getpage_gfp+0xba/0x7f0 [<0>] shmem_fault+0x5c/0x1d0 [<0>] __do_fault+0x2d/0x80 [<0>] __handle_mm_fault+0xabd/0xfa0 [<0>] handle_mm_fault+0xb8/0x1b0 [<0>] __do_page_fault+0x18f/0x3f0 [<0>] page_fault+0x1b/0x20 [<0>] copy_user_enhanced_fast_string+0x7/0x10 [<0>] _copy_from_user+0x37/0x60 [<0>] i915_gem_object_pwrite_gtt+0xf0/0x160 [i915] [<0>] i915_gem_pwrite_ioctl+0x145/0x4b0 [i915] [<0>] drm_ioctl_kernel+0x81/0xd0 [<0>] drm_ioctl+0x1a7/0x310 [<0>] do_vfs_ioctl+0x88/0x5d0 [<0>] ksys_ioctl+0x35/0x70 [<0>] __x64_sys_ioctl+0x11/0x20 [<0>] do_syscall_64+0x39/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 just ending shmem_fault as predicted. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
