All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/4] dma-buf: add reservation_object_fences helper
@ 2019-08-07 13:53 Christian König
  2019-08-07 13:53 ` [PATCH 2/4] drm/i915: use new " Christian König
                   ` (6 more replies)
  0 siblings, 7 replies; 23+ messages in thread
From: Christian König @ 2019-08-07 13:53 UTC (permalink / raw)
  To: intel-gfx, linaro-mm-sig, dri-devel, chris

Add a new helper to get a consistent set of pointers from the reservation
object. While at it group all access helpers together in the header file.

v2: correctly return shared_count as well

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/dma-buf/dma-buf.c     |  31 ++-------
 drivers/dma-buf/reservation.c |  82 ++++++++----------------
 include/linux/reservation.h   | 115 +++++++++++++++++++++-------------
 3 files changed, 101 insertions(+), 127 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f45bfb29ef96..67510f2be8bc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
 	struct reservation_object_list *fobj;
 	struct dma_fence *fence_excl;
 	__poll_t events;
-	unsigned shared_count, seq;
+	unsigned shared_count;
 
 	dmabuf = file->private_data;
 	if (!dmabuf || !dmabuf->resv)
@@ -213,21 +213,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
 	if (!events)
 		return 0;
 
-retry:
-	seq = read_seqcount_begin(&resv->seq);
 	rcu_read_lock();
-
-	fobj = rcu_dereference(resv->fence);
-	if (fobj)
-		shared_count = fobj->shared_count;
-	else
-		shared_count = 0;
-	fence_excl = rcu_dereference(resv->fence_excl);
-	if (read_seqcount_retry(&resv->seq, seq)) {
-		rcu_read_unlock();
-		goto retry;
-	}
-
+	reservation_object_fences(resv, &fence_excl, &fobj, &shared_count);
 	if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
 		struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
 		__poll_t pevents = EPOLLIN;
@@ -1157,7 +1144,6 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
 	struct reservation_object *robj;
 	struct reservation_object_list *fobj;
 	struct dma_fence *fence;
-	unsigned seq;
 	int count = 0, attach_count, shared_count, i;
 	size_t size = 0;
 
@@ -1188,16 +1174,9 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
 				buf_obj->name ?: "");
 
 		robj = buf_obj->resv;
-		while (true) {
-			seq = read_seqcount_begin(&robj->seq);
-			rcu_read_lock();
-			fobj = rcu_dereference(robj->fence);
-			shared_count = fobj ? fobj->shared_count : 0;
-			fence = rcu_dereference(robj->fence_excl);
-			if (!read_seqcount_retry(&robj->seq, seq))
-				break;
-			rcu_read_unlock();
-		}
+		rcu_read_lock();
+		reservation_object_fences(robj, &fence, &fobj, &shared_count);
+		rcu_read_unlock();
 
 		if (fence)
 			seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index ad6775b32a73..8fcaddffd5d4 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -317,17 +317,15 @@ int reservation_object_copy_fences(struct reservation_object *dst,
 {
 	struct reservation_object_list *src_list, *dst_list;
 	struct dma_fence *old, *new;
-	unsigned i;
+	unsigned int i, shared_count;
 
 	reservation_object_assert_held(dst);
 
 	rcu_read_lock();
-	src_list = rcu_dereference(src->fence);
 
 retry:
-	if (src_list) {
-		unsigned shared_count = src_list->shared_count;
-
+	reservation_object_fences(src, &new, &src_list, &shared_count);
+	if (shared_count) {
 		rcu_read_unlock();
 
 		dst_list = reservation_object_list_alloc(shared_count);
@@ -335,14 +333,14 @@ int reservation_object_copy_fences(struct reservation_object *dst,
 			return -ENOMEM;
 
 		rcu_read_lock();
-		src_list = rcu_dereference(src->fence);
-		if (!src_list || src_list->shared_count > shared_count) {
+		reservation_object_fences(src, &new, &src_list, &shared_count);
+		if (!src_list || shared_count > dst_list->shared_max) {
 			kfree(dst_list);
 			goto retry;
 		}
 
 		dst_list->shared_count = 0;
-		for (i = 0; i < src_list->shared_count; ++i) {
+		for (i = 0; i < shared_count; ++i) {
 			struct dma_fence *fence;
 
 			fence = rcu_dereference(src_list->shared[i]);
@@ -352,7 +350,6 @@ int reservation_object_copy_fences(struct reservation_object *dst,
 
 			if (!dma_fence_get_rcu(fence)) {
 				reservation_object_list_free(dst_list);
-				src_list = rcu_dereference(src->fence);
 				goto retry;
 			}
 
@@ -367,7 +364,10 @@ int reservation_object_copy_fences(struct reservation_object *dst,
 		dst_list = NULL;
 	}
 
-	new = dma_fence_get_rcu_safe(&src->fence_excl);
+	if (new && !dma_fence_get_rcu(new)) {
+		reservation_object_list_free(dst_list);
+		goto retry;
+	}
 	rcu_read_unlock();
 
 	src_list = reservation_object_get_list(dst);
@@ -413,19 +413,18 @@ int reservation_object_get_fences_rcu(struct reservation_object *obj,
 
 	do {
 		struct reservation_object_list *fobj;
-		unsigned int i, seq;
+		unsigned int i;
 		size_t sz = 0;
 
-		shared_count = i = 0;
+		i = 0;
 
 		rcu_read_lock();
-		seq = read_seqcount_begin(&obj->seq);
+		reservation_object_fences(obj, &fence_excl, &fobj,
+					  &shared_count);
 
-		fence_excl = rcu_dereference(obj->fence_excl);
 		if (fence_excl && !dma_fence_get_rcu(fence_excl))
 			goto unlock;
 
-		fobj = rcu_dereference(obj->fence);
 		if (fobj)
 			sz += sizeof(*shared) * fobj->shared_max;
 
@@ -453,7 +452,6 @@ int reservation_object_get_fences_rcu(struct reservation_object *obj,
 				break;
 			}
 			shared = nshared;
-			shared_count = fobj ? fobj->shared_count : 0;
 			for (i = 0; i < shared_count; ++i) {
 				shared[i] = rcu_dereference(fobj->shared[i]);
 				if (!dma_fence_get_rcu(shared[i]))
@@ -461,7 +459,7 @@ int reservation_object_get_fences_rcu(struct reservation_object *obj,
 			}
 		}
 
-		if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
+		if (i != shared_count) {
 			while (i--)
 				dma_fence_put(shared[i]);
 			dma_fence_put(fence_excl);
@@ -505,18 +503,17 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 					 bool wait_all, bool intr,
 					 unsigned long timeout)
 {
+	struct reservation_object_list *fobj;
 	struct dma_fence *fence;
-	unsigned seq, shared_count;
+	unsigned shared_count;
 	long ret = timeout ? timeout : 1;
 	int i;
 
 retry:
-	shared_count = 0;
-	seq = read_seqcount_begin(&obj->seq);
 	rcu_read_lock();
 	i = -1;
 
-	fence = rcu_dereference(obj->fence_excl);
+	reservation_object_fences(obj, &fence, &fobj, &shared_count);
 	if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
 		if (!dma_fence_get_rcu(fence))
 			goto unlock_retry;
@@ -531,12 +528,6 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 	}
 
 	if (wait_all) {
-		struct reservation_object_list *fobj =
-						rcu_dereference(obj->fence);
-
-		if (fobj)
-			shared_count = fobj->shared_count;
-
 		for (i = 0; !fence && i < shared_count; ++i) {
 			struct dma_fence *lfence = rcu_dereference(fobj->shared[i]);
 
@@ -559,11 +550,6 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 
 	rcu_read_unlock();
 	if (fence) {
-		if (read_seqcount_retry(&obj->seq, seq)) {
-			dma_fence_put(fence);
-			goto retry;
-		}
-
 		ret = dma_fence_wait_timeout(fence, intr, ret);
 		dma_fence_put(fence);
 		if (ret > 0 && wait_all && (i + 1 < shared_count))
@@ -608,24 +594,19 @@ reservation_object_test_signaled_single(struct dma_fence *passed_fence)
 bool reservation_object_test_signaled_rcu(struct reservation_object *obj,
 					  bool test_all)
 {
-	unsigned seq, shared_count;
+	struct reservation_object_list *fobj;
+	struct dma_fence *fence_excl;
+	unsigned shared_count;
 	int ret;
 
 	rcu_read_lock();
 retry:
 	ret = true;
-	shared_count = 0;
-	seq = read_seqcount_begin(&obj->seq);
 
+	reservation_object_fences(obj, &fence_excl, &fobj, &shared_count);
 	if (test_all) {
 		unsigned i;
 
-		struct reservation_object_list *fobj =
-						rcu_dereference(obj->fence);
-
-		if (fobj)
-			shared_count = fobj->shared_count;
-
 		for (i = 0; i < shared_count; ++i) {
 			struct dma_fence *fence = rcu_dereference(fobj->shared[i]);
 
@@ -635,23 +616,12 @@ bool reservation_object_test_signaled_rcu(struct reservation_object *obj,
 			else if (!ret)
 				break;
 		}
-
-		if (read_seqcount_retry(&obj->seq, seq))
-			goto retry;
 	}
 
-	if (!shared_count) {
-		struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
-		if (fence_excl) {
-			ret = reservation_object_test_signaled_single(
-								fence_excl);
-			if (ret < 0)
-				goto retry;
-
-			if (read_seqcount_retry(&obj->seq, seq))
-				goto retry;
-		}
+	if (!shared_count && fence_excl) {
+		ret = reservation_object_test_signaled_single(fence_excl);
+		if (ret < 0)
+			goto retry;
 	}
 
 	rcu_read_unlock();
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 56b782fec49b..044a5cd4af50 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -81,6 +81,51 @@ struct reservation_object {
 #define reservation_object_assert_held(obj) \
 	lockdep_assert_held(&(obj)->lock.base)
 
+/**
+ * reservation_object_get_excl - get the reservation object's
+ * exclusive fence, with update-side lock held
+ * @obj: the reservation object
+ *
+ * Returns the exclusive fence (if any).  Does NOT take a
+ * reference. Writers must hold obj->lock, readers may only
+ * hold a RCU read side lock.
+ *
+ * RETURNS
+ * The exclusive fence or NULL
+ */
+static inline struct dma_fence *
+reservation_object_get_excl(struct reservation_object *obj)
+{
+	return rcu_dereference_protected(obj->fence_excl,
+					 reservation_object_held(obj));
+}
+
+/**
+ * reservation_object_get_excl_rcu - get the reservation object's
+ * exclusive fence, without lock held.
+ * @obj: the reservation object
+ *
+ * If there is an exclusive fence, this atomically increments it's
+ * reference count and returns it.
+ *
+ * RETURNS
+ * The exclusive fence or NULL if none
+ */
+static inline struct dma_fence *
+reservation_object_get_excl_rcu(struct reservation_object *obj)
+{
+	struct dma_fence *fence;
+
+	if (!rcu_access_pointer(obj->fence_excl))
+		return NULL;
+
+	rcu_read_lock();
+	fence = dma_fence_get_rcu_safe(&obj->fence_excl);
+	rcu_read_unlock();
+
+	return fence;
+}
+
 /**
  * reservation_object_get_list - get the reservation object's
  * shared fence list, with update-side lock held
@@ -96,6 +141,31 @@ reservation_object_get_list(struct reservation_object *obj)
 					 reservation_object_held(obj));
 }
 
+/**
+ * reservation_object_fences - read consistent fence pointers
+ * @obj: reservation object where we get the fences from
+ * @excl: pointer for the exclusive fence
+ * @list: pointer for the shared fence list
+ *
+ * Make sure we have a consisten exclusive fence and shared fence list.
+ * Must be called with rcu read side lock held.
+ */
+static inline void
+reservation_object_fences(struct reservation_object *obj,
+			  struct dma_fence **excl,
+			  struct reservation_object_list **list,
+			  u32 *shared_count)
+{
+	unsigned int seq;
+
+	do {
+		seq = read_seqcount_begin(&obj->seq);
+		*excl = rcu_dereference(obj->fence_excl);
+		*list = rcu_dereference(obj->fence);
+		*shared_count = *list ? (*list)->shared_count : 0;
+	} while (read_seqcount_retry(&obj->seq, seq));
+}
+
 /**
  * reservation_object_lock - lock the reservation object
  * @obj: the reservation object
@@ -239,51 +309,6 @@ reservation_object_unlock(struct reservation_object *obj)
 	ww_mutex_unlock(&obj->lock);
 }
 
-/**
- * reservation_object_get_excl - get the reservation object's
- * exclusive fence, with update-side lock held
- * @obj: the reservation object
- *
- * Returns the exclusive fence (if any).  Does NOT take a
- * reference. Writers must hold obj->lock, readers may only
- * hold a RCU read side lock.
- *
- * RETURNS
- * The exclusive fence or NULL
- */
-static inline struct dma_fence *
-reservation_object_get_excl(struct reservation_object *obj)
-{
-	return rcu_dereference_protected(obj->fence_excl,
-					 reservation_object_held(obj));
-}
-
-/**
- * reservation_object_get_excl_rcu - get the reservation object's
- * exclusive fence, without lock held.
- * @obj: the reservation object
- *
- * If there is an exclusive fence, this atomically increments it's
- * reference count and returns it.
- *
- * RETURNS
- * The exclusive fence or NULL if none
- */
-static inline struct dma_fence *
-reservation_object_get_excl_rcu(struct reservation_object *obj)
-{
-	struct dma_fence *fence;
-
-	if (!rcu_access_pointer(obj->fence_excl))
-		return NULL;
-
-	rcu_read_lock();
-	fence = dma_fence_get_rcu_safe(&obj->fence_excl);
-	rcu_read_unlock();
-
-	return fence;
-}
-
 void reservation_object_init(struct reservation_object *obj);
 void reservation_object_fini(struct reservation_object *obj);
 int reservation_object_reserve_shared(struct reservation_object *obj,
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* [PATCH 2/4] drm/i915: use new reservation_object_fences helper
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
@ 2019-08-07 13:53 ` Christian König
  2019-08-07 16:08   ` Chris Wilson
  2019-08-07 13:53 ` [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence Christian König
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: Christian König @ 2019-08-07 13:53 UTC (permalink / raw)
  To: intel-gfx, linaro-mm-sig, dri-devel, chris

Instead of open coding the sequence loop use the new helper.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 +++++++-----------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 6ad93a09968c..8473292096cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -83,7 +83,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
 	struct drm_i915_gem_busy *args = data;
 	struct drm_i915_gem_object *obj;
 	struct reservation_object_list *list;
-	unsigned int seq;
+	unsigned int i, shared_count;
+	struct dma_fence *excl;
 	int err;
 
 	err = -ENOENT;
@@ -109,29 +110,18 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
 	 * to report the overall busyness. This is what the wait-ioctl does.
 	 *
 	 */
-retry:
-	seq = raw_read_seqcount(&obj->base.resv->seq);
+	reservation_object_fences(obj->base.resv, &excl, &list, &shared_count);
 
 	/* Translate the exclusive fence to the READ *and* WRITE engine */
-	args->busy =
-		busy_check_writer(rcu_dereference(obj->base.resv->fence_excl));
+	args->busy = busy_check_writer(excl);
 
 	/* Translate shared fences to READ set of engines */
-	list = rcu_dereference(obj->base.resv->fence);
-	if (list) {
-		unsigned int shared_count = list->shared_count, i;
+	for (i = 0; i < shared_count; ++i) {
+		struct dma_fence *fence = rcu_dereference(list->shared[i]);
 
-		for (i = 0; i < shared_count; ++i) {
-			struct dma_fence *fence =
-				rcu_dereference(list->shared[i]);
-
-			args->busy |= busy_check_reader(fence);
-		}
+		args->busy |= busy_check_reader(fence);
 	}
 
-	if (args->busy && read_seqcount_retry(&obj->base.resv->seq, seq))
-		goto retry;
-
 	err = 0;
 out:
 	rcu_read_unlock();
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
  2019-08-07 13:53 ` [PATCH 2/4] drm/i915: use new " Christian König
@ 2019-08-07 13:53 ` Christian König
  2019-08-07 16:10   ` Chris Wilson
  2019-08-07 13:53 ` [PATCH 4/4] dma-buf: nuke reservation_object seq number Christian König
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: Christian König @ 2019-08-07 13:53 UTC (permalink / raw)
  To: intel-gfx, linaro-mm-sig, dri-devel, chris

Other cores don't busy wait any more and we removed the last user of checking
the seqno for changes. Drop updating the number for shared fences altogether.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/dma-buf/reservation.c                    | 6 ------
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +------
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 8fcaddffd5d4..90bc6ef03598 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -237,9 +237,6 @@ void reservation_object_add_shared_fence(struct reservation_object *obj,
 	fobj = reservation_object_get_list(obj);
 	count = fobj->shared_count;
 
-	preempt_disable();
-	write_seqcount_begin(&obj->seq);
-
 	for (i = 0; i < count; ++i) {
 
 		old = rcu_dereference_protected(fobj->shared[i],
@@ -257,9 +254,6 @@ void reservation_object_add_shared_fence(struct reservation_object *obj,
 	RCU_INIT_POINTER(fobj->shared[i], fence);
 	/* pointer update must be visible before we extend the shared_count */
 	smp_store_mb(fobj->shared_count, count);
-
-	write_seqcount_end(&obj->seq);
-	preempt_enable();
 	dma_fence_put(old);
 }
 EXPORT_SYMBOL(reservation_object_add_shared_fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index fe062b76ec91..a4640ddc24d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -251,12 +251,7 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
 	new->shared_max = old->shared_max;
 	new->shared_count = k;
 
-	/* Install the new fence list, seqcount provides the barriers */
-	preempt_disable();
-	write_seqcount_begin(&resv->seq);
-	RCU_INIT_POINTER(resv->fence, new);
-	write_seqcount_end(&resv->seq);
-	preempt_enable();
+	rcu_assign_pointer(resv->fence, new);
 
 	/* Drop the references to the removed fences or move them to ef_list */
 	for (i = j, k = 0; i < old->shared_count; ++i) {
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
  2019-08-07 13:53 ` [PATCH 2/4] drm/i915: use new " Christian König
  2019-08-07 13:53 ` [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence Christian König
@ 2019-08-07 13:53 ` Christian König
  2019-08-07 14:17   ` Chris Wilson
  2019-08-07 16:07 ` [PATCH 1/4] dma-buf: add reservation_object_fences helper Chris Wilson
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 23+ messages in thread
From: Christian König @ 2019-08-07 13:53 UTC (permalink / raw)
  To: intel-gfx, linaro-mm-sig, dri-devel, chris

The only remaining use for this is to protect against setting a new exclusive
fence while we grab both exclusive and shared. That can also be archived by
looking if the exclusive fence has changed or not after completing the
operation.

v2: switch setting excl fence to rcu_assign_pointer

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/dma-buf/reservation.c | 24 +++++-------------------
 include/linux/reservation.h   |  9 ++-------
 2 files changed, 7 insertions(+), 26 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 90bc6ef03598..f7f4a0858c2a 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -49,12 +49,6 @@
 DEFINE_WD_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);
 
-struct lock_class_key reservation_seqcount_class;
-EXPORT_SYMBOL(reservation_seqcount_class);
-
-const char reservation_seqcount_string[] = "reservation_seqcount";
-EXPORT_SYMBOL(reservation_seqcount_string);
-
 /**
  * reservation_object_list_alloc - allocate fence list
  * @shared_max: number of fences we need space for
@@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
 void reservation_object_init(struct reservation_object *obj)
 {
 	ww_mutex_init(&obj->lock, &reservation_ww_class);
-
-	__seqcount_init(&obj->seq, reservation_seqcount_string,
-			&reservation_seqcount_class);
 	RCU_INIT_POINTER(obj->fence, NULL);
 	RCU_INIT_POINTER(obj->fence_excl, NULL);
 }
@@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
 		dma_fence_get(fence);
 
 	preempt_disable();
-	write_seqcount_begin(&obj->seq);
-	/* write_seqcount_begin provides the necessary memory barrier */
-	RCU_INIT_POINTER(obj->fence_excl, fence);
+	rcu_assign_pointer(obj->fence_excl, fence);
+	/* pointer update must be visible before we modify the shared_count */
 	if (old)
-		old->shared_count = 0;
-	write_seqcount_end(&obj->seq);
+		smp_store_mb(old->shared_count, 0);
 	preempt_enable();
 
 	/* inplace update, no shared fences */
@@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
 	old = reservation_object_get_excl(dst);
 
 	preempt_disable();
-	write_seqcount_begin(&dst->seq);
-	/* write_seqcount_begin provides the necessary memory barrier */
-	RCU_INIT_POINTER(dst->fence_excl, new);
-	RCU_INIT_POINTER(dst->fence, dst_list);
-	write_seqcount_end(&dst->seq);
+	rcu_assign_pointer(dst->fence_excl, new);
+	rcu_assign_pointer(dst->fence, dst_list);
 	preempt_enable();
 
 	reservation_object_list_free(src_list);
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 044a5cd4af50..fd29baad0be3 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -46,8 +46,6 @@
 #include <linux/rcupdate.h>
 
 extern struct ww_class reservation_ww_class;
-extern struct lock_class_key reservation_seqcount_class;
-extern const char reservation_seqcount_string[];
 
 /**
  * struct reservation_object_list - a list of shared fences
@@ -71,7 +69,6 @@ struct reservation_object_list {
  */
 struct reservation_object {
 	struct ww_mutex lock;
-	seqcount_t seq;
 
 	struct dma_fence __rcu *fence_excl;
 	struct reservation_object_list __rcu *fence;
@@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
 			  struct reservation_object_list **list,
 			  u32 *shared_count)
 {
-	unsigned int seq;
-
 	do {
-		seq = read_seqcount_begin(&obj->seq);
 		*excl = rcu_dereference(obj->fence_excl);
 		*list = rcu_dereference(obj->fence);
 		*shared_count = *list ? (*list)->shared_count : 0;
-	} while (read_seqcount_retry(&obj->seq, seq));
+		smp_rmb(); /* See reservation_object_add_excl_fence */
+	} while (rcu_access_pointer(obj->fence_excl) != *excl);
 }
 
 /**
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-07 13:53 ` [PATCH 4/4] dma-buf: nuke reservation_object seq number Christian König
@ 2019-08-07 14:17   ` Chris Wilson
  2019-08-10 10:51     ` Christian König
  0 siblings, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-07 14:17 UTC (permalink / raw)
  To: Christian König, dri-devel, intel-gfx, linaro-mm-sig; +Cc: Daniel Vetter

Quoting Christian König (2019-08-07 14:53:12)
> The only remaining use for this is to protect against setting a new exclusive
> fence while we grab both exclusive and shared. That can also be archived by
> looking if the exclusive fence has changed or not after completing the
> operation.
> 
> v2: switch setting excl fence to rcu_assign_pointer
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/dma-buf/reservation.c | 24 +++++-------------------
>  include/linux/reservation.h   |  9 ++-------
>  2 files changed, 7 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 90bc6ef03598..f7f4a0858c2a 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -49,12 +49,6 @@
>  DEFINE_WD_CLASS(reservation_ww_class);
>  EXPORT_SYMBOL(reservation_ww_class);
>  
> -struct lock_class_key reservation_seqcount_class;
> -EXPORT_SYMBOL(reservation_seqcount_class);
> -
> -const char reservation_seqcount_string[] = "reservation_seqcount";
> -EXPORT_SYMBOL(reservation_seqcount_string);
> -
>  /**
>   * reservation_object_list_alloc - allocate fence list
>   * @shared_max: number of fences we need space for
> @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
>  void reservation_object_init(struct reservation_object *obj)
>  {
>         ww_mutex_init(&obj->lock, &reservation_ww_class);
> -
> -       __seqcount_init(&obj->seq, reservation_seqcount_string,
> -                       &reservation_seqcount_class);
>         RCU_INIT_POINTER(obj->fence, NULL);
>         RCU_INIT_POINTER(obj->fence_excl, NULL);
>  }
> @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
>                 dma_fence_get(fence);
>  
>         preempt_disable();
> -       write_seqcount_begin(&obj->seq);
> -       /* write_seqcount_begin provides the necessary memory barrier */
> -       RCU_INIT_POINTER(obj->fence_excl, fence);
> +       rcu_assign_pointer(obj->fence_excl, fence);
> +       /* pointer update must be visible before we modify the shared_count */
>         if (old)
> -               old->shared_count = 0;
> -       write_seqcount_end(&obj->seq);
> +               smp_store_mb(old->shared_count, 0);
>         preempt_enable();
>  
>         /* inplace update, no shared fences */
> @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
>         old = reservation_object_get_excl(dst);
>  
>         preempt_disable();
> -       write_seqcount_begin(&dst->seq);
> -       /* write_seqcount_begin provides the necessary memory barrier */
> -       RCU_INIT_POINTER(dst->fence_excl, new);
> -       RCU_INIT_POINTER(dst->fence, dst_list);
> -       write_seqcount_end(&dst->seq);
> +       rcu_assign_pointer(dst->fence_excl, new);
> +       rcu_assign_pointer(dst->fence, dst_list);
>         preempt_enable();
>  
>         reservation_object_list_free(src_list);
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index 044a5cd4af50..fd29baad0be3 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -46,8 +46,6 @@
>  #include <linux/rcupdate.h>
>  
>  extern struct ww_class reservation_ww_class;
> -extern struct lock_class_key reservation_seqcount_class;
> -extern const char reservation_seqcount_string[];
>  
>  /**
>   * struct reservation_object_list - a list of shared fences
> @@ -71,7 +69,6 @@ struct reservation_object_list {
>   */
>  struct reservation_object {
>         struct ww_mutex lock;
> -       seqcount_t seq;
>  
>         struct dma_fence __rcu *fence_excl;
>         struct reservation_object_list __rcu *fence;
> @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
>                           struct reservation_object_list **list,
>                           u32 *shared_count)
>  {
> -       unsigned int seq;
> -
>         do {
> -               seq = read_seqcount_begin(&obj->seq);
>                 *excl = rcu_dereference(obj->fence_excl);
>                 *list = rcu_dereference(obj->fence);
>                 *shared_count = *list ? (*list)->shared_count : 0;
> -       } while (read_seqcount_retry(&obj->seq, seq));
> +               smp_rmb(); /* See reservation_object_add_excl_fence */
> +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
>  }

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

I think this is correct. Now see if we can convince Daniel!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 1/4] dma-buf: add reservation_object_fences helper
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
                   ` (2 preceding siblings ...)
  2019-08-07 13:53 ` [PATCH 4/4] dma-buf: nuke reservation_object seq number Christian König
@ 2019-08-07 16:07 ` Chris Wilson
  2019-08-09 13:07 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] " Patchwork
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 23+ messages in thread
From: Chris Wilson @ 2019-08-07 16:07 UTC (permalink / raw)
  To: Christian König, dri-devel, intel-gfx, linaro-mm-sig

Quoting Christian König (2019-08-07 14:53:09)
> Add a new helper to get a consistent set of pointers from the reservation
> object. While at it group all access helpers together in the header file.
> 
> v2: correctly return shared_count as well
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 2/4] drm/i915: use new reservation_object_fences helper
  2019-08-07 13:53 ` [PATCH 2/4] drm/i915: use new " Christian König
@ 2019-08-07 16:08   ` Chris Wilson
  0 siblings, 0 replies; 23+ messages in thread
From: Chris Wilson @ 2019-08-07 16:08 UTC (permalink / raw)
  To: Christian König, dri-devel, intel-gfx, linaro-mm-sig

Quoting Christian König (2019-08-07 14:53:10)
> Instead of open coding the sequence loop use the new helper.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence
  2019-08-07 13:53 ` [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence Christian König
@ 2019-08-07 16:10   ` Chris Wilson
  0 siblings, 0 replies; 23+ messages in thread
From: Chris Wilson @ 2019-08-07 16:10 UTC (permalink / raw)
  To: Christian König, dri-devel, intel-gfx, linaro-mm-sig

Quoting Christian König (2019-08-07 14:53:11)
> Other cores don't busy wait any more and we removed the last user of checking
> the seqno for changes. Drop updating the number for shared fences altogether.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

> ---
>  drivers/dma-buf/reservation.c                    | 6 ------
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +------
>  2 files changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 8fcaddffd5d4..90bc6ef03598 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -237,9 +237,6 @@ void reservation_object_add_shared_fence(struct reservation_object *obj,
>         fobj = reservation_object_get_list(obj);
>         count = fobj->shared_count;
>  
> -       preempt_disable();
> -       write_seqcount_begin(&obj->seq);
> -
>         for (i = 0; i < count; ++i) {
>  
>                 old = rcu_dereference_protected(fobj->shared[i],
> @@ -257,9 +254,6 @@ void reservation_object_add_shared_fence(struct reservation_object *obj,
>         RCU_INIT_POINTER(fobj->shared[i], fence);
>         /* pointer update must be visible before we extend the shared_count */
>         smp_store_mb(fobj->shared_count, count);
> -
> -       write_seqcount_end(&obj->seq);
> -       preempt_enable();
>         dma_fence_put(old);
>  }
>  EXPORT_SYMBOL(reservation_object_add_shared_fence);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index fe062b76ec91..a4640ddc24d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -251,12 +251,7 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
>         new->shared_max = old->shared_max;
>         new->shared_count = k;
>  
> -       /* Install the new fence list, seqcount provides the barriers */
> -       preempt_disable();
> -       write_seqcount_begin(&resv->seq);
> -       RCU_INIT_POINTER(resv->fence, new);
> -       write_seqcount_end(&resv->seq);
> -       preempt_enable();
> +       rcu_assign_pointer(resv->fence, new);

but you'll probably want a local ack for amdgpu/
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] dma-buf: add reservation_object_fences helper
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
                   ` (3 preceding siblings ...)
  2019-08-07 16:07 ` [PATCH 1/4] dma-buf: add reservation_object_fences helper Chris Wilson
@ 2019-08-09 13:07 ` Patchwork
  2019-08-09 13:31 ` ✓ Fi.CI.BAT: success " Patchwork
  2019-08-10  6:31 ` ✓ Fi.CI.IGT: " Patchwork
  6 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2019-08-09 13:07 UTC (permalink / raw)
  To: Christian König; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] dma-buf: add reservation_object_fences helper
URL   : https://patchwork.freedesktop.org/series/64955/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6ff342a1513c dma-buf: add reservation_object_fences helper
-:25: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#25: FILE: drivers/dma-buf/dma-buf.c:202:
+	unsigned shared_count;

-:191: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#191: FILE: drivers/dma-buf/reservation.c:508:
+	unsigned shared_count;

-:238: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#238: FILE: drivers/dma-buf/reservation.c:599:
+	unsigned shared_count;

-:427: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 4 warnings, 0 checks, 381 lines checked
aaef55f6b88d drm/i915: use new reservation_object_fences helper
-:61: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 43 lines checked
5dd5e3f55895 dma-buf: further relax reservation_object_add_shared_fence
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#9: 
Other cores don't busy wait any more and we removed the last user of checking

-:55: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 2 warnings, 0 checks, 31 lines checked
ee9de2492811 dma-buf: nuke reservation_object seq number
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#9: 
The only remaining use for this is to protect against setting a new exclusive

-:57: WARNING:MEMORY_BARRIER: memory barrier without comment
#57: FILE: drivers/dma-buf/reservation.c:279:
+		smp_store_mb(old->shared_count, 0);

-:112: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 3 warnings, 0 checks, 80 lines checked

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with [1/4] dma-buf: add reservation_object_fences helper
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
                   ` (4 preceding siblings ...)
  2019-08-09 13:07 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] " Patchwork
@ 2019-08-09 13:31 ` Patchwork
  2019-08-10  6:31 ` ✓ Fi.CI.IGT: " Patchwork
  6 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2019-08-09 13:31 UTC (permalink / raw)
  To: Christian König; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] dma-buf: add reservation_object_fences helper
URL   : https://patchwork.freedesktop.org/series/64955/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6667 -> Patchwork_13941
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@basic-flip-a:
    - fi-kbl-7567u:       [PASS][1] -> [SKIP][2] ([fdo#109271] / [fdo#109278]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
    - fi-kbl-7500u:       [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278]) +2 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7500u/igt@kms_busy@basic-flip-c.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7500u/igt@kms_busy@basic-flip-c.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-7567u:       [PASS][5] -> [WARN][6] ([fdo#109380])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html

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

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
    - fi-kbl-7567u:       [PASS][9] -> [SKIP][10] ([fdo#109271]) +23 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html

  
#### Possible fixes ####

  * igt@kms_chamelium@dp-crc-fast:
    - fi-cml-u2:          [FAIL][11] ([fdo#110627]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-cml-u2/igt@kms_chamelium@dp-crc-fast.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-cml-u2/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7567u:       [FAIL][13] ([fdo#109485]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [DMESG-WARN][15] ([fdo#102614]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
    - fi-icl-u2:          [FAIL][17] ([fdo#103167]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-kbl-7500u:       [SKIP][19] ([fdo#109271]) -> [PASS][20] +23 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/fi-kbl-7500u/igt@prime_vgem@basic-fence-flip.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/fi-kbl-7500u/igt@prime_vgem@basic-fence-flip.html

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627


Participating hosts (55 -> 47)
------------------------------

  Missing    (8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6667 -> Patchwork_13941

  CI-20190529: 20190529
  CI_DRM_6667: e4aebcb3848d8118eb9d42456bdff183268b221c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5127: f43f5fa12ac1b93febfe3eeb9e9985f5f3e2eff0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13941: ee9de2492811c710ce6da6c8bd2a4c6311a60e3f @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ee9de2492811 dma-buf: nuke reservation_object seq number
5dd5e3f55895 dma-buf: further relax reservation_object_add_shared_fence
aaef55f6b88d drm/i915: use new reservation_object_fences helper
6ff342a1513c dma-buf: add reservation_object_fences helper

== Logs ==

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* ✓ Fi.CI.IGT: success for series starting with [1/4] dma-buf: add reservation_object_fences helper
  2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
                   ` (5 preceding siblings ...)
  2019-08-09 13:31 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-08-10  6:31 ` Patchwork
  6 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2019-08-10  6:31 UTC (permalink / raw)
  To: Christian König; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] dma-buf: add reservation_object_fences helper
URL   : https://patchwork.freedesktop.org/series/64955/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13941_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_eio@reset-stress:
    - shard-apl:          [PASS][1] -> [FAIL][2] ([fdo#109661])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl6/igt@gem_eio@reset-stress.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl3/igt@gem_eio@reset-stress.html

  * igt@gem_exec_await@wide-all:
    - shard-iclb:         [PASS][3] -> [FAIL][4] ([fdo#110946])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb6/igt@gem_exec_await@wide-all.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb1/igt@gem_exec_await@wide-all.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_6667/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#111325]) +6 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb6/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb1/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_workarounds@suspend-resume:
    - shard-kbl:          [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +3 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-kbl1/igt@gem_workarounds@suspend-resume.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-kbl4/igt@gem_workarounds@suspend-resume.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-apl:          [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl5/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
    - shard-glk:          [PASS][13] -> [FAIL][14] ([fdo#104873])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-glk1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-glk3/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-modeset-vs-vblank-race:
    - shard-glk:          [PASS][15] -> [FAIL][16] ([fdo#103060])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-glk2/igt@kms_flip@2x-modeset-vs-vblank-race.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-glk4/igt@kms_flip@2x-modeset-vs-vblank-race.html

  * igt@kms_flip@flip-vs-panning-vs-hang:
    - shard-hsw:          [PASS][17] -> [INCOMPLETE][18] ([fdo#103540])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-hsw4/igt@kms_flip@flip-vs-panning-vs-hang.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-hsw5/igt@kms_flip@flip-vs-panning-vs-hang.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
    - shard-iclb:         [PASS][19] -> [FAIL][20] ([fdo#103167]) +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [PASS][21] -> [FAIL][22] ([fdo#108145])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [PASS][25] -> [SKIP][26] ([fdo#109441])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_sequence@queue-idle:
    - shard-apl:          [PASS][27] -> [INCOMPLETE][28] ([fdo#103927])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl6/igt@kms_sequence@queue-idle.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl8/igt@kms_sequence@queue-idle.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][29] -> [FAIL][30] ([fdo#99912])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl6/igt@kms_setmode@basic.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl3/igt@kms_setmode@basic.html

  * igt@prime_busy@hang-bsd2:
    - shard-iclb:         [PASS][31] -> [SKIP][32] ([fdo#109276]) +27 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb1/igt@prime_busy@hang-bsd2.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb5/igt@prime_busy@hang-bsd2.html

  
#### Possible fixes ####

  * igt@gem_exec_async@concurrent-writes-bsd:
    - shard-iclb:         [SKIP][33] ([fdo#111325]) -> [PASS][34] +5 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb1/igt@gem_exec_async@concurrent-writes-bsd.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@gem_exec_async@concurrent-writes-bsd.html

  * igt@gem_exec_blt@dumb-buf-min:
    - shard-apl:          [INCOMPLETE][35] ([fdo#103927]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl1/igt@gem_exec_blt@dumb-buf-min.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl4/igt@gem_exec_blt@dumb-buf-min.html

  * igt@gem_exec_schedule@fifo-bsd1:
    - shard-iclb:         [SKIP][37] ([fdo#109276]) -> [PASS][38] +14 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb7/igt@gem_exec_schedule@fifo-bsd1.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb4/igt@gem_exec_schedule@fifo-bsd1.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][39] ([fdo#108566]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-kbl6/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled:
    - shard-skl:          [FAIL][41] ([fdo#103184] / [fdo#103232] / [fdo#108472]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-skl1/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-skl6/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled.html

  * igt@kms_flip@2x-flip-vs-expired-vblank:
    - shard-glk:          [FAIL][43] ([fdo#105363]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-panning-interruptible:
    - shard-hsw:          [INCOMPLETE][45] ([fdo#103540]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-hsw7/igt@kms_flip@flip-vs-panning-interruptible.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-hsw2/igt@kms_flip@flip-vs-panning-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [DMESG-WARN][47] ([fdo#108566]) -> [PASS][48] +2 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl7/igt@kms_flip@flip-vs-suspend-interruptible.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl5/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [FAIL][49] ([fdo#103167]) -> [PASS][50] +3 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@psr-suspend:
    - shard-skl:          [INCOMPLETE][51] ([fdo#104108] / [fdo#106978]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-skl4/igt@kms_frontbuffer_tracking@psr-suspend.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-skl6/igt@kms_frontbuffer_tracking@psr-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-kbl:          [INCOMPLETE][53] ([fdo#103665]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-kbl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-kbl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
    - shard-skl:          [FAIL][55] ([fdo#108145]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-skl5/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-skl2/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][57] ([fdo#109441]) -> [PASS][58] +2 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb8/igt@kms_psr@psr2_cursor_blt.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  * igt@perf_pmu@rc6-runtime-pm-long:
    - shard-apl:          [FAIL][59] ([fdo#105010]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-apl7/igt@perf_pmu@rc6-runtime-pm-long.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-apl5/igt@perf_pmu@rc6-runtime-pm-long.html
    - shard-hsw:          [FAIL][61] ([fdo#105010]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-hsw1/igt@perf_pmu@rc6-runtime-pm-long.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-hsw2/igt@perf_pmu@rc6-runtime-pm-long.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][63] ([fdo#111329]) -> [SKIP][64] ([fdo#109276])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd1:
    - shard-iclb:         [FAIL][65] ([fdo#111327]) -> [SKIP][66] ([fdo#109276])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb2/igt@gem_ctx_shared@exec-single-timeline-bsd1.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb7/igt@gem_ctx_shared@exec-single-timeline-bsd1.html

  * igt@gem_exec_params@invalid-bsd-ring:
    - shard-iclb:         [SKIP][67] ([fdo#109276]) -> [FAIL][68] ([fdo#111328])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb5/igt@gem_exec_params@invalid-bsd-ring.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb1/igt@gem_exec_params@invalid-bsd-ring.html

  * igt@gem_exec_schedule@independent-bsd1:
    - shard-iclb:         [SKIP][69] ([fdo#109276]) -> [FAIL][70] ([fdo#110946])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb7/igt@gem_exec_schedule@independent-bsd1.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb4/igt@gem_exec_schedule@independent-bsd1.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [FAIL][71] ([fdo#110946]) -> [SKIP][72] ([fdo#109276])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb3/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_mocs_settings@mocs-reset-bsd2:
    - shard-iclb:         [FAIL][73] ([fdo#111330]) -> [SKIP][74] ([fdo#109276])
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb2/igt@gem_mocs_settings@mocs-reset-bsd2.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb8/igt@gem_mocs_settings@mocs-reset-bsd2.html

  * igt@gem_mocs_settings@mocs-settings-bsd2:
    - shard-iclb:         [SKIP][75] ([fdo#109276]) -> [FAIL][76] ([fdo#111330])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6667/shard-iclb8/igt@gem_mocs_settings@mocs-settings-bsd2.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13941/shard-iclb2/igt@gem_mocs_settings@mocs-settings-bsd2.html

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

  [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#105010]: https://bugs.freedesktop.org/show_bug.cgi?id=105010
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108472]: https://bugs.freedesktop.org/show_bug.cgi?id=108472
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#110946]: https://bugs.freedesktop.org/show_bug.cgi?id=110946
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111327]: https://bugs.freedesktop.org/show_bug.cgi?id=111327
  [fdo#111328]: https://bugs.freedesktop.org/show_bug.cgi?id=111328
  [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6667 -> Patchwork_13941

  CI-20190529: 20190529
  CI_DRM_6667: e4aebcb3848d8118eb9d42456bdff183268b221c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5127: f43f5fa12ac1b93febfe3eeb9e9985f5f3e2eff0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13941: ee9de2492811c710ce6da6c8bd2a4c6311a60e3f @ 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_13941/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-07 14:17   ` Chris Wilson
@ 2019-08-10 10:51     ` Christian König
  2019-08-14 15:39       ` Daniel Vetter
  0 siblings, 1 reply; 23+ messages in thread
From: Christian König @ 2019-08-10 10:51 UTC (permalink / raw)
  To: Chris Wilson, dri-devel, intel-gfx, linaro-mm-sig, Daniel Vetter

Am 07.08.19 um 16:17 schrieb Chris Wilson:
> Quoting Christian König (2019-08-07 14:53:12)
>> The only remaining use for this is to protect against setting a new exclusive
>> fence while we grab both exclusive and shared. That can also be archived by
>> looking if the exclusive fence has changed or not after completing the
>> operation.
>>
>> v2: switch setting excl fence to rcu_assign_pointer
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/reservation.c | 24 +++++-------------------
>>   include/linux/reservation.h   |  9 ++-------
>>   2 files changed, 7 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>> index 90bc6ef03598..f7f4a0858c2a 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -49,12 +49,6 @@
>>   DEFINE_WD_CLASS(reservation_ww_class);
>>   EXPORT_SYMBOL(reservation_ww_class);
>>   
>> -struct lock_class_key reservation_seqcount_class;
>> -EXPORT_SYMBOL(reservation_seqcount_class);
>> -
>> -const char reservation_seqcount_string[] = "reservation_seqcount";
>> -EXPORT_SYMBOL(reservation_seqcount_string);
>> -
>>   /**
>>    * reservation_object_list_alloc - allocate fence list
>>    * @shared_max: number of fences we need space for
>> @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
>>   void reservation_object_init(struct reservation_object *obj)
>>   {
>>          ww_mutex_init(&obj->lock, &reservation_ww_class);
>> -
>> -       __seqcount_init(&obj->seq, reservation_seqcount_string,
>> -                       &reservation_seqcount_class);
>>          RCU_INIT_POINTER(obj->fence, NULL);
>>          RCU_INIT_POINTER(obj->fence_excl, NULL);
>>   }
>> @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
>>                  dma_fence_get(fence);
>>   
>>          preempt_disable();
>> -       write_seqcount_begin(&obj->seq);
>> -       /* write_seqcount_begin provides the necessary memory barrier */
>> -       RCU_INIT_POINTER(obj->fence_excl, fence);
>> +       rcu_assign_pointer(obj->fence_excl, fence);
>> +       /* pointer update must be visible before we modify the shared_count */
>>          if (old)
>> -               old->shared_count = 0;
>> -       write_seqcount_end(&obj->seq);
>> +               smp_store_mb(old->shared_count, 0);
>>          preempt_enable();
>>   
>>          /* inplace update, no shared fences */
>> @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
>>          old = reservation_object_get_excl(dst);
>>   
>>          preempt_disable();
>> -       write_seqcount_begin(&dst->seq);
>> -       /* write_seqcount_begin provides the necessary memory barrier */
>> -       RCU_INIT_POINTER(dst->fence_excl, new);
>> -       RCU_INIT_POINTER(dst->fence, dst_list);
>> -       write_seqcount_end(&dst->seq);
>> +       rcu_assign_pointer(dst->fence_excl, new);
>> +       rcu_assign_pointer(dst->fence, dst_list);
>>          preempt_enable();
>>   
>>          reservation_object_list_free(src_list);
>> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
>> index 044a5cd4af50..fd29baad0be3 100644
>> --- a/include/linux/reservation.h
>> +++ b/include/linux/reservation.h
>> @@ -46,8 +46,6 @@
>>   #include <linux/rcupdate.h>
>>   
>>   extern struct ww_class reservation_ww_class;
>> -extern struct lock_class_key reservation_seqcount_class;
>> -extern const char reservation_seqcount_string[];
>>   
>>   /**
>>    * struct reservation_object_list - a list of shared fences
>> @@ -71,7 +69,6 @@ struct reservation_object_list {
>>    */
>>   struct reservation_object {
>>          struct ww_mutex lock;
>> -       seqcount_t seq;
>>   
>>          struct dma_fence __rcu *fence_excl;
>>          struct reservation_object_list __rcu *fence;
>> @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
>>                            struct reservation_object_list **list,
>>                            u32 *shared_count)
>>   {
>> -       unsigned int seq;
>> -
>>          do {
>> -               seq = read_seqcount_begin(&obj->seq);
>>                  *excl = rcu_dereference(obj->fence_excl);
>>                  *list = rcu_dereference(obj->fence);
>>                  *shared_count = *list ? (*list)->shared_count : 0;
>> -       } while (read_seqcount_retry(&obj->seq, seq));
>> +               smp_rmb(); /* See reservation_object_add_excl_fence */
>> +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
>>   }
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> I think this is correct. Now see if we can convince Daniel!

Daniel any objections to this? IGTs look good as well, so if not I'm 
going to push it.

Christian.

> -Chris

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-10 10:51     ` Christian König
@ 2019-08-14 15:39       ` Daniel Vetter
  2019-08-14 16:42         ` Chris Wilson
  0 siblings, 1 reply; 23+ messages in thread
From: Daniel Vetter @ 2019-08-14 15:39 UTC (permalink / raw)
  To: christian.koenig; +Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Sorry I burried myself in some other stuff ...

On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > Quoting Christian König (2019-08-07 14:53:12)
> > > The only remaining use for this is to protect against setting a new exclusive
> > > fence while we grab both exclusive and shared. That can also be archived by
> > > looking if the exclusive fence has changed or not after completing the
> > > operation.
> > > 
> > > v2: switch setting excl fence to rcu_assign_pointer
> > > 
> > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > ---
> > >   drivers/dma-buf/reservation.c | 24 +++++-------------------
> > >   include/linux/reservation.h   |  9 ++-------
> > >   2 files changed, 7 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > --- a/drivers/dma-buf/reservation.c
> > > +++ b/drivers/dma-buf/reservation.c
> > > @@ -49,12 +49,6 @@
> > >   DEFINE_WD_CLASS(reservation_ww_class);
> > >   EXPORT_SYMBOL(reservation_ww_class);
> > > -struct lock_class_key reservation_seqcount_class;
> > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > -
> > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > -
> > >   /**
> > >    * reservation_object_list_alloc - allocate fence list
> > >    * @shared_max: number of fences we need space for
> > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
> > >   void reservation_object_init(struct reservation_object *obj)
> > >   {
> > >          ww_mutex_init(&obj->lock, &reservation_ww_class);
> > > -
> > > -       __seqcount_init(&obj->seq, reservation_seqcount_string,
> > > -                       &reservation_seqcount_class);
> > >          RCU_INIT_POINTER(obj->fence, NULL);
> > >          RCU_INIT_POINTER(obj->fence_excl, NULL);
> > >   }
> > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
> > >                  dma_fence_get(fence);
> > >          preempt_disable();
> > > -       write_seqcount_begin(&obj->seq);
> > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > -       RCU_INIT_POINTER(obj->fence_excl, fence);
> > > +       rcu_assign_pointer(obj->fence_excl, fence);
> > > +       /* pointer update must be visible before we modify the shared_count */

Pls add a "see reservation_object_fence()" here or similar.

> > >          if (old)
> > > -               old->shared_count = 0;
> > > -       write_seqcount_end(&obj->seq);
> > > +               smp_store_mb(old->shared_count, 0);

So your comment and the kerneldoc don't match up. Quoting
Documentation/memory-barriers.txt:

     This assigns the value to the variable and then inserts a full memory
     barrier after it.  It isn't guaranteed to insert anything more than a
     compiler barrier in a UP compilation.

So order is 1. store 2. fence, but your comment suggests you want it the
other way round.

> > >          preempt_enable();
> > >          /* inplace update, no shared fences */
> > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
> > >          old = reservation_object_get_excl(dst);
> > >          preempt_disable();
> > > -       write_seqcount_begin(&dst->seq);
> > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > -       RCU_INIT_POINTER(dst->fence_excl, new);
> > > -       RCU_INIT_POINTER(dst->fence, dst_list);
> > > -       write_seqcount_end(&dst->seq);
> > > +       rcu_assign_pointer(dst->fence_excl, new);
> > > +       rcu_assign_pointer(dst->fence, dst_list);
> > >          preempt_enable();
> > >          reservation_object_list_free(src_list);
> > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > index 044a5cd4af50..fd29baad0be3 100644
> > > --- a/include/linux/reservation.h
> > > +++ b/include/linux/reservation.h
> > > @@ -46,8 +46,6 @@
> > >   #include <linux/rcupdate.h>
> > >   extern struct ww_class reservation_ww_class;
> > > -extern struct lock_class_key reservation_seqcount_class;
> > > -extern const char reservation_seqcount_string[];
> > >   /**
> > >    * struct reservation_object_list - a list of shared fences
> > > @@ -71,7 +69,6 @@ struct reservation_object_list {
> > >    */
> > >   struct reservation_object {
> > >          struct ww_mutex lock;
> > > -       seqcount_t seq;
> > >          struct dma_fence __rcu *fence_excl;
> > >          struct reservation_object_list __rcu *fence;
> > > @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
> > >                            struct reservation_object_list **list,
> > >                            u32 *shared_count)
> > >   {
> > > -       unsigned int seq;
> > > -
> > >          do {
> > > -               seq = read_seqcount_begin(&obj->seq);
> > >                  *excl = rcu_dereference(obj->fence_excl);

I think you need a barrier between this and the read of shared_count
below. But rcu_derefence only gives you a dependent barrier, i.e. only
stuff that's accesses through this pointer is ordered. Which means the
access to ->shared_count, which goes through another pointer, isn't
actually ordered.

I think the implementation is that it is an unconditional compiler barrier
(but that might change), but you're definitely missing the cpu barrier, so
a cpue might speculate the entire thing out of order.

I think you need another smb_rmb(); here


> > >                  *list = rcu_dereference(obj->fence);
> > >                  *shared_count = *list ? (*list)->shared_count : 0;
> > > -       } while (read_seqcount_retry(&obj->seq, seq));
> > > +               smp_rmb(); /* See reservation_object_add_excl_fence */

This fence here I think prevents the re-reading of ->fence_excl from
getting hoisted above the critical reads. So this is just the open-coded
seqlock retry loop.

> > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);

What if someone is real fast (like really real fast) and recycles the
exclusive fence so you read the same pointer twice, but everything else
changed? reused fence pointer is a lot more likely than seqlock wrapping
around.

> > >   }
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > I think this is correct. Now see if we can convince Daniel!
> 
> Daniel any objections to this? IGTs look good as well, so if not I'm going
> to push it.

Not really convinced. Also haven't looked at the entire thing yet, this is
just from staring at this patch in isolation and poking at it.
-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] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 15:39       ` Daniel Vetter
@ 2019-08-14 16:42         ` Chris Wilson
  2019-08-14 17:06           ` Chris Wilson
  2019-08-14 17:06           ` Daniel Vetter
  0 siblings, 2 replies; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 16:42 UTC (permalink / raw)
  To: Daniel Vetter, christian.koenig
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Daniel Vetter (2019-08-14 16:39:08)
> Sorry I burried myself in some other stuff ...
> 
> On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > Quoting Christian König (2019-08-07 14:53:12)
> > > > The only remaining use for this is to protect against setting a new exclusive
> > > > fence while we grab both exclusive and shared. That can also be archived by
> > > > looking if the exclusive fence has changed or not after completing the
> > > > operation.
> > > > 
> > > > v2: switch setting excl fence to rcu_assign_pointer
> > > > 
> > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > ---
> > > >   drivers/dma-buf/reservation.c | 24 +++++-------------------
> > > >   include/linux/reservation.h   |  9 ++-------
> > > >   2 files changed, 7 insertions(+), 26 deletions(-)
> > > > 
> > > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > > --- a/drivers/dma-buf/reservation.c
> > > > +++ b/drivers/dma-buf/reservation.c
> > > > @@ -49,12 +49,6 @@
> > > >   DEFINE_WD_CLASS(reservation_ww_class);
> > > >   EXPORT_SYMBOL(reservation_ww_class);
> > > > -struct lock_class_key reservation_seqcount_class;
> > > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > > -
> > > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > > -
> > > >   /**
> > > >    * reservation_object_list_alloc - allocate fence list
> > > >    * @shared_max: number of fences we need space for
> > > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
> > > >   void reservation_object_init(struct reservation_object *obj)
> > > >   {
> > > >          ww_mutex_init(&obj->lock, &reservation_ww_class);
> > > > -
> > > > -       __seqcount_init(&obj->seq, reservation_seqcount_string,
> > > > -                       &reservation_seqcount_class);
> > > >          RCU_INIT_POINTER(obj->fence, NULL);
> > > >          RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > >   }
> > > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
> > > >                  dma_fence_get(fence);
> > > >          preempt_disable();
> > > > -       write_seqcount_begin(&obj->seq);
> > > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > > -       RCU_INIT_POINTER(obj->fence_excl, fence);
> > > > +       rcu_assign_pointer(obj->fence_excl, fence);
> > > > +       /* pointer update must be visible before we modify the shared_count */
> 
> Pls add a "see reservation_object_fence()" here or similar.
> 
> > > >          if (old)
> > > > -               old->shared_count = 0;
> > > > -       write_seqcount_end(&obj->seq);
> > > > +               smp_store_mb(old->shared_count, 0);
> 
> So your comment and the kerneldoc don't match up. Quoting
> Documentation/memory-barriers.txt:
> 
>      This assigns the value to the variable and then inserts a full memory
>      barrier after it.  It isn't guaranteed to insert anything more than a
>      compiler barrier in a UP compilation.
> 
> So order is 1. store 2. fence, but your comment suggests you want it the
> other way round.

What's more weird is that it is a fully serialising instruction that is
used to fence first as part of the update. If that's way PeterZ uses
it...

> > > >          preempt_enable();
> > > >          /* inplace update, no shared fences */
> > > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
> > > >          old = reservation_object_get_excl(dst);
> > > >          preempt_disable();
> > > > -       write_seqcount_begin(&dst->seq);
> > > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > > -       RCU_INIT_POINTER(dst->fence_excl, new);
> > > > -       RCU_INIT_POINTER(dst->fence, dst_list);
> > > > -       write_seqcount_end(&dst->seq);
> > > > +       rcu_assign_pointer(dst->fence_excl, new);
> > > > +       rcu_assign_pointer(dst->fence, dst_list);
> > > >          preempt_enable();
> > > >          reservation_object_list_free(src_list);
> > > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > > index 044a5cd4af50..fd29baad0be3 100644
> > > > --- a/include/linux/reservation.h
> > > > +++ b/include/linux/reservation.h
> > > > @@ -46,8 +46,6 @@
> > > >   #include <linux/rcupdate.h>
> > > >   extern struct ww_class reservation_ww_class;
> > > > -extern struct lock_class_key reservation_seqcount_class;
> > > > -extern const char reservation_seqcount_string[];
> > > >   /**
> > > >    * struct reservation_object_list - a list of shared fences
> > > > @@ -71,7 +69,6 @@ struct reservation_object_list {
> > > >    */
> > > >   struct reservation_object {
> > > >          struct ww_mutex lock;
> > > > -       seqcount_t seq;
> > > >          struct dma_fence __rcu *fence_excl;
> > > >          struct reservation_object_list __rcu *fence;
> > > > @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
> > > >                            struct reservation_object_list **list,
> > > >                            u32 *shared_count)
> > > >   {
> > > > -       unsigned int seq;
> > > > -
> > > >          do {
> > > > -               seq = read_seqcount_begin(&obj->seq);
> > > >                  *excl = rcu_dereference(obj->fence_excl);
> 
> I think you need a barrier between this and the read of shared_count
> below. But rcu_derefence only gives you a dependent barrier, i.e. only
> stuff that's accesses through this pointer is ordered. Which means the
> access to ->shared_count, which goes through another pointer, isn't
> actually ordered.

Well,

do {
	excl = ...
	smp_rmb();
	(list, count) = ...
	smp_rmb();
} while (excl != ...)

would be the straightforward conversion of the seqlock.

> I think the implementation is that it is an unconditional compiler barrier
> (but that might change), but you're definitely missing the cpu barrier, so
> a cpue might speculate the entire thing out of order.
> 
> I think you need another smb_rmb(); here
> 
> 
> > > >                  *list = rcu_dereference(obj->fence);
> > > >                  *shared_count = *list ? (*list)->shared_count : 0;
> > > > -       } while (read_seqcount_retry(&obj->seq, seq));
> > > > +               smp_rmb(); /* See reservation_object_add_excl_fence */
> 
> This fence here I think prevents the re-reading of ->fence_excl from
> getting hoisted above the critical reads. So this is just the open-coded
> seqlock retry loop.

Without the seq.

The dilemma for dropping the seq would be what if we were to add another
state here, such as modified or even invalidate.

> > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> 
> What if someone is real fast (like really real fast) and recycles the
> exclusive fence so you read the same pointer twice, but everything else
> changed? reused fence pointer is a lot more likely than seqlock wrapping
> around.

It's an exclusive fence. If it is replaced, it must be later than all
the shared fences (and dependent on them directly or indirectly), and
so still a consistent snapshot.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 16:42         ` Chris Wilson
@ 2019-08-14 17:06           ` Chris Wilson
  2019-08-14 17:22             ` Chris Wilson
  2019-08-14 17:06           ` Daniel Vetter
  1 sibling, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 17:06 UTC (permalink / raw)
  To: Daniel Vetter, christian.koenig
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > 
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive fence so you read the same pointer twice, but everything else
> > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > around.
> 
> It's an exclusive fence. If it is replaced, it must be later than all
> the shared fences (and dependent on them directly or indirectly), and
> so still a consistent snapshot.

An extension of that argument says we don't even need to loop,

*list = rcu_dereference(obj->fence);
*shared_count = *list ? (*list)->shared_count : 0;
smp_rmb();
*excl = rcu_dereference(obj->fence_excl);

Gives a consistent snapshot. It doesn't matter if the fence_excl is
before or after the shared_list -- if it's after, it's a superset of all
fences, if it's before, we have a correct list of shared fences the
earlier fence_excl.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 16:42         ` Chris Wilson
  2019-08-14 17:06           ` Chris Wilson
@ 2019-08-14 17:06           ` Daniel Vetter
  2019-08-14 17:20             ` Chris Wilson
  1 sibling, 1 reply; 23+ messages in thread
From: Daniel Vetter @ 2019-08-14 17:06 UTC (permalink / raw)
  To: Chris Wilson
  Cc: Daniel Vetter, intel-gfx, dri-devel, linaro-mm-sig, christian.koenig

On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > Sorry I burried myself in some other stuff ...
> > 
> > On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > > Quoting Christian König (2019-08-07 14:53:12)
> > > > > The only remaining use for this is to protect against setting a new exclusive
> > > > > fence while we grab both exclusive and shared. That can also be archived by
> > > > > looking if the exclusive fence has changed or not after completing the
> > > > > operation.
> > > > > 
> > > > > v2: switch setting excl fence to rcu_assign_pointer
> > > > > 
> > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > ---
> > > > >   drivers/dma-buf/reservation.c | 24 +++++-------------------
> > > > >   include/linux/reservation.h   |  9 ++-------
> > > > >   2 files changed, 7 insertions(+), 26 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > > > --- a/drivers/dma-buf/reservation.c
> > > > > +++ b/drivers/dma-buf/reservation.c
> > > > > @@ -49,12 +49,6 @@
> > > > >   DEFINE_WD_CLASS(reservation_ww_class);
> > > > >   EXPORT_SYMBOL(reservation_ww_class);
> > > > > -struct lock_class_key reservation_seqcount_class;
> > > > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > > > -
> > > > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > > > -
> > > > >   /**
> > > > >    * reservation_object_list_alloc - allocate fence list
> > > > >    * @shared_max: number of fences we need space for
> > > > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct reservation_object_list *list)
> > > > >   void reservation_object_init(struct reservation_object *obj)
> > > > >   {
> > > > >          ww_mutex_init(&obj->lock, &reservation_ww_class);
> > > > > -
> > > > > -       __seqcount_init(&obj->seq, reservation_seqcount_string,
> > > > > -                       &reservation_seqcount_class);
> > > > >          RCU_INIT_POINTER(obj->fence, NULL);
> > > > >          RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > > >   }
> > > > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
> > > > >                  dma_fence_get(fence);
> > > > >          preempt_disable();
> > > > > -       write_seqcount_begin(&obj->seq);
> > > > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > > > -       RCU_INIT_POINTER(obj->fence_excl, fence);
> > > > > +       rcu_assign_pointer(obj->fence_excl, fence);
> > > > > +       /* pointer update must be visible before we modify the shared_count */
> > 
> > Pls add a "see reservation_object_fence()" here or similar.
> > 
> > > > >          if (old)
> > > > > -               old->shared_count = 0;
> > > > > -       write_seqcount_end(&obj->seq);
> > > > > +               smp_store_mb(old->shared_count, 0);
> > 
> > So your comment and the kerneldoc don't match up. Quoting
> > Documentation/memory-barriers.txt:
> > 
> >      This assigns the value to the variable and then inserts a full memory
> >      barrier after it.  It isn't guaranteed to insert anything more than a
> >      compiler barrier in a UP compilation.
> > 
> > So order is 1. store 2. fence, but your comment suggests you want it the
> > other way round.
> 
> What's more weird is that it is a fully serialising instruction that is
> used to fence first as part of the update. If that's way PeterZ uses
> it...

I haven't looked at the implementations tbh, just going with the text. Or
do you mean in the write_seqlock that we're replacing?

> 
> > > > >          preempt_enable();
> > > > >          /* inplace update, no shared fences */
> > > > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct reservation_object *dst,
> > > > >          old = reservation_object_get_excl(dst);
> > > > >          preempt_disable();
> > > > > -       write_seqcount_begin(&dst->seq);
> > > > > -       /* write_seqcount_begin provides the necessary memory barrier */
> > > > > -       RCU_INIT_POINTER(dst->fence_excl, new);
> > > > > -       RCU_INIT_POINTER(dst->fence, dst_list);
> > > > > -       write_seqcount_end(&dst->seq);
> > > > > +       rcu_assign_pointer(dst->fence_excl, new);
> > > > > +       rcu_assign_pointer(dst->fence, dst_list);
> > > > >          preempt_enable();
> > > > >          reservation_object_list_free(src_list);
> > > > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > > > index 044a5cd4af50..fd29baad0be3 100644
> > > > > --- a/include/linux/reservation.h
> > > > > +++ b/include/linux/reservation.h
> > > > > @@ -46,8 +46,6 @@
> > > > >   #include <linux/rcupdate.h>
> > > > >   extern struct ww_class reservation_ww_class;
> > > > > -extern struct lock_class_key reservation_seqcount_class;
> > > > > -extern const char reservation_seqcount_string[];
> > > > >   /**
> > > > >    * struct reservation_object_list - a list of shared fences
> > > > > @@ -71,7 +69,6 @@ struct reservation_object_list {
> > > > >    */
> > > > >   struct reservation_object {
> > > > >          struct ww_mutex lock;
> > > > > -       seqcount_t seq;
> > > > >          struct dma_fence __rcu *fence_excl;
> > > > >          struct reservation_object_list __rcu *fence;
> > > > > @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object *obj,
> > > > >                            struct reservation_object_list **list,
> > > > >                            u32 *shared_count)
> > > > >   {
> > > > > -       unsigned int seq;
> > > > > -
> > > > >          do {
> > > > > -               seq = read_seqcount_begin(&obj->seq);
> > > > >                  *excl = rcu_dereference(obj->fence_excl);
> > 
> > I think you need a barrier between this and the read of shared_count
> > below. But rcu_derefence only gives you a dependent barrier, i.e. only
> > stuff that's accesses through this pointer is ordered. Which means the
> > access to ->shared_count, which goes through another pointer, isn't
> > actually ordered.
> 
> Well,
> 
> do {
> 	excl = ...
> 	smp_rmb();
> 	(list, count) = ...
> 	smp_rmb();
> } while (excl != ...)
> 
> would be the straightforward conversion of the seqlock.

Yeah I cheated by looking there, and couldn't convince myself that we
can't drop the first smp_rmb() ...

> 
> > I think the implementation is that it is an unconditional compiler barrier
> > (but that might change), but you're definitely missing the cpu barrier, so
> > a cpue might speculate the entire thing out of order.
> > 
> > I think you need another smb_rmb(); here
> > 
> > 
> > > > >                  *list = rcu_dereference(obj->fence);
> > > > >                  *shared_count = *list ? (*list)->shared_count : 0;
> > > > > -       } while (read_seqcount_retry(&obj->seq, seq));
> > > > > +               smp_rmb(); /* See reservation_object_add_excl_fence */
> > 
> > This fence here I think prevents the re-reading of ->fence_excl from
> > getting hoisted above the critical reads. So this is just the open-coded
> > seqlock retry loop.
> 
> Without the seq.
> 
> The dilemma for dropping the seq would be what if we were to add another
> state here, such as modified or even invalidate.
> 
> > > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > 
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive fence so you read the same pointer twice, but everything else
> > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > around.
> 
> It's an exclusive fence. If it is replaced, it must be later than all
> the shared fences (and dependent on them directly or indirectly), and
> so still a consistent snapshot.

I'm not worried about the fence, that part is fine. But we're defacto
using the fence as a fancy seqlock-of-sorts. And if the fence gets reused
and the pointers match, then our seqlock-of-sorts breaks. But I haven't
looked around whether there's more in the code that makes this an
irrelevant issue.
-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] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:06           ` Daniel Vetter
@ 2019-08-14 17:20             ` Chris Wilson
  2019-08-14 17:48               ` Daniel Vetter
  0 siblings, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 17:20 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, intel-gfx, dri-devel, linaro-mm-sig, christian.koenig

Quoting Daniel Vetter (2019-08-14 18:06:26)
> On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
[snip]
> > > > > >          if (old)
> > > > > > -               old->shared_count = 0;
> > > > > > -       write_seqcount_end(&obj->seq);
> > > > > > +               smp_store_mb(old->shared_count, 0);
> > > 
> > > So your comment and the kerneldoc don't match up. Quoting
> > > Documentation/memory-barriers.txt:
> > > 
> > >      This assigns the value to the variable and then inserts a full memory
> > >      barrier after it.  It isn't guaranteed to insert anything more than a
> > >      compiler barrier in a UP compilation.
> > > 
> > > So order is 1. store 2. fence, but your comment suggests you want it the
> > > other way round.
> > 
> > What's more weird is that it is a fully serialising instruction that is
> > used to fence first as part of the update. If that's way PeterZ uses
> > it...
> 
> I haven't looked at the implementations tbh, just going with the text. Or
> do you mean in the write_seqlock that we're replacing?

Nah, I misremembered set_current_state(), all that implies is the fence
is before the following instructions. I have some recollection that it
can be used as a RELEASE operation (if only because it is a locked xchg).
If all else fails, make it an xchg_release(). Or normal assignment +
smp_wmb().

> > It's an exclusive fence. If it is replaced, it must be later than all
> > the shared fences (and dependent on them directly or indirectly), and
> > so still a consistent snapshot.
> 
> I'm not worried about the fence, that part is fine. But we're defacto
> using the fence as a fancy seqlock-of-sorts. And if the fence gets reused
> and the pointers match, then our seqlock-of-sorts breaks. But I haven't
> looked around whether there's more in the code that makes this an
> irrelevant issue.

No, it should not break if we replace the fence with the same pointer.
If the fence pointer expires, reused and assigned back as the excl_fence
-- it is still the excl_fence and by the properties of that
excl_fence construction, it is later than the shared_fences.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:06           ` Chris Wilson
@ 2019-08-14 17:22             ` Chris Wilson
  2019-08-14 17:38               ` Chris Wilson
  0 siblings, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 17:22 UTC (permalink / raw)
  To: Daniel Vetter, christian.koenig
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > 
> > > What if someone is real fast (like really real fast) and recycles the
> > > exclusive fence so you read the same pointer twice, but everything else
> > > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > > around.
> > 
> > It's an exclusive fence. If it is replaced, it must be later than all
> > the shared fences (and dependent on them directly or indirectly), and
> > so still a consistent snapshot.
> 
> An extension of that argument says we don't even need to loop,
> 
> *list = rcu_dereference(obj->fence);
> *shared_count = *list ? (*list)->shared_count : 0;
> smp_rmb();
> *excl = rcu_dereference(obj->fence_excl);
> 
> Gives a consistent snapshot. It doesn't matter if the fence_excl is
> before or after the shared_list -- if it's after, it's a superset of all
> fences, if it's before, we have a correct list of shared fences the
> earlier fence_excl.

The problem is that the point of the loop is that we do need a check on
the fences after the full memory barrier.

Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()

We don't have a full memory barrier here, so this cannot be used safely
in light of fence reallocation.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:22             ` Chris Wilson
@ 2019-08-14 17:38               ` Chris Wilson
  2019-08-14 17:48                 ` Chris Wilson
  0 siblings, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 17:38 UTC (permalink / raw)
  To: Daniel Vetter, christian.koenig
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Chris Wilson (2019-08-14 18:22:53)
> Quoting Chris Wilson (2019-08-14 18:06:18)
> > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > > 
> > > > What if someone is real fast (like really real fast) and recycles the
> > > > exclusive fence so you read the same pointer twice, but everything else
> > > > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > > > around.
> > > 
> > > It's an exclusive fence. If it is replaced, it must be later than all
> > > the shared fences (and dependent on them directly or indirectly), and
> > > so still a consistent snapshot.
> > 
> > An extension of that argument says we don't even need to loop,
> > 
> > *list = rcu_dereference(obj->fence);
> > *shared_count = *list ? (*list)->shared_count : 0;
> > smp_rmb();
> > *excl = rcu_dereference(obj->fence_excl);
> > 
> > Gives a consistent snapshot. It doesn't matter if the fence_excl is
> > before or after the shared_list -- if it's after, it's a superset of all
> > fences, if it's before, we have a correct list of shared fences the
> > earlier fence_excl.
> 
> The problem is that the point of the loop is that we do need a check on
> the fences after the full memory barrier.
> 
> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
> 
> We don't have a full memory barrier here, so this cannot be used safely
> in light of fence reallocation.

i.e. we need to restore the loops in the callers,

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index a2aff1d8290e..f019062c8cd7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
         * to report the overall busyness. This is what the wait-ioctl does.
         *
         */
+retry:
        dma_resv_fences(obj->base.resv, &excl, &list, &shared_count);

        /* Translate the exclusive fence to the READ *and* WRITE engine */
@@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
                args->busy |= busy_check_reader(fence);
        }

+       smp_rmb();
+       if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
+               goto retry;
+

wrap that up as

static inline bool
dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
{
	smp_rmb();
	return excl != rcu_access_pointer(resv->fence_excl);
}
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:38               ` Chris Wilson
@ 2019-08-14 17:48                 ` Chris Wilson
  2019-08-14 17:58                   ` Koenig, Christian
  0 siblings, 1 reply; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 17:48 UTC (permalink / raw)
  To: Daniel Vetter, christian.koenig
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Chris Wilson (2019-08-14 18:38:20)
> Quoting Chris Wilson (2019-08-14 18:22:53)
> > Quoting Chris Wilson (2019-08-14 18:06:18)
> > > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > > +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > > > 
> > > > > What if someone is real fast (like really real fast) and recycles the
> > > > > exclusive fence so you read the same pointer twice, but everything else
> > > > > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > > > > around.
> > > > 
> > > > It's an exclusive fence. If it is replaced, it must be later than all
> > > > the shared fences (and dependent on them directly or indirectly), and
> > > > so still a consistent snapshot.
> > > 
> > > An extension of that argument says we don't even need to loop,
> > > 
> > > *list = rcu_dereference(obj->fence);
> > > *shared_count = *list ? (*list)->shared_count : 0;
> > > smp_rmb();
> > > *excl = rcu_dereference(obj->fence_excl);
> > > 
> > > Gives a consistent snapshot. It doesn't matter if the fence_excl is
> > > before or after the shared_list -- if it's after, it's a superset of all
> > > fences, if it's before, we have a correct list of shared fences the
> > > earlier fence_excl.
> > 
> > The problem is that the point of the loop is that we do need a check on
> > the fences after the full memory barrier.
> > 
> > Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
> > 
> > We don't have a full memory barrier here, so this cannot be used safely
> > in light of fence reallocation.
> 
> i.e. we need to restore the loops in the callers,
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> index a2aff1d8290e..f019062c8cd7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>          * to report the overall busyness. This is what the wait-ioctl does.
>          *
>          */
> +retry:
>         dma_resv_fences(obj->base.resv, &excl, &list, &shared_count);
> 
>         /* Translate the exclusive fence to the READ *and* WRITE engine */
> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>                 args->busy |= busy_check_reader(fence);
>         }
> 
> +       smp_rmb();
> +       if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
> +               goto retry;
> +
> 
> wrap that up as
> 
> static inline bool
> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
> {
>         smp_rmb();
>         return excl != rcu_access_pointer(resv->fence_excl);
> }

I give up. It's not just the fence_excl that's an issue here.

Any of the shared fences may be replaced after dma_resv_fences()
and so the original shared fence pointer may be reassigned (even under
RCU). The only defense against that is the seqcount.

I totally screwed that up.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:20             ` Chris Wilson
@ 2019-08-14 17:48               ` Daniel Vetter
  0 siblings, 0 replies; 23+ messages in thread
From: Daniel Vetter @ 2019-08-14 17:48 UTC (permalink / raw)
  To: Chris Wilson
  Cc: Daniel Vetter, intel-gfx, dri-devel, linaro-mm-sig, christian.koenig

On Wed, Aug 14, 2019 at 06:20:28PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 18:06:26)
> > On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> [snip]
> > > > > > >          if (old)
> > > > > > > -               old->shared_count = 0;
> > > > > > > -       write_seqcount_end(&obj->seq);
> > > > > > > +               smp_store_mb(old->shared_count, 0);
> > > > 
> > > > So your comment and the kerneldoc don't match up. Quoting
> > > > Documentation/memory-barriers.txt:
> > > > 
> > > >      This assigns the value to the variable and then inserts a full memory
> > > >      barrier after it.  It isn't guaranteed to insert anything more than a
> > > >      compiler barrier in a UP compilation.
> > > > 
> > > > So order is 1. store 2. fence, but your comment suggests you want it the
> > > > other way round.
> > > 
> > > What's more weird is that it is a fully serialising instruction that is
> > > used to fence first as part of the update. If that's way PeterZ uses
> > > it...
> > 
> > I haven't looked at the implementations tbh, just going with the text. Or
> > do you mean in the write_seqlock that we're replacing?
> 
> Nah, I misremembered set_current_state(), all that implies is the fence
> is before the following instructions. I have some recollection that it
> can be used as a RELEASE operation (if only because it is a locked xchg).
> If all else fails, make it an xchg_release(). Or normal assignment +
> smp_wmb().

Yeah that one is called smp_store_release, not smp_store_mb. I think
smp_store_release is the right one here.

> > > It's an exclusive fence. If it is replaced, it must be later than all
> > > the shared fences (and dependent on them directly or indirectly), and
> > > so still a consistent snapshot.
> > 
> > I'm not worried about the fence, that part is fine. But we're defacto
> > using the fence as a fancy seqlock-of-sorts. And if the fence gets reused
> > and the pointers match, then our seqlock-of-sorts breaks. But I haven't
> > looked around whether there's more in the code that makes this an
> > irrelevant issue.
> 
> No, it should not break if we replace the fence with the same pointer.
> If the fence pointer expires, reused and assigned back as the excl_fence
> -- it is still the excl_fence and by the properties of that
> excl_fence construction, it is later than the shared_fences.

So I thought the rules are that if we have an exclusive fence and shared
fences both present, then the shared fences are after the exclusive one.

But if we race here, then I think we could accidentally sample shared
fences from _before_ the exclusive fences. Rough timeline:

exlusive fence 1 -> shared fence 2 -> exclusive fence, but reuses memory
of fence 1

Then we sample fence 1, capture the shared fence 2, and notice that the
exclusive fence pointer is the same (but not the fence on the timeline)
and conclude that we got a consistent sample.

But the only consistent sample with the new fence state would be only the
exclusive fence.

Reminds me I forgot to look for the usual kref_get_unless_zero trickery we
also need to do here to make sure we have the right fence.
-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] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:48                 ` Chris Wilson
@ 2019-08-14 17:58                   ` Koenig, Christian
  2019-08-14 18:52                     ` Chris Wilson
  0 siblings, 1 reply; 23+ messages in thread
From: Koenig, Christian @ 2019-08-14 17:58 UTC (permalink / raw)
  To: Chris Wilson, Daniel Vetter
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Am 14.08.19 um 19:48 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 18:38:20)
>> Quoting Chris Wilson (2019-08-14 18:22:53)
>>> Quoting Chris Wilson (2019-08-14 18:06:18)
>>>> Quoting Chris Wilson (2019-08-14 17:42:48)
>>>>> Quoting Daniel Vetter (2019-08-14 16:39:08)
>>>>>>>>> +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
>>>>>> What if someone is real fast (like really real fast) and recycles the
>>>>>> exclusive fence so you read the same pointer twice, but everything else
>>>>>> changed? reused fence pointer is a lot more likely than seqlock wrapping
>>>>>> around.
>>>>> It's an exclusive fence. If it is replaced, it must be later than all
>>>>> the shared fences (and dependent on them directly or indirectly), and
>>>>> so still a consistent snapshot.
>>>> An extension of that argument says we don't even need to loop,
>>>>
>>>> *list = rcu_dereference(obj->fence);
>>>> *shared_count = *list ? (*list)->shared_count : 0;
>>>> smp_rmb();
>>>> *excl = rcu_dereference(obj->fence_excl);
>>>>
>>>> Gives a consistent snapshot. It doesn't matter if the fence_excl is
>>>> before or after the shared_list -- if it's after, it's a superset of all
>>>> fences, if it's before, we have a correct list of shared fences the
>>>> earlier fence_excl.
>>> The problem is that the point of the loop is that we do need a check on
>>> the fences after the full memory barrier.
>>>
>>> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
>>>
>>> We don't have a full memory barrier here, so this cannot be used safely
>>> in light of fence reallocation.
>> i.e. we need to restore the loops in the callers,
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> index a2aff1d8290e..f019062c8cd7 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>>           * to report the overall busyness. This is what the wait-ioctl does.
>>           *
>>           */
>> +retry:
>>          dma_resv_fences(obj->base.resv, &excl, &list, &shared_count);
>>
>>          /* Translate the exclusive fence to the READ *and* WRITE engine */
>> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>>                  args->busy |= busy_check_reader(fence);
>>          }
>>
>> +       smp_rmb();
>> +       if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
>> +               goto retry;
>> +
>>
>> wrap that up as
>>
>> static inline bool
>> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
>> {
>>          smp_rmb();
>>          return excl != rcu_access_pointer(resv->fence_excl);
>> }
> I give up. It's not just the fence_excl that's an issue here.
>
> Any of the shared fences may be replaced after dma_resv_fences()
> and so the original shared fence pointer may be reassigned (even under
> RCU).

Yeah, but this should be harmless. See fences are always replaced either 
when they are signaled anyway or by later fences from the same context.

And existing fences shouldn't be re-used while under RCU, or is anybody 
still using SLAB_TYPESAFE_BY_RCU?

Christian.

>   The only defense against that is the seqcount.
>
> I totally screwed that up.
> -Chris

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
  2019-08-14 17:58                   ` Koenig, Christian
@ 2019-08-14 18:52                     ` Chris Wilson
  0 siblings, 0 replies; 23+ messages in thread
From: Chris Wilson @ 2019-08-14 18:52 UTC (permalink / raw)
  To: Koenig, Christian, Daniel Vetter
  Cc: linaro-mm-sig, Daniel Vetter, intel-gfx, dri-devel

Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> >>>> Quoting Chris Wilson (2019-08-14 17:42:48)
> >>>>> Quoting Daniel Vetter (2019-08-14 16:39:08)
> >>>>>>>>> +       } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >>>>>> What if someone is real fast (like really real fast) and recycles the
> >>>>>> exclusive fence so you read the same pointer twice, but everything else
> >>>>>> changed? reused fence pointer is a lot more likely than seqlock wrapping
> >>>>>> around.
> >>>>> It's an exclusive fence. If it is replaced, it must be later than all
> >>>>> the shared fences (and dependent on them directly or indirectly), and
> >>>>> so still a consistent snapshot.
> >>>> An extension of that argument says we don't even need to loop,
> >>>>
> >>>> *list = rcu_dereference(obj->fence);
> >>>> *shared_count = *list ? (*list)->shared_count : 0;
> >>>> smp_rmb();
> >>>> *excl = rcu_dereference(obj->fence_excl);
> >>>>
> >>>> Gives a consistent snapshot. It doesn't matter if the fence_excl is
> >>>> before or after the shared_list -- if it's after, it's a superset of all
> >>>> fences, if it's before, we have a correct list of shared fences the
> >>>> earlier fence_excl.
> >>> The problem is that the point of the loop is that we do need a check on
> >>> the fences after the full memory barrier.
> >>>
> >>> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
> >>>
> >>> We don't have a full memory barrier here, so this cannot be used safely
> >>> in light of fence reallocation.
> >> i.e. we need to restore the loops in the callers,
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> index a2aff1d8290e..f019062c8cd7 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
> >>           * to report the overall busyness. This is what the wait-ioctl does.
> >>           *
> >>           */
> >> +retry:
> >>          dma_resv_fences(obj->base.resv, &excl, &list, &shared_count);
> >>
> >>          /* Translate the exclusive fence to the READ *and* WRITE engine */
> >> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
> >>                  args->busy |= busy_check_reader(fence);
> >>          }
> >>
> >> +       smp_rmb();
> >> +       if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
> >> +               goto retry;
> >> +
> >>
> >> wrap that up as
> >>
> >> static inline bool
> >> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
> >> {
> >>          smp_rmb();
> >>          return excl != rcu_access_pointer(resv->fence_excl);
> >> }
> > I give up. It's not just the fence_excl that's an issue here.
> >
> > Any of the shared fences may be replaced after dma_resv_fences()
> > and so the original shared fence pointer may be reassigned (even under
> > RCU).
> 
> Yeah, but this should be harmless. See fences are always replaced either 
> when they are signaled anyway or by later fences from the same context.
> 
> And existing fences shouldn't be re-used while under RCU, or is anybody 
> still using SLAB_TYPESAFE_BY_RCU?

Yes. We go through enough fences that the freelist is a noticeable
improvement.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2019-08-14 18:52 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-07 13:53 [PATCH 1/4] dma-buf: add reservation_object_fences helper Christian König
2019-08-07 13:53 ` [PATCH 2/4] drm/i915: use new " Christian König
2019-08-07 16:08   ` Chris Wilson
2019-08-07 13:53 ` [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence Christian König
2019-08-07 16:10   ` Chris Wilson
2019-08-07 13:53 ` [PATCH 4/4] dma-buf: nuke reservation_object seq number Christian König
2019-08-07 14:17   ` Chris Wilson
2019-08-10 10:51     ` Christian König
2019-08-14 15:39       ` Daniel Vetter
2019-08-14 16:42         ` Chris Wilson
2019-08-14 17:06           ` Chris Wilson
2019-08-14 17:22             ` Chris Wilson
2019-08-14 17:38               ` Chris Wilson
2019-08-14 17:48                 ` Chris Wilson
2019-08-14 17:58                   ` Koenig, Christian
2019-08-14 18:52                     ` Chris Wilson
2019-08-14 17:06           ` Daniel Vetter
2019-08-14 17:20             ` Chris Wilson
2019-08-14 17:48               ` Daniel Vetter
2019-08-07 16:07 ` [PATCH 1/4] dma-buf: add reservation_object_fences helper Chris Wilson
2019-08-09 13:07 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] " Patchwork
2019-08-09 13:31 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-10  6:31 ` ✓ Fi.CI.IGT: " Patchwork

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.