Skip to contentSkip to conversation

dma-buf: fix debugfs versus rcu and fence dumping v2

PATCH In review [email protected] 4 participants 4 messages Dec 6, 2018 – Dec 7, 2018

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 dma-buf: fix debugfs versus rcu and fence dumping v2

From: Jérôme Glisse <[email protected]>

The debugfs take reference on fence without dropping them. Also the rcu section are not well balance. Fix all that ...

Changed since v1:
- moved fobj logic around to be rcu safe

---
 drivers/dma-buf/dma-buf.c | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)
drivers/dma-buf/dma-buf.c +16 -5
index 13884474d158..9688d99894d6 100644
@@ -1048,27 +1048,38 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
 		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);
+			fence = dma_fence_get_rcu(fence);
 			if (!read_seqcount_retry(&robj->seq, seq))
 				break;
 			rcu_read_unlock();
 		}
-
-		if (fence)
+		if (fence) {
 			seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
 				   fence->ops->get_driver_name(fence),
 				   fence->ops->get_timeline_name(fence),
 				   dma_fence_is_signaled(fence) ? "" : "un");
-		for (i = 0; i < shared_count; i++) {
+			dma_fence_put(fence);
+		}
+
+		rcu_read_lock();
+		fobj = rcu_dereference(robj->fence);
+		shared_count = fobj ? fobj->shared_count : 0;
+		for (i = 0, fence = NULL; i < shared_count; i++) {
 			fence = rcu_dereference(fobj->shared[i]);
 			if (!dma_fence_get_rcu(fence))
 				continue;
+			rcu_read_unlock();
+
 			seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
 				   fence->ops->get_driver_name(fence),
 				   fence->ops->get_timeline_name(fence),
 				   dma_fence_is_signaled(fence) ? "" : "un");
+			dma_fence_put(fence);
+
+			rcu_read_lock();
+			fobj = rcu_dereference(robj->fence);
+			shared_count = fobj ? fobj->shared_count : 0;
 		}
 		rcu_read_unlock();
 
Signature · 6 lines
2.17.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
#1 lore raw

Quoting [email protected] (2018-12-06 15:47:04)

Quoted 4 lines

From: Jérôme Glisse <[email protected]>

The debugfs take reference on fence without dropping them. Also the rcu section are not well balance. Fix all that ...

Wouldn't the code be a lot simpler (and a consistent snapshot) if it used reservation_object_get_fences_rcu()?
-Chris

#2 lore raw

Am 06.12.18 um 17:58 schrieb Chris Wilson:

Quoted 7 lines

Quoting [email protected] (2018-12-06 15:47:04)

Quoted 4 lines

From: Jérôme Glisse <[email protected]>

The debugfs take reference on fence without dropping them. Also the rcu section are not well balance. Fix all that ...

Wouldn't the code be a lot simpler (and a consistent snapshot) if it used reservation_object_get_fences_rcu()?

Yeah, thought about that as well.

Or even better move that code into reservation_object.c as reservation_object_show_fences() or something like that.

Christian.

Quoted 1 line

-Chris

maintainer
#3 lore raw
In reply to [email protected]

Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.19.7, v4.14.86, v4.9.143, v4.4.166, v3.18.128,

v4.19.7: Build OK!
v4.14.86: Build OK!
v4.9.143: Failed to apply! Possible dependencies:

    5eb2c72c8acc ("dma-buf: fence debugging")

v4.4.166: Failed to apply! Possible dependencies:

    5eb2c72c8acc ("dma-buf: fence debugging")

v3.18.128: Failed to apply! Possible dependencies:

    5eb2c72c8acc ("dma-buf: fence debugging")

How should we proceed with this patch?

--
Thanks,
Sasha
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel