[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