[PATCH 1/3] dma_resv: prime lockdep annotations

[PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.

Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.

Solution is to spawn a worker (but only once). It's horrible, but it
works.

v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.

v4: Annotate with __init (Rob Herring)

Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 	kfree_rcu(list, rcu);
 }
 
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+	struct mm_struct *mm = mm_alloc();
+	struct dma_resv obj;
+
+	if (!mm)
+		return;
+
+	dma_resv_init(&obj);
+
+	down_read(&mm->mmap_sem);
+	ww_mutex_lock(&obj.lock, NULL);
+	fs_reclaim_acquire(GFP_KERNEL);
+	fs_reclaim_release(GFP_KERNEL);
+	ww_mutex_unlock(&obj.lock);
+	up_read(&mm->mmap_sem);
+	
+	mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
 /**
  * dma_resv_init - initialize a reservation object
  * @obj: the reservation object
-- 
2.24.0.rc2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.

Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.

Solution is to spawn a worker (but only once). It's horrible, but it
works.

v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.

v4: Annotate with __init (Rob Herring)

Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 	kfree_rcu(list, rcu);
 }
 
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+	struct mm_struct *mm = mm_alloc();
+	struct dma_resv obj;
+
+	if (!mm)
+		return;
+
+	dma_resv_init(&obj);
+
+	down_read(&mm->mmap_sem);
+	ww_mutex_lock(&obj.lock, NULL);
+	fs_reclaim_acquire(GFP_KERNEL);
+	fs_reclaim_release(GFP_KERNEL);
+	ww_mutex_unlock(&obj.lock);
+	up_read(&mm->mmap_sem);
+	
+	mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
 /**
  * dma_resv_init - initialize a reservation object
  * @obj: the reservation object
-- 
2.24.0.rc2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.

Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.

Solution is to spawn a worker (but only once). It's horrible, but it
works.

v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.

v4: Annotate with __init (Rob Herring)

Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 	kfree_rcu(list, rcu);
 }
 
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+	struct mm_struct *mm = mm_alloc();
+	struct dma_resv obj;
+
+	if (!mm)
+		return;
+
+	dma_resv_init(&obj);
+
+	down_read(&mm->mmap_sem);
+	ww_mutex_lock(&obj.lock, NULL);
+	fs_reclaim_acquire(GFP_KERNEL);
+	fs_reclaim_release(GFP_KERNEL);
+	ww_mutex_unlock(&obj.lock);
+	up_read(&mm->mmap_sem);
+	
+	mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
 /**
  * dma_resv_init - initialize a reservation object
  * @obj: the reservation object
-- 
2.24.0.rc2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.

Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.

Aside from "it compiles" entirely untested unfortunately.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1324c19f4e5c..05ec8edd6a8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
 
 static int
 validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
-	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
-	      uint64_t user_pbbo_ptr)
+	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
 {
 	struct nouveau_drm *drm = chan->drm;
-	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
-				(void __force __user *)(uintptr_t)user_pbbo_ptr;
 	struct nouveau_bo *nvbo;
 	int ret, relocs = 0;
 
@@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
 			b->presumed.offset = nvbo->bo.offset;
 			b->presumed.valid = 0;
 			relocs++;
-
-			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
-					     &b->presumed, sizeof(b->presumed)))
-				return -EFAULT;
 		}
 	}
 
@@ -547,8 +540,8 @@ static int
 nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 			     struct drm_file *file_priv,
 			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
-			     uint64_t user_buffers, int nr_buffers,
-			     struct validate_op *op, int *apply_relocs)
+			     int nr_buffers,
+			     struct validate_op *op, bool *apply_relocs)
 {
 	struct nouveau_cli *cli = nouveau_cli(file_priv);
 	int ret;
@@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 		return ret;
 	}
 
-	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
+	ret = validate_list(chan, cli, &op->list, pbbo);
 	if (unlikely(ret < 0)) {
 		if (ret != -ERESTARTSYS)
 			NV_PRINTK(err, cli, "validating bo list\n");
@@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
 static int
 nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
 				struct drm_nouveau_gem_pushbuf *req,
+				struct drm_nouveau_gem_pushbuf_reloc *reloc,
 				struct drm_nouveau_gem_pushbuf_bo *bo)
 {
-	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	int ret = 0;
 	unsigned i;
 
-	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
-	if (IS_ERR(reloc))
-		return PTR_ERR(reloc);
-
 	for (i = 0; i < req->nr_relocs; i++) {
 		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
 		struct drm_nouveau_gem_pushbuf_bo *b;
@@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	struct nouveau_drm *drm = nouveau_drm(dev);
 	struct drm_nouveau_gem_pushbuf *req = data;
 	struct drm_nouveau_gem_pushbuf_push *push;
+	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	struct drm_nouveau_gem_pushbuf_bo *bo;
 	struct nouveau_channel *chan = NULL;
 	struct validate_op op;
 	struct nouveau_fence *fence = NULL;
-	int i, j, ret = 0, do_reloc = 0;
+	int i, j, ret = 0;
+	bool do_reloc = false;
 
 	if (unlikely(!abi16))
 		return -ENOMEM;
@@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	}
 
 	/* Validate buffer list */
-	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
+revalidate:
+	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
 					   req->nr_buffers, &op, &do_reloc);
 	if (ret) {
 		if (ret != -ERESTARTSYS)
@@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 
 	/* Apply any relocations that are required */
 	if (do_reloc) {
-		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
+		if (!reloc) {
+			validate_fini(&op, chan, NULL, bo);
+			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
+			if (IS_ERR(reloc)) {
+				ret = PTR_ERR(reloc);
+				goto out_prevalid;
+			}
+
+			goto revalidate;
+		}
+
+		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
 		if (ret) {
 			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
 			goto out;
@@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	validate_fini(&op, chan, fence, bo);
 	nouveau_fence_unref(&fence);
 
+	if (do_reloc) {
+		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
+			u64_to_user_ptr(req->buffers);
+
+		for (i = 0; i < req->nr_buffers; i++) {
+			if (bo[i].presumed.valid)
+				continue;
+
+			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
+					 sizeof(bo[i].presumed))) {
+				ret = -EFAULT;
+				break;
+			}
+		}
+		u_free(reloc);
+	}
 out_prevalid:
 	u_free(bo);
 	u_free(push);
-- 
2.24.0.rc2

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.

Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.

Aside from "it compiles" entirely untested unfortunately.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1324c19f4e5c..05ec8edd6a8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
 
 static int
 validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
-	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
-	      uint64_t user_pbbo_ptr)
+	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
 {
 	struct nouveau_drm *drm = chan->drm;
-	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
-				(void __force __user *)(uintptr_t)user_pbbo_ptr;
 	struct nouveau_bo *nvbo;
 	int ret, relocs = 0;
 
@@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
 			b->presumed.offset = nvbo->bo.offset;
 			b->presumed.valid = 0;
 			relocs++;
-
-			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
-					     &b->presumed, sizeof(b->presumed)))
-				return -EFAULT;
 		}
 	}
 
@@ -547,8 +540,8 @@ static int
 nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 			     struct drm_file *file_priv,
 			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
-			     uint64_t user_buffers, int nr_buffers,
-			     struct validate_op *op, int *apply_relocs)
+			     int nr_buffers,
+			     struct validate_op *op, bool *apply_relocs)
 {
 	struct nouveau_cli *cli = nouveau_cli(file_priv);
 	int ret;
@@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 		return ret;
 	}
 
-	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
+	ret = validate_list(chan, cli, &op->list, pbbo);
 	if (unlikely(ret < 0)) {
 		if (ret != -ERESTARTSYS)
 			NV_PRINTK(err, cli, "validating bo list\n");
@@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
 static int
 nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
 				struct drm_nouveau_gem_pushbuf *req,
+				struct drm_nouveau_gem_pushbuf_reloc *reloc,
 				struct drm_nouveau_gem_pushbuf_bo *bo)
 {
-	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	int ret = 0;
 	unsigned i;
 
-	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
-	if (IS_ERR(reloc))
-		return PTR_ERR(reloc);
-
 	for (i = 0; i < req->nr_relocs; i++) {
 		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
 		struct drm_nouveau_gem_pushbuf_bo *b;
@@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	struct nouveau_drm *drm = nouveau_drm(dev);
 	struct drm_nouveau_gem_pushbuf *req = data;
 	struct drm_nouveau_gem_pushbuf_push *push;
+	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	struct drm_nouveau_gem_pushbuf_bo *bo;
 	struct nouveau_channel *chan = NULL;
 	struct validate_op op;
 	struct nouveau_fence *fence = NULL;
-	int i, j, ret = 0, do_reloc = 0;
+	int i, j, ret = 0;
+	bool do_reloc = false;
 
 	if (unlikely(!abi16))
 		return -ENOMEM;
@@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	}
 
 	/* Validate buffer list */
-	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
+revalidate:
+	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
 					   req->nr_buffers, &op, &do_reloc);
 	if (ret) {
 		if (ret != -ERESTARTSYS)
@@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 
 	/* Apply any relocations that are required */
 	if (do_reloc) {
-		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
+		if (!reloc) {
+			validate_fini(&op, chan, NULL, bo);
+			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
+			if (IS_ERR(reloc)) {
+				ret = PTR_ERR(reloc);
+				goto out_prevalid;
+			}
+
+			goto revalidate;
+		}
+
+		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
 		if (ret) {
 			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
 			goto out;
@@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	validate_fini(&op, chan, fence, bo);
 	nouveau_fence_unref(&fence);
 
+	if (do_reloc) {
+		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
+			u64_to_user_ptr(req->buffers);
+
+		for (i = 0; i < req->nr_buffers; i++) {
+			if (bo[i].presumed.valid)
+				continue;
+
+			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
+					 sizeof(bo[i].presumed))) {
+				ret = -EFAULT;
+				break;
+			}
+		}
+		u_free(reloc);
+	}
 out_prevalid:
 	u_free(bo);
 	u_free(push);
-- 
2.24.0.rc2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.

Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.

Aside from "it compiles" entirely untested unfortunately.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1324c19f4e5c..05ec8edd6a8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
 
 static int
 validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
-	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
-	      uint64_t user_pbbo_ptr)
+	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
 {
 	struct nouveau_drm *drm = chan->drm;
-	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
-				(void __force __user *)(uintptr_t)user_pbbo_ptr;
 	struct nouveau_bo *nvbo;
 	int ret, relocs = 0;
 
@@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
 			b->presumed.offset = nvbo->bo.offset;
 			b->presumed.valid = 0;
 			relocs++;
-
-			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
-					     &b->presumed, sizeof(b->presumed)))
-				return -EFAULT;
 		}
 	}
 
@@ -547,8 +540,8 @@ static int
 nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 			     struct drm_file *file_priv,
 			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
-			     uint64_t user_buffers, int nr_buffers,
-			     struct validate_op *op, int *apply_relocs)
+			     int nr_buffers,
+			     struct validate_op *op, bool *apply_relocs)
 {
 	struct nouveau_cli *cli = nouveau_cli(file_priv);
 	int ret;
@@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 		return ret;
 	}
 
-	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
+	ret = validate_list(chan, cli, &op->list, pbbo);
 	if (unlikely(ret < 0)) {
 		if (ret != -ERESTARTSYS)
 			NV_PRINTK(err, cli, "validating bo list\n");
@@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
 static int
 nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
 				struct drm_nouveau_gem_pushbuf *req,
+				struct drm_nouveau_gem_pushbuf_reloc *reloc,
 				struct drm_nouveau_gem_pushbuf_bo *bo)
 {
-	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	int ret = 0;
 	unsigned i;
 
-	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
-	if (IS_ERR(reloc))
-		return PTR_ERR(reloc);
-
 	for (i = 0; i < req->nr_relocs; i++) {
 		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
 		struct drm_nouveau_gem_pushbuf_bo *b;
@@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	struct nouveau_drm *drm = nouveau_drm(dev);
 	struct drm_nouveau_gem_pushbuf *req = data;
 	struct drm_nouveau_gem_pushbuf_push *push;
+	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
 	struct drm_nouveau_gem_pushbuf_bo *bo;
 	struct nouveau_channel *chan = NULL;
 	struct validate_op op;
 	struct nouveau_fence *fence = NULL;
-	int i, j, ret = 0, do_reloc = 0;
+	int i, j, ret = 0;
+	bool do_reloc = false;
 
 	if (unlikely(!abi16))
 		return -ENOMEM;
@@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	}
 
 	/* Validate buffer list */
-	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
+revalidate:
+	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
 					   req->nr_buffers, &op, &do_reloc);
 	if (ret) {
 		if (ret != -ERESTARTSYS)
@@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 
 	/* Apply any relocations that are required */
 	if (do_reloc) {
-		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
+		if (!reloc) {
+			validate_fini(&op, chan, NULL, bo);
+			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
+			if (IS_ERR(reloc)) {
+				ret = PTR_ERR(reloc);
+				goto out_prevalid;
+			}
+
+			goto revalidate;
+		}
+
+		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
 		if (ret) {
 			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
 			goto out;
@@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
 	validate_fini(&op, chan, fence, bo);
 	nouveau_fence_unref(&fence);
 
+	if (do_reloc) {
+		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
+			u64_to_user_ptr(req->buffers);
+
+		for (i = 0; i < req->nr_buffers; i++) {
+			if (bo[i].presumed.valid)
+				continue;
+
+			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
+					 sizeof(bo[i].presumed))) {
+				ret = -EFAULT;
+				break;
+			}
+		}
+		u_free(reloc);
+	}
 out_prevalid:
 	u_free(bo);
 	u_free(push);
-- 
2.24.0.rc2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

[Daniel Vetter]

With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.

Assuming I didn't screw up anything with my audit of course.

v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)

v3: Rebase over fault handler helperification.

Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c      | 36 -------------------------------
 drivers/gpu/drm/ttm/ttm_bo_util.c |  1 -
 drivers/gpu/drm/ttm/ttm_bo_vm.c   | 18 +++++-----------
 include/drm/ttm/ttm_bo_api.h      |  4 ----
 4 files changed, 5 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8d91b0428af1..5df596fb0280 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -161,7 +161,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
 	dma_fence_put(bo->moving);
 	if (!ttm_bo_uses_embedded_gem_object(bo))
 		dma_resv_fini(&bo->base._resv);
-	mutex_destroy(&bo->wu_mutex);
 	bo->destroy(bo);
 	ttm_mem_global_free(&ttm_mem_glob, acc_size);
 }
@@ -1299,7 +1298,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
 	INIT_LIST_HEAD(&bo->ddestroy);
 	INIT_LIST_HEAD(&bo->swap);
 	INIT_LIST_HEAD(&bo->io_reserve_lru);
-	mutex_init(&bo->wu_mutex);
 	bo->bdev = bdev;
 	bo->type = type;
 	bo->num_pages = num_pages;
@@ -1903,37 +1901,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
 	while (ttm_bo_swapout(&ttm_bo_glob, &ctx) == 0);
 }
 EXPORT_SYMBOL(ttm_bo_swapout_all);
-
-/**
- * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
- * unreserved
- *
- * @bo: Pointer to buffer
- */
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
-{
-	int ret;
-
-	/*
-	 * In the absense of a wait_unlocked API,
-	 * Use the bo::wu_mutex to avoid triggering livelocks due to
-	 * concurrent use of this function. Note that this use of
-	 * bo::wu_mutex can go away if we change locking order to
-	 * mmap_sem -> bo::reserve.
-	 */
-	ret = mutex_lock_interruptible(&bo->wu_mutex);
-	if (unlikely(ret != 0))
-		return -ERESTARTSYS;
-	if (!dma_resv_is_locked(bo->base.resv))
-		goto out_unlock;
-	ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
-	if (ret == -EINTR)
-		ret = -ERESTARTSYS;
-	if (unlikely(ret != 0))
-		goto out_unlock;
-	dma_resv_unlock(bo->base.resv);
-
-out_unlock:
-	mutex_unlock(&bo->wu_mutex);
-	return ret;
-}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6b0883a1776e..2b0e5a088da0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -504,7 +504,6 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
 	INIT_LIST_HEAD(&fbo->base.lru);
 	INIT_LIST_HEAD(&fbo->base.swap);
 	INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
-	mutex_init(&fbo->base.wu_mutex);
 	fbo->base.moving = NULL;
 	drm_vma_node_reset(&fbo->base.base.vma_node);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 11863fbdd5d6..91466cfb6f16 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -128,30 +128,22 @@ static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
 vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
 			     struct vm_fault *vmf)
 {
-	/*
-	 * Work around locking order reversal in fault / nopfn
-	 * between mmap_sem and bo_reserve: Perform a trylock operation
-	 * for reserve, and if it fails, retry the fault after waiting
-	 * for the buffer to become unreserved.
-	 */
 	if (unlikely(!dma_resv_trylock(bo->base.resv))) {
 		if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
 			if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
 				ttm_bo_get(bo);
 				up_read(&vmf->vma->vm_mm->mmap_sem);
-				(void) ttm_bo_wait_unreserved(bo);
+				if (!dma_resv_lock_interruptible(bo->base.resv,
+								 NULL))
+					dma_resv_unlock(bo->base.resv);
 				ttm_bo_put(bo);
 			}
 
 			return VM_FAULT_RETRY;
 		}
 
-		/*
-		 * If we'd want to change locking order to
-		 * mmap_sem -> bo::reserve, we'd use a blocking reserve here
-		 * instead of retrying the fault...
-		 */
-		return VM_FAULT_NOPAGE;
+		if (dma_resv_lock_interruptible(bo->base.resv, NULL))
+			return VM_FAULT_NOPAGE;
 	}
 
 	return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 65e399d280f7..e8b0f0c66059 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -154,7 +154,6 @@ struct ttm_tt;
  * @offset: The current GPU offset, which can have different meanings
  * depending on the memory type. For SYSTEM type memory, it should be 0.
  * @cur_placement: Hint of current placement.
- * @wu_mutex: Wait unreserved mutex.
  *
  * Base class for TTM buffer object, that deals with data placement and CPU
  * mappings. GPU mappings are really up to the driver, but for simpler GPUs
@@ -222,8 +221,6 @@ struct ttm_buffer_object {
 	uint64_t offset; /* GPU address space is independent of CPU word size */
 
 	struct sg_table *sg;
-
-	struct mutex wu_mutex;
 };
 
 /**
@@ -707,7 +704,6 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
 int ttm_bo_swapout(struct ttm_bo_global *glob,
 			struct ttm_operation_ctx *ctx);
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
 
 /**
  * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
-- 
2.24.0.rc2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

[Daniel Vetter]

With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.

Assuming I didn't screw up anything with my audit of course.

v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)

v3: Rebase over fault handler helperification.

Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c      | 36 -------------------------------
 drivers/gpu/drm/ttm/ttm_bo_util.c |  1 -
 drivers/gpu/drm/ttm/ttm_bo_vm.c   | 18 +++++-----------
 include/drm/ttm/ttm_bo_api.h      |  4 ----
 4 files changed, 5 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8d91b0428af1..5df596fb0280 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -161,7 +161,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
 	dma_fence_put(bo->moving);
 	if (!ttm_bo_uses_embedded_gem_object(bo))
 		dma_resv_fini(&bo->base._resv);
-	mutex_destroy(&bo->wu_mutex);
 	bo->destroy(bo);
 	ttm_mem_global_free(&ttm_mem_glob, acc_size);
 }
@@ -1299,7 +1298,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
 	INIT_LIST_HEAD(&bo->ddestroy);
 	INIT_LIST_HEAD(&bo->swap);
 	INIT_LIST_HEAD(&bo->io_reserve_lru);
-	mutex_init(&bo->wu_mutex);
 	bo->bdev = bdev;
 	bo->type = type;
 	bo->num_pages = num_pages;
@@ -1903,37 +1901,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
 	while (ttm_bo_swapout(&ttm_bo_glob, &ctx) == 0);
 }
 EXPORT_SYMBOL(ttm_bo_swapout_all);
-
-/**
- * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
- * unreserved
- *
- * @bo: Pointer to buffer
- */
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
-{
-	int ret;
-
-	/*
-	 * In the absense of a wait_unlocked API,
-	 * Use the bo::wu_mutex to avoid triggering livelocks due to
-	 * concurrent use of this function. Note that this use of
-	 * bo::wu_mutex can go away if we change locking order to
-	 * mmap_sem -> bo::reserve.
-	 */
-	ret = mutex_lock_interruptible(&bo->wu_mutex);
-	if (unlikely(ret != 0))
-		return -ERESTARTSYS;
-	if (!dma_resv_is_locked(bo->base.resv))
-		goto out_unlock;
-	ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
-	if (ret == -EINTR)
-		ret = -ERESTARTSYS;
-	if (unlikely(ret != 0))
-		goto out_unlock;
-	dma_resv_unlock(bo->base.resv);
-
-out_unlock:
-	mutex_unlock(&bo->wu_mutex);
-	return ret;
-}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6b0883a1776e..2b0e5a088da0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -504,7 +504,6 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
 	INIT_LIST_HEAD(&fbo->base.lru);
 	INIT_LIST_HEAD(&fbo->base.swap);
 	INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
-	mutex_init(&fbo->base.wu_mutex);
 	fbo->base.moving = NULL;
 	drm_vma_node_reset(&fbo->base.base.vma_node);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 11863fbdd5d6..91466cfb6f16 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -128,30 +128,22 @@ static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
 vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
 			     struct vm_fault *vmf)
 {
-	/*
-	 * Work around locking order reversal in fault / nopfn
-	 * between mmap_sem and bo_reserve: Perform a trylock operation
-	 * for reserve, and if it fails, retry the fault after waiting
-	 * for the buffer to become unreserved.
-	 */
 	if (unlikely(!dma_resv_trylock(bo->base.resv))) {
 		if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
 			if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
 				ttm_bo_get(bo);
 				up_read(&vmf->vma->vm_mm->mmap_sem);
-				(void) ttm_bo_wait_unreserved(bo);
+				if (!dma_resv_lock_interruptible(bo->base.resv,
+								 NULL))
+					dma_resv_unlock(bo->base.resv);
 				ttm_bo_put(bo);
 			}
 
 			return VM_FAULT_RETRY;
 		}
 
-		/*
-		 * If we'd want to change locking order to
-		 * mmap_sem -> bo::reserve, we'd use a blocking reserve here
-		 * instead of retrying the fault...
-		 */
-		return VM_FAULT_NOPAGE;
+		if (dma_resv_lock_interruptible(bo->base.resv, NULL))
+			return VM_FAULT_NOPAGE;
 	}
 
 	return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 65e399d280f7..e8b0f0c66059 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -154,7 +154,6 @@ struct ttm_tt;
  * @offset: The current GPU offset, which can have different meanings
  * depending on the memory type. For SYSTEM type memory, it should be 0.
  * @cur_placement: Hint of current placement.
- * @wu_mutex: Wait unreserved mutex.
  *
  * Base class for TTM buffer object, that deals with data placement and CPU
  * mappings. GPU mappings are really up to the driver, but for simpler GPUs
@@ -222,8 +221,6 @@ struct ttm_buffer_object {
 	uint64_t offset; /* GPU address space is independent of CPU word size */
 
 	struct sg_table *sg;
-
-	struct mutex wu_mutex;
 };
 
 /**
@@ -707,7 +704,6 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
 int ttm_bo_swapout(struct ttm_bo_global *glob,
 			struct ttm_operation_ctx *ctx);
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
 
 /**
  * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
-- 
2.24.0.rc2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:37:59PM +0100, Daniel Vetter wrote:
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
> 
> v4: Annotate with __init (Rob Herring)
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

I lost the r-b from Thomas on the last round:

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
> ---
>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  	kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>  /**
>   * dma_resv_init - initialize a reservation object
>   * @obj: the reservation object
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:37:59PM +0100, Daniel Vetter wrote:
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
> 
> v4: Annotate with __init (Rob Herring)
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

I lost the r-b from Thomas on the last round:

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
> ---
>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  	kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>  /**
>   * dma_resv_init - initialize a reservation object
>   * @obj: the reservation object
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:37:59PM +0100, Daniel Vetter wrote:
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
> 
> v4: Annotate with __init (Rob Herring)
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

I lost the r-b from Thomas on the last round:

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
> ---
>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  	kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>  /**
>   * dma_resv_init - initialize a reservation object
>   * @obj: the reservation object
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Koenig, Christian]

Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>    really no business holding struct_mutex while doing copy_*_user. But
>    I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>    looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>    copying from/to userspace happens all in v3d_lookup_bos which is
>    outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>    - vmw_execbuf_process: First this does some copies in
>      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>      Then comes the usual ttm reserve/validate sequence, then actual
>      submission/fencing, then unreserving, and finally some more
>      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>      details, but looks all safe.
>    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>      seen, seems to only create a fence and copy it out.
>    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>      found there.
>    Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>    copying from userspace before even looking up objects through their
>    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>    qxl_process_single_command. There's a lovely comment before the
>    __copy_from_user_inatomic that the slowpath should be copied from
>    i915, but I guess that never happened. Try not to be unlucky and get
>    your CS data evicted between when it's written and the kernel tries
>    to read it. The only other copy_from_user is for relocs, but those
>    are done before qxl_release_reserve_list(), which seems to be the
>    only thing reserving buffers (in the ttm/dma_resv sense) in that
>    code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>    everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

What's holding you back to commit that?

Christian.

> ---
>   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/dma-resv.h>
>   #include <linux/export.h>
> +#include <linux/sched/mm.h>
>   
>   /**
>    * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>   	kfree_rcu(list, rcu);
>   }
>   
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>   /**
>    * dma_resv_init - initialize a reservation object
>    * @obj: the reservation object

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Koenig, Christian]

Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>    really no business holding struct_mutex while doing copy_*_user. But
>    I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>    looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>    copying from/to userspace happens all in v3d_lookup_bos which is
>    outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>    - vmw_execbuf_process: First this does some copies in
>      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>      Then comes the usual ttm reserve/validate sequence, then actual
>      submission/fencing, then unreserving, and finally some more
>      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>      details, but looks all safe.
>    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>      seen, seems to only create a fence and copy it out.
>    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>      found there.
>    Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>    copying from userspace before even looking up objects through their
>    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>    qxl_process_single_command. There's a lovely comment before the
>    __copy_from_user_inatomic that the slowpath should be copied from
>    i915, but I guess that never happened. Try not to be unlucky and get
>    your CS data evicted between when it's written and the kernel tries
>    to read it. The only other copy_from_user is for relocs, but those
>    are done before qxl_release_reserve_list(), which seems to be the
>    only thing reserving buffers (in the ttm/dma_resv sense) in that
>    code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>    everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

What's holding you back to commit that?

Christian.

> ---
>   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/dma-resv.h>
>   #include <linux/export.h>
> +#include <linux/sched/mm.h>
>   
>   /**
>    * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>   	kfree_rcu(list, rcu);
>   }
>   
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>   /**
>    * dma_resv_init - initialize a reservation object
>    * @obj: the reservation object

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Koenig, Christian]

Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>    really no business holding struct_mutex while doing copy_*_user. But
>    I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>    looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>    copying from/to userspace happens all in v3d_lookup_bos which is
>    outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>    - vmw_execbuf_process: First this does some copies in
>      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>      Then comes the usual ttm reserve/validate sequence, then actual
>      submission/fencing, then unreserving, and finally some more
>      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>      details, but looks all safe.
>    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>      seen, seems to only create a fence and copy it out.
>    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>      found there.
>    Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>    copying from userspace before even looking up objects through their
>    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>    qxl_process_single_command. There's a lovely comment before the
>    __copy_from_user_inatomic that the slowpath should be copied from
>    i915, but I guess that never happened. Try not to be unlucky and get
>    your CS data evicted between when it's written and the kernel tries
>    to read it. The only other copy_from_user is for relocs, but those
>    are done before qxl_release_reserve_list(), which seems to be the
>    only thing reserving buffers (in the ttm/dma_resv sense) in that
>    code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>    everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

What's holding you back to commit that?

Christian.

> ---
>   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/dma-resv.h>
>   #include <linux/export.h>
> +#include <linux/sched/mm.h>
>   
>   /**
>    * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>   	kfree_rcu(list, rcu);
>   }
>   
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	
> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
>   /**
>    * dma_resv_init - initialize a reservation object
>    * @obj: the reservation object

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 08:01:09PM +0000, Koenig, Christian wrote:
> Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >    really no business holding struct_mutex while doing copy_*_user. But
> >    I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >    looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >    copying from/to userspace happens all in v3d_lookup_bos which is
> >    outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >    - vmw_execbuf_process: First this does some copies in
> >      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >      Then comes the usual ttm reserve/validate sequence, then actual
> >      submission/fencing, then unreserving, and finally some more
> >      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >      details, but looks all safe.
> >    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >      seen, seems to only create a fence and copy it out.
> >    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >      found there.
> >    Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >    copying from userspace before even looking up objects through their
> >    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >    qxl_process_single_command. There's a lovely comment before the
> >    __copy_from_user_inatomic that the slowpath should be copied from
> >    i915, but I guess that never happened. Try not to be unlucky and get
> >    your CS data evicted between when it's written and the kernel tries
> >    to read it. The only other copy_from_user is for relocs, but those
> >    are done before qxl_release_reserve_list(), which seems to be the
> >    only thing reserving buffers (in the ttm/dma_resv sense) in that
> >    code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >    everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> What's holding you back to commit that?

The nouveau patch, can't push this one without also fixing nouveau :-/
-Daniel

> 
> Christian.
> 
> > ---
> >   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >   
> >   #include <linux/dma-resv.h>
> >   #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >   
> >   /**
> >    * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >   	kfree_rcu(list, rcu);
> >   }
> >   
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +	struct mm_struct *mm = mm_alloc();
> > +	struct dma_resv obj;
> > +
> > +	if (!mm)
> > +		return;
> > +
> > +	dma_resv_init(&obj);
> > +
> > +	down_read(&mm->mmap_sem);
> > +	ww_mutex_lock(&obj.lock, NULL);
> > +	fs_reclaim_acquire(GFP_KERNEL);
> > +	fs_reclaim_release(GFP_KERNEL);
> > +	ww_mutex_unlock(&obj.lock);
> > +	up_read(&mm->mmap_sem);
> > +	
> > +	mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
> > +#endif
> > +
> >   /**
> >    * dma_resv_init - initialize a reservation object
> >    * @obj: the reservation object
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 08:01:09PM +0000, Koenig, Christian wrote:
> Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >    really no business holding struct_mutex while doing copy_*_user. But
> >    I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >    looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >    copying from/to userspace happens all in v3d_lookup_bos which is
> >    outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >    - vmw_execbuf_process: First this does some copies in
> >      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >      Then comes the usual ttm reserve/validate sequence, then actual
> >      submission/fencing, then unreserving, and finally some more
> >      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >      details, but looks all safe.
> >    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >      seen, seems to only create a fence and copy it out.
> >    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >      found there.
> >    Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >    copying from userspace before even looking up objects through their
> >    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >    qxl_process_single_command. There's a lovely comment before the
> >    __copy_from_user_inatomic that the slowpath should be copied from
> >    i915, but I guess that never happened. Try not to be unlucky and get
> >    your CS data evicted between when it's written and the kernel tries
> >    to read it. The only other copy_from_user is for relocs, but those
> >    are done before qxl_release_reserve_list(), which seems to be the
> >    only thing reserving buffers (in the ttm/dma_resv sense) in that
> >    code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >    everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> What's holding you back to commit that?

The nouveau patch, can't push this one without also fixing nouveau :-/
-Daniel

> 
> Christian.
> 
> > ---
> >   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >   
> >   #include <linux/dma-resv.h>
> >   #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >   
> >   /**
> >    * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >   	kfree_rcu(list, rcu);
> >   }
> >   
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +	struct mm_struct *mm = mm_alloc();
> > +	struct dma_resv obj;
> > +
> > +	if (!mm)
> > +		return;
> > +
> > +	dma_resv_init(&obj);
> > +
> > +	down_read(&mm->mmap_sem);
> > +	ww_mutex_lock(&obj.lock, NULL);
> > +	fs_reclaim_acquire(GFP_KERNEL);
> > +	fs_reclaim_release(GFP_KERNEL);
> > +	ww_mutex_unlock(&obj.lock);
> > +	up_read(&mm->mmap_sem);
> > +	
> > +	mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
> > +#endif
> > +
> >   /**
> >    * dma_resv_init - initialize a reservation object
> >    * @obj: the reservation object
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 04, 2019 at 08:01:09PM +0000, Koenig, Christian wrote:
> Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >    really no business holding struct_mutex while doing copy_*_user. But
> >    I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >    looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >    copying from/to userspace happens all in v3d_lookup_bos which is
> >    outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >    - vmw_execbuf_process: First this does some copies in
> >      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >      Then comes the usual ttm reserve/validate sequence, then actual
> >      submission/fencing, then unreserving, and finally some more
> >      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >      details, but looks all safe.
> >    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >      seen, seems to only create a fence and copy it out.
> >    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >      found there.
> >    Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >    copying from userspace before even looking up objects through their
> >    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >    qxl_process_single_command. There's a lovely comment before the
> >    __copy_from_user_inatomic that the slowpath should be copied from
> >    i915, but I guess that never happened. Try not to be unlucky and get
> >    your CS data evicted between when it's written and the kernel tries
> >    to read it. The only other copy_from_user is for relocs, but those
> >    are done before qxl_release_reserve_list(), which seems to be the
> >    only thing reserving buffers (in the ttm/dma_resv sense) in that
> >    code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >    everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> What's holding you back to commit that?

The nouveau patch, can't push this one without also fixing nouveau :-/
-Daniel

> 
> Christian.
> 
> > ---
> >   drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >   
> >   #include <linux/dma-resv.h>
> >   #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >   
> >   /**
> >    * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >   	kfree_rcu(list, rcu);
> >   }
> >   
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +	struct mm_struct *mm = mm_alloc();
> > +	struct dma_resv obj;
> > +
> > +	if (!mm)
> > +		return;
> > +
> > +	dma_resv_init(&obj);
> > +
> > +	down_read(&mm->mmap_sem);
> > +	ww_mutex_lock(&obj.lock, NULL);
> > +	fs_reclaim_acquire(GFP_KERNEL);
> > +	fs_reclaim_release(GFP_KERNEL);
> > +	ww_mutex_unlock(&obj.lock);
> > +	up_read(&mm->mmap_sem);
> > +	
> > +	mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
> > +#endif
> > +
> >   /**
> >    * dma_resv_init - initialize a reservation object
> >    * @obj: the reservation object
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
294603555e6b dma_resv: prime lockdep annotations
-:77: WARNING:BAD_SIGN_OFF: Duplicate signature
#77: 
Cc: Rob Herring <robh@kernel.org>

-:83: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" <linux-graphics-maintainer@vmware.com>' might be better as 'VMware Graphics <linux-graphics-maintainer@vmware.com>'
#83: 
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>

-:124: ERROR:TRAILING_WHITESPACE: trailing whitespace
#124: FILE: drivers/dma-buf/dma-resv.c:116:
+^I$

-:132: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 1 errors, 3 warnings, 0 checks, 36 lines checked
f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl
-:155: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 122 lines checked
88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved
-:27: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" <linux-graphics-maintainer@vmware.com>' might be better as 'VMware Graphics <linux-graphics-maintainer@vmware.com>'
#27: 
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>

-:168: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 81 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
294603555e6b dma_resv: prime lockdep annotations
-:77: WARNING:BAD_SIGN_OFF: Duplicate signature
#77: 
Cc: Rob Herring <robh@kernel.org>

-:83: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" <linux-graphics-maintainer@vmware.com>' might be better as 'VMware Graphics <linux-graphics-maintainer@vmware.com>'
#83: 
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>

-:124: ERROR:TRAILING_WHITESPACE: trailing whitespace
#124: FILE: drivers/dma-buf/dma-resv.c:116:
+^I$

-:132: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 1 errors, 3 warnings, 0 checks, 36 lines checked
f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl
-:155: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 122 lines checked
88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved
-:27: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" <linux-graphics-maintainer@vmware.com>' might be better as 'VMware Graphics <linux-graphics-maintainer@vmware.com>'
#27: 
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>

-:168: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 81 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7258 -> Patchwork_15124
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html

Known issues
------------

  Here are the changes found in Patchwork_15124 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_flink_basic@double-flink:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@double-flink.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_basic@double-flink.html

  
#### Possible fixes ####

  * {igt@gem_exec_suspend@basic-s0}:
    - fi-bsw-kefka:       [DMESG-WARN][3] ([fdo#112120]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_flink_basic@basic:
    - fi-icl-u3:          [DMESG-WARN][5] ([fdo#107724] / [fdo#112052 ]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@basic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_basic@basic.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][7] ([fdo#111407]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@prime_busy@basic-before-default:
    - fi-icl-u3:          [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@prime_busy@basic-before-default.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@prime_busy@basic-before-default.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
  [fdo#112052 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112052 
  [fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120


Participating hosts (52 -> 44)
------------------------------

  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7258 -> Patchwork_15124

  CI-20190529: 20190529
  CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15124: 88df22c347f93b3fc5582f4132ecd283ccb89804 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved
f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl
294603555e6b dma_resv: prime lockdep annotations

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7258 -> Patchwork_15124
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html

Known issues
------------

  Here are the changes found in Patchwork_15124 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_flink_basic@double-flink:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@double-flink.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_basic@double-flink.html

  
#### Possible fixes ####

  * {igt@gem_exec_suspend@basic-s0}:
    - fi-bsw-kefka:       [DMESG-WARN][3] ([fdo#112120]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_flink_basic@basic:
    - fi-icl-u3:          [DMESG-WARN][5] ([fdo#107724] / [fdo#112052 ]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@basic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_basic@basic.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][7] ([fdo#111407]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@prime_busy@basic-before-default:
    - fi-icl-u3:          [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@prime_busy@basic-before-default.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@prime_busy@basic-before-default.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
  [fdo#112052 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112052 
  [fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120


Participating hosts (52 -> 44)
------------------------------

  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7258 -> Patchwork_15124

  CI-20190529: 20190529
  CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15124: 88df22c347f93b3fc5582f4132ecd283ccb89804 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved
f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl
294603555e6b dma_resv: prime lockdep annotations

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7258_full -> Patchwork_15124_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_15124_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_busy@busy-vcs1.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb8/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276]) +16 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb5/igt@gem_exec_schedule@reorder-wide-bsd.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
    - shard-kbl:          [PASS][11] -> [FAIL][12] ([fdo#112037])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl6/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html

  * igt@gem_userptr_blits@dmabuf-unsync:
    - shard-hsw:          [PASS][13] -> [DMESG-WARN][14] ([fdo#111870])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw5/igt@gem_userptr_blits@dmabuf-unsync.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw5/igt@gem_userptr_blits@dmabuf-unsync.html

  * igt@i915_suspend@sysfs-reader:
    - shard-kbl:          [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl3/igt@i915_suspend@sysfs-reader.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@i915_suspend@sysfs-reader.html

  * igt@kms_atomic_interruptible@atomic-setmode:
    - shard-hsw:          [PASS][17] -> [INCOMPLETE][18] ([fdo#103540])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw7/igt@kms_atomic_interruptible@atomic-setmode.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw2/igt@kms_atomic_interruptible@atomic-setmode.html

  * igt@kms_busy@basic-flip-b:
    - shard-skl:          [PASS][19] -> [DMESG-WARN][20] ([fdo#106107])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl6/igt@kms_busy@basic-flip-b.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl5/igt@kms_busy@basic-flip-b.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-skl:          [PASS][23] -> [FAIL][24] ([fdo#100368])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
    - shard-snb:          [PASS][25] -> [SKIP][26] ([fdo#109271]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-snb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
    - shard-iclb:         [PASS][27] -> [FAIL][28] ([fdo#103167]) +6 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_psr@psr2_sprite_mmap_cpu:
    - shard-iclb:         [PASS][29] -> [SKIP][30] ([fdo#109441])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][31] -> [FAIL][32] ([fdo#99912])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_setmode@basic.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl8/igt@kms_setmode@basic.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@vcs1-clean:
    - shard-iclb:         [SKIP][33] ([fdo#109276] / [fdo#112080]) -> [PASS][34] +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@gem_ctx_isolation@vcs1-clean.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@gem_ctx_isolation@vcs1-clean.html

  * igt@gem_ctx_shared@q-smoketest-blt:
    - {shard-tglb}:       [INCOMPLETE][35] ([fdo#111735]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb6/igt@gem_ctx_shared@q-smoketest-blt.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb5/igt@gem_ctx_shared@q-smoketest-blt.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [SKIP][37] ([fdo#112146]) -> [PASS][38] +7 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb6/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_sync@basic-each:
    - {shard-tglb}:       [INCOMPLETE][39] ([fdo#111647] / [fdo#111998]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb5/igt@gem_sync@basic-each.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb4/igt@gem_sync@basic-each.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][41] ([fdo#111870]) -> [PASS][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw1/igt@gem_userptr_blits@sync-unmap.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw1/igt@gem_userptr_blits@sync-unmap.html

  * igt@gem_workarounds@suspend-resume:
    - {shard-tglb}:       [INCOMPLETE][43] ([fdo#111832] / [fdo#111850]) -> [PASS][44] +5 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@gem_workarounds@suspend-resume.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb8/igt@gem_workarounds@suspend-resume.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-kbl:          [SKIP][45] ([fdo#109271]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl1/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl6/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@kms_color@pipe-b-ctm-0-25:
    - shard-skl:          [DMESG-WARN][47] ([fdo#106107]) -> [PASS][48] +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen:
    - shard-skl:          [FAIL][49] ([fdo#103232]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl8/igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen.html

  * igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge:
    - shard-snb:          [SKIP][51] ([fdo#109271]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb4/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-snb1/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [FAIL][53] ([fdo#105363]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-glk:          [FAIL][55] ([fdo#105363]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-apl:          [DMESG-WARN][57] ([fdo#108566]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_flip@flip-vs-suspend.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl7/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt:
    - shard-iclb:         [FAIL][59] ([fdo#103167]) -> [PASS][60] +6 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][61] ([fdo#108566]) -> [PASS][62] +8 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl3/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite:
    - {shard-tglb}:       [FAIL][63] ([fdo#103167]) -> [PASS][64] +4 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb4/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [FAIL][65] ([fdo#103166]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [FAIL][67] ([fdo#108341]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_psr@no_drrs.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb3/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][69] ([fdo#109441]) -> [PASS][70] +1 similar issue
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][71] ([fdo#99912]) -> [PASS][72]
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl3/igt@kms_setmode@basic.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - {shard-tglb}:       [INCOMPLETE][73] ([fdo#111850]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb7/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@perf_pmu@busy-no-semaphores-vcs1:
    - shard-iclb:         [SKIP][75] ([fdo#112080]) -> [PASS][76] +11 similar issues
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@perf_pmu@busy-no-semaphores-vcs1.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@perf_pmu@busy-no-semaphores-vcs1.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][77] ([fdo#109276]) -> [PASS][78] +12 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb7/igt@prime_vgem@fence-wait-bsd2.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][79] ([fdo#111329]) -> [SKIP][80] ([fdo#109276] / [fdo#112080])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_mocs_settings@mocs-isolation-bsd2:
    - shard-iclb:         [SKIP][81] ([fdo#109276]) -> [FAIL][82] ([fdo#111330])
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb8/igt@gem_mocs_settings@mocs-isolation-bsd2.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb4/igt@gem_mocs_settings@mocs-isolation-bsd2.html

  * igt@gem_mocs_settings@mocs-settings-bsd2:
    - shard-iclb:         [FAIL][83] ([fdo#111330]) -> [SKIP][84] ([fdo#109276]) +1 similar issue
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_mocs_settings@mocs-settings-bsd2.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_mocs_settings@mocs-settings-bsd2.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][85] ([fdo#104108]) -> [INCOMPLETE][86] ([fdo#104108] / [fdo#107773])
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl10/igt@gem_softpin@noreloc-s3.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl2/igt@gem_softpin@noreloc-s3.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
  [fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
  [fdo#111606]: https://bugs.freedesktop.org/show_bug.cgi?id=111606
  [fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646
  [fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
  [fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671
  [fdo#111677]: https://bugs.freedesktop.org/show_bug.cgi?id=111677
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
  [fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#111998]: https://bugs.freedesktop.org/show_bug.cgi?id=111998
  [fdo#112037]: https://bugs.freedesktop.org/show_bug.cgi?id=112037
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7258 -> Patchwork_15124

  CI-20190529: 20190529
  CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15124: 88df22c347f93b3fc5582f4132ecd283ccb89804 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] dma_resv: prime lockdep annotations

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL   : https://patchwork.freedesktop.org/series/68958/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7258_full -> Patchwork_15124_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_15124_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_busy@busy-vcs1.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb8/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276]) +16 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb5/igt@gem_exec_schedule@reorder-wide-bsd.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
    - shard-kbl:          [PASS][11] -> [FAIL][12] ([fdo#112037])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl6/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html

  * igt@gem_userptr_blits@dmabuf-unsync:
    - shard-hsw:          [PASS][13] -> [DMESG-WARN][14] ([fdo#111870])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw5/igt@gem_userptr_blits@dmabuf-unsync.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw5/igt@gem_userptr_blits@dmabuf-unsync.html

  * igt@i915_suspend@sysfs-reader:
    - shard-kbl:          [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl3/igt@i915_suspend@sysfs-reader.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@i915_suspend@sysfs-reader.html

  * igt@kms_atomic_interruptible@atomic-setmode:
    - shard-hsw:          [PASS][17] -> [INCOMPLETE][18] ([fdo#103540])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw7/igt@kms_atomic_interruptible@atomic-setmode.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw2/igt@kms_atomic_interruptible@atomic-setmode.html

  * igt@kms_busy@basic-flip-b:
    - shard-skl:          [PASS][19] -> [DMESG-WARN][20] ([fdo#106107])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl6/igt@kms_busy@basic-flip-b.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl5/igt@kms_busy@basic-flip-b.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-skl:          [PASS][23] -> [FAIL][24] ([fdo#100368])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
    - shard-snb:          [PASS][25] -> [SKIP][26] ([fdo#109271]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-snb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
    - shard-iclb:         [PASS][27] -> [FAIL][28] ([fdo#103167]) +6 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_psr@psr2_sprite_mmap_cpu:
    - shard-iclb:         [PASS][29] -> [SKIP][30] ([fdo#109441])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][31] -> [FAIL][32] ([fdo#99912])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_setmode@basic.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl8/igt@kms_setmode@basic.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@vcs1-clean:
    - shard-iclb:         [SKIP][33] ([fdo#109276] / [fdo#112080]) -> [PASS][34] +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@gem_ctx_isolation@vcs1-clean.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@gem_ctx_isolation@vcs1-clean.html

  * igt@gem_ctx_shared@q-smoketest-blt:
    - {shard-tglb}:       [INCOMPLETE][35] ([fdo#111735]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb6/igt@gem_ctx_shared@q-smoketest-blt.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb5/igt@gem_ctx_shared@q-smoketest-blt.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [SKIP][37] ([fdo#112146]) -> [PASS][38] +7 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb6/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_sync@basic-each:
    - {shard-tglb}:       [INCOMPLETE][39] ([fdo#111647] / [fdo#111998]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb5/igt@gem_sync@basic-each.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb4/igt@gem_sync@basic-each.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][41] ([fdo#111870]) -> [PASS][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw1/igt@gem_userptr_blits@sync-unmap.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-hsw1/igt@gem_userptr_blits@sync-unmap.html

  * igt@gem_workarounds@suspend-resume:
    - {shard-tglb}:       [INCOMPLETE][43] ([fdo#111832] / [fdo#111850]) -> [PASS][44] +5 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@gem_workarounds@suspend-resume.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb8/igt@gem_workarounds@suspend-resume.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-kbl:          [SKIP][45] ([fdo#109271]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl1/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl6/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@kms_color@pipe-b-ctm-0-25:
    - shard-skl:          [DMESG-WARN][47] ([fdo#106107]) -> [PASS][48] +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen:
    - shard-skl:          [FAIL][49] ([fdo#103232]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl8/igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen.html

  * igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge:
    - shard-snb:          [SKIP][51] ([fdo#109271]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb4/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-snb1/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [FAIL][53] ([fdo#105363]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-glk:          [FAIL][55] ([fdo#105363]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-apl:          [DMESG-WARN][57] ([fdo#108566]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_flip@flip-vs-suspend.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-apl7/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt:
    - shard-iclb:         [FAIL][59] ([fdo#103167]) -> [PASS][60] +6 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][61] ([fdo#108566]) -> [PASS][62] +8 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl3/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite:
    - {shard-tglb}:       [FAIL][63] ([fdo#103167]) -> [PASS][64] +4 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb4/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [FAIL][65] ([fdo#103166]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [FAIL][67] ([fdo#108341]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_psr@no_drrs.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb3/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][69] ([fdo#109441]) -> [PASS][70] +1 similar issue
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][71] ([fdo#99912]) -> [PASS][72]
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl3/igt@kms_setmode@basic.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-kbl2/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - {shard-tglb}:       [INCOMPLETE][73] ([fdo#111850]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-tglb7/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@perf_pmu@busy-no-semaphores-vcs1:
    - shard-iclb:         [SKIP][75] ([fdo#112080]) -> [PASS][76] +11 similar issues
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@perf_pmu@busy-no-semaphores-vcs1.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb2/igt@perf_pmu@busy-no-semaphores-vcs1.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][77] ([fdo#109276]) -> [PASS][78] +12 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb7/igt@prime_vgem@fence-wait-bsd2.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][79] ([fdo#111329]) -> [SKIP][80] ([fdo#109276] / [fdo#112080])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb7/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_mocs_settings@mocs-isolation-bsd2:
    - shard-iclb:         [SKIP][81] ([fdo#109276]) -> [FAIL][82] ([fdo#111330])
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb8/igt@gem_mocs_settings@mocs-isolation-bsd2.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb4/igt@gem_mocs_settings@mocs-isolation-bsd2.html

  * igt@gem_mocs_settings@mocs-settings-bsd2:
    - shard-iclb:         [FAIL][83] ([fdo#111330]) -> [SKIP][84] ([fdo#109276]) +1 similar issue
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_mocs_settings@mocs-settings-bsd2.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-iclb5/igt@gem_mocs_settings@mocs-settings-bsd2.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][85] ([fdo#104108]) -> [INCOMPLETE][86] ([fdo#104108] / [fdo#107773])
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl10/igt@gem_softpin@noreloc-s3.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/shard-skl2/igt@gem_softpin@noreloc-s3.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
  [fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
  [fdo#111606]: https://bugs.freedesktop.org/show_bug.cgi?id=111606
  [fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646
  [fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
  [fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671
  [fdo#111677]: https://bugs.freedesktop.org/show_bug.cgi?id=111677
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
  [fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#111998]: https://bugs.freedesktop.org/show_bug.cgi?id=111998
  [fdo#112037]: https://bugs.freedesktop.org/show_bug.cgi?id=112037
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7258 -> Patchwork_15124

  CI-20190529: 20190529
  CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15124: 88df22c347f93b3fc5582f4132ecd283ccb89804 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
> We can't copy_*_user while holding reservations, that will (soon even
> for nouveau) lead to deadlocks. And it breaks the cross-driver
> contract around dma_resv.
> 
> Fix this by adding a slowpath for when we need relocations, and by
> pushing the writeback of the new presumed offsets to the very end.
> 
> Aside from "it compiles" entirely untested unfortunately.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: nouveau@lists.freedesktop.org

Ping for ack/review so I can land this entire series. intel-gfx-ci is all
happy with the rebased version, so nouveau ack is the only hold-up here.
-Daniel

> ---
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
>  1 file changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 1324c19f4e5c..05ec8edd6a8b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
>  
>  static int
>  validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
> -	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -	      uint64_t user_pbbo_ptr)
> +	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
>  {
>  	struct nouveau_drm *drm = chan->drm;
> -	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> -				(void __force __user *)(uintptr_t)user_pbbo_ptr;
>  	struct nouveau_bo *nvbo;
>  	int ret, relocs = 0;
>  
> @@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
>  			b->presumed.offset = nvbo->bo.offset;
>  			b->presumed.valid = 0;
>  			relocs++;
> -
> -			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
> -					     &b->presumed, sizeof(b->presumed)))
> -				return -EFAULT;
>  		}
>  	}
>  
> @@ -547,8 +540,8 @@ static int
>  nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  			     struct drm_file *file_priv,
>  			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -			     uint64_t user_buffers, int nr_buffers,
> -			     struct validate_op *op, int *apply_relocs)
> +			     int nr_buffers,
> +			     struct validate_op *op, bool *apply_relocs)
>  {
>  	struct nouveau_cli *cli = nouveau_cli(file_priv);
>  	int ret;
> @@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  		return ret;
>  	}
>  
> -	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
> +	ret = validate_list(chan, cli, &op->list, pbbo);
>  	if (unlikely(ret < 0)) {
>  		if (ret != -ERESTARTSYS)
>  			NV_PRINTK(err, cli, "validating bo list\n");
> @@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
>  static int
>  nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
>  				struct drm_nouveau_gem_pushbuf *req,
> +				struct drm_nouveau_gem_pushbuf_reloc *reloc,
>  				struct drm_nouveau_gem_pushbuf_bo *bo)
>  {
> -	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	int ret = 0;
>  	unsigned i;
>  
> -	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> -	if (IS_ERR(reloc))
> -		return PTR_ERR(reloc);
> -
>  	for (i = 0; i < req->nr_relocs; i++) {
>  		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
>  		struct drm_nouveau_gem_pushbuf_bo *b;
> @@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	struct nouveau_drm *drm = nouveau_drm(dev);
>  	struct drm_nouveau_gem_pushbuf *req = data;
>  	struct drm_nouveau_gem_pushbuf_push *push;
> +	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	struct drm_nouveau_gem_pushbuf_bo *bo;
>  	struct nouveau_channel *chan = NULL;
>  	struct validate_op op;
>  	struct nouveau_fence *fence = NULL;
> -	int i, j, ret = 0, do_reloc = 0;
> +	int i, j, ret = 0;
> +	bool do_reloc = false;
>  
>  	if (unlikely(!abi16))
>  		return -ENOMEM;
> @@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	}
>  
>  	/* Validate buffer list */
> -	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
> +revalidate:
> +	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
>  					   req->nr_buffers, &op, &do_reloc);
>  	if (ret) {
>  		if (ret != -ERESTARTSYS)
> @@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  
>  	/* Apply any relocations that are required */
>  	if (do_reloc) {
> -		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
> +		if (!reloc) {
> +			validate_fini(&op, chan, NULL, bo);
> +			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> +			if (IS_ERR(reloc)) {
> +				ret = PTR_ERR(reloc);
> +				goto out_prevalid;
> +			}
> +
> +			goto revalidate;
> +		}
> +
> +		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
>  		if (ret) {
>  			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
>  			goto out;
> @@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	validate_fini(&op, chan, fence, bo);
>  	nouveau_fence_unref(&fence);
>  
> +	if (do_reloc) {
> +		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> +			u64_to_user_ptr(req->buffers);
> +
> +		for (i = 0; i < req->nr_buffers; i++) {
> +			if (bo[i].presumed.valid)
> +				continue;
> +
> +			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
> +					 sizeof(bo[i].presumed))) {
> +				ret = -EFAULT;
> +				break;
> +			}
> +		}
> +		u_free(reloc);
> +	}
>  out_prevalid:
>  	u_free(bo);
>  	u_free(push);
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
> We can't copy_*_user while holding reservations, that will (soon even
> for nouveau) lead to deadlocks. And it breaks the cross-driver
> contract around dma_resv.
> 
> Fix this by adding a slowpath for when we need relocations, and by
> pushing the writeback of the new presumed offsets to the very end.
> 
> Aside from "it compiles" entirely untested unfortunately.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: nouveau@lists.freedesktop.org

Ping for ack/review so I can land this entire series. intel-gfx-ci is all
happy with the rebased version, so nouveau ack is the only hold-up here.
-Daniel

> ---
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
>  1 file changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 1324c19f4e5c..05ec8edd6a8b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
>  
>  static int
>  validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
> -	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -	      uint64_t user_pbbo_ptr)
> +	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
>  {
>  	struct nouveau_drm *drm = chan->drm;
> -	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> -				(void __force __user *)(uintptr_t)user_pbbo_ptr;
>  	struct nouveau_bo *nvbo;
>  	int ret, relocs = 0;
>  
> @@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
>  			b->presumed.offset = nvbo->bo.offset;
>  			b->presumed.valid = 0;
>  			relocs++;
> -
> -			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
> -					     &b->presumed, sizeof(b->presumed)))
> -				return -EFAULT;
>  		}
>  	}
>  
> @@ -547,8 +540,8 @@ static int
>  nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  			     struct drm_file *file_priv,
>  			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -			     uint64_t user_buffers, int nr_buffers,
> -			     struct validate_op *op, int *apply_relocs)
> +			     int nr_buffers,
> +			     struct validate_op *op, bool *apply_relocs)
>  {
>  	struct nouveau_cli *cli = nouveau_cli(file_priv);
>  	int ret;
> @@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  		return ret;
>  	}
>  
> -	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
> +	ret = validate_list(chan, cli, &op->list, pbbo);
>  	if (unlikely(ret < 0)) {
>  		if (ret != -ERESTARTSYS)
>  			NV_PRINTK(err, cli, "validating bo list\n");
> @@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
>  static int
>  nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
>  				struct drm_nouveau_gem_pushbuf *req,
> +				struct drm_nouveau_gem_pushbuf_reloc *reloc,
>  				struct drm_nouveau_gem_pushbuf_bo *bo)
>  {
> -	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	int ret = 0;
>  	unsigned i;
>  
> -	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> -	if (IS_ERR(reloc))
> -		return PTR_ERR(reloc);
> -
>  	for (i = 0; i < req->nr_relocs; i++) {
>  		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
>  		struct drm_nouveau_gem_pushbuf_bo *b;
> @@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	struct nouveau_drm *drm = nouveau_drm(dev);
>  	struct drm_nouveau_gem_pushbuf *req = data;
>  	struct drm_nouveau_gem_pushbuf_push *push;
> +	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	struct drm_nouveau_gem_pushbuf_bo *bo;
>  	struct nouveau_channel *chan = NULL;
>  	struct validate_op op;
>  	struct nouveau_fence *fence = NULL;
> -	int i, j, ret = 0, do_reloc = 0;
> +	int i, j, ret = 0;
> +	bool do_reloc = false;
>  
>  	if (unlikely(!abi16))
>  		return -ENOMEM;
> @@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	}
>  
>  	/* Validate buffer list */
> -	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
> +revalidate:
> +	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
>  					   req->nr_buffers, &op, &do_reloc);
>  	if (ret) {
>  		if (ret != -ERESTARTSYS)
> @@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  
>  	/* Apply any relocations that are required */
>  	if (do_reloc) {
> -		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
> +		if (!reloc) {
> +			validate_fini(&op, chan, NULL, bo);
> +			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> +			if (IS_ERR(reloc)) {
> +				ret = PTR_ERR(reloc);
> +				goto out_prevalid;
> +			}
> +
> +			goto revalidate;
> +		}
> +
> +		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
>  		if (ret) {
>  			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
>  			goto out;
> @@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	validate_fini(&op, chan, fence, bo);
>  	nouveau_fence_unref(&fence);
>  
> +	if (do_reloc) {
> +		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> +			u64_to_user_ptr(req->buffers);
> +
> +		for (i = 0; i < req->nr_buffers; i++) {
> +			if (bo[i].presumed.valid)
> +				continue;
> +
> +			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
> +					 sizeof(bo[i].presumed))) {
> +				ret = -EFAULT;
> +				break;
> +			}
> +		}
> +		u_free(reloc);
> +	}
>  out_prevalid:
>  	u_free(bo);
>  	u_free(push);
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
> We can't copy_*_user while holding reservations, that will (soon even
> for nouveau) lead to deadlocks. And it breaks the cross-driver
> contract around dma_resv.
> 
> Fix this by adding a slowpath for when we need relocations, and by
> pushing the writeback of the new presumed offsets to the very end.
> 
> Aside from "it compiles" entirely untested unfortunately.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: nouveau@lists.freedesktop.org

Ping for ack/review so I can land this entire series. intel-gfx-ci is all
happy with the rebased version, so nouveau ack is the only hold-up here.
-Daniel

> ---
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++++++++++++++++++---------
>  1 file changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 1324c19f4e5c..05ec8edd6a8b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv,
>  
>  static int
>  validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
> -	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -	      uint64_t user_pbbo_ptr)
> +	      struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
>  {
>  	struct nouveau_drm *drm = chan->drm;
> -	struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> -				(void __force __user *)(uintptr_t)user_pbbo_ptr;
>  	struct nouveau_bo *nvbo;
>  	int ret, relocs = 0;
>  
> @@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
>  			b->presumed.offset = nvbo->bo.offset;
>  			b->presumed.valid = 0;
>  			relocs++;
> -
> -			if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
> -					     &b->presumed, sizeof(b->presumed)))
> -				return -EFAULT;
>  		}
>  	}
>  
> @@ -547,8 +540,8 @@ static int
>  nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  			     struct drm_file *file_priv,
>  			     struct drm_nouveau_gem_pushbuf_bo *pbbo,
> -			     uint64_t user_buffers, int nr_buffers,
> -			     struct validate_op *op, int *apply_relocs)
> +			     int nr_buffers,
> +			     struct validate_op *op, bool *apply_relocs)
>  {
>  	struct nouveau_cli *cli = nouveau_cli(file_priv);
>  	int ret;
> @@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
>  		return ret;
>  	}
>  
> -	ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
> +	ret = validate_list(chan, cli, &op->list, pbbo);
>  	if (unlikely(ret < 0)) {
>  		if (ret != -ERESTARTSYS)
>  			NV_PRINTK(err, cli, "validating bo list\n");
> @@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
>  static int
>  nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
>  				struct drm_nouveau_gem_pushbuf *req,
> +				struct drm_nouveau_gem_pushbuf_reloc *reloc,
>  				struct drm_nouveau_gem_pushbuf_bo *bo)
>  {
> -	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	int ret = 0;
>  	unsigned i;
>  
> -	reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> -	if (IS_ERR(reloc))
> -		return PTR_ERR(reloc);
> -
>  	for (i = 0; i < req->nr_relocs; i++) {
>  		struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
>  		struct drm_nouveau_gem_pushbuf_bo *b;
> @@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	struct nouveau_drm *drm = nouveau_drm(dev);
>  	struct drm_nouveau_gem_pushbuf *req = data;
>  	struct drm_nouveau_gem_pushbuf_push *push;
> +	struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
>  	struct drm_nouveau_gem_pushbuf_bo *bo;
>  	struct nouveau_channel *chan = NULL;
>  	struct validate_op op;
>  	struct nouveau_fence *fence = NULL;
> -	int i, j, ret = 0, do_reloc = 0;
> +	int i, j, ret = 0;
> +	bool do_reloc = false;
>  
>  	if (unlikely(!abi16))
>  		return -ENOMEM;
> @@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	}
>  
>  	/* Validate buffer list */
> -	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
> +revalidate:
> +	ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
>  					   req->nr_buffers, &op, &do_reloc);
>  	if (ret) {
>  		if (ret != -ERESTARTSYS)
> @@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  
>  	/* Apply any relocations that are required */
>  	if (do_reloc) {
> -		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
> +		if (!reloc) {
> +			validate_fini(&op, chan, NULL, bo);
> +			reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
> +			if (IS_ERR(reloc)) {
> +				ret = PTR_ERR(reloc);
> +				goto out_prevalid;
> +			}
> +
> +			goto revalidate;
> +		}
> +
> +		ret = nouveau_gem_pushbuf_reloc_apply(cli, req, reloc, bo);
>  		if (ret) {
>  			NV_PRINTK(err, cli, "reloc apply: %d\n", ret);
>  			goto out;
> @@ -851,6 +854,22 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
>  	validate_fini(&op, chan, fence, bo);
>  	nouveau_fence_unref(&fence);
>  
> +	if (do_reloc) {
> +		struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
> +			u64_to_user_ptr(req->buffers);
> +
> +		for (i = 0; i < req->nr_buffers; i++) {
> +			if (bo[i].presumed.valid)
> +				continue;
> +
> +			if (copy_to_user(&upbbo[i].presumed, &bo[i].presumed,
> +					 sizeof(bo[i].presumed))) {
> +				ret = -EFAULT;
> +				break;
> +			}
> +		}
> +		u_free(reloc);
> +	}
>  out_prevalid:
>  	u_free(bo);
>  	u_free(push);
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Maarten Lankhorst]

Op 05-11-2019 om 12:04 schreef Daniel Vetter:
> On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
>> We can't copy_*_user while holding reservations, that will (soon even
>> for nouveau) lead to deadlocks. And it breaks the cross-driver
>> contract around dma_resv.
>>
>> Fix this by adding a slowpath for when we need relocations, and by
>> pushing the writeback of the new presumed offsets to the very end.
>>
>> Aside from "it compiles" entirely untested unfortunately.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Ben Skeggs <bskeggs@redhat.com>
>> Cc: nouveau@lists.freedesktop.org
> Ping for ack/review so I can land this entire series. intel-gfx-ci is all
> happy with the rebased version, so nouveau ack is the only hold-up here.

I don't feel confident reviewing this as I lack the hw, so all review caveats reply.

Having said that, this looks sane, and if it blows up we'll found out eventually. :)

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Maarten Lankhorst]

Op 05-11-2019 om 12:04 schreef Daniel Vetter:
> On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
>> We can't copy_*_user while holding reservations, that will (soon even
>> for nouveau) lead to deadlocks. And it breaks the cross-driver
>> contract around dma_resv.
>>
>> Fix this by adding a slowpath for when we need relocations, and by
>> pushing the writeback of the new presumed offsets to the very end.
>>
>> Aside from "it compiles" entirely untested unfortunately.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Ben Skeggs <bskeggs@redhat.com>
>> Cc: nouveau@lists.freedesktop.org
> Ping for ack/review so I can land this entire series. intel-gfx-ci is all
> happy with the rebased version, so nouveau ack is the only hold-up here.

I don't feel confident reviewing this as I lack the hw, so all review caveats reply.

Having said that, this looks sane, and if it blows up we'll found out eventually. :)

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

[Maarten Lankhorst]

Op 05-11-2019 om 12:04 schreef Daniel Vetter:
> On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote:
>> We can't copy_*_user while holding reservations, that will (soon even
>> for nouveau) lead to deadlocks. And it breaks the cross-driver
>> contract around dma_resv.
>>
>> Fix this by adding a slowpath for when we need relocations, and by
>> pushing the writeback of the new presumed offsets to the very end.
>>
>> Aside from "it compiles" entirely untested unfortunately.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Ben Skeggs <bskeggs@redhat.com>
>> Cc: nouveau@lists.freedesktop.org
> Ping for ack/review so I can land this entire series. intel-gfx-ci is all
> happy with the rebased version, so nouveau ack is the only hold-up here.

I don't feel confident reviewing this as I lack the hw, so all review caveats reply.

Having said that, this looks sane, and if it blows up we'll found out eventually. :)

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:38:01PM +0100, Daniel Vetter wrote:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
> 
> Assuming I didn't screw up anything with my audit of course.
> 
> v2:
> - Dont forget wu_mutex (Christian König)
> - Keep the mmap_sem-less wait optimization (Thomas)
> - Use _lock_interruptible to be good citizens (Thomas)
> 
> v3: Rebase over fault handler helperification.
> 
> Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
> Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2)
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>

Entire series merged into drm-misc-next (probably for 5.6) with Dave's
irc-ack for the nouveau patch.
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c      | 36 -------------------------------
>  drivers/gpu/drm/ttm/ttm_bo_util.c |  1 -
>  drivers/gpu/drm/ttm/ttm_bo_vm.c   | 18 +++++-----------
>  include/drm/ttm/ttm_bo_api.h      |  4 ----
>  4 files changed, 5 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8d91b0428af1..5df596fb0280 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -161,7 +161,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
>  	dma_fence_put(bo->moving);
>  	if (!ttm_bo_uses_embedded_gem_object(bo))
>  		dma_resv_fini(&bo->base._resv);
> -	mutex_destroy(&bo->wu_mutex);
>  	bo->destroy(bo);
>  	ttm_mem_global_free(&ttm_mem_glob, acc_size);
>  }
> @@ -1299,7 +1298,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
>  	INIT_LIST_HEAD(&bo->ddestroy);
>  	INIT_LIST_HEAD(&bo->swap);
>  	INIT_LIST_HEAD(&bo->io_reserve_lru);
> -	mutex_init(&bo->wu_mutex);
>  	bo->bdev = bdev;
>  	bo->type = type;
>  	bo->num_pages = num_pages;
> @@ -1903,37 +1901,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
>  	while (ttm_bo_swapout(&ttm_bo_glob, &ctx) == 0);
>  }
>  EXPORT_SYMBOL(ttm_bo_swapout_all);
> -
> -/**
> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
> - * unreserved
> - *
> - * @bo: Pointer to buffer
> - */
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> -{
> -	int ret;
> -
> -	/*
> -	 * In the absense of a wait_unlocked API,
> -	 * Use the bo::wu_mutex to avoid triggering livelocks due to
> -	 * concurrent use of this function. Note that this use of
> -	 * bo::wu_mutex can go away if we change locking order to
> -	 * mmap_sem -> bo::reserve.
> -	 */
> -	ret = mutex_lock_interruptible(&bo->wu_mutex);
> -	if (unlikely(ret != 0))
> -		return -ERESTARTSYS;
> -	if (!dma_resv_is_locked(bo->base.resv))
> -		goto out_unlock;
> -	ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> -	if (ret == -EINTR)
> -		ret = -ERESTARTSYS;
> -	if (unlikely(ret != 0))
> -		goto out_unlock;
> -	dma_resv_unlock(bo->base.resv);
> -
> -out_unlock:
> -	mutex_unlock(&bo->wu_mutex);
> -	return ret;
> -}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 6b0883a1776e..2b0e5a088da0 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -504,7 +504,6 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
>  	INIT_LIST_HEAD(&fbo->base.lru);
>  	INIT_LIST_HEAD(&fbo->base.swap);
>  	INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
> -	mutex_init(&fbo->base.wu_mutex);
>  	fbo->base.moving = NULL;
>  	drm_vma_node_reset(&fbo->base.base.vma_node);
>  
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 11863fbdd5d6..91466cfb6f16 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -128,30 +128,22 @@ static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
>  vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
>  			     struct vm_fault *vmf)
>  {
> -	/*
> -	 * Work around locking order reversal in fault / nopfn
> -	 * between mmap_sem and bo_reserve: Perform a trylock operation
> -	 * for reserve, and if it fails, retry the fault after waiting
> -	 * for the buffer to become unreserved.
> -	 */
>  	if (unlikely(!dma_resv_trylock(bo->base.resv))) {
>  		if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
>  			if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
>  				ttm_bo_get(bo);
>  				up_read(&vmf->vma->vm_mm->mmap_sem);
> -				(void) ttm_bo_wait_unreserved(bo);
> +				if (!dma_resv_lock_interruptible(bo->base.resv,
> +								 NULL))
> +					dma_resv_unlock(bo->base.resv);
>  				ttm_bo_put(bo);
>  			}
>  
>  			return VM_FAULT_RETRY;
>  		}
>  
> -		/*
> -		 * If we'd want to change locking order to
> -		 * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> -		 * instead of retrying the fault...
> -		 */
> -		return VM_FAULT_NOPAGE;
> +		if (dma_resv_lock_interruptible(bo->base.resv, NULL))
> +			return VM_FAULT_NOPAGE;
>  	}
>  
>  	return 0;
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 65e399d280f7..e8b0f0c66059 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -154,7 +154,6 @@ struct ttm_tt;
>   * @offset: The current GPU offset, which can have different meanings
>   * depending on the memory type. For SYSTEM type memory, it should be 0.
>   * @cur_placement: Hint of current placement.
> - * @wu_mutex: Wait unreserved mutex.
>   *
>   * Base class for TTM buffer object, that deals with data placement and CPU
>   * mappings. GPU mappings are really up to the driver, but for simpler GPUs
> @@ -222,8 +221,6 @@ struct ttm_buffer_object {
>  	uint64_t offset; /* GPU address space is independent of CPU word size */
>  
>  	struct sg_table *sg;
> -
> -	struct mutex wu_mutex;
>  };
>  
>  /**
> @@ -707,7 +704,6 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
>  int ttm_bo_swapout(struct ttm_bo_global *glob,
>  			struct ttm_operation_ctx *ctx);
>  void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
>  
>  /**
>   * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

[Daniel Vetter]

On Mon, Nov 04, 2019 at 06:38:01PM +0100, Daniel Vetter wrote:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
> 
> Assuming I didn't screw up anything with my audit of course.
> 
> v2:
> - Dont forget wu_mutex (Christian König)
> - Keep the mmap_sem-less wait optimization (Thomas)
> - Use _lock_interruptible to be good citizens (Thomas)
> 
> v3: Rebase over fault handler helperification.
> 
> Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
> Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2)
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>

Entire series merged into drm-misc-next (probably for 5.6) with Dave's
irc-ack for the nouveau patch.
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c      | 36 -------------------------------
>  drivers/gpu/drm/ttm/ttm_bo_util.c |  1 -
>  drivers/gpu/drm/ttm/ttm_bo_vm.c   | 18 +++++-----------
>  include/drm/ttm/ttm_bo_api.h      |  4 ----
>  4 files changed, 5 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8d91b0428af1..5df596fb0280 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -161,7 +161,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
>  	dma_fence_put(bo->moving);
>  	if (!ttm_bo_uses_embedded_gem_object(bo))
>  		dma_resv_fini(&bo->base._resv);
> -	mutex_destroy(&bo->wu_mutex);
>  	bo->destroy(bo);
>  	ttm_mem_global_free(&ttm_mem_glob, acc_size);
>  }
> @@ -1299,7 +1298,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
>  	INIT_LIST_HEAD(&bo->ddestroy);
>  	INIT_LIST_HEAD(&bo->swap);
>  	INIT_LIST_HEAD(&bo->io_reserve_lru);
> -	mutex_init(&bo->wu_mutex);
>  	bo->bdev = bdev;
>  	bo->type = type;
>  	bo->num_pages = num_pages;
> @@ -1903,37 +1901,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
>  	while (ttm_bo_swapout(&ttm_bo_glob, &ctx) == 0);
>  }
>  EXPORT_SYMBOL(ttm_bo_swapout_all);
> -
> -/**
> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
> - * unreserved
> - *
> - * @bo: Pointer to buffer
> - */
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> -{
> -	int ret;
> -
> -	/*
> -	 * In the absense of a wait_unlocked API,
> -	 * Use the bo::wu_mutex to avoid triggering livelocks due to
> -	 * concurrent use of this function. Note that this use of
> -	 * bo::wu_mutex can go away if we change locking order to
> -	 * mmap_sem -> bo::reserve.
> -	 */
> -	ret = mutex_lock_interruptible(&bo->wu_mutex);
> -	if (unlikely(ret != 0))
> -		return -ERESTARTSYS;
> -	if (!dma_resv_is_locked(bo->base.resv))
> -		goto out_unlock;
> -	ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> -	if (ret == -EINTR)
> -		ret = -ERESTARTSYS;
> -	if (unlikely(ret != 0))
> -		goto out_unlock;
> -	dma_resv_unlock(bo->base.resv);
> -
> -out_unlock:
> -	mutex_unlock(&bo->wu_mutex);
> -	return ret;
> -}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 6b0883a1776e..2b0e5a088da0 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -504,7 +504,6 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
>  	INIT_LIST_HEAD(&fbo->base.lru);
>  	INIT_LIST_HEAD(&fbo->base.swap);
>  	INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
> -	mutex_init(&fbo->base.wu_mutex);
>  	fbo->base.moving = NULL;
>  	drm_vma_node_reset(&fbo->base.base.vma_node);
>  
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 11863fbdd5d6..91466cfb6f16 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -128,30 +128,22 @@ static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
>  vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
>  			     struct vm_fault *vmf)
>  {
> -	/*
> -	 * Work around locking order reversal in fault / nopfn
> -	 * between mmap_sem and bo_reserve: Perform a trylock operation
> -	 * for reserve, and if it fails, retry the fault after waiting
> -	 * for the buffer to become unreserved.
> -	 */
>  	if (unlikely(!dma_resv_trylock(bo->base.resv))) {
>  		if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
>  			if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
>  				ttm_bo_get(bo);
>  				up_read(&vmf->vma->vm_mm->mmap_sem);
> -				(void) ttm_bo_wait_unreserved(bo);
> +				if (!dma_resv_lock_interruptible(bo->base.resv,
> +								 NULL))
> +					dma_resv_unlock(bo->base.resv);
>  				ttm_bo_put(bo);
>  			}
>  
>  			return VM_FAULT_RETRY;
>  		}
>  
> -		/*
> -		 * If we'd want to change locking order to
> -		 * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> -		 * instead of retrying the fault...
> -		 */
> -		return VM_FAULT_NOPAGE;
> +		if (dma_resv_lock_interruptible(bo->base.resv, NULL))
> +			return VM_FAULT_NOPAGE;
>  	}
>  
>  	return 0;
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 65e399d280f7..e8b0f0c66059 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -154,7 +154,6 @@ struct ttm_tt;
>   * @offset: The current GPU offset, which can have different meanings
>   * depending on the memory type. For SYSTEM type memory, it should be 0.
>   * @cur_placement: Hint of current placement.
> - * @wu_mutex: Wait unreserved mutex.
>   *
>   * Base class for TTM buffer object, that deals with data placement and CPU
>   * mappings. GPU mappings are really up to the driver, but for simpler GPUs
> @@ -222,8 +221,6 @@ struct ttm_buffer_object {
>  	uint64_t offset; /* GPU address space is independent of CPU word size */
>  
>  	struct sg_table *sg;
> -
> -	struct mutex wu_mutex;
>  };
>  
>  /**
> @@ -707,7 +704,6 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
>  int ttm_bo_swapout(struct ttm_bo_global *glob,
>  			struct ttm_operation_ctx *ctx);
>  void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
>  
>  /**
>   * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
> -- 
> 2.24.0.rc2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Steven Price]

On 04/11/2019 17:37, Daniel Vetter wrote:
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
> 
> v4: Annotate with __init (Rob Herring)
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  	kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	

Nit: trailing whitespace

> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);

This expects a function returning int, but dma_resv_lockdep() is void.
Causing:

drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
{aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
[-Werror=incompatible-pointer-types]
 subsys_initcall(dma_resv_lockdep);

The below fixes it for me.

Steve

----8<----
From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001
From: Steven Price <steven.price@arm.com>
Date: Mon, 11 Nov 2019 13:07:19 +0000
Subject: [PATCH] dma_resv: Correct return type of dma_resv_lockdep()

subsys_initcall() expects a function which returns 'int'. Fix
dma_resv_lockdep() so it returns an 'int' error code.

Fixes: b2a8116e2592 ("dma_resv: prime lockdep annotations")
Signed-off-by: Steven Price <steven.price@arm.com>
---
 drivers/dma-buf/dma-resv.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a05ff542be22..9918a6e5cf91 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -97,13 +97,13 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 }
 
 #if IS_ENABLED(CONFIG_LOCKDEP)
-static void __init dma_resv_lockdep(void)
+static int __init dma_resv_lockdep(void)
 {
 	struct mm_struct *mm = mm_alloc();
 	struct dma_resv obj;
 
 	if (!mm)
-		return;
+		return -ENOMEM;
 
 	dma_resv_init(&obj);
 
@@ -115,6 +115,8 @@ static void __init dma_resv_lockdep(void)
 	up_read(&mm->mmap_sem);
 	
 	mmput(mm);
+
+	return 0;
 }
 subsys_initcall(dma_resv_lockdep);
 #endif
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Steven Price]

On 04/11/2019 17:37, Daniel Vetter wrote:
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
> 
> v4: Annotate with __init (Rob Herring)
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  	kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> +	struct mm_struct *mm = mm_alloc();
> +	struct dma_resv obj;
> +
> +	if (!mm)
> +		return;
> +
> +	dma_resv_init(&obj);
> +
> +	down_read(&mm->mmap_sem);
> +	ww_mutex_lock(&obj.lock, NULL);
> +	fs_reclaim_acquire(GFP_KERNEL);
> +	fs_reclaim_release(GFP_KERNEL);
> +	ww_mutex_unlock(&obj.lock);
> +	up_read(&mm->mmap_sem);
> +	

Nit: trailing whitespace

> +	mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);

This expects a function returning int, but dma_resv_lockdep() is void.
Causing:

drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
{aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
[-Werror=incompatible-pointer-types]
 subsys_initcall(dma_resv_lockdep);

The below fixes it for me.

Steve

----8<----
From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001
From: Steven Price <steven.price@arm.com>
Date: Mon, 11 Nov 2019 13:07:19 +0000
Subject: [PATCH] dma_resv: Correct return type of dma_resv_lockdep()

subsys_initcall() expects a function which returns 'int'. Fix
dma_resv_lockdep() so it returns an 'int' error code.

Fixes: b2a8116e2592 ("dma_resv: prime lockdep annotations")
Signed-off-by: Steven Price <steven.price@arm.com>
---
 drivers/dma-buf/dma-resv.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a05ff542be22..9918a6e5cf91 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -97,13 +97,13 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 }
 
 #if IS_ENABLED(CONFIG_LOCKDEP)
-static void __init dma_resv_lockdep(void)
+static int __init dma_resv_lockdep(void)
 {
 	struct mm_struct *mm = mm_alloc();
 	struct dma_resv obj;
 
 	if (!mm)
-		return;
+		return -ENOMEM;
 
 	dma_resv_init(&obj);
 
@@ -115,6 +115,8 @@ static void __init dma_resv_lockdep(void)
 	up_read(&mm->mmap_sem);
 	
 	mmput(mm);
+
+	return 0;
 }
 subsys_initcall(dma_resv_lockdep);
 #endif
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>
> On 04/11/2019 17:37, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >   really no business holding struct_mutex while doing copy_*_user. But
> >   I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >   looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >   copying from/to userspace happens all in v3d_lookup_bos which is
> >   outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >   - vmw_execbuf_process: First this does some copies in
> >     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >     Then comes the usual ttm reserve/validate sequence, then actual
> >     submission/fencing, then unreserving, and finally some more
> >     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >     details, but looks all safe.
> >   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >     seen, seems to only create a fence and copy it out.
> >   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >     found there.
> >   Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >   copying from userspace before even looking up objects through their
> >   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >   qxl_process_single_command. There's a lovely comment before the
> >   __copy_from_user_inatomic that the slowpath should be copied from
> >   i915, but I guess that never happened. Try not to be unlucky and get
> >   your CS data evicted between when it's written and the kernel tries
> >   to read it. The only other copy_from_user is for relocs, but those
> >   are done before qxl_release_reserve_list(), which seems to be the
> >   only thing reserving buffers (in the ttm/dma_resv sense) in that
> >   code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >   everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> >  #include <linux/dma-resv.h>
> >  #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >
> >  /**
> >   * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >       kfree_rcu(list, rcu);
> >  }
> >
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +     struct mm_struct *mm = mm_alloc();
> > +     struct dma_resv obj;
> > +
> > +     if (!mm)
> > +             return;
> > +
> > +     dma_resv_init(&obj);
> > +
> > +     down_read(&mm->mmap_sem);
> > +     ww_mutex_lock(&obj.lock, NULL);
> > +     fs_reclaim_acquire(GFP_KERNEL);
> > +     fs_reclaim_release(GFP_KERNEL);
> > +     ww_mutex_unlock(&obj.lock);
> > +     up_read(&mm->mmap_sem);
> > +
>
> Nit: trailing whitespace
>
> > +     mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
>
> This expects a function returning int, but dma_resv_lockdep() is void.
> Causing:
>
> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> [-Werror=incompatible-pointer-types]
>  subsys_initcall(dma_resv_lockdep);
>
> The below fixes it for me.

Uh, so _that_ was what the 0day thing was all about, I totally misread
that completely. Thanks for the patch.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Aside, do you need commit rights for pushing this kind of stuff?
-Daniel

>
> Steve
>
> ----8<----
> From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001
> From: Steven Price <steven.price@arm.com>
> Date: Mon, 11 Nov 2019 13:07:19 +0000
> Subject: [PATCH] dma_resv: Correct return type of dma_resv_lockdep()
>
> subsys_initcall() expects a function which returns 'int'. Fix
> dma_resv_lockdep() so it returns an 'int' error code.
>
> Fixes: b2a8116e2592 ("dma_resv: prime lockdep annotations")
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
>  drivers/dma-buf/dma-resv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index a05ff542be22..9918a6e5cf91 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -97,13 +97,13 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  }
>
>  #if IS_ENABLED(CONFIG_LOCKDEP)
> -static void __init dma_resv_lockdep(void)
> +static int __init dma_resv_lockdep(void)
>  {
>         struct mm_struct *mm = mm_alloc();
>         struct dma_resv obj;
>
>         if (!mm)
> -               return;
> +               return -ENOMEM;
>
>         dma_resv_init(&obj);
>
> @@ -115,6 +115,8 @@ static void __init dma_resv_lockdep(void)
>         up_read(&mm->mmap_sem);
>
>         mmput(mm);
> +
> +       return 0;
>  }
>  subsys_initcall(dma_resv_lockdep);
>  #endif
> --
> 2.20.1
>


-- 
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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>
> On 04/11/2019 17:37, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >   really no business holding struct_mutex while doing copy_*_user. But
> >   I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >   looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >   copying from/to userspace happens all in v3d_lookup_bos which is
> >   outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >   - vmw_execbuf_process: First this does some copies in
> >     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >     Then comes the usual ttm reserve/validate sequence, then actual
> >     submission/fencing, then unreserving, and finally some more
> >     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >     details, but looks all safe.
> >   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >     seen, seems to only create a fence and copy it out.
> >   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >     found there.
> >   Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >   copying from userspace before even looking up objects through their
> >   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >   qxl_process_single_command. There's a lovely comment before the
> >   __copy_from_user_inatomic that the slowpath should be copied from
> >   i915, but I guess that never happened. Try not to be unlucky and get
> >   your CS data evicted between when it's written and the kernel tries
> >   to read it. The only other copy_from_user is for relocs, but those
> >   are done before qxl_release_reserve_list(), which seems to be the
> >   only thing reserving buffers (in the ttm/dma_resv sense) in that
> >   code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >   everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> >  #include <linux/dma-resv.h>
> >  #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >
> >  /**
> >   * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >       kfree_rcu(list, rcu);
> >  }
> >
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +     struct mm_struct *mm = mm_alloc();
> > +     struct dma_resv obj;
> > +
> > +     if (!mm)
> > +             return;
> > +
> > +     dma_resv_init(&obj);
> > +
> > +     down_read(&mm->mmap_sem);
> > +     ww_mutex_lock(&obj.lock, NULL);
> > +     fs_reclaim_acquire(GFP_KERNEL);
> > +     fs_reclaim_release(GFP_KERNEL);
> > +     ww_mutex_unlock(&obj.lock);
> > +     up_read(&mm->mmap_sem);
> > +
>
> Nit: trailing whitespace
>
> > +     mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
>
> This expects a function returning int, but dma_resv_lockdep() is void.
> Causing:
>
> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> [-Werror=incompatible-pointer-types]
>  subsys_initcall(dma_resv_lockdep);
>
> The below fixes it for me.

Uh, so _that_ was what the 0day thing was all about, I totally misread
that completely. Thanks for the patch.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Aside, do you need commit rights for pushing this kind of stuff?
-Daniel

>
> Steve
>
> ----8<----
> From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001
> From: Steven Price <steven.price@arm.com>
> Date: Mon, 11 Nov 2019 13:07:19 +0000
> Subject: [PATCH] dma_resv: Correct return type of dma_resv_lockdep()
>
> subsys_initcall() expects a function which returns 'int'. Fix
> dma_resv_lockdep() so it returns an 'int' error code.
>
> Fixes: b2a8116e2592 ("dma_resv: prime lockdep annotations")
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
>  drivers/dma-buf/dma-resv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index a05ff542be22..9918a6e5cf91 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -97,13 +97,13 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  }
>
>  #if IS_ENABLED(CONFIG_LOCKDEP)
> -static void __init dma_resv_lockdep(void)
> +static int __init dma_resv_lockdep(void)
>  {
>         struct mm_struct *mm = mm_alloc();
>         struct dma_resv obj;
>
>         if (!mm)
> -               return;
> +               return -ENOMEM;
>
>         dma_resv_init(&obj);
>
> @@ -115,6 +115,8 @@ static void __init dma_resv_lockdep(void)
>         up_read(&mm->mmap_sem);
>
>         mmput(mm);
> +
> +       return 0;
>  }
>  subsys_initcall(dma_resv_lockdep);
>  #endif
> --
> 2.20.1
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>
> On 04/11/2019 17:37, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >   really no business holding struct_mutex while doing copy_*_user. But
> >   I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >   looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >   copying from/to userspace happens all in v3d_lookup_bos which is
> >   outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >   - vmw_execbuf_process: First this does some copies in
> >     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >     Then comes the usual ttm reserve/validate sequence, then actual
> >     submission/fencing, then unreserving, and finally some more
> >     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >     details, but looks all safe.
> >   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >     seen, seems to only create a fence and copy it out.
> >   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >     found there.
> >   Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >   copying from userspace before even looking up objects through their
> >   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >   qxl_process_single_command. There's a lovely comment before the
> >   __copy_from_user_inatomic that the slowpath should be copied from
> >   i915, but I guess that never happened. Try not to be unlucky and get
> >   your CS data evicted between when it's written and the kernel tries
> >   to read it. The only other copy_from_user is for relocs, but those
> >   are done before qxl_release_reserve_list(), which seems to be the
> >   only thing reserving buffers (in the ttm/dma_resv sense) in that
> >   code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >   everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> >  #include <linux/dma-resv.h>
> >  #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >
> >  /**
> >   * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >       kfree_rcu(list, rcu);
> >  }
> >
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > +     struct mm_struct *mm = mm_alloc();
> > +     struct dma_resv obj;
> > +
> > +     if (!mm)
> > +             return;
> > +
> > +     dma_resv_init(&obj);
> > +
> > +     down_read(&mm->mmap_sem);
> > +     ww_mutex_lock(&obj.lock, NULL);
> > +     fs_reclaim_acquire(GFP_KERNEL);
> > +     fs_reclaim_release(GFP_KERNEL);
> > +     ww_mutex_unlock(&obj.lock);
> > +     up_read(&mm->mmap_sem);
> > +
>
> Nit: trailing whitespace
>
> > +     mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
>
> This expects a function returning int, but dma_resv_lockdep() is void.
> Causing:
>
> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> [-Werror=incompatible-pointer-types]
>  subsys_initcall(dma_resv_lockdep);
>
> The below fixes it for me.

Uh, so _that_ was what the 0day thing was all about, I totally misread
that completely. Thanks for the patch.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Aside, do you need commit rights for pushing this kind of stuff?
-Daniel

>
> Steve
>
> ----8<----
> From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001
> From: Steven Price <steven.price@arm.com>
> Date: Mon, 11 Nov 2019 13:07:19 +0000
> Subject: [PATCH] dma_resv: Correct return type of dma_resv_lockdep()
>
> subsys_initcall() expects a function which returns 'int'. Fix
> dma_resv_lockdep() so it returns an 'int' error code.
>
> Fixes: b2a8116e2592 ("dma_resv: prime lockdep annotations")
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
>  drivers/dma-buf/dma-resv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index a05ff542be22..9918a6e5cf91 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -97,13 +97,13 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>  }
>
>  #if IS_ENABLED(CONFIG_LOCKDEP)
> -static void __init dma_resv_lockdep(void)
> +static int __init dma_resv_lockdep(void)
>  {
>         struct mm_struct *mm = mm_alloc();
>         struct dma_resv obj;
>
>         if (!mm)
> -               return;
> +               return -ENOMEM;
>
>         dma_resv_init(&obj);
>
> @@ -115,6 +115,8 @@ static void __init dma_resv_lockdep(void)
>         up_read(&mm->mmap_sem);
>
>         mmput(mm);
> +
> +       return 0;
>  }
>  subsys_initcall(dma_resv_lockdep);
>  #endif
> --
> 2.20.1
>


-- 
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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
URL   : https://patchwork.freedesktop.org/series/68958/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
87afb1ee808f dma_resv: prime lockdep annotations
-:106: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#106: 
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)

-:148: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit fatal: bad o ("f42d23dbcca2da2f8")'
#148: 
From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001

total: 1 errors, 1 warnings, 0 checks, 23 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
URL   : https://patchwork.freedesktop.org/series/68958/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
87afb1ee808f dma_resv: prime lockdep annotations
-:106: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#106: 
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)

-:148: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit fatal: bad o ("f42d23dbcca2da2f8")'
#148: 
From d07ea81611ed6e4fb8cc290f42d23dbcca2da2f8 Mon Sep 17 00:00:00 2001

total: 1 errors, 1 warnings, 0 checks, 23 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
URL   : https://patchwork.freedesktop.org/series/68958/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7310 -> Patchwork_15218
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_15218 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15218, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_15218:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_blt:
    - fi-hsw-peppy:       [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
Known issues
------------

  Here are the changes found in Patchwork_15218 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_chamelium@dp-crc-fast:
    - fi-kbl-7500u:       [PASS][3] -> [FAIL][4] ([fdo#109635 ] / [fdo#110387])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-skl-6770hq:      [PASS][5] -> [FAIL][6] ([fdo#109495])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
    - fi-skl-6770hq:      [PASS][7] -> [DMESG-WARN][8] ([fdo#105541])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
#### Possible fixes ####

  * igt@kms_chamelium@dp-edid-read:
    - fi-icl-u4:          [FAIL][9] ([fdo#111045]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-icl-u4/igt@kms_chamelium@dp-edid-read.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-icl-u4/igt@kms_chamelium@dp-edid-read.html

  * igt@kms_setmode@basic-clone-single-crtc:
    - fi-skl-6770hq:      [WARN][11] -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_setmode@basic-clone-single-crtc.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_setmode@basic-clone-single-crtc.html

  
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109495]: https://bugs.freedesktop.org/show_bug.cgi?id=109495
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045


Participating hosts (51 -> 44)
------------------------------

  Additional (1): fi-bwr-2160 
  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7310 -> Patchwork_15218

  CI-20190529: 20190529
  CI_DRM_7310: f3edc24676599b6c4e6ab713030ae630e864e732 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5271: 05f0400c50af843df301efb5475e9f5e2d16a098 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15218: 87afb1ee808f83018fadc5214536580d0501c0e4 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

87afb1ee808f dma_resv: prime lockdep annotations

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
URL   : https://patchwork.freedesktop.org/series/68958/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7310 -> Patchwork_15218
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_15218 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15218, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_15218:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_blt:
    - fi-hsw-peppy:       [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
Known issues
------------

  Here are the changes found in Patchwork_15218 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_chamelium@dp-crc-fast:
    - fi-kbl-7500u:       [PASS][3] -> [FAIL][4] ([fdo#109635 ] / [fdo#110387])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-skl-6770hq:      [PASS][5] -> [FAIL][6] ([fdo#109495])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
    - fi-skl-6770hq:      [PASS][7] -> [DMESG-WARN][8] ([fdo#105541])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
#### Possible fixes ####

  * igt@kms_chamelium@dp-edid-read:
    - fi-icl-u4:          [FAIL][9] ([fdo#111045]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-icl-u4/igt@kms_chamelium@dp-edid-read.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-icl-u4/igt@kms_chamelium@dp-edid-read.html

  * igt@kms_setmode@basic-clone-single-crtc:
    - fi-skl-6770hq:      [WARN][11] -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7310/fi-skl-6770hq/igt@kms_setmode@basic-clone-single-crtc.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/fi-skl-6770hq/igt@kms_setmode@basic-clone-single-crtc.html

  
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109495]: https://bugs.freedesktop.org/show_bug.cgi?id=109495
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045


Participating hosts (51 -> 44)
------------------------------

  Additional (1): fi-bwr-2160 
  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7310 -> Patchwork_15218

  CI-20190529: 20190529
  CI_DRM_7310: f3edc24676599b6c4e6ab713030ae630e864e732 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5271: 05f0400c50af843df301efb5475e9f5e2d16a098 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15218: 87afb1ee808f83018fadc5214536580d0501c0e4 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

87afb1ee808f dma_resv: prime lockdep annotations

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15218/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Steven Price]

On 11/11/2019 15:42, Daniel Vetter wrote:
> On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>>
>> On 04/11/2019 17:37, Daniel Vetter wrote:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>
>>> - vram helpers should be fine, they don't do command submission, so
>>>   really no business holding struct_mutex while doing copy_*_user. But
>>>   I haven't checked them all.
>>>
>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>   looks clean.
>>>
>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>   copying from/to userspace happens all in v3d_lookup_bos which is
>>>   outside of the critical section.
>>>
>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>   - vmw_execbuf_process: First this does some copies in
>>>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>     Then comes the usual ttm reserve/validate sequence, then actual
>>>     submission/fencing, then unreserving, and finally some more
>>>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>     details, but looks all safe.
>>>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>     seen, seems to only create a fence and copy it out.
>>>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>     found there.
>>>   Summary: vmwgfx seems to be fine too.
>>>
>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>   copying from userspace before even looking up objects through their
>>>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>
>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>   qxl_process_single_command. There's a lovely comment before the
>>>   __copy_from_user_inatomic that the slowpath should be copied from
>>>   i915, but I guess that never happened. Try not to be unlucky and get
>>>   your CS data evicted between when it's written and the kernel tries
>>>   to read it. The only other copy_from_user is for relocs, but those
>>>   are done before qxl_release_reserve_list(), which seems to be the
>>>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>   code. So looks safe.
>>>
>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>   everywhere and needs to be fixed up.
>>>
>>> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
>>> dma_resv lock of a different object already. Christian mentioned that
>>> ttm core does this too for ghost objects. intel-gfx-ci highlighted
>>> that i915 has similar issues.
>>>
>>> Unfortunately we can't do this in the usual module init functions,
>>> because kernel threads don't have an ->mm - we have to wait around for
>>> some user thread to do this.
>>>
>>> Solution is to spawn a worker (but only once). It's horrible, but it
>>> works.
>>>
>>> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
>>> initcall solution in.
>>>
>>> v4: Annotate with __init (Rob Herring)
>>>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>> Cc: Eric Anholt <eric@anholt.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>> index 709002515550..a05ff542be22 100644
>>> --- a/drivers/dma-buf/dma-resv.c
>>> +++ b/drivers/dma-buf/dma-resv.c
>>> @@ -34,6 +34,7 @@
>>>
>>>  #include <linux/dma-resv.h>
>>>  #include <linux/export.h>
>>> +#include <linux/sched/mm.h>
>>>
>>>  /**
>>>   * DOC: Reservation Object Overview
>>> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>>>       kfree_rcu(list, rcu);
>>>  }
>>>
>>> +#if IS_ENABLED(CONFIG_LOCKDEP)
>>> +static void __init dma_resv_lockdep(void)
>>> +{
>>> +     struct mm_struct *mm = mm_alloc();
>>> +     struct dma_resv obj;
>>> +
>>> +     if (!mm)
>>> +             return;
>>> +
>>> +     dma_resv_init(&obj);
>>> +
>>> +     down_read(&mm->mmap_sem);
>>> +     ww_mutex_lock(&obj.lock, NULL);
>>> +     fs_reclaim_acquire(GFP_KERNEL);
>>> +     fs_reclaim_release(GFP_KERNEL);
>>> +     ww_mutex_unlock(&obj.lock);
>>> +     up_read(&mm->mmap_sem);
>>> +
>>
>> Nit: trailing whitespace
>>
>>> +     mmput(mm);
>>> +}
>>> +subsys_initcall(dma_resv_lockdep);
>>
>> This expects a function returning int, but dma_resv_lockdep() is void.
>> Causing:
>>
>> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
>> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
>> [-Werror=incompatible-pointer-types]
>>  subsys_initcall(dma_resv_lockdep);
>>
>> The below fixes it for me.
> 
> Uh, so _that_ was what the 0day thing was all about, I totally misread
> that completely. Thanks for the patch.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Aside, do you need commit rights for pushing this kind of stuff?

I guess it's about time I got round to requesting that:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/208

Thanks,

Steve
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Steven Price]

On 11/11/2019 15:42, Daniel Vetter wrote:
> On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>>
>> On 04/11/2019 17:37, Daniel Vetter wrote:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>
>>> - vram helpers should be fine, they don't do command submission, so
>>>   really no business holding struct_mutex while doing copy_*_user. But
>>>   I haven't checked them all.
>>>
>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>   looks clean.
>>>
>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>   copying from/to userspace happens all in v3d_lookup_bos which is
>>>   outside of the critical section.
>>>
>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>   - vmw_execbuf_process: First this does some copies in
>>>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>     Then comes the usual ttm reserve/validate sequence, then actual
>>>     submission/fencing, then unreserving, and finally some more
>>>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>     details, but looks all safe.
>>>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>     seen, seems to only create a fence and copy it out.
>>>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>     found there.
>>>   Summary: vmwgfx seems to be fine too.
>>>
>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>   copying from userspace before even looking up objects through their
>>>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>
>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>   qxl_process_single_command. There's a lovely comment before the
>>>   __copy_from_user_inatomic that the slowpath should be copied from
>>>   i915, but I guess that never happened. Try not to be unlucky and get
>>>   your CS data evicted between when it's written and the kernel tries
>>>   to read it. The only other copy_from_user is for relocs, but those
>>>   are done before qxl_release_reserve_list(), which seems to be the
>>>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>   code. So looks safe.
>>>
>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>   everywhere and needs to be fixed up.
>>>
>>> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
>>> dma_resv lock of a different object already. Christian mentioned that
>>> ttm core does this too for ghost objects. intel-gfx-ci highlighted
>>> that i915 has similar issues.
>>>
>>> Unfortunately we can't do this in the usual module init functions,
>>> because kernel threads don't have an ->mm - we have to wait around for
>>> some user thread to do this.
>>>
>>> Solution is to spawn a worker (but only once). It's horrible, but it
>>> works.
>>>
>>> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
>>> initcall solution in.
>>>
>>> v4: Annotate with __init (Rob Herring)
>>>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>> Cc: Eric Anholt <eric@anholt.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>> index 709002515550..a05ff542be22 100644
>>> --- a/drivers/dma-buf/dma-resv.c
>>> +++ b/drivers/dma-buf/dma-resv.c
>>> @@ -34,6 +34,7 @@
>>>
>>>  #include <linux/dma-resv.h>
>>>  #include <linux/export.h>
>>> +#include <linux/sched/mm.h>
>>>
>>>  /**
>>>   * DOC: Reservation Object Overview
>>> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>>>       kfree_rcu(list, rcu);
>>>  }
>>>
>>> +#if IS_ENABLED(CONFIG_LOCKDEP)
>>> +static void __init dma_resv_lockdep(void)
>>> +{
>>> +     struct mm_struct *mm = mm_alloc();
>>> +     struct dma_resv obj;
>>> +
>>> +     if (!mm)
>>> +             return;
>>> +
>>> +     dma_resv_init(&obj);
>>> +
>>> +     down_read(&mm->mmap_sem);
>>> +     ww_mutex_lock(&obj.lock, NULL);
>>> +     fs_reclaim_acquire(GFP_KERNEL);
>>> +     fs_reclaim_release(GFP_KERNEL);
>>> +     ww_mutex_unlock(&obj.lock);
>>> +     up_read(&mm->mmap_sem);
>>> +
>>
>> Nit: trailing whitespace
>>
>>> +     mmput(mm);
>>> +}
>>> +subsys_initcall(dma_resv_lockdep);
>>
>> This expects a function returning int, but dma_resv_lockdep() is void.
>> Causing:
>>
>> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
>> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
>> [-Werror=incompatible-pointer-types]
>>  subsys_initcall(dma_resv_lockdep);
>>
>> The below fixes it for me.
> 
> Uh, so _that_ was what the 0day thing was all about, I totally misread
> that completely. Thanks for the patch.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Aside, do you need commit rights for pushing this kind of stuff?

I guess it's about time I got round to requesting that:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/208

Thanks,

Steve
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Steven Price]

On 11/11/2019 15:42, Daniel Vetter wrote:
> On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
>>
>> On 04/11/2019 17:37, Daniel Vetter wrote:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>
>>> - vram helpers should be fine, they don't do command submission, so
>>>   really no business holding struct_mutex while doing copy_*_user. But
>>>   I haven't checked them all.
>>>
>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>   looks clean.
>>>
>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>   copying from/to userspace happens all in v3d_lookup_bos which is
>>>   outside of the critical section.
>>>
>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>   - vmw_execbuf_process: First this does some copies in
>>>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>     Then comes the usual ttm reserve/validate sequence, then actual
>>>     submission/fencing, then unreserving, and finally some more
>>>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>     details, but looks all safe.
>>>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>     seen, seems to only create a fence and copy it out.
>>>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>     found there.
>>>   Summary: vmwgfx seems to be fine too.
>>>
>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>   copying from userspace before even looking up objects through their
>>>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>
>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>   qxl_process_single_command. There's a lovely comment before the
>>>   __copy_from_user_inatomic that the slowpath should be copied from
>>>   i915, but I guess that never happened. Try not to be unlucky and get
>>>   your CS data evicted between when it's written and the kernel tries
>>>   to read it. The only other copy_from_user is for relocs, but those
>>>   are done before qxl_release_reserve_list(), which seems to be the
>>>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>   code. So looks safe.
>>>
>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>   everywhere and needs to be fixed up.
>>>
>>> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
>>> dma_resv lock of a different object already. Christian mentioned that
>>> ttm core does this too for ghost objects. intel-gfx-ci highlighted
>>> that i915 has similar issues.
>>>
>>> Unfortunately we can't do this in the usual module init functions,
>>> because kernel threads don't have an ->mm - we have to wait around for
>>> some user thread to do this.
>>>
>>> Solution is to spawn a worker (but only once). It's horrible, but it
>>> works.
>>>
>>> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
>>> initcall solution in.
>>>
>>> v4: Annotate with __init (Rob Herring)
>>>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>> Cc: Eric Anholt <eric@anholt.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>> index 709002515550..a05ff542be22 100644
>>> --- a/drivers/dma-buf/dma-resv.c
>>> +++ b/drivers/dma-buf/dma-resv.c
>>> @@ -34,6 +34,7 @@
>>>
>>>  #include <linux/dma-resv.h>
>>>  #include <linux/export.h>
>>> +#include <linux/sched/mm.h>
>>>
>>>  /**
>>>   * DOC: Reservation Object Overview
>>> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>>>       kfree_rcu(list, rcu);
>>>  }
>>>
>>> +#if IS_ENABLED(CONFIG_LOCKDEP)
>>> +static void __init dma_resv_lockdep(void)
>>> +{
>>> +     struct mm_struct *mm = mm_alloc();
>>> +     struct dma_resv obj;
>>> +
>>> +     if (!mm)
>>> +             return;
>>> +
>>> +     dma_resv_init(&obj);
>>> +
>>> +     down_read(&mm->mmap_sem);
>>> +     ww_mutex_lock(&obj.lock, NULL);
>>> +     fs_reclaim_acquire(GFP_KERNEL);
>>> +     fs_reclaim_release(GFP_KERNEL);
>>> +     ww_mutex_unlock(&obj.lock);
>>> +     up_read(&mm->mmap_sem);
>>> +
>>
>> Nit: trailing whitespace
>>
>>> +     mmput(mm);
>>> +}
>>> +subsys_initcall(dma_resv_lockdep);
>>
>> This expects a function returning int, but dma_resv_lockdep() is void.
>> Causing:
>>
>> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
>> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
>> [-Werror=incompatible-pointer-types]
>>  subsys_initcall(dma_resv_lockdep);
>>
>> The below fixes it for me.
> 
> Uh, so _that_ was what the 0day thing was all about, I totally misread
> that completely. Thanks for the patch.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Aside, do you need commit rights for pushing this kind of stuff?

I guess it's about time I got round to requesting that:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/208

Thanks,

Steve
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Thu, Nov 14, 2019 at 11:50:28AM +0000, Steven Price wrote:
> On 11/11/2019 15:42, Daniel Vetter wrote:
> > On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
> >>
> >> On 04/11/2019 17:37, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgpu should be clean per their maintainers.
> >>>
> >>> - vram helpers should be fine, they don't do command submission, so
> >>>   really no business holding struct_mutex while doing copy_*_user. But
> >>>   I haven't checked them all.
> >>>
> >>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >>>   looks clean.
> >>>
> >>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >>>   copying from/to userspace happens all in v3d_lookup_bos which is
> >>>   outside of the critical section.
> >>>
> >>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >>>   - vmw_execbuf_process: First this does some copies in
> >>>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >>>     Then comes the usual ttm reserve/validate sequence, then actual
> >>>     submission/fencing, then unreserving, and finally some more
> >>>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >>>     details, but looks all safe.
> >>>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >>>     seen, seems to only create a fence and copy it out.
> >>>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >>>     found there.
> >>>   Summary: vmwgfx seems to be fine too.
> >>>
> >>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >>>   copying from userspace before even looking up objects through their
> >>>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >>>
> >>> - qxl only has qxl_execbuffer_ioctl, which calls into
> >>>   qxl_process_single_command. There's a lovely comment before the
> >>>   __copy_from_user_inatomic that the slowpath should be copied from
> >>>   i915, but I guess that never happened. Try not to be unlucky and get
> >>>   your CS data evicted between when it's written and the kernel tries
> >>>   to read it. The only other copy_from_user is for relocs, but those
> >>>   are done before qxl_release_reserve_list(), which seems to be the
> >>>   only thing reserving buffers (in the ttm/dma_resv sense) in that
> >>>   code. So looks safe.
> >>>
> >>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >>>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >>>   everywhere and needs to be fixed up.
> >>>
> >>> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> >>> dma_resv lock of a different object already. Christian mentioned that
> >>> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> >>> that i915 has similar issues.
> >>>
> >>> Unfortunately we can't do this in the usual module init functions,
> >>> because kernel threads don't have an ->mm - we have to wait around for
> >>> some user thread to do this.
> >>>
> >>> Solution is to spawn a worker (but only once). It's horrible, but it
> >>> works.
> >>>
> >>> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> >>> initcall solution in.
> >>>
> >>> v4: Annotate with __init (Rob Herring)
> >>>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Alex Deucher <alexander.deucher@amd.com>
> >>> Cc: Christian König <christian.koenig@amd.com>
> >>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >>> Cc: Eric Anholt <eric@anholt.net>
> >>> Cc: Dave Airlie <airlied@redhat.com>
> >>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> >>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >>> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>> ---
> >>>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >>>  1 file changed, 24 insertions(+)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >>> index 709002515550..a05ff542be22 100644
> >>> --- a/drivers/dma-buf/dma-resv.c
> >>> +++ b/drivers/dma-buf/dma-resv.c
> >>> @@ -34,6 +34,7 @@
> >>>
> >>>  #include <linux/dma-resv.h>
> >>>  #include <linux/export.h>
> >>> +#include <linux/sched/mm.h>
> >>>
> >>>  /**
> >>>   * DOC: Reservation Object Overview
> >>> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >>>       kfree_rcu(list, rcu);
> >>>  }
> >>>
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> +static void __init dma_resv_lockdep(void)
> >>> +{
> >>> +     struct mm_struct *mm = mm_alloc();
> >>> +     struct dma_resv obj;
> >>> +
> >>> +     if (!mm)
> >>> +             return;
> >>> +
> >>> +     dma_resv_init(&obj);
> >>> +
> >>> +     down_read(&mm->mmap_sem);
> >>> +     ww_mutex_lock(&obj.lock, NULL);
> >>> +     fs_reclaim_acquire(GFP_KERNEL);
> >>> +     fs_reclaim_release(GFP_KERNEL);
> >>> +     ww_mutex_unlock(&obj.lock);
> >>> +     up_read(&mm->mmap_sem);
> >>> +
> >>
> >> Nit: trailing whitespace
> >>
> >>> +     mmput(mm);
> >>> +}
> >>> +subsys_initcall(dma_resv_lockdep);
> >>
> >> This expects a function returning int, but dma_resv_lockdep() is void.
> >> Causing:
> >>
> >> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> >> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> >> [-Werror=incompatible-pointer-types]
> >>  subsys_initcall(dma_resv_lockdep);
> >>
> >> The below fixes it for me.
> > 
> > Uh, so _that_ was what the 0day thing was all about, I totally misread
> > that completely. Thanks for the patch.
> > 
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > Aside, do you need commit rights for pushing this kind of stuff?
> 
> I guess it's about time I got round to requesting that:
> 
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/208

Since this seems a bit stuck in processing I went ahead and merged your
fix meanwhile.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Thu, Nov 14, 2019 at 11:50:28AM +0000, Steven Price wrote:
> On 11/11/2019 15:42, Daniel Vetter wrote:
> > On Mon, Nov 11, 2019 at 2:11 PM Steven Price <steven.price@arm.com> wrote:
> >>
> >> On 04/11/2019 17:37, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgpu should be clean per their maintainers.
> >>>
> >>> - vram helpers should be fine, they don't do command submission, so
> >>>   really no business holding struct_mutex while doing copy_*_user. But
> >>>   I haven't checked them all.
> >>>
> >>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >>>   looks clean.
> >>>
> >>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >>>   copying from/to userspace happens all in v3d_lookup_bos which is
> >>>   outside of the critical section.
> >>>
> >>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >>>   - vmw_execbuf_process: First this does some copies in
> >>>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >>>     Then comes the usual ttm reserve/validate sequence, then actual
> >>>     submission/fencing, then unreserving, and finally some more
> >>>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >>>     details, but looks all safe.
> >>>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >>>     seen, seems to only create a fence and copy it out.
> >>>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >>>     found there.
> >>>   Summary: vmwgfx seems to be fine too.
> >>>
> >>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >>>   copying from userspace before even looking up objects through their
> >>>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >>>
> >>> - qxl only has qxl_execbuffer_ioctl, which calls into
> >>>   qxl_process_single_command. There's a lovely comment before the
> >>>   __copy_from_user_inatomic that the slowpath should be copied from
> >>>   i915, but I guess that never happened. Try not to be unlucky and get
> >>>   your CS data evicted between when it's written and the kernel tries
> >>>   to read it. The only other copy_from_user is for relocs, but those
> >>>   are done before qxl_release_reserve_list(), which seems to be the
> >>>   only thing reserving buffers (in the ttm/dma_resv sense) in that
> >>>   code. So looks safe.
> >>>
> >>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >>>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >>>   everywhere and needs to be fixed up.
> >>>
> >>> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> >>> dma_resv lock of a different object already. Christian mentioned that
> >>> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> >>> that i915 has similar issues.
> >>>
> >>> Unfortunately we can't do this in the usual module init functions,
> >>> because kernel threads don't have an ->mm - we have to wait around for
> >>> some user thread to do this.
> >>>
> >>> Solution is to spawn a worker (but only once). It's horrible, but it
> >>> works.
> >>>
> >>> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> >>> initcall solution in.
> >>>
> >>> v4: Annotate with __init (Rob Herring)
> >>>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Alex Deucher <alexander.deucher@amd.com>
> >>> Cc: Christian König <christian.koenig@amd.com>
> >>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >>> Cc: Eric Anholt <eric@anholt.net>
> >>> Cc: Dave Airlie <airlied@redhat.com>
> >>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> >>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >>> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>> ---
> >>>  drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
> >>>  1 file changed, 24 insertions(+)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >>> index 709002515550..a05ff542be22 100644
> >>> --- a/drivers/dma-buf/dma-resv.c
> >>> +++ b/drivers/dma-buf/dma-resv.c
> >>> @@ -34,6 +34,7 @@
> >>>
> >>>  #include <linux/dma-resv.h>
> >>>  #include <linux/export.h>
> >>> +#include <linux/sched/mm.h>
> >>>
> >>>  /**
> >>>   * DOC: Reservation Object Overview
> >>> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> >>>       kfree_rcu(list, rcu);
> >>>  }
> >>>
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> +static void __init dma_resv_lockdep(void)
> >>> +{
> >>> +     struct mm_struct *mm = mm_alloc();
> >>> +     struct dma_resv obj;
> >>> +
> >>> +     if (!mm)
> >>> +             return;
> >>> +
> >>> +     dma_resv_init(&obj);
> >>> +
> >>> +     down_read(&mm->mmap_sem);
> >>> +     ww_mutex_lock(&obj.lock, NULL);
> >>> +     fs_reclaim_acquire(GFP_KERNEL);
> >>> +     fs_reclaim_release(GFP_KERNEL);
> >>> +     ww_mutex_unlock(&obj.lock);
> >>> +     up_read(&mm->mmap_sem);
> >>> +
> >>
> >> Nit: trailing whitespace
> >>
> >>> +     mmput(mm);
> >>> +}
> >>> +subsys_initcall(dma_resv_lockdep);
> >>
> >> This expects a function returning int, but dma_resv_lockdep() is void.
> >> Causing:
> >>
> >> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> >> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> >> [-Werror=incompatible-pointer-types]
> >>  subsys_initcall(dma_resv_lockdep);
> >>
> >> The below fixes it for me.
> > 
> > Uh, so _that_ was what the 0day thing was all about, I totally misread
> > that completely. Thanks for the patch.
> > 
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > Aside, do you need commit rights for pushing this kind of stuff?
> 
> I guess it's about time I got round to requesting that:
> 
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/208

Since this seems a bit stuck in processing I went ahead and merged your
fix meanwhile.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 6716 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/dma_resv-lockdep-annotations-priming/20191022-015539
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 7d194c2100ad2a6dded545887d02754948ca5241
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
                    from include/linux/kernel.h:15,
                    from include/asm-generic/bug.h:19,
                    from arch/sparc/include/asm/bug.h:25,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:12,
                    from arch/sparc/include/asm/current.h:15,
                    from include/linux/mutex.h:14,
                    from include/linux/ww_mutex.h:20,
                    from include/linux/dma-resv.h:42,
                    from drivers/dma-buf/dma-resv.c:35:
>> drivers/dma-buf/dma-resv.c:119:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
    subsys_initcall(dma_resv_lockdep);
                    ^
   include/linux/init.h:197:50: note: in definition of macro '___define_initcall'
      __attribute__((__section__(#__sec ".init"))) = fn;
                                                     ^~
>> include/linux/init.h:224:30: note: in expansion of macro '__define_initcall'
    #define subsys_initcall(fn)  __define_initcall(fn, 4)
                                 ^~~~~~~~~~~~~~~~~
>> drivers/dma-buf/dma-resv.c:119:1: note: in expansion of macro 'subsys_initcall'
    subsys_initcall(dma_resv_lockdep);
    ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/linux/printk.h:6:0,
                    from include/linux/kernel.h:15,
                    from include/asm-generic/bug.h:19,
                    from arch/sparc/include/asm/bug.h:25,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:12,
                    from arch/sparc/include/asm/current.h:15,
                    from include/linux/mutex.h:14,
                    from include/linux/ww_mutex.h:20,
                    from include/linux/dma-resv.h:42,
                    from drivers//dma-buf/dma-resv.c:35:
   drivers//dma-buf/dma-resv.c:119:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
    subsys_initcall(dma_resv_lockdep);
                    ^
   include/linux/init.h:197:50: note: in definition of macro '___define_initcall'
      __attribute__((__section__(#__sec ".init"))) = fn;
                                                     ^~
>> include/linux/init.h:224:30: note: in expansion of macro '__define_initcall'
    #define subsys_initcall(fn)  __define_initcall(fn, 4)
                                 ^~~~~~~~~~~~~~~~~
   drivers//dma-buf/dma-resv.c:119:1: note: in expansion of macro 'subsys_initcall'
    subsys_initcall(dma_resv_lockdep);
    ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +119 drivers/dma-buf/dma-resv.c

  > 35	#include <linux/dma-resv.h>
    36	#include <linux/export.h>
    37	#include <linux/sched/mm.h>
    38	
    39	/**
    40	 * DOC: Reservation Object Overview
    41	 *
    42	 * The reservation object provides a mechanism to manage shared and
    43	 * exclusive fences associated with a buffer.  A reservation object
    44	 * can have attached one exclusive fence (normally associated with
    45	 * write operations) or N shared fences (read operations).  The RCU
    46	 * mechanism is used to protect read access to fences from locked
    47	 * write-side updates.
    48	 */
    49	
    50	DEFINE_WD_CLASS(reservation_ww_class);
    51	EXPORT_SYMBOL(reservation_ww_class);
    52	
    53	struct lock_class_key reservation_seqcount_class;
    54	EXPORT_SYMBOL(reservation_seqcount_class);
    55	
    56	const char reservation_seqcount_string[] = "reservation_seqcount";
    57	EXPORT_SYMBOL(reservation_seqcount_string);
    58	
    59	/**
    60	 * dma_resv_list_alloc - allocate fence list
    61	 * @shared_max: number of fences we need space for
    62	 *
    63	 * Allocate a new dma_resv_list and make sure to correctly initialize
    64	 * shared_max.
    65	 */
    66	static struct dma_resv_list *dma_resv_list_alloc(unsigned int shared_max)
    67	{
    68		struct dma_resv_list *list;
    69	
    70		list = kmalloc(offsetof(typeof(*list), shared[shared_max]), GFP_KERNEL);
    71		if (!list)
    72			return NULL;
    73	
    74		list->shared_max = (ksize(list) - offsetof(typeof(*list), shared)) /
    75			sizeof(*list->shared);
    76	
    77		return list;
    78	}
    79	
    80	/**
    81	 * dma_resv_list_free - free fence list
    82	 * @list: list to free
    83	 *
    84	 * Free a dma_resv_list and make sure to drop all references.
    85	 */
    86	static void dma_resv_list_free(struct dma_resv_list *list)
    87	{
    88		unsigned int i;
    89	
    90		if (!list)
    91			return;
    92	
    93		for (i = 0; i < list->shared_count; ++i)
    94			dma_fence_put(rcu_dereference_protected(list->shared[i], true));
    95	
    96		kfree_rcu(list, rcu);
    97	}
    98	
    99	#if IS_ENABLED(CONFIG_LOCKDEP)
   100	static void __init dma_resv_lockdep(void)
   101	{
   102		struct mm_struct *mm = mm_alloc();
   103		struct dma_resv obj;
   104	
   105		if (!mm)
   106			return;
   107	
   108		dma_resv_init(&obj);
   109	
   110		down_read(&mm->mmap_sem);
   111		ww_mutex_lock(&obj.lock, NULL);
   112		fs_reclaim_acquire(GFP_KERNEL);
   113		fs_reclaim_release(GFP_KERNEL);
   114		ww_mutex_unlock(&obj.lock);
   115		up_read(&mm->mmap_sem);
   116		
   117		mmput(mm);
   118	}
 > 119	subsys_initcall(dma_resv_lockdep);
   120	#endif
   121	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59103 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 6884 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/dma_resv-lockdep-annotations-priming/20191022-015539
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 7d194c2100ad2a6dded545887d02754948ca5241
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
                    from include/linux/kernel.h:15,
                    from include/asm-generic/bug.h:19,
                    from arch/sparc/include/asm/bug.h:25,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:12,
                    from arch/sparc/include/asm/current.h:15,
                    from include/linux/mutex.h:14,
                    from include/linux/ww_mutex.h:20,
                    from include/linux/dma-resv.h:42,
                    from drivers/dma-buf/dma-resv.c:35:
>> drivers/dma-buf/dma-resv.c:119:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
    subsys_initcall(dma_resv_lockdep);
                    ^
   include/linux/init.h:197:50: note: in definition of macro '___define_initcall'
      __attribute__((__section__(#__sec ".init"))) = fn;
                                                     ^~
>> include/linux/init.h:224:30: note: in expansion of macro '__define_initcall'
    #define subsys_initcall(fn)  __define_initcall(fn, 4)
                                 ^~~~~~~~~~~~~~~~~
>> drivers/dma-buf/dma-resv.c:119:1: note: in expansion of macro 'subsys_initcall'
    subsys_initcall(dma_resv_lockdep);
    ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/linux/printk.h:6:0,
                    from include/linux/kernel.h:15,
                    from include/asm-generic/bug.h:19,
                    from arch/sparc/include/asm/bug.h:25,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:12,
                    from arch/sparc/include/asm/current.h:15,
                    from include/linux/mutex.h:14,
                    from include/linux/ww_mutex.h:20,
                    from include/linux/dma-resv.h:42,
                    from drivers//dma-buf/dma-resv.c:35:
   drivers//dma-buf/dma-resv.c:119:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
    subsys_initcall(dma_resv_lockdep);
                    ^
   include/linux/init.h:197:50: note: in definition of macro '___define_initcall'
      __attribute__((__section__(#__sec ".init"))) = fn;
                                                     ^~
>> include/linux/init.h:224:30: note: in expansion of macro '__define_initcall'
    #define subsys_initcall(fn)  __define_initcall(fn, 4)
                                 ^~~~~~~~~~~~~~~~~
   drivers//dma-buf/dma-resv.c:119:1: note: in expansion of macro 'subsys_initcall'
    subsys_initcall(dma_resv_lockdep);
    ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +119 drivers/dma-buf/dma-resv.c

  > 35	#include <linux/dma-resv.h>
    36	#include <linux/export.h>
    37	#include <linux/sched/mm.h>
    38	
    39	/**
    40	 * DOC: Reservation Object Overview
    41	 *
    42	 * The reservation object provides a mechanism to manage shared and
    43	 * exclusive fences associated with a buffer.  A reservation object
    44	 * can have attached one exclusive fence (normally associated with
    45	 * write operations) or N shared fences (read operations).  The RCU
    46	 * mechanism is used to protect read access to fences from locked
    47	 * write-side updates.
    48	 */
    49	
    50	DEFINE_WD_CLASS(reservation_ww_class);
    51	EXPORT_SYMBOL(reservation_ww_class);
    52	
    53	struct lock_class_key reservation_seqcount_class;
    54	EXPORT_SYMBOL(reservation_seqcount_class);
    55	
    56	const char reservation_seqcount_string[] = "reservation_seqcount";
    57	EXPORT_SYMBOL(reservation_seqcount_string);
    58	
    59	/**
    60	 * dma_resv_list_alloc - allocate fence list
    61	 * @shared_max: number of fences we need space for
    62	 *
    63	 * Allocate a new dma_resv_list and make sure to correctly initialize
    64	 * shared_max.
    65	 */
    66	static struct dma_resv_list *dma_resv_list_alloc(unsigned int shared_max)
    67	{
    68		struct dma_resv_list *list;
    69	
    70		list = kmalloc(offsetof(typeof(*list), shared[shared_max]), GFP_KERNEL);
    71		if (!list)
    72			return NULL;
    73	
    74		list->shared_max = (ksize(list) - offsetof(typeof(*list), shared)) /
    75			sizeof(*list->shared);
    76	
    77		return list;
    78	}
    79	
    80	/**
    81	 * dma_resv_list_free - free fence list
    82	 * @list: list to free
    83	 *
    84	 * Free a dma_resv_list and make sure to drop all references.
    85	 */
    86	static void dma_resv_list_free(struct dma_resv_list *list)
    87	{
    88		unsigned int i;
    89	
    90		if (!list)
    91			return;
    92	
    93		for (i = 0; i < list->shared_count; ++i)
    94			dma_fence_put(rcu_dereference_protected(list->shared[i], true));
    95	
    96		kfree_rcu(list, rcu);
    97	}
    98	
    99	#if IS_ENABLED(CONFIG_LOCKDEP)
   100	static void __init dma_resv_lockdep(void)
   101	{
   102		struct mm_struct *mm = mm_alloc();
   103		struct dma_resv obj;
   104	
   105		if (!mm)
   106			return;
   107	
   108		dma_resv_init(&obj);
   109	
   110		down_read(&mm->mmap_sem);
   111		ww_mutex_lock(&obj.lock, NULL);
   112		fs_reclaim_acquire(GFP_KERNEL);
   113		fs_reclaim_release(GFP_KERNEL);
   114		ww_mutex_unlock(&obj.lock);
   115		up_read(&mm->mmap_sem);
   116		
   117		mmput(mm);
   118	}
 > 119	subsys_initcall(dma_resv_lockdep);
   120	#endif
   121	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 59103 bytes --]

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Thomas Hellstrom]

On 10/21/19 4:50 PM, Daniel Vetter wrote:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Including the vmwgfx audit,

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Thanks,

Thomas



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.

Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.

Solution is to spawn a worker (but only once). It's horrible, but it
works.

v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.

v4: Annotate with __init (Rob Herring)

Cc: Rob Herring <robh@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 	kfree_rcu(list, rcu);
 }
 
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+	struct mm_struct *mm = mm_alloc();
+	struct dma_resv obj;
+
+	if (!mm)
+		return;
+
+	dma_resv_init(&obj);
+
+	down_read(&mm->mmap_sem);
+	ww_mutex_lock(&obj.lock, NULL);
+	fs_reclaim_acquire(GFP_KERNEL);
+	fs_reclaim_release(GFP_KERNEL);
+	ww_mutex_unlock(&obj.lock);
+	up_read(&mm->mmap_sem);
+	
+	mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
 /**
  * dma_resv_init - initialize a reservation object
  * @obj: the reservation object
-- 
2.23.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Thu, Aug 22, 2019 at 8:42 AM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> On 8/21/19 9:51 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
> >> On 8/21/19 8:11 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> >>> <thomas_os@shipmail.org> wrote:
> >>>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
> >>>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> >>>>>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>>>>>> Full audit of everyone:
> >>>>>>>
> >>>>>>> - i915, radeon, amdgpu should be clean per their maintainers.
> >>>>>>>
> >>>>>>> - vram helpers should be fine, they don't do command submission, so
> >>>>>>>       really no business holding struct_mutex while doing copy_*_user. But
> >>>>>>>       I haven't checked them all.
> >>>>>>>
> >>>>>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >>>>>>>       looks clean.
> >>>>>>>
> >>>>>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >>>>>>>       copying from/to userspace happens all in v3d_lookup_bos which is
> >>>>>>>       outside of the critical section.
> >>>>>>>
> >>>>>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >>>>>>>       - vmw_execbuf_process: First this does some copies in
> >>>>>>>         vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >>>>>>>         Then comes the usual ttm reserve/validate sequence, then actual
> >>>>>>>         submission/fencing, then unreserving, and finally some more
> >>>>>>>         copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >>>>>>>         details, but looks all safe.
> >>>>>>>       - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >>>>>>>         seen, seems to only create a fence and copy it out.
> >>>>>>>       - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >>>>>>>         found there.
> >>>>>>>       Summary: vmwgfx seems to be fine too.
> >>>>>>>
> >>>>>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >>>>>>>       copying from userspace before even looking up objects through their
> >>>>>>>       handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >>>>>>>
> >>>>>>> - qxl only has qxl_execbuffer_ioctl, which calls into
> >>>>>>>       qxl_process_single_command. There's a lovely comment before the
> >>>>>>>       __copy_from_user_inatomic that the slowpath should be copied from
> >>>>>>>       i915, but I guess that never happened. Try not to be unlucky and get
> >>>>>>>       your CS data evicted between when it's written and the kernel tries
> >>>>>>>       to read it. The only other copy_from_user is for relocs, but those
> >>>>>>>       are done before qxl_release_reserve_list(), which seems to be the
> >>>>>>>       only thing reserving buffers (in the ttm/dma_resv sense) in that
> >>>>>>>       code. So looks safe.
> >>>>>>>
> >>>>>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >>>>>>>       usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >>>>>>>       everywhere and needs to be fixed up.
> >>>>>>>
> >>>>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
> >>>>>>> Cc: Christian König <christian.koenig@amd.com>
> >>>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >>>>>>> Cc: Eric Anholt <eric@anholt.net>
> >>>>>>> Cc: Dave Airlie <airlied@redhat.com>
> >>>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>>>>>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>>>>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> >>>>>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >>>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>>>>>> ---
> >>>>>>>      drivers/dma-buf/dma-resv.c | 12 ++++++++++++
> >>>>>>>      1 file changed, 12 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >>>>>>> index 42a8f3f11681..3edca10d3faf 100644
> >>>>>>> --- a/drivers/dma-buf/dma-resv.c
> >>>>>>> +++ b/drivers/dma-buf/dma-resv.c
> >>>>>>> @@ -34,6 +34,7 @@
> >>>>>>>      #include <linux/dma-resv.h>
> >>>>>>>      #include <linux/export.h>
> >>>>>>> +#include <linux/sched/mm.h>
> >>>>>>>      /**
> >>>>>>>       * DOC: Reservation Object Overview
> >>>>>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> >>>>>>>                       &reservation_seqcount_class);
> >>>>>>>       RCU_INIT_POINTER(obj->fence, NULL);
> >>>>>>>       RCU_INIT_POINTER(obj->fence_excl, NULL);
> >>>>>>> +
> >>>>>>> +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
> >>>>>>> +           if (current->mm)
> >>>>>>> +                   down_read(&current->mm->mmap_sem);
> >>>>>>> +           ww_mutex_lock(&obj->lock, NULL);
> >>>>>>> +           fs_reclaim_acquire(GFP_KERNEL);
> >>>>>>> +           fs_reclaim_release(GFP_KERNEL);
> >>>>>>> +           ww_mutex_unlock(&obj->lock);
> >>>>>>> +           if (current->mm)
> >>>>>>> +                   up_read(&current->mm->mmap_sem);
> >>>>>>> +   }
> >>>>>>>      }
> >>>>>>>      EXPORT_SYMBOL(dma_resv_init);
> >>>>>> I assume if this would have been easily done and maintainable using only
> >>>>>> lockdep annotation instead of actually acquiring the locks, that would have
> >>>>>> been done?
> >>>>> There's might_lock(), plus a pile of macros, but they don't map obviuosly,
> >>>>> so pretty good chances I accidentally end up with the wrong type of
> >>>>> annotation. Easier to just take the locks quickly, and stuff that all into
> >>>>> a lockdep-only section to avoid overhead.
> >>>>>
> >>>>>> Otherwise LGTM.
> >>>>>>
> >>>>>> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
> >>>>>>
> >>>>>> Will test this and let you know if it trips on vmwgfx, but it really
> >>>>>> shouldn't.
> >>>>> Thanks, Daniel
> >>>> One thing that strikes me is that this puts restrictions on where you
> >>>> can actually initialize a dma_resv, even if locking orders are otherwise
> >>>> obeyed. But that might not be a big problem.
> >>> Hm yeah ... the trouble is a need a non-kthread thread so that I have
> >>> a current->mm. Otherwise I'd have put it into some init section with a
> >>> temp dma_buf. And I kinda don't want to create a fake ->mm just for
> >>> lockdep priming. I don't expect this to be a real problem in practice,
> >>> since before you've called dma_resv_init the reservation lock doesn't
> >>> exist, so you can't hold it. And you've probably just allocated it, so
> >>> fs_reclaim is going to be fine. And if you allocate dma_resv objects
> >>> from your fault handlers I have questions anyway :-)
> >> Coming to think of it, I think vmwgfx sometimes create bos with other bo's
> >> reservation lock held. I guess that would trip both the mmap_sem check the
> >> ww_mutex check?
> > If you do that, yes we're busted. Do you do that?
>
> Yes, we do, in a couple of places it seems, and it also appears like TTM
> is doing it according to Christian.
>
> >
> > I guess needs a new idea for where to put this ... while making sure
> > everyone gets it. So some evil trick like putting it in drm_open() won't
> > work, since I also want to make sure everyone else using dma-buf follows
> > these rules.
>
> IMO it should be sufficient to establish this locking order once, but I
> guess dma-buf module init time won't work because we might not have an
> mm structure?

mm_alloc() is a thing as Chris pointed out, and it works. v3 on its way.
-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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Thomas Hellström (VMware)]

On 8/21/19 9:51 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
>> On 8/21/19 8:11 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
>>> <thomas_os@shipmail.org> wrote:
>>>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
>>>>>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>>>>>> Full audit of everyone:
>>>>>>>
>>>>>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>>>>>
>>>>>>> - vram helpers should be fine, they don't do command submission, so
>>>>>>>       really no business holding struct_mutex while doing copy_*_user. But
>>>>>>>       I haven't checked them all.
>>>>>>>
>>>>>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>>>>>       looks clean.
>>>>>>>
>>>>>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>>>>>       copying from/to userspace happens all in v3d_lookup_bos which is
>>>>>>>       outside of the critical section.
>>>>>>>
>>>>>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>>>>>       - vmw_execbuf_process: First this does some copies in
>>>>>>>         vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>>>>>         Then comes the usual ttm reserve/validate sequence, then actual
>>>>>>>         submission/fencing, then unreserving, and finally some more
>>>>>>>         copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>>>>>         details, but looks all safe.
>>>>>>>       - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>>>>>         seen, seems to only create a fence and copy it out.
>>>>>>>       - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>>>>>         found there.
>>>>>>>       Summary: vmwgfx seems to be fine too.
>>>>>>>
>>>>>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>>>>>       copying from userspace before even looking up objects through their
>>>>>>>       handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>>>>>
>>>>>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>>>>>       qxl_process_single_command. There's a lovely comment before the
>>>>>>>       __copy_from_user_inatomic that the slowpath should be copied from
>>>>>>>       i915, but I guess that never happened. Try not to be unlucky and get
>>>>>>>       your CS data evicted between when it's written and the kernel tries
>>>>>>>       to read it. The only other copy_from_user is for relocs, but those
>>>>>>>       are done before qxl_release_reserve_list(), which seems to be the
>>>>>>>       only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>>>>>       code. So looks safe.
>>>>>>>
>>>>>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>>>>>       usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>>>>>       everywhere and needs to be fixed up.
>>>>>>>
>>>>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>>>>>> Cc: Christian König <christian.koenig@amd.com>
>>>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>>>>> Cc: Eric Anholt <eric@anholt.net>
>>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>>>>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>>>>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>>>>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>>>>> ---
>>>>>>>      drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>>>>>>>      1 file changed, 12 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>>>>>> index 42a8f3f11681..3edca10d3faf 100644
>>>>>>> --- a/drivers/dma-buf/dma-resv.c
>>>>>>> +++ b/drivers/dma-buf/dma-resv.c
>>>>>>> @@ -34,6 +34,7 @@
>>>>>>>      #include <linux/dma-resv.h>
>>>>>>>      #include <linux/export.h>
>>>>>>> +#include <linux/sched/mm.h>
>>>>>>>      /**
>>>>>>>       * DOC: Reservation Object Overview
>>>>>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>>>>>>>                       &reservation_seqcount_class);
>>>>>>>       RCU_INIT_POINTER(obj->fence, NULL);
>>>>>>>       RCU_INIT_POINTER(obj->fence_excl, NULL);
>>>>>>> +
>>>>>>> +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
>>>>>>> +           if (current->mm)
>>>>>>> +                   down_read(&current->mm->mmap_sem);
>>>>>>> +           ww_mutex_lock(&obj->lock, NULL);
>>>>>>> +           fs_reclaim_acquire(GFP_KERNEL);
>>>>>>> +           fs_reclaim_release(GFP_KERNEL);
>>>>>>> +           ww_mutex_unlock(&obj->lock);
>>>>>>> +           if (current->mm)
>>>>>>> +                   up_read(&current->mm->mmap_sem);
>>>>>>> +   }
>>>>>>>      }
>>>>>>>      EXPORT_SYMBOL(dma_resv_init);
>>>>>> I assume if this would have been easily done and maintainable using only
>>>>>> lockdep annotation instead of actually acquiring the locks, that would have
>>>>>> been done?
>>>>> There's might_lock(), plus a pile of macros, but they don't map obviuosly,
>>>>> so pretty good chances I accidentally end up with the wrong type of
>>>>> annotation. Easier to just take the locks quickly, and stuff that all into
>>>>> a lockdep-only section to avoid overhead.
>>>>>
>>>>>> Otherwise LGTM.
>>>>>>
>>>>>> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
>>>>>>
>>>>>> Will test this and let you know if it trips on vmwgfx, but it really
>>>>>> shouldn't.
>>>>> Thanks, Daniel
>>>> One thing that strikes me is that this puts restrictions on where you
>>>> can actually initialize a dma_resv, even if locking orders are otherwise
>>>> obeyed. But that might not be a big problem.
>>> Hm yeah ... the trouble is a need a non-kthread thread so that I have
>>> a current->mm. Otherwise I'd have put it into some init section with a
>>> temp dma_buf. And I kinda don't want to create a fake ->mm just for
>>> lockdep priming. I don't expect this to be a real problem in practice,
>>> since before you've called dma_resv_init the reservation lock doesn't
>>> exist, so you can't hold it. And you've probably just allocated it, so
>>> fs_reclaim is going to be fine. And if you allocate dma_resv objects
>>> from your fault handlers I have questions anyway :-)
>> Coming to think of it, I think vmwgfx sometimes create bos with other bo's
>> reservation lock held. I guess that would trip both the mmap_sem check the
>> ww_mutex check?
> If you do that, yes we're busted. Do you do that?

Yes, we do, in a couple of places it seems, and it also appears like TTM 
is doing it according to Christian.

>
> I guess needs a new idea for where to put this ... while making sure
> everyone gets it. So some evil trick like putting it in drm_open() won't
> work, since I also want to make sure everyone else using dma-buf follows
> these rules.

IMO it should be sufficient to establish this locking order once, but I 
guess dma-buf module init time won't work because we might not have an 
mm structure?

/Thomas

>
> Ideas?
> -Daniel


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Chris Wilson]

Quoting Daniel Vetter (2019-08-21 22:50:28)
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
> 
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
> 
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/dma-buf/dma-resv.c | 42 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 42a8f3f11681..29988b1564c1 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -95,6 +96,28 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>         kfree_rcu(list, rcu);
>  }
>  
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +struct lockdep_work {
> +       struct work_struct work;
> +       struct dma_resv obj;
> +       struct mm_struct *mm;
> +} lockdep_work;
> +
> +void lockdep_work_fn(struct work_struct *work)
> +{
> +       dma_resv_init(&lockdep_work.obj);
> +
> +       down_read(&lockdep_work.mm->mmap_sem);
> +       ww_mutex_lock(&lockdep_work.obj.lock, NULL);
> +       fs_reclaim_acquire(GFP_KERNEL);
> +       fs_reclaim_release(GFP_KERNEL);
> +       ww_mutex_unlock(&lockdep_work.obj.lock);
> +       up_read(&lockdep_work.mm->mmap_sem);
> +       
> +       mmput(lockdep_work.mm);
> +}
> +#endif

#if IS_ENABLED(CONFIG_LOCKDEP)
static void dma_resv_lockmap(void)
{
	struct mm_struct *mm = alloc_mm();
	struct dma_resv obj;

	dma_resv_init(&obj);

	down_read(&mm->mmap_sem);
	ww_mutex_lock(&obj.lock, NULL);
	fs_reclaim_acquire(GFP_KERNEL);
	fs_reclaim_release(GFP_KERNEL);
	ww_mutex_unlock(&obj.lock);
	up_read(&mm->mmap_sem);

	mmput(mm);
}
core_initcall(dma_resv_lockmap);
#endif

as a thought.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.

Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.

Solution is to spawn a worker (but only once). It's horrible, but it
works.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 42 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 42a8f3f11681..29988b1564c1 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -95,6 +96,28 @@ static void dma_resv_list_free(struct dma_resv_list *list)
 	kfree_rcu(list, rcu);
 }
 
+#if IS_ENABLED(CONFIG_LOCKDEP)
+struct lockdep_work {
+	struct work_struct work;
+	struct dma_resv obj;
+	struct mm_struct *mm;
+} lockdep_work;
+
+void lockdep_work_fn(struct work_struct *work)
+{
+	dma_resv_init(&lockdep_work.obj);
+
+	down_read(&lockdep_work.mm->mmap_sem);
+	ww_mutex_lock(&lockdep_work.obj.lock, NULL);
+	fs_reclaim_acquire(GFP_KERNEL);
+	fs_reclaim_release(GFP_KERNEL);
+	ww_mutex_unlock(&lockdep_work.obj.lock);
+	up_read(&lockdep_work.mm->mmap_sem);
+	
+	mmput(lockdep_work.mm);
+}
+#endif
+
 /**
  * dma_resv_init - initialize a reservation object
  * @obj: the reservation object
@@ -107,6 +130,25 @@ void dma_resv_init(struct dma_resv *obj)
 			&reservation_seqcount_class);
 	RCU_INIT_POINTER(obj->fence, NULL);
 	RCU_INIT_POINTER(obj->fence_excl, NULL);
+
+#if IS_ENABLED(CONFIG_LOCKDEP)
+	if (current->mm) {
+		static atomic_t lockdep_primed;
+
+		/*
+		 * This gets called from all kinds of places, launch a worker.
+		 * Usual init sections don't work for kernel threads lack an
+		 * ->mm.
+		 */
+		if (atomic_cmpxchg(&lockdep_primed, 0, 1) == 0) {
+			INIT_WORK(&lockdep_work.work, lockdep_work_fn);
+			lockdep_work.mm = current->mm;
+			mmget(lockdep_work.mm);
+
+			schedule_work(&lockdep_work.work);
+		}
+	}
+#endif
 }
 EXPORT_SYMBOL(dma_resv_init);
 
-- 
2.23.0.rc1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
> On 8/21/19 8:11 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> wrote:
> > > On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > > > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> > > > > On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > > > > > Full audit of everyone:
> > > > > > 
> > > > > > - i915, radeon, amdgpu should be clean per their maintainers.
> > > > > > 
> > > > > > - vram helpers should be fine, they don't do command submission, so
> > > > > >      really no business holding struct_mutex while doing copy_*_user. But
> > > > > >      I haven't checked them all.
> > > > > > 
> > > > > > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> > > > > >      looks clean.
> > > > > > 
> > > > > > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> > > > > >      copying from/to userspace happens all in v3d_lookup_bos which is
> > > > > >      outside of the critical section.
> > > > > > 
> > > > > > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> > > > > >      - vmw_execbuf_process: First this does some copies in
> > > > > >        vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> > > > > >        Then comes the usual ttm reserve/validate sequence, then actual
> > > > > >        submission/fencing, then unreserving, and finally some more
> > > > > >        copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> > > > > >        details, but looks all safe.
> > > > > >      - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> > > > > >        seen, seems to only create a fence and copy it out.
> > > > > >      - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> > > > > >        found there.
> > > > > >      Summary: vmwgfx seems to be fine too.
> > > > > > 
> > > > > > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> > > > > >      copying from userspace before even looking up objects through their
> > > > > >      handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> > > > > > 
> > > > > > - qxl only has qxl_execbuffer_ioctl, which calls into
> > > > > >      qxl_process_single_command. There's a lovely comment before the
> > > > > >      __copy_from_user_inatomic that the slowpath should be copied from
> > > > > >      i915, but I guess that never happened. Try not to be unlucky and get
> > > > > >      your CS data evicted between when it's written and the kernel tries
> > > > > >      to read it. The only other copy_from_user is for relocs, but those
> > > > > >      are done before qxl_release_reserve_list(), which seems to be the
> > > > > >      only thing reserving buffers (in the ttm/dma_resv sense) in that
> > > > > >      code. So looks safe.
> > > > > > 
> > > > > > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> > > > > >      usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> > > > > >      everywhere and needs to be fixed up.
> > > > > > 
> > > > > > Cc: Alex Deucher <alexander.deucher@amd.com>
> > > > > > Cc: Christian König <christian.koenig@amd.com>
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > > > > > Cc: Eric Anholt <eric@anholt.net>
> > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > > > > > Cc: Ben Skeggs <bskeggs@redhat.com>
> > > > > > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > > > > > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > ---
> > > > > >     drivers/dma-buf/dma-resv.c | 12 ++++++++++++
> > > > > >     1 file changed, 12 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > > > > > index 42a8f3f11681..3edca10d3faf 100644
> > > > > > --- a/drivers/dma-buf/dma-resv.c
> > > > > > +++ b/drivers/dma-buf/dma-resv.c
> > > > > > @@ -34,6 +34,7 @@
> > > > > >     #include <linux/dma-resv.h>
> > > > > >     #include <linux/export.h>
> > > > > > +#include <linux/sched/mm.h>
> > > > > >     /**
> > > > > >      * DOC: Reservation Object Overview
> > > > > > @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> > > > > >                      &reservation_seqcount_class);
> > > > > >      RCU_INIT_POINTER(obj->fence, NULL);
> > > > > >      RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > > > > +
> > > > > > +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > > > > > +           if (current->mm)
> > > > > > +                   down_read(&current->mm->mmap_sem);
> > > > > > +           ww_mutex_lock(&obj->lock, NULL);
> > > > > > +           fs_reclaim_acquire(GFP_KERNEL);
> > > > > > +           fs_reclaim_release(GFP_KERNEL);
> > > > > > +           ww_mutex_unlock(&obj->lock);
> > > > > > +           if (current->mm)
> > > > > > +                   up_read(&current->mm->mmap_sem);
> > > > > > +   }
> > > > > >     }
> > > > > >     EXPORT_SYMBOL(dma_resv_init);
> > > > > I assume if this would have been easily done and maintainable using only
> > > > > lockdep annotation instead of actually acquiring the locks, that would have
> > > > > been done?
> > > > There's might_lock(), plus a pile of macros, but they don't map obviuosly,
> > > > so pretty good chances I accidentally end up with the wrong type of
> > > > annotation. Easier to just take the locks quickly, and stuff that all into
> > > > a lockdep-only section to avoid overhead.
> > > > 
> > > > > Otherwise LGTM.
> > > > > 
> > > > > Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
> > > > > 
> > > > > Will test this and let you know if it trips on vmwgfx, but it really
> > > > > shouldn't.
> > > > Thanks, Daniel
> > > One thing that strikes me is that this puts restrictions on where you
> > > can actually initialize a dma_resv, even if locking orders are otherwise
> > > obeyed. But that might not be a big problem.
> > Hm yeah ... the trouble is a need a non-kthread thread so that I have
> > a current->mm. Otherwise I'd have put it into some init section with a
> > temp dma_buf. And I kinda don't want to create a fake ->mm just for
> > lockdep priming. I don't expect this to be a real problem in practice,
> > since before you've called dma_resv_init the reservation lock doesn't
> > exist, so you can't hold it. And you've probably just allocated it, so
> > fs_reclaim is going to be fine. And if you allocate dma_resv objects
> > from your fault handlers I have questions anyway :-)
> 
> Coming to think of it, I think vmwgfx sometimes create bos with other bo's
> reservation lock held. I guess that would trip both the mmap_sem check the
> ww_mutex check?

If you do that, yes we're busted. Do you do that?

I guess needs a new idea for where to put this ... while making sure
everyone gets it. So some evil trick like putting it in drm_open() won't
work, since I also want to make sure everyone else using dma-buf follows
these rules.

Ideas?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Koenig, Christian]

[-- Attachment #1.1: Type: text/plain, Size: 6825 bytes --]



Am 21.08.2019 20:28 schrieb "Thomas Hellström (VMware)" <thomas_os@shipmail.org>:
On 8/21/19 8:11 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
>>>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>>>> Full audit of everyone:
>>>>>
>>>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>>>
>>>>> - vram helpers should be fine, they don't do command submission, so
>>>>>      really no business holding struct_mutex while doing copy_*_user. But
>>>>>      I haven't checked them all.
>>>>>
>>>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>>>      looks clean.
>>>>>
>>>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>>>      copying from/to userspace happens all in v3d_lookup_bos which is
>>>>>      outside of the critical section.
>>>>>
>>>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>>>      - vmw_execbuf_process: First this does some copies in
>>>>>        vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>>>        Then comes the usual ttm reserve/validate sequence, then actual
>>>>>        submission/fencing, then unreserving, and finally some more
>>>>>        copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>>>        details, but looks all safe.
>>>>>      - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>>>        seen, seems to only create a fence and copy it out.
>>>>>      - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>>>        found there.
>>>>>      Summary: vmwgfx seems to be fine too.
>>>>>
>>>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>>>      copying from userspace before even looking up objects through their
>>>>>      handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>>>
>>>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>>>      qxl_process_single_command. There's a lovely comment before the
>>>>>      __copy_from_user_inatomic that the slowpath should be copied from
>>>>>      i915, but I guess that never happened. Try not to be unlucky and get
>>>>>      your CS data evicted between when it's written and the kernel tries
>>>>>      to read it. The only other copy_from_user is for relocs, but those
>>>>>      are done before qxl_release_reserve_list(), which seems to be the
>>>>>      only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>>>      code. So looks safe.
>>>>>
>>>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>>>      usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>>>      everywhere and needs to be fixed up.
>>>>>
>>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>>>> Cc: Christian König <christian.koenig@amd.com>
>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>>> Cc: Eric Anholt <eric@anholt.net>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>>> ---
>>>>>     drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>>>>>     1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>>>> index 42a8f3f11681..3edca10d3faf 100644
>>>>> --- a/drivers/dma-buf/dma-resv.c
>>>>> +++ b/drivers/dma-buf/dma-resv.c
>>>>> @@ -34,6 +34,7 @@
>>>>>     #include <linux/dma-resv.h>
>>>>>     #include <linux/export.h>
>>>>> +#include <linux/sched/mm.h>
>>>>>     /**
>>>>>      * DOC: Reservation Object Overview
>>>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>>>>>                      &reservation_seqcount_class);
>>>>>      RCU_INIT_POINTER(obj->fence, NULL);
>>>>>      RCU_INIT_POINTER(obj->fence_excl, NULL);
>>>>> +
>>>>> +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
>>>>> +           if (current->mm)
>>>>> +                   down_read(&current->mm->mmap_sem);
>>>>> +           ww_mutex_lock(&obj->lock, NULL);
>>>>> +           fs_reclaim_acquire(GFP_KERNEL);
>>>>> +           fs_reclaim_release(GFP_KERNEL);
>>>>> +           ww_mutex_unlock(&obj->lock);
>>>>> +           if (current->mm)
>>>>> +                   up_read(&current->mm->mmap_sem);
>>>>> +   }
>>>>>     }
>>>>>     EXPORT_SYMBOL(dma_resv_init);
>>>> I assume if this would have been easily done and maintainable using only
>>>> lockdep annotation instead of actually acquiring the locks, that would have
>>>> been done?
>>> There's might_lock(), plus a pile of macros, but they don't map obviuosly,
>>> so pretty good chances I accidentally end up with the wrong type of
>>> annotation. Easier to just take the locks quickly, and stuff that all into
>>> a lockdep-only section to avoid overhead.
>>>
>>>> Otherwise LGTM.
>>>>
>>>> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
>>>>
>>>> Will test this and let you know if it trips on vmwgfx, but it really
>>>> shouldn't.
>>> Thanks, Daniel
>> One thing that strikes me is that this puts restrictions on where you
>> can actually initialize a dma_resv, even if locking orders are otherwise
>> obeyed. But that might not be a big problem.
> Hm yeah ... the trouble is a need a non-kthread thread so that I have
> a current->mm. Otherwise I'd have put it into some init section with a
> temp dma_buf. And I kinda don't want to create a fake ->mm just for
> lockdep priming. I don't expect this to be a real problem in practice,
> since before you've called dma_resv_init the reservation lock doesn't
> exist, so you can't hold it. And you've probably just allocated it, so
> fs_reclaim is going to be fine. And if you allocate dma_resv objects
> from your fault handlers I have questions anyway :-)

Coming to think of it, I think vmwgfx sometimes create bos with other
bo's reservation lock held. I guess that would trip both the mmap_sem
check the ww_mutex check?

Dito inside TTM for ghost objects.

We even used to have an dma_resv_init() in an atomic section, but that should be gone by now.

Anyway, probably have to take my review back since this will certainly go up in flames.

Need a better place for this,
Christian.


/Thomas


/Thomas




>
> So I think this should be safe.
> -Daniel




[-- Attachment #1.2: Type: text/html, Size: 11899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Thomas Hellström (VMware)]

On 8/21/19 8:11 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
>>>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>>>> Full audit of everyone:
>>>>>
>>>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>>>
>>>>> - vram helpers should be fine, they don't do command submission, so
>>>>>      really no business holding struct_mutex while doing copy_*_user. But
>>>>>      I haven't checked them all.
>>>>>
>>>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>>>      looks clean.
>>>>>
>>>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>>>      copying from/to userspace happens all in v3d_lookup_bos which is
>>>>>      outside of the critical section.
>>>>>
>>>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>>>      - vmw_execbuf_process: First this does some copies in
>>>>>        vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>>>        Then comes the usual ttm reserve/validate sequence, then actual
>>>>>        submission/fencing, then unreserving, and finally some more
>>>>>        copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>>>        details, but looks all safe.
>>>>>      - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>>>        seen, seems to only create a fence and copy it out.
>>>>>      - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>>>        found there.
>>>>>      Summary: vmwgfx seems to be fine too.
>>>>>
>>>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>>>      copying from userspace before even looking up objects through their
>>>>>      handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>>>
>>>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>>>      qxl_process_single_command. There's a lovely comment before the
>>>>>      __copy_from_user_inatomic that the slowpath should be copied from
>>>>>      i915, but I guess that never happened. Try not to be unlucky and get
>>>>>      your CS data evicted between when it's written and the kernel tries
>>>>>      to read it. The only other copy_from_user is for relocs, but those
>>>>>      are done before qxl_release_reserve_list(), which seems to be the
>>>>>      only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>>>      code. So looks safe.
>>>>>
>>>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>>>      usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>>>      everywhere and needs to be fixed up.
>>>>>
>>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>>>> Cc: Christian König <christian.koenig@amd.com>
>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>>> Cc: Eric Anholt <eric@anholt.net>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>>> ---
>>>>>     drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>>>>>     1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>>>> index 42a8f3f11681..3edca10d3faf 100644
>>>>> --- a/drivers/dma-buf/dma-resv.c
>>>>> +++ b/drivers/dma-buf/dma-resv.c
>>>>> @@ -34,6 +34,7 @@
>>>>>     #include <linux/dma-resv.h>
>>>>>     #include <linux/export.h>
>>>>> +#include <linux/sched/mm.h>
>>>>>     /**
>>>>>      * DOC: Reservation Object Overview
>>>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>>>>>                      &reservation_seqcount_class);
>>>>>      RCU_INIT_POINTER(obj->fence, NULL);
>>>>>      RCU_INIT_POINTER(obj->fence_excl, NULL);
>>>>> +
>>>>> +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
>>>>> +           if (current->mm)
>>>>> +                   down_read(&current->mm->mmap_sem);
>>>>> +           ww_mutex_lock(&obj->lock, NULL);
>>>>> +           fs_reclaim_acquire(GFP_KERNEL);
>>>>> +           fs_reclaim_release(GFP_KERNEL);
>>>>> +           ww_mutex_unlock(&obj->lock);
>>>>> +           if (current->mm)
>>>>> +                   up_read(&current->mm->mmap_sem);
>>>>> +   }
>>>>>     }
>>>>>     EXPORT_SYMBOL(dma_resv_init);
>>>> I assume if this would have been easily done and maintainable using only
>>>> lockdep annotation instead of actually acquiring the locks, that would have
>>>> been done?
>>> There's might_lock(), plus a pile of macros, but they don't map obviuosly,
>>> so pretty good chances I accidentally end up with the wrong type of
>>> annotation. Easier to just take the locks quickly, and stuff that all into
>>> a lockdep-only section to avoid overhead.
>>>
>>>> Otherwise LGTM.
>>>>
>>>> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
>>>>
>>>> Will test this and let you know if it trips on vmwgfx, but it really
>>>> shouldn't.
>>> Thanks, Daniel
>> One thing that strikes me is that this puts restrictions on where you
>> can actually initialize a dma_resv, even if locking orders are otherwise
>> obeyed. But that might not be a big problem.
> Hm yeah ... the trouble is a need a non-kthread thread so that I have
> a current->mm. Otherwise I'd have put it into some init section with a
> temp dma_buf. And I kinda don't want to create a fake ->mm just for
> lockdep priming. I don't expect this to be a real problem in practice,
> since before you've called dma_resv_init the reservation lock doesn't
> exist, so you can't hold it. And you've probably just allocated it, so
> fs_reclaim is going to be fine. And if you allocate dma_resv objects
> from your fault handlers I have questions anyway :-)

Coming to think of it, I think vmwgfx sometimes create bos with other 
bo's reservation lock held. I guess that would trip both the mmap_sem 
check the ww_mutex check?

/Thomas


/Thomas




>
> So I think this should be safe.
> -Daniel


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> >> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgpu should be clean per their maintainers.
> >>>
> >>> - vram helpers should be fine, they don't do command submission, so
> >>>     really no business holding struct_mutex while doing copy_*_user. But
> >>>     I haven't checked them all.
> >>>
> >>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >>>     looks clean.
> >>>
> >>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >>>     copying from/to userspace happens all in v3d_lookup_bos which is
> >>>     outside of the critical section.
> >>>
> >>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >>>     - vmw_execbuf_process: First this does some copies in
> >>>       vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >>>       Then comes the usual ttm reserve/validate sequence, then actual
> >>>       submission/fencing, then unreserving, and finally some more
> >>>       copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >>>       details, but looks all safe.
> >>>     - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >>>       seen, seems to only create a fence and copy it out.
> >>>     - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >>>       found there.
> >>>     Summary: vmwgfx seems to be fine too.
> >>>
> >>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >>>     copying from userspace before even looking up objects through their
> >>>     handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >>>
> >>> - qxl only has qxl_execbuffer_ioctl, which calls into
> >>>     qxl_process_single_command. There's a lovely comment before the
> >>>     __copy_from_user_inatomic that the slowpath should be copied from
> >>>     i915, but I guess that never happened. Try not to be unlucky and get
> >>>     your CS data evicted between when it's written and the kernel tries
> >>>     to read it. The only other copy_from_user is for relocs, but those
> >>>     are done before qxl_release_reserve_list(), which seems to be the
> >>>     only thing reserving buffers (in the ttm/dma_resv sense) in that
> >>>     code. So looks safe.
> >>>
> >>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >>>     usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >>>     everywhere and needs to be fixed up.
> >>>
> >>> Cc: Alex Deucher <alexander.deucher@amd.com>
> >>> Cc: Christian König <christian.koenig@amd.com>
> >>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >>> Cc: Eric Anholt <eric@anholt.net>
> >>> Cc: Dave Airlie <airlied@redhat.com>
> >>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> >>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>> ---
> >>>    drivers/dma-buf/dma-resv.c | 12 ++++++++++++
> >>>    1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >>> index 42a8f3f11681..3edca10d3faf 100644
> >>> --- a/drivers/dma-buf/dma-resv.c
> >>> +++ b/drivers/dma-buf/dma-resv.c
> >>> @@ -34,6 +34,7 @@
> >>>    #include <linux/dma-resv.h>
> >>>    #include <linux/export.h>
> >>> +#include <linux/sched/mm.h>
> >>>    /**
> >>>     * DOC: Reservation Object Overview
> >>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> >>>                     &reservation_seqcount_class);
> >>>     RCU_INIT_POINTER(obj->fence, NULL);
> >>>     RCU_INIT_POINTER(obj->fence_excl, NULL);
> >>> +
> >>> +   if (IS_ENABLED(CONFIG_LOCKDEP)) {
> >>> +           if (current->mm)
> >>> +                   down_read(&current->mm->mmap_sem);
> >>> +           ww_mutex_lock(&obj->lock, NULL);
> >>> +           fs_reclaim_acquire(GFP_KERNEL);
> >>> +           fs_reclaim_release(GFP_KERNEL);
> >>> +           ww_mutex_unlock(&obj->lock);
> >>> +           if (current->mm)
> >>> +                   up_read(&current->mm->mmap_sem);
> >>> +   }
> >>>    }
> >>>    EXPORT_SYMBOL(dma_resv_init);
> >> I assume if this would have been easily done and maintainable using only
> >> lockdep annotation instead of actually acquiring the locks, that would have
> >> been done?
> > There's might_lock(), plus a pile of macros, but they don't map obviuosly,
> > so pretty good chances I accidentally end up with the wrong type of
> > annotation. Easier to just take the locks quickly, and stuff that all into
> > a lockdep-only section to avoid overhead.
> >
> >> Otherwise LGTM.
> >>
> >> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
> >>
> >> Will test this and let you know if it trips on vmwgfx, but it really
> >> shouldn't.
> > Thanks, Daniel
>
> One thing that strikes me is that this puts restrictions on where you
> can actually initialize a dma_resv, even if locking orders are otherwise
> obeyed. But that might not be a big problem.

Hm yeah ... the trouble is a need a non-kthread thread so that I have
a current->mm. Otherwise I'd have put it into some init section with a
temp dma_buf. And I kinda don't want to create a fake ->mm just for
lockdep priming. I don't expect this to be a real problem in practice,
since before you've called dma_resv_init the reservation lock doesn't
exist, so you can't hold it. And you've probably just allocated it, so
fs_reclaim is going to be fine. And if you allocate dma_resv objects
from your fault handlers I have questions anyway :-)

So I think this should be safe.
-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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Thomas Hellström (VMware)]

On 8/21/19 6:34 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>>
>>> - vram helpers should be fine, they don't do command submission, so
>>>     really no business holding struct_mutex while doing copy_*_user. But
>>>     I haven't checked them all.
>>>
>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>>>     looks clean.
>>>
>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>>>     copying from/to userspace happens all in v3d_lookup_bos which is
>>>     outside of the critical section.
>>>
>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>>>     - vmw_execbuf_process: First this does some copies in
>>>       vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>>>       Then comes the usual ttm reserve/validate sequence, then actual
>>>       submission/fencing, then unreserving, and finally some more
>>>       copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>>>       details, but looks all safe.
>>>     - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>>>       seen, seems to only create a fence and copy it out.
>>>     - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>>>       found there.
>>>     Summary: vmwgfx seems to be fine too.
>>>
>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>>>     copying from userspace before even looking up objects through their
>>>     handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>>>
>>> - qxl only has qxl_execbuffer_ioctl, which calls into
>>>     qxl_process_single_command. There's a lovely comment before the
>>>     __copy_from_user_inatomic that the slowpath should be copied from
>>>     i915, but I guess that never happened. Try not to be unlucky and get
>>>     your CS data evicted between when it's written and the kernel tries
>>>     to read it. The only other copy_from_user is for relocs, but those
>>>     are done before qxl_release_reserve_list(), which seems to be the
>>>     only thing reserving buffers (in the ttm/dma_resv sense) in that
>>>     code. So looks safe.
>>>
>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>>>     usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>>>     everywhere and needs to be fixed up.
>>>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>> Cc: Eric Anholt <eric@anholt.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>    drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>>>    1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>>> index 42a8f3f11681..3edca10d3faf 100644
>>> --- a/drivers/dma-buf/dma-resv.c
>>> +++ b/drivers/dma-buf/dma-resv.c
>>> @@ -34,6 +34,7 @@
>>>    #include <linux/dma-resv.h>
>>>    #include <linux/export.h>
>>> +#include <linux/sched/mm.h>
>>>    /**
>>>     * DOC: Reservation Object Overview
>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>>>    			&reservation_seqcount_class);
>>>    	RCU_INIT_POINTER(obj->fence, NULL);
>>>    	RCU_INIT_POINTER(obj->fence_excl, NULL);
>>> +
>>> +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
>>> +		if (current->mm)
>>> +			down_read(&current->mm->mmap_sem);
>>> +		ww_mutex_lock(&obj->lock, NULL);
>>> +		fs_reclaim_acquire(GFP_KERNEL);
>>> +		fs_reclaim_release(GFP_KERNEL);
>>> +		ww_mutex_unlock(&obj->lock);
>>> +		if (current->mm)
>>> +			up_read(&current->mm->mmap_sem);
>>> +	}
>>>    }
>>>    EXPORT_SYMBOL(dma_resv_init);
>> I assume if this would have been easily done and maintainable using only
>> lockdep annotation instead of actually acquiring the locks, that would have
>> been done?
> There's might_lock(), plus a pile of macros, but they don't map obviuosly,
> so pretty good chances I accidentally end up with the wrong type of
> annotation. Easier to just take the locks quickly, and stuff that all into
> a lockdep-only section to avoid overhead.
>
>> Otherwise LGTM.
>>
>> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
>>
>> Will test this and let you know if it trips on vmwgfx, but it really
>> shouldn't.
> Thanks, Daniel

One thing that strikes me is that this puts restrictions on where you 
can actually initialize a dma_resv, even if locking orders are otherwise 
obeyed. But that might not be a big problem.

/Thomas




_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> > 
> > - i915, radeon, amdgpu should be clean per their maintainers.
> > 
> > - vram helpers should be fine, they don't do command submission, so
> >    really no business holding struct_mutex while doing copy_*_user. But
> >    I haven't checked them all.
> > 
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >    looks clean.
> > 
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >    copying from/to userspace happens all in v3d_lookup_bos which is
> >    outside of the critical section.
> > 
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >    - vmw_execbuf_process: First this does some copies in
> >      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >      Then comes the usual ttm reserve/validate sequence, then actual
> >      submission/fencing, then unreserving, and finally some more
> >      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >      details, but looks all safe.
> >    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >      seen, seems to only create a fence and copy it out.
> >    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >      found there.
> >    Summary: vmwgfx seems to be fine too.
> > 
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >    copying from userspace before even looking up objects through their
> >    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> > 
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >    qxl_process_single_command. There's a lovely comment before the
> >    __copy_from_user_inatomic that the slowpath should be copied from
> >    i915, but I guess that never happened. Try not to be unlucky and get
> >    your CS data evicted between when it's written and the kernel tries
> >    to read it. The only other copy_from_user is for relocs, but those
> >    are done before qxl_release_reserve_list(), which seems to be the
> >    only thing reserving buffers (in the ttm/dma_resv sense) in that
> >    code. So looks safe.
> > 
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >    everywhere and needs to be fixed up.
> > 
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >   drivers/dma-buf/dma-resv.c | 12 ++++++++++++
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 42a8f3f11681..3edca10d3faf 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >   #include <linux/dma-resv.h>
> >   #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >   /**
> >    * DOC: Reservation Object Overview
> > @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> >   			&reservation_seqcount_class);
> >   	RCU_INIT_POINTER(obj->fence, NULL);
> >   	RCU_INIT_POINTER(obj->fence_excl, NULL);
> > +
> > +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > +		if (current->mm)
> > +			down_read(&current->mm->mmap_sem);
> > +		ww_mutex_lock(&obj->lock, NULL);
> > +		fs_reclaim_acquire(GFP_KERNEL);
> > +		fs_reclaim_release(GFP_KERNEL);
> > +		ww_mutex_unlock(&obj->lock);
> > +		if (current->mm)
> > +			up_read(&current->mm->mmap_sem);
> > +	}
> >   }
> >   EXPORT_SYMBOL(dma_resv_init);
> 
> I assume if this would have been easily done and maintainable using only
> lockdep annotation instead of actually acquiring the locks, that would have
> been done?

There's might_lock(), plus a pile of macros, but they don't map obviuosly,
so pretty good chances I accidentally end up with the wrong type of
annotation. Easier to just take the locks quickly, and stuff that all into
a lockdep-only section to avoid overhead.

> Otherwise LGTM.
> 
> Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
> 
> Will test this and let you know if it trips on vmwgfx, but it really
> shouldn't.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Thomas Hellström (VMware)]

On 8/20/19 4:53 PM, Daniel Vetter wrote:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>    really no business holding struct_mutex while doing copy_*_user. But
>    I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>    looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>    copying from/to userspace happens all in v3d_lookup_bos which is
>    outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>    - vmw_execbuf_process: First this does some copies in
>      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>      Then comes the usual ttm reserve/validate sequence, then actual
>      submission/fencing, then unreserving, and finally some more
>      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>      details, but looks all safe.
>    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>      seen, seems to only create a fence and copy it out.
>    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>      found there.
>    Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>    copying from userspace before even looking up objects through their
>    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>    qxl_process_single_command. There's a lovely comment before the
>    __copy_from_user_inatomic that the slowpath should be copied from
>    i915, but I guess that never happened. Try not to be unlucky and get
>    your CS data evicted between when it's written and the kernel tries
>    to read it. The only other copy_from_user is for relocs, but those
>    are done before qxl_release_reserve_list(), which seems to be the
>    only thing reserving buffers (in the ttm/dma_resv sense) in that
>    code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>    everywhere and needs to be fixed up.
>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>   drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 42a8f3f11681..3edca10d3faf 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/dma-resv.h>
>   #include <linux/export.h>
> +#include <linux/sched/mm.h>
>   
>   /**
>    * DOC: Reservation Object Overview
> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>   			&reservation_seqcount_class);
>   	RCU_INIT_POINTER(obj->fence, NULL);
>   	RCU_INIT_POINTER(obj->fence_excl, NULL);
> +
> +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
> +		if (current->mm)
> +			down_read(&current->mm->mmap_sem);
> +		ww_mutex_lock(&obj->lock, NULL);
> +		fs_reclaim_acquire(GFP_KERNEL);
> +		fs_reclaim_release(GFP_KERNEL);
> +		ww_mutex_unlock(&obj->lock);
> +		if (current->mm)
> +			up_read(&current->mm->mmap_sem);
> +	}
>   }
>   EXPORT_SYMBOL(dma_resv_init);
>   

I assume if this would have been easily done and maintainable using only 
lockdep annotation instead of actually acquiring the locks, that would 
have been done?

Otherwise LGTM.

Reviewed-by: Thomas Hellström <thellstrom@vmware.com>

Will test this and let you know if it trips on vmwgfx, but it really 
shouldn't.

/Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

On Tue, Aug 20, 2019 at 02:56:36PM +0000, Koenig, Christian wrote:
> Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >    really no business holding struct_mutex while doing copy_*_user. But
> >    I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >    looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >    copying from/to userspace happens all in v3d_lookup_bos which is
> >    outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >    - vmw_execbuf_process: First this does some copies in
> >      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >      Then comes the usual ttm reserve/validate sequence, then actual
> >      submission/fencing, then unreserving, and finally some more
> >      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >      details, but looks all safe.
> >    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >      seen, seems to only create a fence and copy it out.
> >    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >      found there.
> >    Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >    copying from userspace before even looking up objects through their
> >    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >    qxl_process_single_command. There's a lovely comment before the
> >    __copy_from_user_inatomic that the slowpath should be copied from
> >    i915, but I guess that never happened. Try not to be unlucky and get
> >    your CS data evicted between when it's written and the kernel tries
> >    to read it. The only other copy_from_user is for relocs, but those
> >    are done before qxl_release_reserve_list(), which seems to be the
> >    only thing reserving buffers (in the ttm/dma_resv sense) in that
> >    code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >    everywhere and needs to be fixed up.
> >
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> Reviewed-by: Christian König <christian.koenig@amd.com>

Does this r-b just apply to radeon/amdgpu or for the full audit?
-Daniel

> 
> > ---
> >   drivers/dma-buf/dma-resv.c | 12 ++++++++++++
> >   1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 42a8f3f11681..3edca10d3faf 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >   
> >   #include <linux/dma-resv.h>
> >   #include <linux/export.h>
> > +#include <linux/sched/mm.h>
> >   
> >   /**
> >    * DOC: Reservation Object Overview
> > @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> >   			&reservation_seqcount_class);
> >   	RCU_INIT_POINTER(obj->fence, NULL);
> >   	RCU_INIT_POINTER(obj->fence_excl, NULL);
> > +
> > +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > +		if (current->mm)
> > +			down_read(&current->mm->mmap_sem);
> > +		ww_mutex_lock(&obj->lock, NULL);
> > +		fs_reclaim_acquire(GFP_KERNEL);
> > +		fs_reclaim_release(GFP_KERNEL);
> > +		ww_mutex_unlock(&obj->lock);
> > +		if (current->mm)
> > +			up_read(&current->mm->mmap_sem);
> > +	}
> >   }
> >   EXPORT_SYMBOL(dma_resv_init);
> >   
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Chris Wilson]

Quoting Daniel Vetter (2019-08-20 15:53:34)
> Full audit of everyone:
> 
> - i915, radeon, amdgpu should be clean per their maintainers.
> 
> - vram helpers should be fine, they don't do command submission, so
>   really no business holding struct_mutex while doing copy_*_user. But
>   I haven't checked them all.
> 
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>   looks clean.
> 
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>   copying from/to userspace happens all in v3d_lookup_bos which is
>   outside of the critical section.
> 
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>   - vmw_execbuf_process: First this does some copies in
>     vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>     Then comes the usual ttm reserve/validate sequence, then actual
>     submission/fencing, then unreserving, and finally some more
>     copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>     details, but looks all safe.
>   - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>     seen, seems to only create a fence and copy it out.
>   - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>     found there.
>   Summary: vmwgfx seems to be fine too.
> 
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>   copying from userspace before even looking up objects through their
>   handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> 
> - qxl only has qxl_execbuffer_ioctl, which calls into
>   qxl_process_single_command. There's a lovely comment before the
>   __copy_from_user_inatomic that the slowpath should be copied from
>   i915, but I guess that never happened. Try not to be unlucky and get
>   your CS data evicted between when it's written and the kernel tries
>   to read it. The only other copy_from_user is for relocs, but those
>   are done before qxl_release_reserve_list(), which seems to be the
>   only thing reserving buffers (in the ttm/dma_resv sense) in that
>   code. So looks safe.
> 
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>   usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>   everywhere and needs to be fixed up.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 42a8f3f11681..3edca10d3faf 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/dma-resv.h>
>  #include <linux/export.h>
> +#include <linux/sched/mm.h>
>  
>  /**
>   * DOC: Reservation Object Overview
> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>                         &reservation_seqcount_class);
>         RCU_INIT_POINTER(obj->fence, NULL);
>         RCU_INIT_POINTER(obj->fence_excl, NULL);
> +
> +       if (IS_ENABLED(CONFIG_LOCKDEP)) {
> +               if (current->mm)
> +                       down_read(&current->mm->mmap_sem);
> +               ww_mutex_lock(&obj->lock, NULL);
> +               fs_reclaim_acquire(GFP_KERNEL);
> +               fs_reclaim_release(GFP_KERNEL);

A candidate for might_alloc(GFP_KERNEL), we've repeated this often
enough.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] dma_resv: prime lockdep annotations

[Koenig, Christian]

Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>    really no business holding struct_mutex while doing copy_*_user. But
>    I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>    looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>    copying from/to userspace happens all in v3d_lookup_bos which is
>    outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>    - vmw_execbuf_process: First this does some copies in
>      vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
>      Then comes the usual ttm reserve/validate sequence, then actual
>      submission/fencing, then unreserving, and finally some more
>      copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
>      details, but looks all safe.
>    - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
>      seen, seems to only create a fence and copy it out.
>    - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
>      found there.
>    Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>    copying from userspace before even looking up objects through their
>    handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>    qxl_process_single_command. There's a lovely comment before the
>    __copy_from_user_inatomic that the slowpath should be copied from
>    i915, but I guess that never happened. Try not to be unlucky and get
>    your CS data evicted between when it's written and the kernel tries
>    to read it. The only other copy_from_user is for relocs, but those
>    are done before qxl_release_reserve_list(), which seems to be the
>    only thing reserving buffers (in the ttm/dma_resv sense) in that
>    code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>    usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>    everywhere and needs to be fixed up.
>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

> ---
>   drivers/dma-buf/dma-resv.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 42a8f3f11681..3edca10d3faf 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/dma-resv.h>
>   #include <linux/export.h>
> +#include <linux/sched/mm.h>
>   
>   /**
>    * DOC: Reservation Object Overview
> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
>   			&reservation_seqcount_class);
>   	RCU_INIT_POINTER(obj->fence, NULL);
>   	RCU_INIT_POINTER(obj->fence_excl, NULL);
> +
> +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
> +		if (current->mm)
> +			down_read(&current->mm->mmap_sem);
> +		ww_mutex_lock(&obj->lock, NULL);
> +		fs_reclaim_acquire(GFP_KERNEL);
> +		fs_reclaim_release(GFP_KERNEL);
> +		ww_mutex_unlock(&obj->lock);
> +		if (current->mm)
> +			up_read(&current->mm->mmap_sem);
> +	}
>   }
>   EXPORT_SYMBOL(dma_resv_init);
>   

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] dma_resv: prime lockdep annotations

[Daniel Vetter]

Full audit of everyone:

- i915, radeon, amdgpu should be clean per their maintainers.

- vram helpers should be fine, they don't do command submission, so
  really no business holding struct_mutex while doing copy_*_user. But
  I haven't checked them all.

- panfrost seems to dma_resv_lock only in panfrost_job_push, which
  looks clean.

- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
  copying from/to userspace happens all in v3d_lookup_bos which is
  outside of the critical section.

- vmwgfx has a bunch of ioctls that do their own copy_*_user:
  - vmw_execbuf_process: First this does some copies in
    vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
    Then comes the usual ttm reserve/validate sequence, then actual
    submission/fencing, then unreserving, and finally some more
    copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
    details, but looks all safe.
  - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
    seen, seems to only create a fence and copy it out.
  - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
    found there.
  Summary: vmwgfx seems to be fine too.

- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
  copying from userspace before even looking up objects through their
  handles, so safe. Plus the getparam/getcaps ioctl, also both safe.

- qxl only has qxl_execbuffer_ioctl, which calls into
  qxl_process_single_command. There's a lovely comment before the
  __copy_from_user_inatomic that the slowpath should be copied from
  i915, but I guess that never happened. Try not to be unlucky and get
  your CS data evicted between when it's written and the kernel tries
  to read it. The only other copy_from_user is for relocs, but those
  are done before qxl_release_reserve_list(), which seems to be the
  only thing reserving buffers (in the ttm/dma_resv sense) in that
  code. So looks safe.

- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
  usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
  everywhere and needs to be fixed up.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/dma-buf/dma-resv.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 42a8f3f11681..3edca10d3faf 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
 
 #include <linux/dma-resv.h>
 #include <linux/export.h>
+#include <linux/sched/mm.h>
 
 /**
  * DOC: Reservation Object Overview
@@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
 			&reservation_seqcount_class);
 	RCU_INIT_POINTER(obj->fence, NULL);
 	RCU_INIT_POINTER(obj->fence_excl, NULL);
+
+	if (IS_ENABLED(CONFIG_LOCKDEP)) {
+		if (current->mm)
+			down_read(&current->mm->mmap_sem);
+		ww_mutex_lock(&obj->lock, NULL);
+		fs_reclaim_acquire(GFP_KERNEL);
+		fs_reclaim_release(GFP_KERNEL);
+		ww_mutex_unlock(&obj->lock);
+		if (current->mm)
+			up_read(&current->mm->mmap_sem);
+	}
 }
 EXPORT_SYMBOL(dma_resv_init);
 
-- 
2.23.0.rc1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx