Re: [Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
On Tue, 02 Sep 2014, Daniel Vetter dan...@ffwll.ch wrote: Queued for -next, thanks for the patch. Aside: Is there other userptr stuff outstanding? I've definitely lost track of them :( Picked up for drm-intel-fixes instead. Thanks. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task-mm,
calling mmput() may trigger exit_mmap() which close the vma
which will call drm_gem_vm_close() and attempt to reacquire
the struct_mutex. In order to avoid that recursion, we have
to defer the mmput() until after we drop the struct_mutex,
i.e. we need to schedule a worker to do the clean up. A further issue
spotted by Tvrtko was caused when we took a GTT mmapping of a userptr
buffer object. In that case, we would never call mmput as the object
would be cyclically referenced by the GTT mmapping and not freed upon
process exit - keeping the entire process mm alive after the process
task was reaped. The fix employed is to replace the mm_users/mmput()
reference handling to mm_count/mmdrop() for the shared i915_mm_struct.
INFO: task test_surfaces:1632 blocked for more than 120 seconds.
Tainted: GF O 3.14.5+ #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
test_surfaces D 0 1632 1590 0x0082
88014914baa8 0046 88014914a010
00012c40 00012c40 8800a0058210 88014784b010
88014914a010 880037b1c820 8800a0058210 880037b1c824
Call Trace:
[81582499] schedule+0x29/0x70
[815825fe] schedule_preempt_disabled+0xe/0x10
[81583b93] __mutex_lock_slowpath+0x183/0x220
[81583c53] mutex_lock+0x23/0x40
[a005c2a3] drm_gem_vm_close+0x33/0x70 [drm]
[8115a483] remove_vma+0x33/0x70
[8115a5dc] exit_mmap+0x11c/0x170
[8104d6eb] mmput+0x6b/0x100
[a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915]
[a00e6706] i915_gem_free_object+0x126/0x250 [i915]
[a005c06a] drm_gem_object_free+0x2a/0x40 [drm]
[a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120
[drm]
[a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm]
[8127ffeb] idr_for_each+0xab/0x100
[a005cc70] ?
drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm]
[81583c46] ? mutex_lock+0x16/0x40
[a005c354] drm_gem_release+0x24/0x40 [drm]
[a005b82b] drm_release+0x3fb/0x480 [drm]
[8118d482] __fput+0xb2/0x260
[8118d6de] fput+0xe/0x10
[8106f27f] task_work_run+0x8f/0xf0
[81052228] do_exit+0x1a8/0x480
[81052551] do_group_exit+0x51/0xc0
[810525d7] SyS_exit_group+0x17/0x20
[8158e092] system_call_fastpath+0x16/0x1b
v2: Incorporate feedback from Tvrtko and remove the unnessary mm
referencing when creating the i915_mm_struct and improve some of the
function names and comments.
Reported-by: Jacek Danecki jacek.dane...@intel.com
Test-case: igt/gem_userptr_blits/process-exit*
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: Gong, Zhipeng zhipeng.g...@intel.com
Cc: Jacek Danecki jacek.dane...@intel.com
Cc: Ursulin, Tvrtko tvrtko.ursu...@intel.com
Reviewed-by: Ursulin, Tvrtko tvrtko.ursu...@intel.com
Tested-by: Wang, Wendy wendy.w...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 12 +-
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 412 ++--
3 files changed, 238 insertions(+), 193 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4aa540348f24..a9d28b7c64ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -189,6 +189,7 @@ enum hpd_pin {
if ((1 (domain)) (mask))
struct drm_i915_private;
+struct i915_mm_struct;
struct i915_mmu_object;
struct i915_gem_request;
@@ -1545,9 +1546,8 @@ struct drm_i915_private {
struct i915_gtt gtt; /* VM representing the global address space */
struct i915_gem_mm mm;
-#if defined(CONFIG_MMU_NOTIFIER)
- DECLARE_HASHTABLE(mmu_notifiers, 7);
-#endif
+ DECLARE_HASHTABLE(mm_structs, 7);
+ struct mutex mm_lock;
/* Kernel Modesetting */
@@ -1852,8 +1852,8 @@ struct drm_i915_gem_object {
unsigned workers :4;
#define I915_GEM_USERPTR_MAX_WORKERS 15
- struct mm_struct *mm;
- struct i915_mmu_object *mn;
+ struct i915_mm_struct *mm;
+ struct i915_mmu_object *mmu_object;
struct work_struct *work;
} userptr;
};
@@ -2269,7 +2269,7 @@ int i915_gem_set_tiling(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
int i915_gem_get_tiling(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int i915_gem_init_userptr(struct drm_device *dev);
+void i915_gem_init_userptr(struct drm_device *dev);
int
Re: [Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote: On 08/07/2014 02:20 PM, Chris Wilson wrote: During release of the GEM object we hold the struct_mutex. As the object may be holding onto the last reference for the task-mm, calling mmput() may trigger exit_mmap() which close the vma which will call drm_gem_vm_close() and attempt to reacquire the struct_mutex. In order to avoid that recursion, we have to defer the mmput() until after we drop the struct_mutex, i.e. we need to schedule a worker to do the clean up. A further issue spotted by Tvrtko was caused when we took a GTT mmapping of a userptr buffer object. In that case, we would never call mmput as the object would be cyclically referenced by the GTT mmapping and not freed upon process exit - keeping the entire process mm alive after the process task was reaped. The fix employed is to replace the mm_users/mmput() reference handling to mm_count/mmdrop() for the shared i915_mm_struct. INFO: task test_surfaces:1632 blocked for more than 120 seconds. Tainted: GF O 3.14.5+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. test_surfaces D 0 1632 1590 0x0082 88014914baa8 0046 88014914a010 00012c40 00012c40 8800a0058210 88014784b010 88014914a010 880037b1c820 8800a0058210 880037b1c824 Call Trace: [81582499] schedule+0x29/0x70 [815825fe] schedule_preempt_disabled+0xe/0x10 [81583b93] __mutex_lock_slowpath+0x183/0x220 [81583c53] mutex_lock+0x23/0x40 [a005c2a3] drm_gem_vm_close+0x33/0x70 [drm] [8115a483] remove_vma+0x33/0x70 [8115a5dc] exit_mmap+0x11c/0x170 [8104d6eb] mmput+0x6b/0x100 [a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915] [a00e6706] i915_gem_free_object+0x126/0x250 [i915] [a005c06a] drm_gem_object_free+0x2a/0x40 [drm] [a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm] [a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm] [8127ffeb] idr_for_each+0xab/0x100 [a005cc70] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm] [81583c46] ? mutex_lock+0x16/0x40 [a005c354] drm_gem_release+0x24/0x40 [drm] [a005b82b] drm_release+0x3fb/0x480 [drm] [8118d482] __fput+0xb2/0x260 [8118d6de] fput+0xe/0x10 [8106f27f] task_work_run+0x8f/0xf0 [81052228] do_exit+0x1a8/0x480 [81052551] do_group_exit+0x51/0xc0 [810525d7] SyS_exit_group+0x17/0x20 [8158e092] system_call_fastpath+0x16/0x1b v2: Incorporate feedback from Tvrtko and remove the unnessary mm referencing when creating the i915_mm_struct and improve some of the function names and comments. [snip] I reviewed this some weeks back and did not spot any issues. Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Queued for -next, thanks for the patch. Aside: Is there other userptr stuff outstanding? I've definitely lost track of them :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
On Tue, Sep 02, 2014 at 11:35:00AM +0200, Daniel Vetter wrote: On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote: On 08/07/2014 02:20 PM, Chris Wilson wrote: During release of the GEM object we hold the struct_mutex. As the object may be holding onto the last reference for the task-mm, calling mmput() may trigger exit_mmap() which close the vma which will call drm_gem_vm_close() and attempt to reacquire the struct_mutex. In order to avoid that recursion, we have to defer the mmput() until after we drop the struct_mutex, i.e. we need to schedule a worker to do the clean up. A further issue spotted by Tvrtko was caused when we took a GTT mmapping of a userptr buffer object. In that case, we would never call mmput as the object would be cyclically referenced by the GTT mmapping and not freed upon process exit - keeping the entire process mm alive after the process task was reaped. The fix employed is to replace the mm_users/mmput() reference handling to mm_count/mmdrop() for the shared i915_mm_struct. INFO: task test_surfaces:1632 blocked for more than 120 seconds. Tainted: GF O 3.14.5+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. test_surfaces D 0 1632 1590 0x0082 88014914baa8 0046 88014914a010 00012c40 00012c40 8800a0058210 88014784b010 88014914a010 880037b1c820 8800a0058210 880037b1c824 Call Trace: [81582499] schedule+0x29/0x70 [815825fe] schedule_preempt_disabled+0xe/0x10 [81583b93] __mutex_lock_slowpath+0x183/0x220 [81583c53] mutex_lock+0x23/0x40 [a005c2a3] drm_gem_vm_close+0x33/0x70 [drm] [8115a483] remove_vma+0x33/0x70 [8115a5dc] exit_mmap+0x11c/0x170 [8104d6eb] mmput+0x6b/0x100 [a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915] [a00e6706] i915_gem_free_object+0x126/0x250 [i915] [a005c06a] drm_gem_object_free+0x2a/0x40 [drm] [a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm] [a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm] [8127ffeb] idr_for_each+0xab/0x100 [a005cc70] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm] [81583c46] ? mutex_lock+0x16/0x40 [a005c354] drm_gem_release+0x24/0x40 [drm] [a005b82b] drm_release+0x3fb/0x480 [drm] [8118d482] __fput+0xb2/0x260 [8118d6de] fput+0xe/0x10 [8106f27f] task_work_run+0x8f/0xf0 [81052228] do_exit+0x1a8/0x480 [81052551] do_group_exit+0x51/0xc0 [810525d7] SyS_exit_group+0x17/0x20 [8158e092] system_call_fastpath+0x16/0x1b v2: Incorporate feedback from Tvrtko and remove the unnessary mm referencing when creating the i915_mm_struct and improve some of the function names and comments. [snip] I reviewed this some weeks back and did not spot any issues. Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Queued for -next, thanks for the patch. Aside: Is there other userptr stuff outstanding? I've definitely lost track of them :( The one I posted with the extra r-b and t-b has a minor tweak to kill the unused error code during init. but otherwise this is the last outstanding patch. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Sep 02, 2014 at 11:35:00AM +0200, Daniel Vetter wrote: On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote: On 08/07/2014 02:20 PM, Chris Wilson wrote: During release of the GEM object we hold the struct_mutex. As the object may be holding onto the last reference for the task-mm, calling mmput() may trigger exit_mmap() which close the vma which will call drm_gem_vm_close() and attempt to reacquire the struct_mutex. In order to avoid that recursion, we have to defer the mmput() until after we drop the struct_mutex, i.e. we need to schedule a worker to do the clean up. A further issue spotted by Tvrtko was caused when we took a GTT mmapping of a userptr buffer object. In that case, we would never call mmput as the object would be cyclically referenced by the GTT mmapping and not freed upon process exit - keeping the entire process mm alive after the process task was reaped. The fix employed is to replace the mm_users/mmput() reference handling to mm_count/mmdrop() for the shared i915_mm_struct. INFO: task test_surfaces:1632 blocked for more than 120 seconds. Tainted: GF O 3.14.5+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. test_surfaces D 0 1632 1590 0x0082 88014914baa8 0046 88014914a010 00012c40 00012c40 8800a0058210 88014784b010 88014914a010 880037b1c820 8800a0058210 880037b1c824 Call Trace: [81582499] schedule+0x29/0x70 [815825fe] schedule_preempt_disabled+0xe/0x10 [81583b93] __mutex_lock_slowpath+0x183/0x220 [81583c53] mutex_lock+0x23/0x40 [a005c2a3] drm_gem_vm_close+0x33/0x70 [drm] [8115a483] remove_vma+0x33/0x70 [8115a5dc] exit_mmap+0x11c/0x170 [8104d6eb] mmput+0x6b/0x100 [a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915] [a00e6706] i915_gem_free_object+0x126/0x250 [i915] [a005c06a] drm_gem_object_free+0x2a/0x40 [drm] [a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm] [a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm] [8127ffeb] idr_for_each+0xab/0x100 [a005cc70] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm] [81583c46] ? mutex_lock+0x16/0x40 [a005c354] drm_gem_release+0x24/0x40 [drm] [a005b82b] drm_release+0x3fb/0x480 [drm] [8118d482] __fput+0xb2/0x260 [8118d6de] fput+0xe/0x10 [8106f27f] task_work_run+0x8f/0xf0 [81052228] do_exit+0x1a8/0x480 [81052551] do_group_exit+0x51/0xc0 [810525d7] SyS_exit_group+0x17/0x20 [8158e092] system_call_fastpath+0x16/0x1b v2: Incorporate feedback from Tvrtko and remove the unnessary mm referencing when creating the i915_mm_struct and improve some of the function names and comments. [snip] I reviewed this some weeks back and did not spot any issues. Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Queued for -next, thanks for the patch. Aside: Is there other userptr stuff outstanding? I've definitely lost track of them :( The one I posted with the extra r-b and t-b has a minor tweak to kill the unused error code during init. but otherwise this is the last outstanding patch. This was referenced from [1], do we need a stable backport? BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=80745 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
On 08/07/2014 02:20 PM, Chris Wilson wrote: During release of the GEM object we hold the struct_mutex. As the object may be holding onto the last reference for the task-mm, calling mmput() may trigger exit_mmap() which close the vma which will call drm_gem_vm_close() and attempt to reacquire the struct_mutex. In order to avoid that recursion, we have to defer the mmput() until after we drop the struct_mutex, i.e. we need to schedule a worker to do the clean up. A further issue spotted by Tvrtko was caused when we took a GTT mmapping of a userptr buffer object. In that case, we would never call mmput as the object would be cyclically referenced by the GTT mmapping and not freed upon process exit - keeping the entire process mm alive after the process task was reaped. The fix employed is to replace the mm_users/mmput() reference handling to mm_count/mmdrop() for the shared i915_mm_struct. INFO: task test_surfaces:1632 blocked for more than 120 seconds. Tainted: GF O 3.14.5+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. test_surfaces D 0 1632 1590 0x0082 88014914baa8 0046 88014914a010 00012c40 00012c40 8800a0058210 88014784b010 88014914a010 880037b1c820 8800a0058210 880037b1c824 Call Trace: [81582499] schedule+0x29/0x70 [815825fe] schedule_preempt_disabled+0xe/0x10 [81583b93] __mutex_lock_slowpath+0x183/0x220 [81583c53] mutex_lock+0x23/0x40 [a005c2a3] drm_gem_vm_close+0x33/0x70 [drm] [8115a483] remove_vma+0x33/0x70 [8115a5dc] exit_mmap+0x11c/0x170 [8104d6eb] mmput+0x6b/0x100 [a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915] [a00e6706] i915_gem_free_object+0x126/0x250 [i915] [a005c06a] drm_gem_object_free+0x2a/0x40 [drm] [a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm] [a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm] [8127ffeb] idr_for_each+0xab/0x100 [a005cc70] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm] [81583c46] ? mutex_lock+0x16/0x40 [a005c354] drm_gem_release+0x24/0x40 [drm] [a005b82b] drm_release+0x3fb/0x480 [drm] [8118d482] __fput+0xb2/0x260 [8118d6de] fput+0xe/0x10 [8106f27f] task_work_run+0x8f/0xf0 [81052228] do_exit+0x1a8/0x480 [81052551] do_group_exit+0x51/0xc0 [810525d7] SyS_exit_group+0x17/0x20 [8158e092] system_call_fastpath+0x16/0x1b v2: Incorporate feedback from Tvrtko and remove the unnessary mm referencing when creating the i915_mm_struct and improve some of the function names and comments. [snip] I reviewed this some weeks back and did not spot any issues. Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Thanks, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prevent recursive deadlock on releasing a busy userptr
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task-mm,
calling mmput() may trigger exit_mmap() which close the vma
which will call drm_gem_vm_close() and attempt to reacquire
the struct_mutex. In order to avoid that recursion, we have
to defer the mmput() until after we drop the struct_mutex,
i.e. we need to schedule a worker to do the clean up. A further issue
spotted by Tvrtko was caused when we took a GTT mmapping of a userptr
buffer object. In that case, we would never call mmput as the object
would be cyclically referenced by the GTT mmapping and not freed upon
process exit - keeping the entire process mm alive after the process
task was reaped. The fix employed is to replace the mm_users/mmput()
reference handling to mm_count/mmdrop() for the shared i915_mm_struct.
INFO: task test_surfaces:1632 blocked for more than 120 seconds.
Tainted: GF O 3.14.5+ #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
test_surfaces D 0 1632 1590 0x0082
88014914baa8 0046 88014914a010
00012c40 00012c40 8800a0058210 88014784b010
88014914a010 880037b1c820 8800a0058210 880037b1c824
Call Trace:
[81582499] schedule+0x29/0x70
[815825fe] schedule_preempt_disabled+0xe/0x10
[81583b93] __mutex_lock_slowpath+0x183/0x220
[81583c53] mutex_lock+0x23/0x40
[a005c2a3] drm_gem_vm_close+0x33/0x70 [drm]
[8115a483] remove_vma+0x33/0x70
[8115a5dc] exit_mmap+0x11c/0x170
[8104d6eb] mmput+0x6b/0x100
[a00f44b9] i915_gem_userptr_release+0x89/0xc0 [i915]
[a00e6706] i915_gem_free_object+0x126/0x250 [i915]
[a005c06a] drm_gem_object_free+0x2a/0x40 [drm]
[a005cc32] drm_gem_object_handle_unreference_unlocked+0xe2/0x120
[drm]
[a005ccd4] drm_gem_object_release_handle+0x64/0x90 [drm]
[8127ffeb] idr_for_each+0xab/0x100
[a005cc70] ?
drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm]
[81583c46] ? mutex_lock+0x16/0x40
[a005c354] drm_gem_release+0x24/0x40 [drm]
[a005b82b] drm_release+0x3fb/0x480 [drm]
[8118d482] __fput+0xb2/0x260
[8118d6de] fput+0xe/0x10
[8106f27f] task_work_run+0x8f/0xf0
[81052228] do_exit+0x1a8/0x480
[81052551] do_group_exit+0x51/0xc0
[810525d7] SyS_exit_group+0x17/0x20
[8158e092] system_call_fastpath+0x16/0x1b
v2: Incorporate feedback from Tvrtko and remove the unnessary mm
referencing when creating the i915_mm_struct and improve some of the
function names and comments.
Reported-by: Jacek Danecki jacek.dane...@intel.com
Test-case: igt/gem_userptr_blits/process-exit*
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: Gong, Zhipeng zhipeng.g...@intel.com
Cc: Jacek Danecki jacek.dane...@intel.com
Cc: Ursulin, Tvrtko tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 409 ++--
2 files changed, 235 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1d29f5..299233e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -190,6 +190,7 @@ enum hpd_pin {
if ((1 (domain)) (mask))
struct drm_i915_private;
+struct i915_mm_struct;
struct i915_mmu_object;
enum intel_dpll_id {
@@ -1536,9 +1537,8 @@ struct drm_i915_private {
struct i915_gtt gtt; /* VM representing the global address space */
struct i915_gem_mm mm;
-#if defined(CONFIG_MMU_NOTIFIER)
- DECLARE_HASHTABLE(mmu_notifiers, 7);
-#endif
+ DECLARE_HASHTABLE(mm_structs, 7);
+ struct mutex mm_lock;
/* Kernel Modesetting */
@@ -1845,8 +1845,8 @@ struct drm_i915_gem_object {
unsigned workers :4;
#define I915_GEM_USERPTR_MAX_WORKERS 15
- struct mm_struct *mm;
- struct i915_mmu_object *mn;
+ struct i915_mm_struct *mm;
+ struct i915_mmu_object *mmu_object;
struct work_struct *work;
} userptr;
};
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index fe69fc8..d384139 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -32,6 +32,15 @@
#include linux/mempolicy.h
#include linux/swap.h
+struct i915_mm_struct {
+ struct mm_struct *mm;
+ struct drm_device *dev;
+ struct i915_mmu_notifier *mn;
+ struct hlist_node node;
+ struct kref kref;
+ struct work_struct work;
+};
+
#if
