* [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:37 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:37 UTC (permalink / raw)
To: DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:37 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:37 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:37 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:37 UTC (permalink / raw)
To: DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-04 17:38 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:38 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Maarten Lankhorst, Ben Skeggs,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, 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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-04 17:38 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:38 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, nouveau,
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-04 17:38 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:38 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, nouveau,
Daniel Vetter, Ilia Mirkin
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
@ 2019-11-04 17:38 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:38 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellström, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
@ 2019-11-04 17:38 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:38 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellström, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:48 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:48 UTC (permalink / raw)
To: DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:48 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:48 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 17:48 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 17:48 UTC (permalink / raw)
To: DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:01 ` Koenig, Christian
0 siblings, 0 replies; 68+ messages in thread
From: Koenig, Christian @ 2019-11-04 20:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Deucher, Alexander,
Dave Airlie, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:01 ` Koenig, Christian
0 siblings, 0 replies; 68+ messages in thread
From: Koenig, Christian @ 2019-11-04 20:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
VMware Graphics, Gerd Hoffmann, Thomas Zimmermann, Daniel Vetter,
Deucher, Alexander, Dave Airlie, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:01 ` Koenig, Christian
0 siblings, 0 replies; 68+ messages in thread
From: Koenig, Christian @ 2019-11-04 20:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Rob Herring, Thomas Hellstrom, Tomeu Vizoso,
Intel Graphics Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Deucher, Alexander,
Dave Airlie, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:55 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 20:55 UTC (permalink / raw)
To: Koenig, Christian
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, DRI Development, VMware Graphics,
Gerd Hoffmann, Thomas Zimmermann, Dave Airlie, Deucher,
Alexander, Daniel Vetter, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:55 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 20:55 UTC (permalink / raw)
To: Koenig, Christian
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, DRI Development, VMware Graphics,
Gerd Hoffmann, Thomas Zimmermann, Dave Airlie, Deucher,
Alexander, Daniel Vetter, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 20:55 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-04 20:55 UTC (permalink / raw)
To: Koenig, Christian
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, DRI Development, VMware Graphics,
Gerd Hoffmann, Thomas Zimmermann, Dave Airlie, Deucher,
Alexander, Daniel Vetter, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 21:00 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-04 21:00 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 21:00 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-04 21:00 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* ✓ Fi.CI.BAT: success for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 21:22 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-04 21:22 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-04 21:22 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-04 21:22 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* ✓ Fi.CI.IGT: success for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-05 8:31 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-05 8:31 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] dma_resv: prime lockdep annotations
@ 2019-11-05 8:31 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-05 8:31 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 11:04 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-05 11:04 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, nouveau,
Daniel Vetter, Ilia Mirkin
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 11:04 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-05 11:04 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, nouveau,
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 11:04 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-05 11:04 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, nouveau,
Daniel Vetter, Ilia Mirkin
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 12:30 ` Maarten Lankhorst
0 siblings, 0 replies; 68+ messages in thread
From: Maarten Lankhorst @ 2019-11-05 12:30 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
Intel Graphics Development, Ben Skeggs, Daniel Vetter
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 12:30 ` Maarten Lankhorst
0 siblings, 0 replies; 68+ messages in thread
From: Maarten Lankhorst @ 2019-11-05 12:30 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: nouveau, Intel Graphics Development, Ben Skeggs, Daniel Vetter,
Daniel Vetter
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
@ 2019-11-05 12:30 ` Maarten Lankhorst
0 siblings, 0 replies; 68+ messages in thread
From: Maarten Lankhorst @ 2019-11-05 12:30 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: nouveau, Intel Graphics Development, Ben Skeggs, Daniel Vetter,
Daniel Vetter, Ilia Mirkin
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
@ 2019-11-06 10:24 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:24 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellström, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
@ 2019-11-06 10:24 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:24 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellström, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-11 13:11 ` Steven Price
0 siblings, 0 replies; 68+ messages in thread
From: Steven Price @ 2019-11-11 13:11 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
VMware Graphics, Gerd Hoffmann, Thomas Zimmermann, Dave Airlie,
Alex Deucher, Daniel Vetter, Christian König, Ben Skeggs
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-11 13:11 ` Steven Price
0 siblings, 0 replies; 68+ messages in thread
From: Steven Price @ 2019-11-11 13:11 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
VMware Graphics, Gerd Hoffmann, Thomas Zimmermann, Dave Airlie,
Alex Deucher, Daniel Vetter, Christian König, Ben Skeggs
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
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-11 15:42 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-11 15:42 UTC (permalink / raw)
To: Steven Price
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Dave Airlie, Alex Deucher, Daniel Vetter,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-11 15:42 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-11 15:42 UTC (permalink / raw)
To: Steven Price
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Dave Airlie, Alex Deucher, Daniel Vetter,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-11 15:42 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-11 15:42 UTC (permalink / raw)
To: Steven Price
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Dave Airlie, Alex Deucher, Daniel Vetter,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
@ 2019-11-11 18:12 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-11 18:12 UTC (permalink / raw)
To: Steven Price; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
@ 2019-11-11 18:12 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-11 18:12 UTC (permalink / raw)
To: Steven Price; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* ✗ Fi.CI.BAT: failure for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
@ 2019-11-11 18:48 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-11 18:48 UTC (permalink / raw)
To: Steven Price; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] dma_resv: prime lockdep annotations (rev2)
@ 2019-11-11 18:48 ` Patchwork
0 siblings, 0 replies; 68+ messages in thread
From: Patchwork @ 2019-11-11 18:48 UTC (permalink / raw)
To: Steven Price; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-14 11:50 ` Steven Price
0 siblings, 0 replies; 68+ messages in thread
From: Steven Price @ 2019-11-14 11:50 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-14 11:50 ` Steven Price
0 siblings, 0 replies; 68+ messages in thread
From: Steven Price @ 2019-11-14 11:50 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-14 11:50 ` Steven Price
0 siblings, 0 replies; 68+ messages in thread
From: Steven Price @ 2019-11-14 11:50 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Tomeu Vizoso, Intel Graphics Development,
DRI Development, VMware Graphics, Gerd Hoffmann,
Thomas Zimmermann, Daniel Vetter, Alex Deucher, Dave Airlie,
Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-20 10:51 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-20 10:51 UTC (permalink / raw)
To: Steven Price
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, DRI Development, VMware Graphics,
Gerd Hoffmann, Thomas Zimmermann, Daniel Vetter, Alex Deucher,
Dave Airlie, Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
@ 2019-11-20 10:51 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-11-20 10:51 UTC (permalink / raw)
To: Steven Price
Cc: Thomas Hellstrom, Tomeu Vizoso, Daniel Vetter,
Intel Graphics Development, DRI Development, VMware Graphics,
Gerd Hoffmann, Thomas Zimmermann, Daniel Vetter, Alex Deucher,
Dave Airlie, Christian König, Ben Skeggs
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-10-21 14:50 [PATCH 0/3] dma_resv lockdep annotations/priming Daniel Vetter
@ 2019-10-21 14:50 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-10-21 14:50 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellström, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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)
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
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 f00b2e79882f..7a9b01aeaa3f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,7 +162,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(bdev->glob->mem_glob, acc_size);
}
@@ -1320,7 +1319,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;
@@ -1955,37 +1953,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
;
}
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 fe81c565e7ef..82ea26a49959 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -508,7 +508,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);
atomic_set(&fbo->base.cpu_writers, 0);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 79f01c5ff65e..28d73ef17073 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,30 +125,22 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
- * 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;
}
/*
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index d2277e06316d..c589639e9b50 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -155,7 +155,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
@@ -229,8 +228,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;
};
/**
@@ -763,7 +760,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.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 68+ messages in thread
* [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 21:50 [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
@ 2019-08-21 21:50 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 21:50 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellstrom, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian König
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)
Reviewed-by: Christian König <christian.koenig@amd.com>
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 20ff56f27aa4..d1ce5d315d5b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,7 +162,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(bdev->glob->mem_glob, acc_size);
}
@@ -1319,7 +1318,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;
@@ -1954,37 +1952,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
;
}
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 fe81c565e7ef..82ea26a49959 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -508,7 +508,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);
atomic_set(&fbo->base.cpu_writers, 0);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 76eedb963693..a61a35e57d1c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,30 +125,22 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
- * 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;
}
/*
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 43c4929a2171..21c7d0d28757 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -155,7 +155,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
@@ -229,8 +228,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;
};
/**
@@ -765,7 +762,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.23.0.rc1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 15:22 ` Daniel Vetter
@ 2019-08-21 15:34 ` Thomas Hellström (VMware)
0 siblings, 0 replies; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 15:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On 8/21/19 5:22 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 5:19 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 5:14 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
>>> <thomas_os@shipmail.org> wrote:
>>>> On 8/21/19 4:47 PM, Daniel Vetter wrote:
>>>>> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
>>>>> <thomas_os@shipmail.org> wrote:
>>>>>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>>>>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>>>>>> <thomas_os@shipmail.org> wrote:
>>>>>>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
>>>>>>>>> On 8/20/19 4:53 PM, 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.
>>>>>>>>>>
>>>>>>>>>> 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 | 34 ---------------------------------
>>>>>>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>>>>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>>>>>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>>> index 20ff56f27aa4..a952dd624b06 100644
>>>>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>>>>>>>>>> *bdev)
>>>>>>>>>> ;
>>>>>>>>>> }
>>>>>>>>>> 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_vm.c
>>>>>>>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>>>> index 76eedb963693..505e1787aeea 100644
>>>>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>>>>>>>>> vm_fault *vmf)
>>>>>>>>>> &bdev->man[bo->mem.mem_type];
>>>>>>>>>> struct vm_area_struct cvma;
>>>>>>>>>> - /*
>>>>>>>>>> - * 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);
>>>>>>>>>> - 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...
>>>>>>>>>> - */
>>>>>>>>> I think you should justify why the above code is removed, since the
>>>>>>>>> comments actually outlines what to do if we change locking order.
>>>>>>>>>
>>>>>>>>> The code that's removed above is not for adjusting locking orders but
>>>>>>>>> to decrease the mm latency by releasing the mmap_sem while waiting for
>>>>>>>>> bo reserve which in turn might be waiting for GPU. At a minimum we
>>>>>>>>> should have a separate patch with justification.
>>>>>>>>>
>>>>>>>>> Note that the caller here ensures locking progress by adjusting the
>>>>>>>>> RETRY flags after a retry.
>>>>>>> That would be patches 1&2 in this series.
>>>>>>>
>>>>>> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
>>>>>> patch should look along the lines of (based on an older tree) to
>>>>>> implement the new locking-order mmap_sem->reservation,
>>>>> Only nouveau was breaking was doing copy_*_user or get_user_pages
>>>>> while holding dma_resv locks, no one else. So nothing else needed to
>>>>> be changed. But patch 1 contains the full audit. I might have missed
>>>>> something.
>>>>>
>>>>>> but to keep the mm latency optimization using the RETRY functionality:
>>>>> Still no idea why this is needed? All the comments here and the code
>>>>> and history seem like they've been about the mmap_sem vs dma_resv
>>>>> inversion between driver ioctls and fault handling here. Once that's
>>>>> officially fixed there's no reason to play games here and retry loops
>>>>> - previously that was necessary because the old ttm_bo_vm_fault had a
>>>>> busy spin and that's definitely not nice. If it's needed I think it
>>>>> should be a second patch on top, to keep this all clear. I had to
>>>>> audit an enormous amount of code, I'd like to make sure I didn't miss
>>>>> anything before we start to make this super fancy again. Further
>>>>> patches on top is obviously all fine with me.
>>>>> -Daniel
>>>> Yes, but there are two different things you remove here. One is the
>>>> workaround for the locking reversal, which is obviously correct.
>>>>
>>>> One is TTM's implementation of the mmap_sem latency optimization, which
>>>> looks like an oversight.
>>>>
>>>> That optimization is why the VM_FAULT_RETRY functionality was added to
>>>> mm in the first place and is intended to be used when drivers expect a
>>>> substantial sleep to avoid keeping the pretty globalish mmap_sem held
>>>> while that sleep is taking place. We do exactly the same while waiting
>>>> for move-fences (ttm_bo_vm_fault_idle) and other drivers that expect
>>>> long waits in the fault handler do the same.
>>> Hm, are we guaranteed that core mm will only call us once with
>>> ALLOW_RETRY?
>> Last time I looked in the implementation, yes. The ALLOW_RETRY was there
>> to specifically
>> allow making progress in the locking.
>>
>>> Just to make sure that we're not live-locking here. I'd
>>> also like to get rid of the wu_mutex, that just looks really strange
>>> (and I thought it was to duct-tape over the inversion, not as an
>>> optimization). If the livelock due to locking inversion is gone I have
>>> no idea anymore why we even needs the wu_mutex.
>> Yes, my interpretation of this is that wu_mutex definitely can be ditched.
> Ok I'll respin and just do normal interruptible locks, keeping the
> mmap_sem-less path. I think perfectly ok to leave the optimization in,
> as long as we can remove the wu_mutex.
>
> btw r-b/t-b on patch 1 from vmwgfx would be very much appreciated.
> That one is the real trick in this series here I think.
Thanks!
I'll look into patch 1 as well.
/Thomas
> -Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 15:19 ` Thomas Hellström (VMware)
@ 2019-08-21 15:22 ` Daniel Vetter
2019-08-21 15:34 ` Thomas Hellström (VMware)
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 15:22 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 5:19 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
> On 8/21/19 5:14 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> wrote:
> >> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> >>> <thomas_os@shipmail.org> wrote:
> >>>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> >>>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> >>>>> <thomas_os@shipmail.org> wrote:
> >>>>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>>>>>> On 8/20/19 4:53 PM, 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.
> >>>>>>>>
> >>>>>>>> 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 | 34 ---------------------------------
> >>>>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >>>>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
> >>>>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>>>> index 20ff56f27aa4..a952dd624b06 100644
> >>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >>>>>>>> *bdev)
> >>>>>>>> ;
> >>>>>>>> }
> >>>>>>>> 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_vm.c
> >>>>>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>>>> index 76eedb963693..505e1787aeea 100644
> >>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >>>>>>>> vm_fault *vmf)
> >>>>>>>> &bdev->man[bo->mem.mem_type];
> >>>>>>>> struct vm_area_struct cvma;
> >>>>>>>> - /*
> >>>>>>>> - * 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);
> >>>>>>>> - 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...
> >>>>>>>> - */
> >>>>>>> I think you should justify why the above code is removed, since the
> >>>>>>> comments actually outlines what to do if we change locking order.
> >>>>>>>
> >>>>>>> The code that's removed above is not for adjusting locking orders but
> >>>>>>> to decrease the mm latency by releasing the mmap_sem while waiting for
> >>>>>>> bo reserve which in turn might be waiting for GPU. At a minimum we
> >>>>>>> should have a separate patch with justification.
> >>>>>>>
> >>>>>>> Note that the caller here ensures locking progress by adjusting the
> >>>>>>> RETRY flags after a retry.
> >>>>> That would be patches 1&2 in this series.
> >>>>>
> >>>> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
> >>>> patch should look along the lines of (based on an older tree) to
> >>>> implement the new locking-order mmap_sem->reservation,
> >>> Only nouveau was breaking was doing copy_*_user or get_user_pages
> >>> while holding dma_resv locks, no one else. So nothing else needed to
> >>> be changed. But patch 1 contains the full audit. I might have missed
> >>> something.
> >>>
> >>>> but to keep the mm latency optimization using the RETRY functionality:
> >>> Still no idea why this is needed? All the comments here and the code
> >>> and history seem like they've been about the mmap_sem vs dma_resv
> >>> inversion between driver ioctls and fault handling here. Once that's
> >>> officially fixed there's no reason to play games here and retry loops
> >>> - previously that was necessary because the old ttm_bo_vm_fault had a
> >>> busy spin and that's definitely not nice. If it's needed I think it
> >>> should be a second patch on top, to keep this all clear. I had to
> >>> audit an enormous amount of code, I'd like to make sure I didn't miss
> >>> anything before we start to make this super fancy again. Further
> >>> patches on top is obviously all fine with me.
> >>> -Daniel
> >> Yes, but there are two different things you remove here. One is the
> >> workaround for the locking reversal, which is obviously correct.
> >>
> >> One is TTM's implementation of the mmap_sem latency optimization, which
> >> looks like an oversight.
> >>
> >> That optimization is why the VM_FAULT_RETRY functionality was added to
> >> mm in the first place and is intended to be used when drivers expect a
> >> substantial sleep to avoid keeping the pretty globalish mmap_sem held
> >> while that sleep is taking place. We do exactly the same while waiting
> >> for move-fences (ttm_bo_vm_fault_idle) and other drivers that expect
> >> long waits in the fault handler do the same.
> > Hm, are we guaranteed that core mm will only call us once with
> > ALLOW_RETRY?
>
> Last time I looked in the implementation, yes. The ALLOW_RETRY was there
> to specifically
> allow making progress in the locking.
>
> > Just to make sure that we're not live-locking here. I'd
> > also like to get rid of the wu_mutex, that just looks really strange
> > (and I thought it was to duct-tape over the inversion, not as an
> > optimization). If the livelock due to locking inversion is gone I have
> > no idea anymore why we even needs the wu_mutex.
>
> Yes, my interpretation of this is that wu_mutex definitely can be ditched.
Ok I'll respin and just do normal interruptible locks, keeping the
mmap_sem-less path. I think perfectly ok to leave the optimization in,
as long as we can remove the wu_mutex.
btw r-b/t-b on patch 1 from vmwgfx would be very much appreciated.
That one is the real trick in this series here I think.
-Daniel
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 15:14 ` Daniel Vetter
@ 2019-08-21 15:19 ` Thomas Hellström (VMware)
2019-08-21 15:22 ` Daniel Vetter
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 15:19 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On 8/21/19 5:14 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 4:47 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
>>> <thomas_os@shipmail.org> wrote:
>>>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>>>> <thomas_os@shipmail.org> wrote:
>>>>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
>>>>>>> On 8/20/19 4:53 PM, 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.
>>>>>>>>
>>>>>>>> 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 | 34 ---------------------------------
>>>>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>>>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>> index 20ff56f27aa4..a952dd624b06 100644
>>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>>>>>>>> *bdev)
>>>>>>>> ;
>>>>>>>> }
>>>>>>>> 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_vm.c
>>>>>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>> index 76eedb963693..505e1787aeea 100644
>>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>>>>>>> vm_fault *vmf)
>>>>>>>> &bdev->man[bo->mem.mem_type];
>>>>>>>> struct vm_area_struct cvma;
>>>>>>>> - /*
>>>>>>>> - * 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);
>>>>>>>> - 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...
>>>>>>>> - */
>>>>>>> I think you should justify why the above code is removed, since the
>>>>>>> comments actually outlines what to do if we change locking order.
>>>>>>>
>>>>>>> The code that's removed above is not for adjusting locking orders but
>>>>>>> to decrease the mm latency by releasing the mmap_sem while waiting for
>>>>>>> bo reserve which in turn might be waiting for GPU. At a minimum we
>>>>>>> should have a separate patch with justification.
>>>>>>>
>>>>>>> Note that the caller here ensures locking progress by adjusting the
>>>>>>> RETRY flags after a retry.
>>>>> That would be patches 1&2 in this series.
>>>>>
>>>> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
>>>> patch should look along the lines of (based on an older tree) to
>>>> implement the new locking-order mmap_sem->reservation,
>>> Only nouveau was breaking was doing copy_*_user or get_user_pages
>>> while holding dma_resv locks, no one else. So nothing else needed to
>>> be changed. But patch 1 contains the full audit. I might have missed
>>> something.
>>>
>>>> but to keep the mm latency optimization using the RETRY functionality:
>>> Still no idea why this is needed? All the comments here and the code
>>> and history seem like they've been about the mmap_sem vs dma_resv
>>> inversion between driver ioctls and fault handling here. Once that's
>>> officially fixed there's no reason to play games here and retry loops
>>> - previously that was necessary because the old ttm_bo_vm_fault had a
>>> busy spin and that's definitely not nice. If it's needed I think it
>>> should be a second patch on top, to keep this all clear. I had to
>>> audit an enormous amount of code, I'd like to make sure I didn't miss
>>> anything before we start to make this super fancy again. Further
>>> patches on top is obviously all fine with me.
>>> -Daniel
>> Yes, but there are two different things you remove here. One is the
>> workaround for the locking reversal, which is obviously correct.
>>
>> One is TTM's implementation of the mmap_sem latency optimization, which
>> looks like an oversight.
>>
>> That optimization is why the VM_FAULT_RETRY functionality was added to
>> mm in the first place and is intended to be used when drivers expect a
>> substantial sleep to avoid keeping the pretty globalish mmap_sem held
>> while that sleep is taking place. We do exactly the same while waiting
>> for move-fences (ttm_bo_vm_fault_idle) and other drivers that expect
>> long waits in the fault handler do the same.
> Hm, are we guaranteed that core mm will only call us once with
> ALLOW_RETRY?
Last time I looked in the implementation, yes. The ALLOW_RETRY was there
to specifically
allow making progress in the locking.
> Just to make sure that we're not live-locking here. I'd
> also like to get rid of the wu_mutex, that just looks really strange
> (and I thought it was to duct-tape over the inversion, not as an
> optimization). If the livelock due to locking inversion is gone I have
> no idea anymore why we even needs the wu_mutex.
Yes, my interpretation of this is that wu_mutex definitely can be ditched.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 15:03 ` Thomas Hellström (VMware)
@ 2019-08-21 15:14 ` Daniel Vetter
2019-08-21 15:19 ` Thomas Hellström (VMware)
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 15:14 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> wrote:
> >> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> >>> <thomas_os@shipmail.org> wrote:
> >>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>>>> On 8/20/19 4:53 PM, 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.
> >>>>>>
> >>>>>> 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 | 34 ---------------------------------
> >>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
> >>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>> index 20ff56f27aa4..a952dd624b06 100644
> >>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >>>>>> *bdev)
> >>>>>> ;
> >>>>>> }
> >>>>>> 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_vm.c
> >>>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>> index 76eedb963693..505e1787aeea 100644
> >>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >>>>>> vm_fault *vmf)
> >>>>>> &bdev->man[bo->mem.mem_type];
> >>>>>> struct vm_area_struct cvma;
> >>>>>> - /*
> >>>>>> - * 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);
> >>>>>> - 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...
> >>>>>> - */
> >>>>> I think you should justify why the above code is removed, since the
> >>>>> comments actually outlines what to do if we change locking order.
> >>>>>
> >>>>> The code that's removed above is not for adjusting locking orders but
> >>>>> to decrease the mm latency by releasing the mmap_sem while waiting for
> >>>>> bo reserve which in turn might be waiting for GPU. At a minimum we
> >>>>> should have a separate patch with justification.
> >>>>>
> >>>>> Note that the caller here ensures locking progress by adjusting the
> >>>>> RETRY flags after a retry.
> >>> That would be patches 1&2 in this series.
> >>>
> >> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
> >> patch should look along the lines of (based on an older tree) to
> >> implement the new locking-order mmap_sem->reservation,
> > Only nouveau was breaking was doing copy_*_user or get_user_pages
> > while holding dma_resv locks, no one else. So nothing else needed to
> > be changed. But patch 1 contains the full audit. I might have missed
> > something.
> >
> >> but to keep the mm latency optimization using the RETRY functionality:
> > Still no idea why this is needed? All the comments here and the code
> > and history seem like they've been about the mmap_sem vs dma_resv
> > inversion between driver ioctls and fault handling here. Once that's
> > officially fixed there's no reason to play games here and retry loops
> > - previously that was necessary because the old ttm_bo_vm_fault had a
> > busy spin and that's definitely not nice. If it's needed I think it
> > should be a second patch on top, to keep this all clear. I had to
> > audit an enormous amount of code, I'd like to make sure I didn't miss
> > anything before we start to make this super fancy again. Further
> > patches on top is obviously all fine with me.
> > -Daniel
>
> Yes, but there are two different things you remove here. One is the
> workaround for the locking reversal, which is obviously correct.
>
> One is TTM's implementation of the mmap_sem latency optimization, which
> looks like an oversight.
>
> That optimization is why the VM_FAULT_RETRY functionality was added to
> mm in the first place and is intended to be used when drivers expect a
> substantial sleep to avoid keeping the pretty globalish mmap_sem held
> while that sleep is taking place. We do exactly the same while waiting
> for move-fences (ttm_bo_vm_fault_idle) and other drivers that expect
> long waits in the fault handler do the same.
Hm, are we guaranteed that core mm will only call us once with
ALLOW_RETRY? Just to make sure that we're not live-locking here. I'd
also like to get rid of the wu_mutex, that just looks really strange
(and I thought it was to duct-tape over the inversion, not as an
optimization). If the livelock due to locking inversion is gone I have
no idea anymore why we even needs the wu_mutex.
> To avoid this accidently happening there was even this comment:
>
> /*
> * 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;
>
> And I do really think we should avoid accidently removing this just to
> re-add it in a later patch, particularly when I pointed it out at review
> time.
Yeah I read that, but I didn't read this comment the way you now explained it.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:47 ` Daniel Vetter
2019-08-21 15:03 ` Thomas Hellström (VMware)
@ 2019-08-21 15:07 ` Koenig, Christian
1 sibling, 0 replies; 68+ messages in thread
From: Koenig, Christian @ 2019-08-21 15:07 UTC (permalink / raw)
To: Daniel Vetter, Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang, Ray, VMware Graphics, Gerd Hoffmann, Daniel Vetter
Am 21.08.19 um 16:47 schrieb Daniel Vetter:
> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>> <thomas_os@shipmail.org> wrote:
>>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
>>>>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>>>> [SNIP]
>> but to keep the mm latency optimization using the RETRY functionality:
> Still no idea why this is needed? All the comments here and the code
> and history seem like they've been about the mmap_sem vs dma_resv
> inversion between driver ioctls and fault handling here. Once that's
> officially fixed there's no reason to play games here and retry loops
> - previously that was necessary because the old ttm_bo_vm_fault had a
> busy spin and that's definitely not nice. If it's needed I think it
> should be a second patch on top, to keep this all clear. I had to
> audit an enormous amount of code, I'd like to make sure I didn't miss
> anything before we start to make this super fancy again. Further
> patches on top is obviously all fine with me.
I think this is just an optimization to not hold the mmap_sem while
waiting for the dma_resv lock.
I agree that it shouldn't be necessary, but maybe it's a good idea for
performance. I'm also OK with removing it, cause I'm not sure if it's
worth it.
But Thomas noted correctly that we should probably do it in a separate
patch so that when somebody points out "Hey my system is slower now!"
he's able to bisect to the change.
Christian.
> -Daniel
>
>> Thanks,
>> Thomas
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:47 ` Daniel Vetter
@ 2019-08-21 15:03 ` Thomas Hellström (VMware)
2019-08-21 15:14 ` Daniel Vetter
2019-08-21 15:07 ` Koenig, Christian
1 sibling, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 15:03 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On 8/21/19 4:47 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>> <thomas_os@shipmail.org> wrote:
>>>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
>>>>> On 8/20/19 4:53 PM, 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.
>>>>>>
>>>>>> 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 | 34 ---------------------------------
>>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>> index 20ff56f27aa4..a952dd624b06 100644
>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>>>>>> *bdev)
>>>>>> ;
>>>>>> }
>>>>>> 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_vm.c
>>>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>> index 76eedb963693..505e1787aeea 100644
>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>>>>> vm_fault *vmf)
>>>>>> &bdev->man[bo->mem.mem_type];
>>>>>> struct vm_area_struct cvma;
>>>>>> - /*
>>>>>> - * 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);
>>>>>> - 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...
>>>>>> - */
>>>>> I think you should justify why the above code is removed, since the
>>>>> comments actually outlines what to do if we change locking order.
>>>>>
>>>>> The code that's removed above is not for adjusting locking orders but
>>>>> to decrease the mm latency by releasing the mmap_sem while waiting for
>>>>> bo reserve which in turn might be waiting for GPU. At a minimum we
>>>>> should have a separate patch with justification.
>>>>>
>>>>> Note that the caller here ensures locking progress by adjusting the
>>>>> RETRY flags after a retry.
>>> That would be patches 1&2 in this series.
>>>
>> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
>> patch should look along the lines of (based on an older tree) to
>> implement the new locking-order mmap_sem->reservation,
> Only nouveau was breaking was doing copy_*_user or get_user_pages
> while holding dma_resv locks, no one else. So nothing else needed to
> be changed. But patch 1 contains the full audit. I might have missed
> something.
>
>> but to keep the mm latency optimization using the RETRY functionality:
> Still no idea why this is needed? All the comments here and the code
> and history seem like they've been about the mmap_sem vs dma_resv
> inversion between driver ioctls and fault handling here. Once that's
> officially fixed there's no reason to play games here and retry loops
> - previously that was necessary because the old ttm_bo_vm_fault had a
> busy spin and that's definitely not nice. If it's needed I think it
> should be a second patch on top, to keep this all clear. I had to
> audit an enormous amount of code, I'd like to make sure I didn't miss
> anything before we start to make this super fancy again. Further
> patches on top is obviously all fine with me.
> -Daniel
Yes, but there are two different things you remove here. One is the
workaround for the locking reversal, which is obviously correct.
One is TTM's implementation of the mmap_sem latency optimization, which
looks like an oversight.
That optimization is why the VM_FAULT_RETRY functionality was added to
mm in the first place and is intended to be used when drivers expect a
substantial sleep to avoid keeping the pretty globalish mmap_sem held
while that sleep is taking place. We do exactly the same while waiting
for move-fences (ttm_bo_vm_fault_idle) and other drivers that expect
long waits in the fault handler do the same.
To avoid this accidently happening there was even this comment:
/*
* 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;
And I do really think we should avoid accidently removing this just to
re-add it in a later patch, particularly when I pointed it out at review
time.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:27 ` Thomas Hellström (VMware)
@ 2019-08-21 14:47 ` Daniel Vetter
2019-08-21 15:03 ` Thomas Hellström (VMware)
2019-08-21 15:07 ` Koenig, Christian
0 siblings, 2 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 14:47 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> wrote:
> >> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>> On 8/20/19 4:53 PM, 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.
> >>>>
> >>>> 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 | 34 ---------------------------------
> >>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >>>> include/drm/ttm/ttm_bo_api.h | 1 -
> >>>> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>> index 20ff56f27aa4..a952dd624b06 100644
> >>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >>>> *bdev)
> >>>> ;
> >>>> }
> >>>> 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_vm.c
> >>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>> index 76eedb963693..505e1787aeea 100644
> >>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >>>> vm_fault *vmf)
> >>>> &bdev->man[bo->mem.mem_type];
> >>>> struct vm_area_struct cvma;
> >>>> - /*
> >>>> - * 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);
> >>>> - 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...
> >>>> - */
> >>> I think you should justify why the above code is removed, since the
> >>> comments actually outlines what to do if we change locking order.
> >>>
> >>> The code that's removed above is not for adjusting locking orders but
> >>> to decrease the mm latency by releasing the mmap_sem while waiting for
> >>> bo reserve which in turn might be waiting for GPU. At a minimum we
> >>> should have a separate patch with justification.
> >>>
> >>> Note that the caller here ensures locking progress by adjusting the
> >>> RETRY flags after a retry.
> > That would be patches 1&2 in this series.
> >
> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
> patch should look along the lines of (based on an older tree) to
> implement the new locking-order mmap_sem->reservation,
Only nouveau was breaking was doing copy_*_user or get_user_pages
while holding dma_resv locks, no one else. So nothing else needed to
be changed. But patch 1 contains the full audit. I might have missed
something.
> but to keep the mm latency optimization using the RETRY functionality:
Still no idea why this is needed? All the comments here and the code
and history seem like they've been about the mmap_sem vs dma_resv
inversion between driver ioctls and fault handling here. Once that's
officially fixed there's no reason to play games here and retry loops
- previously that was necessary because the old ttm_bo_vm_fault had a
busy spin and that's definitely not nice. If it's needed I think it
should be a second patch on top, to keep this all clear. I had to
audit an enormous amount of code, I'd like to make sure I didn't miss
anything before we start to make this super fancy again. Further
patches on top is obviously all fine with me.
-Daniel
> Thanks,
> Thomas
>
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 85f5bcbe0c76..68482c67b9f7 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -125,30 +125,20 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> &bdev->man[bo->mem.mem_type];
> struct vm_area_struct cvma;
>
> - /*
> - * 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.
> - */
> + /* Avoid blocking on reservation with mmap_sem held, if possible */
> if (unlikely(!reservation_object_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);
> - ttm_bo_put(bo);
> - }
> + if ((vmf->flags & FAULT_FLAG_ALLOW_RETRY) &&
> + !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> + ttm_bo_get(bo);
> + up_read(&vmf->vma->vm_mm->mmap_sem);
> + (void) ttm_bo_wait_unreserved(bo);
> + 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 (reservation_object_lock_interruptible(bo->base.resv, NULL))
> + return VM_FAULT_NOPAGE;
> }
>
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:30 ` Thomas Hellström (VMware)
@ 2019-08-21 14:42 ` Daniel Vetter
0 siblings, 0 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 14:42 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> On 8/21/19 4:10 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> wrote:
> >> On 8/20/19 4:53 PM, 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.
> >>>
> >>> 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 | 34 ---------------------------------
> >>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >>> include/drm/ttm/ttm_bo_api.h | 1 -
> >>> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>>
> >>>
> >>> + dma_resv_lock(bo->base.resv, NULL);
> >> interruptible, or at least killable. (IIRC think killable is the right
> >> choice in fault code, even if TTM initially implemented interruptible to
> >> get reasonable Xorg "silken mouse" latency).
> > I think interruptible is fine. I chickend out of that for v1 because I
> > always mix up the return code for _lock_interruptibl() :-)
>
> :). IIRC I think the in-kernel users of fault() were unhappy with
> interruptible. (GUP?), but I guess it's better to use a bulk change at
> some point if necessary.
We've been using interruptible since forever, returning
VM_FAULT_NOPAGE to get the signal handled and re-run. Seems to not
have pissed off anyone thus far. I think if we do this I'll do it as a
follow-up.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:10 ` Daniel Vetter
@ 2019-08-21 14:30 ` Thomas Hellström (VMware)
2019-08-21 14:42 ` Daniel Vetter
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 14:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On 8/21/19 4:10 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/20/19 4:53 PM, 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.
>>>
>>> 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 | 34 ---------------------------------
>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>
>>>
>>> + dma_resv_lock(bo->base.resv, NULL);
>> interruptible, or at least killable. (IIRC think killable is the right
>> choice in fault code, even if TTM initially implemented interruptible to
>> get reasonable Xorg "silken mouse" latency).
> I think interruptible is fine. I chickend out of that for v1 because I
> always mix up the return code for _lock_interruptibl() :-)
:). IIRC I think the in-kernel users of fault() were unhappy with
interruptible. (GUP?), but I guess it's better to use a bulk change at
some point if necessary.
/Thomas
> I'll add that for the next version too.
> -Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 14:09 ` Daniel Vetter
@ 2019-08-21 14:27 ` Thomas Hellström (VMware)
2019-08-21 14:47 ` Daniel Vetter
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 14:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On 8/21/19 4:09 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> <thomas_os@shipmail.org> wrote:
>> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
>>> On 8/20/19 4:53 PM, 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.
>>>>
>>>> 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 | 34 ---------------------------------
>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> index 20ff56f27aa4..a952dd624b06 100644
>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>>>> *bdev)
>>>> ;
>>>> }
>>>> 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_vm.c
>>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>> index 76eedb963693..505e1787aeea 100644
>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>>> vm_fault *vmf)
>>>> &bdev->man[bo->mem.mem_type];
>>>> struct vm_area_struct cvma;
>>>> - /*
>>>> - * 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);
>>>> - 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...
>>>> - */
>>> I think you should justify why the above code is removed, since the
>>> comments actually outlines what to do if we change locking order.
>>>
>>> The code that's removed above is not for adjusting locking orders but
>>> to decrease the mm latency by releasing the mmap_sem while waiting for
>>> bo reserve which in turn might be waiting for GPU. At a minimum we
>>> should have a separate patch with justification.
>>>
>>> Note that the caller here ensures locking progress by adjusting the
>>> RETRY flags after a retry.
> That would be patches 1&2 in this series.
>
Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
patch should look along the lines of (based on an older tree) to
implement the new locking-order mmap_sem->reservation,
but to keep the mm latency optimization using the RETRY functionality:
Thanks,
Thomas
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 85f5bcbe0c76..68482c67b9f7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,30 +125,20 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
- * 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.
- */
+ /* Avoid blocking on reservation with mmap_sem held, if possible */
if (unlikely(!reservation_object_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);
- ttm_bo_put(bo);
- }
+ if ((vmf->flags & FAULT_FLAG_ALLOW_RETRY) &&
+ !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
+ ttm_bo_get(bo);
+ up_read(&vmf->vma->vm_mm->mmap_sem);
+ (void) ttm_bo_wait_unreserved(bo);
+ 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 (reservation_object_lock_interruptible(bo->base.resv, NULL))
+ return VM_FAULT_NOPAGE;
}
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 13:16 ` Thomas Hellström (VMware)
@ 2019-08-21 14:10 ` Daniel Vetter
2019-08-21 14:30 ` Thomas Hellström (VMware)
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 14:10 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> On 8/20/19 4:53 PM, 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.
> >
> > 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 | 34 ---------------------------------
> > drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> > include/drm/ttm/ttm_bo_api.h | 1 -
> > 3 files changed, 1 insertion(+), 60 deletions(-)
> >
> >
> > + dma_resv_lock(bo->base.resv, NULL);
>
> interruptible, or at least killable. (IIRC think killable is the right
> choice in fault code, even if TTM initially implemented interruptible to
> get reasonable Xorg "silken mouse" latency).
I think interruptible is fine. I chickend out of that for v1 because I
always mix up the return code for _lock_interruptibl() :-)
I'll add that for the next version too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 12:47 ` Thomas Hellström (VMware)
@ 2019-08-21 14:09 ` Daniel Vetter
2019-08-21 14:27 ` Thomas Hellström (VMware)
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-21 14:09 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> > On 8/20/19 4:53 PM, 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.
> >>
> >> 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 | 34 ---------------------------------
> >> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >> include/drm/ttm/ttm_bo_api.h | 1 -
> >> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >> index 20ff56f27aa4..a952dd624b06 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >> *bdev)
> >> ;
> >> }
> >> 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_vm.c
> >> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> index 76eedb963693..505e1787aeea 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >> vm_fault *vmf)
> >> &bdev->man[bo->mem.mem_type];
> >> struct vm_area_struct cvma;
> >> - /*
> >> - * 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);
> >> - 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...
> >> - */
> >
> > I think you should justify why the above code is removed, since the
> > comments actually outlines what to do if we change locking order.
> >
> > The code that's removed above is not for adjusting locking orders but
> > to decrease the mm latency by releasing the mmap_sem while waiting for
> > bo reserve which in turn might be waiting for GPU. At a minimum we
> > should have a separate patch with justification.
> >
> > Note that the caller here ensures locking progress by adjusting the
> > RETRY flags after a retry.
That would be patches 1&2 in this series.
> And this last sentence also means we still can remove the wu-mutex when
> the locking order is changed, since the chance of livelock is goes away.
> IIRC only a single RETRY spin is allowed by the mm core.
Christian already noticed that one too, I simply forgot, it's fixed in
v2 I have here.
-Daniel
> /Thomas
>
> >
> > /Thomas
> >
> >
> >> - return VM_FAULT_NOPAGE;
> >> - }
> >> + dma_resv_lock(bo->base.resv, NULL);
> >> /*
> >> * Refuse to fault imported pages. This should be handled
> >> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> >> index 43c4929a2171..6b50e624e3e2 100644
> >> --- a/include/drm/ttm/ttm_bo_api.h
> >> +++ b/include/drm/ttm/ttm_bo_api.h
> >> @@ -765,7 +765,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
> >
> >
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 14:53 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-20 15:16 ` Koenig, Christian
2019-08-21 12:40 ` Thomas Hellström (VMware)
@ 2019-08-21 13:16 ` Thomas Hellström (VMware)
2019-08-21 14:10 ` Daniel Vetter
2 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 13:16 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Intel Graphics Development, Huang Rui,
VMware Graphics, Gerd Hoffmann, Daniel Vetter, Christian Koenig
On 8/20/19 4:53 PM, 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.
>
> 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 | 34 ---------------------------------
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> include/drm/ttm/ttm_bo_api.h | 1 -
> 3 files changed, 1 insertion(+), 60 deletions(-)
>
>
> + dma_resv_lock(bo->base.resv, NULL);
interruptible, or at least killable. (IIRC think killable is the right
choice in fault code, even if TTM initially implemented interruptible to
get reasonable Xorg "silken mouse" latency).
Thanks,
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-21 12:40 ` Thomas Hellström (VMware)
@ 2019-08-21 12:47 ` Thomas Hellström (VMware)
2019-08-21 14:09 ` Daniel Vetter
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 12:47 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Intel Graphics Development, Huang Rui,
VMware Graphics, Gerd Hoffmann, Daniel Vetter, Christian Koenig
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, 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.
>>
>> 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 | 34 ---------------------------------
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>> include/drm/ttm/ttm_bo_api.h | 1 -
>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 20ff56f27aa4..a952dd624b06 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>> *bdev)
>> ;
>> }
>> 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_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 76eedb963693..505e1787aeea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>> vm_fault *vmf)
>> &bdev->man[bo->mem.mem_type];
>> struct vm_area_struct cvma;
>> - /*
>> - * 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);
>> - 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...
>> - */
>
> I think you should justify why the above code is removed, since the
> comments actually outlines what to do if we change locking order.
>
> The code that's removed above is not for adjusting locking orders but
> to decrease the mm latency by releasing the mmap_sem while waiting for
> bo reserve which in turn might be waiting for GPU. At a minimum we
> should have a separate patch with justification.
>
> Note that the caller here ensures locking progress by adjusting the
> RETRY flags after a retry.
And this last sentence also means we still can remove the wu-mutex when
the locking order is changed, since the chance of livelock is goes away.
IIRC only a single RETRY spin is allowed by the mm core.
/Thomas
>
> /Thomas
>
>
>> - return VM_FAULT_NOPAGE;
>> - }
>> + dma_resv_lock(bo->base.resv, NULL);
>> /*
>> * Refuse to fault imported pages. This should be handled
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 43c4929a2171..6b50e624e3e2 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -765,7 +765,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
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 14:53 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-20 15:16 ` Koenig, Christian
@ 2019-08-21 12:40 ` Thomas Hellström (VMware)
2019-08-21 12:47 ` Thomas Hellström (VMware)
2019-08-21 13:16 ` Thomas Hellström (VMware)
2 siblings, 1 reply; 68+ messages in thread
From: Thomas Hellström (VMware) @ 2019-08-21 12:40 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Intel Graphics Development, Huang Rui,
VMware Graphics, Gerd Hoffmann, Daniel Vetter, Christian Koenig
On 8/20/19 4:53 PM, 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.
>
> 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 | 34 ---------------------------------
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> include/drm/ttm/ttm_bo_api.h | 1 -
> 3 files changed, 1 insertion(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 20ff56f27aa4..a952dd624b06 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> ;
> }
> 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 76eedb963693..505e1787aeea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> &bdev->man[bo->mem.mem_type];
> struct vm_area_struct cvma;
>
> - /*
> - * 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);
> - 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...
> - */
I think you should justify why the above code is removed, since the
comments actually outlines what to do if we change locking order.
The code that's removed above is not for adjusting locking orders but to
decrease the mm latency by releasing the mmap_sem while waiting for bo
reserve which in turn might be waiting for GPU. At a minimum we should
have a separate patch with justification.
Note that the caller here ensures locking progress by adjusting the
RETRY flags after a retry.
/Thomas
> - return VM_FAULT_NOPAGE;
> - }
> + dma_resv_lock(bo->base.resv, NULL);
>
> /*
> * Refuse to fault imported pages. This should be handled
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 43c4929a2171..6b50e624e3e2 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -765,7 +765,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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 15:41 ` Daniel Vetter
@ 2019-08-20 15:45 ` Koenig, Christian
0 siblings, 0 replies; 68+ messages in thread
From: Koenig, Christian @ 2019-08-20 15:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang, Ray, VMware Graphics, Gerd Hoffmann, Daniel Vetter
Am 20.08.19 um 17:41 schrieb Daniel Vetter:
> On Tue, Aug 20, 2019 at 5:34 PM Koenig, Christian
> <Christian.Koenig@amd.com> wrote:
>> Am 20.08.19 um 17:21 schrieb Daniel Vetter:
>>> On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
>>> <Christian.Koenig@amd.com> wrote:
>>>> Am 20.08.19 um 16:53 schrieb 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.
>>>>>
>>>>> 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>
>>>> Yes, please. But one more point: you can now remove bo->wu_mutex as well!
>>> Ah right totally forgot about that in my enthusiasm after all the
>>> auditing and fixing nouveau.
>>>
>>>> Apart from that Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Thanks, I already respun the patches, so will be in the next version.
>>> Can you pls also give this a spin on the amdgpu CI, just to make sure
>>> it's all fine? With full lockdep ofc. And then reply with a t-b.
>> I can ask for this on our call tomorrow, but I fear our CI
>> infrastructure is not ready yet.
> I thought you have some internal branch you all commit amdgpu stuff
> for, and then Alex goes and collects the pieces that are ready?
No, that part is correct. The problem is that this branch is not QA
tested regularly as far as I know.
> Or does that all blow up if you push a patch which touches code outside
> of the dkms?
No, but the problem is related to that.
See the release branches for dkms are separate and indeed QA tested
regularly.
But changes from amd-staging-drm-next are only cherry picked into those
in certain intervals.
Well going to discuss that tomorrow,
Christian.
> -Daniel
>
>> Christian.
>>
>>> Thanks, Daniel
>>>>> ---
>>>>> drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
>>>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>> index 20ff56f27aa4..a952dd624b06 100644
>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
>>>>> ;
>>>>> }
>>>>> 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> index 76eedb963693..505e1787aeea 100644
>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
>>>>> &bdev->man[bo->mem.mem_type];
>>>>> struct vm_area_struct cvma;
>>>>>
>>>>> - /*
>>>>> - * 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);
>>>>> - 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;
>>>>> - }
>>>>> + dma_resv_lock(bo->base.resv, NULL);
>>>>>
>>>>> /*
>>>>> * Refuse to fault imported pages. This should be handled
>>>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>>>>> index 43c4929a2171..6b50e624e3e2 100644
>>>>> --- a/include/drm/ttm/ttm_bo_api.h
>>>>> +++ b/include/drm/ttm/ttm_bo_api.h
>>>>> @@ -765,7 +765,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
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 15:34 ` Koenig, Christian
@ 2019-08-20 15:41 ` Daniel Vetter
2019-08-20 15:45 ` Koenig, Christian
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-20 15:41 UTC (permalink / raw)
To: Koenig, Christian
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang, Ray, VMware Graphics, Gerd Hoffmann, Daniel Vetter
On Tue, Aug 20, 2019 at 5:34 PM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 20.08.19 um 17:21 schrieb Daniel Vetter:
> > On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
> > <Christian.Koenig@amd.com> wrote:
> >> Am 20.08.19 um 16:53 schrieb 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.
> >>>
> >>> 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>
> >> Yes, please. But one more point: you can now remove bo->wu_mutex as well!
> > Ah right totally forgot about that in my enthusiasm after all the
> > auditing and fixing nouveau.
> >
> >> Apart from that Reviewed-by: Christian König <christian.koenig@amd.com>
> > Thanks, I already respun the patches, so will be in the next version.
> > Can you pls also give this a spin on the amdgpu CI, just to make sure
> > it's all fine? With full lockdep ofc. And then reply with a t-b.
>
> I can ask for this on our call tomorrow, but I fear our CI
> infrastructure is not ready yet.
I thought you have some internal branch you all commit amdgpu stuff
for, and then Alex goes and collects the pieces that are ready? Or
does that all blow up if you push a patch which touches code outside
of the dkms?
-Daniel
>
> Christian.
>
> >
> > Thanks, Daniel
> >>> ---
> >>> drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
> >>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> >>> include/drm/ttm/ttm_bo_api.h | 1 -
> >>> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> index 20ff56f27aa4..a952dd624b06 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> >>> ;
> >>> }
> >>> 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> index 76eedb963693..505e1787aeea 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> >>> &bdev->man[bo->mem.mem_type];
> >>> struct vm_area_struct cvma;
> >>>
> >>> - /*
> >>> - * 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);
> >>> - 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;
> >>> - }
> >>> + dma_resv_lock(bo->base.resv, NULL);
> >>>
> >>> /*
> >>> * Refuse to fault imported pages. This should be handled
> >>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> >>> index 43c4929a2171..6b50e624e3e2 100644
> >>> --- a/include/drm/ttm/ttm_bo_api.h
> >>> +++ b/include/drm/ttm/ttm_bo_api.h
> >>> @@ -765,7 +765,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
> >
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 15:21 ` Daniel Vetter
@ 2019-08-20 15:34 ` Koenig, Christian
2019-08-20 15:41 ` Daniel Vetter
0 siblings, 1 reply; 68+ messages in thread
From: Koenig, Christian @ 2019-08-20 15:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang, Ray, VMware Graphics, Gerd Hoffmann, Daniel Vetter
Am 20.08.19 um 17:21 schrieb Daniel Vetter:
> On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
> <Christian.Koenig@amd.com> wrote:
>> Am 20.08.19 um 16:53 schrieb 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.
>>>
>>> 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>
>> Yes, please. But one more point: you can now remove bo->wu_mutex as well!
> Ah right totally forgot about that in my enthusiasm after all the
> auditing and fixing nouveau.
>
>> Apart from that Reviewed-by: Christian König <christian.koenig@amd.com>
> Thanks, I already respun the patches, so will be in the next version.
> Can you pls also give this a spin on the amdgpu CI, just to make sure
> it's all fine? With full lockdep ofc. And then reply with a t-b.
I can ask for this on our call tomorrow, but I fear our CI
infrastructure is not ready yet.
Christian.
>
> Thanks, Daniel
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>> include/drm/ttm/ttm_bo_api.h | 1 -
>>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 20ff56f27aa4..a952dd624b06 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
>>> ;
>>> }
>>> 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> index 76eedb963693..505e1787aeea 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
>>> &bdev->man[bo->mem.mem_type];
>>> struct vm_area_struct cvma;
>>>
>>> - /*
>>> - * 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);
>>> - 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;
>>> - }
>>> + dma_resv_lock(bo->base.resv, NULL);
>>>
>>> /*
>>> * Refuse to fault imported pages. This should be handled
>>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>>> index 43c4929a2171..6b50e624e3e2 100644
>>> --- a/include/drm/ttm/ttm_bo_api.h
>>> +++ b/include/drm/ttm/ttm_bo_api.h
>>> @@ -765,7 +765,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
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 15:16 ` Koenig, Christian
@ 2019-08-20 15:21 ` Daniel Vetter
2019-08-20 15:34 ` Koenig, Christian
0 siblings, 1 reply; 68+ messages in thread
From: Daniel Vetter @ 2019-08-20 15:21 UTC (permalink / raw)
To: Koenig, Christian
Cc: Thomas Hellstrom, Intel Graphics Development, DRI Development,
Huang, Ray, VMware Graphics, Gerd Hoffmann, Daniel Vetter
On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 20.08.19 um 16:53 schrieb 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.
> >
> > 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>
>
> Yes, please. But one more point: you can now remove bo->wu_mutex as well!
Ah right totally forgot about that in my enthusiasm after all the
auditing and fixing nouveau.
> Apart from that Reviewed-by: Christian König <christian.koenig@amd.com>
Thanks, I already respun the patches, so will be in the next version.
Can you pls also give this a spin on the amdgpu CI, just to make sure
it's all fine? With full lockdep ofc. And then reply with a t-b.
Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
> > drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> > include/drm/ttm/ttm_bo_api.h | 1 -
> > 3 files changed, 1 insertion(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 20ff56f27aa4..a952dd624b06 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> > ;
> > }
> > 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > index 76eedb963693..505e1787aeea 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> > &bdev->man[bo->mem.mem_type];
> > struct vm_area_struct cvma;
> >
> > - /*
> > - * 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);
> > - 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;
> > - }
> > + dma_resv_lock(bo->base.resv, NULL);
> >
> > /*
> > * Refuse to fault imported pages. This should be handled
> > diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> > index 43c4929a2171..6b50e624e3e2 100644
> > --- a/include/drm/ttm/ttm_bo_api.h
> > +++ b/include/drm/ttm/ttm_bo_api.h
> > @@ -765,7 +765,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
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 14:53 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
@ 2019-08-20 15:16 ` Koenig, Christian
2019-08-20 15:21 ` Daniel Vetter
2019-08-21 12:40 ` Thomas Hellström (VMware)
2019-08-21 13:16 ` Thomas Hellström (VMware)
2 siblings, 1 reply; 68+ messages in thread
From: Koenig, Christian @ 2019-08-20 15:16 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Hellstrom, Intel Graphics Development, Huang, Ray,
VMware Graphics, Gerd Hoffmann, Daniel Vetter
Am 20.08.19 um 16:53 schrieb 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.
>
> 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>
Yes, please. But one more point: you can now remove bo->wu_mutex as well!
Apart from that Reviewed-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
> include/drm/ttm/ttm_bo_api.h | 1 -
> 3 files changed, 1 insertion(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 20ff56f27aa4..a952dd624b06 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> ;
> }
> 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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 76eedb963693..505e1787aeea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> &bdev->man[bo->mem.mem_type];
> struct vm_area_struct cvma;
>
> - /*
> - * 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);
> - 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;
> - }
> + dma_resv_lock(bo->base.resv, NULL);
>
> /*
> * Refuse to fault imported pages. This should be handled
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 43c4929a2171..6b50e624e3e2 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -765,7 +765,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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 68+ messages in thread
* [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
2019-08-20 14:53 [PATCH 0/3] RFC/T: dma_resv vs. mmap_sem Daniel Vetter
@ 2019-08-20 14:53 ` Daniel Vetter
2019-08-20 15:16 ` Koenig, Christian
` (2 more replies)
0 siblings, 3 replies; 68+ messages in thread
From: Daniel Vetter @ 2019-08-20 14:53 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Hellstrom, Daniel Vetter, Intel Graphics Development,
Huang Rui, VMware Graphics, Gerd Hoffmann, Daniel Vetter,
Christian Koenig
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.
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 | 34 ---------------------------------
drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
include/drm/ttm/ttm_bo_api.h | 1 -
3 files changed, 1 insertion(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 20ff56f27aa4..a952dd624b06 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
;
}
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_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 76eedb963693..505e1787aeea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
- * 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);
- 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;
- }
+ dma_resv_lock(bo->base.resv, NULL);
/*
* Refuse to fault imported pages. This should be handled
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 43c4929a2171..6b50e624e3e2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -765,7 +765,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.23.0.rc1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 68+ messages in thread
end of thread, other threads:[~2019-11-20 10:52 UTC | newest]
Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-04 17:37 [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-11-04 17:37 ` [Intel-gfx] " Daniel Vetter
2019-11-04 17:37 ` Daniel Vetter
[not found] ` <20191104173801.2972-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-11-04 17:38 ` [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl Daniel Vetter
2019-11-04 17:38 ` [Intel-gfx] " Daniel Vetter
2019-11-04 17:38 ` Daniel Vetter
2019-11-05 11:04 ` Daniel Vetter
2019-11-05 11:04 ` [Intel-gfx] " Daniel Vetter
2019-11-05 11:04 ` Daniel Vetter
[not found] ` <20191105110419.GG10326-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-11-05 12:30 ` Maarten Lankhorst
2019-11-05 12:30 ` [Intel-gfx] " Maarten Lankhorst
2019-11-05 12:30 ` Maarten Lankhorst
2019-11-04 17:38 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-11-04 17:38 ` [Intel-gfx] " Daniel Vetter
2019-11-06 10:24 ` Daniel Vetter
2019-11-06 10:24 ` [Intel-gfx] " Daniel Vetter
2019-11-04 17:48 ` [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-11-04 17:48 ` [Intel-gfx] " Daniel Vetter
2019-11-04 17:48 ` Daniel Vetter
2019-11-04 20:01 ` Koenig, Christian
2019-11-04 20:01 ` [Intel-gfx] " Koenig, Christian
2019-11-04 20:01 ` Koenig, Christian
2019-11-04 20:55 ` Daniel Vetter
2019-11-04 20:55 ` [Intel-gfx] " Daniel Vetter
2019-11-04 20:55 ` Daniel Vetter
2019-11-04 21:00 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] " Patchwork
2019-11-04 21:00 ` [Intel-gfx] " Patchwork
2019-11-04 21:22 ` ✓ Fi.CI.BAT: success " Patchwork
2019-11-04 21:22 ` [Intel-gfx] " Patchwork
2019-11-05 8:31 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-05 8:31 ` [Intel-gfx] " Patchwork
2019-11-11 13:11 ` [PATCH 1/3] " Steven Price
2019-11-11 13:11 ` [Intel-gfx] " Steven Price
2019-11-11 15:42 ` Daniel Vetter
2019-11-11 15:42 ` [Intel-gfx] " Daniel Vetter
2019-11-11 15:42 ` Daniel Vetter
2019-11-14 11:50 ` Steven Price
2019-11-14 11:50 ` [Intel-gfx] " Steven Price
2019-11-14 11:50 ` Steven Price
2019-11-20 10:51 ` Daniel Vetter
2019-11-20 10:51 ` [Intel-gfx] " Daniel Vetter
2019-11-11 18:12 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations (rev2) Patchwork
2019-11-11 18:12 ` [Intel-gfx] " Patchwork
2019-11-11 18:48 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-11-11 18:48 ` [Intel-gfx] " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2019-10-21 14:50 [PATCH 0/3] dma_resv lockdep annotations/priming Daniel Vetter
2019-10-21 14:50 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-21 21:50 [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-08-21 21:50 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-20 14:53 [PATCH 0/3] RFC/T: dma_resv vs. mmap_sem Daniel Vetter
2019-08-20 14:53 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-20 15:16 ` Koenig, Christian
2019-08-20 15:21 ` Daniel Vetter
2019-08-20 15:34 ` Koenig, Christian
2019-08-20 15:41 ` Daniel Vetter
2019-08-20 15:45 ` Koenig, Christian
2019-08-21 12:40 ` Thomas Hellström (VMware)
2019-08-21 12:47 ` Thomas Hellström (VMware)
2019-08-21 14:09 ` Daniel Vetter
2019-08-21 14:27 ` Thomas Hellström (VMware)
2019-08-21 14:47 ` Daniel Vetter
2019-08-21 15:03 ` Thomas Hellström (VMware)
2019-08-21 15:14 ` Daniel Vetter
2019-08-21 15:19 ` Thomas Hellström (VMware)
2019-08-21 15:22 ` Daniel Vetter
2019-08-21 15:34 ` Thomas Hellström (VMware)
2019-08-21 15:07 ` Koenig, Christian
2019-08-21 13:16 ` Thomas Hellström (VMware)
2019-08-21 14:10 ` Daniel Vetter
2019-08-21 14:30 ` Thomas Hellström (VMware)
2019-08-21 14:42 ` Daniel Vetter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.