[Intel-gfx] [PATCH] drm/i915: Prefault before locking pages in shmem_pwrite

[Chris Wilson]

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 at chris-wilson.co.uk> 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