dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] dma-buf: fix and rework dma_buf_poll v7
@ 2021-07-20 13:11 Christian König
  2021-07-23  8:04 ` Michel Dänzer
  0 siblings, 1 reply; 8+ messages in thread
From: Christian König @ 2021-07-20 13:11 UTC (permalink / raw)
  To: michel, daniel.vetter; +Cc: dri-devel

Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.

First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.

Then we should always also wait for the exclusive fence.

It's also good practice to keep the reference around when installing callbacks
to fences you don't own.

And last the whole implementation was unnecessary complex and rather hard to
understand which could lead to probably unexpected behavior of the IOCTL.

Fix all this by reworking the implementation from scratch. Dropping the
whole RCU approach and taking the lock instead.

Only mildly tested and needs a thoughtful review of the code.

v2: fix the reference counting as well
v3: keep the excl fence handling as is for stable
v4: back to testing all fences, drop RCU
v5: handle in and out separately
v6: add missing clear of events
v7: change coding style as suggested by Michel, drop unused variables

Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 152 ++++++++++++++++++--------------------
 include/linux/dma-buf.h   |   2 +-
 2 files changed, 71 insertions(+), 83 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 511fe0d217a0..6c520c9bd93c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -72,7 +72,7 @@ static void dma_buf_release(struct dentry *dentry)
 	 * If you hit this BUG() it means someone dropped their ref to the
 	 * dma-buf while still having pending operation to the buffer.
 	 */
-	BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
+	BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
 
 	dmabuf->ops->release(dmabuf);
 
@@ -202,16 +202,55 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
 	wake_up_locked_poll(dcb->poll, dcb->active);
 	dcb->active = 0;
 	spin_unlock_irqrestore(&dcb->poll->lock, flags);
+	dma_fence_put(fence);
+}
+
+static bool dma_buf_poll_shared(struct dma_resv *resv,
+				struct dma_buf_poll_cb_t *dcb)
+{
+	struct dma_resv_list *fobj = dma_resv_shared_list(resv);
+	struct dma_fence *fence;
+	int i, r;
+
+	if (!fobj)
+		return false;
+
+	for (i = 0; i < fobj->shared_count; ++i) {
+		fence = rcu_dereference_protected(fobj->shared[i],
+						  dma_resv_held(resv));
+		dma_fence_get(fence);
+		r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb);
+		if (!r)
+			return true;
+		dma_fence_put(fence);
+	}
+
+	return false;
+}
+
+static bool dma_buf_poll_excl(struct dma_resv *resv,
+			      struct dma_buf_poll_cb_t *dcb)
+{
+	struct dma_fence *fence = dma_resv_excl_fence(resv);
+	int r;
+
+	if (!fence)
+		return false;
+
+	dma_fence_get(fence);
+	r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb);
+	if (!r)
+		return true;
+	dma_fence_put(fence);
+
+	return false;
 }
 
 static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
 {
 	struct dma_buf *dmabuf;
 	struct dma_resv *resv;
-	struct dma_resv_list *fobj;
-	struct dma_fence *fence_excl;
 	__poll_t events;
-	unsigned shared_count, seq;
 
 	dmabuf = file->private_data;
 	if (!dmabuf || !dmabuf->resv)
@@ -225,101 +264,50 @@ 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 = dma_resv_excl_fence(resv);
-	if (read_seqcount_retry(&resv->seq, seq)) {
-		rcu_read_unlock();
-		goto retry;
-	}
-
-	if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
-		struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
-		__poll_t pevents = EPOLLIN;
+	dma_resv_lock(resv, NULL);
 
-		if (shared_count == 0)
-			pevents |= EPOLLOUT;
+	if (events & EPOLLOUT) {
+		struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_out;
 
+		/* Check that callback isn't busy */
 		spin_lock_irq(&dmabuf->poll.lock);
-		if (dcb->active) {
-			dcb->active |= pevents;
-			events &= ~pevents;
-		} else
-			dcb->active = pevents;
+		if (dcb->active)
+			events &= ~EPOLLOUT;
+		else
+			dcb->active = EPOLLOUT;
 		spin_unlock_irq(&dmabuf->poll.lock);
 
-		if (events & pevents) {
-			if (!dma_fence_get_rcu(fence_excl)) {
-				/* force a recheck */
-				events &= ~pevents;
-				dma_buf_poll_cb(NULL, &dcb->cb);
-			} else if (!dma_fence_add_callback(fence_excl, &dcb->cb,
-							   dma_buf_poll_cb)) {
-				events &= ~pevents;
-				dma_fence_put(fence_excl);
-			} else {
-				/*
-				 * No callback queued, wake up any additional
-				 * waiters.
-				 */
-				dma_fence_put(fence_excl);
+		if (events & EPOLLOUT) {
+			if (!dma_buf_poll_shared(resv, dcb) &&
+			    !dma_buf_poll_excl(resv, dcb))
+				/* No callback queued, wake up any other waiters */
 				dma_buf_poll_cb(NULL, &dcb->cb);
-			}
+			else
+				events &= ~EPOLLOUT;
 		}
 	}
 
-	if ((events & EPOLLOUT) && shared_count > 0) {
-		struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared;
-		int i;
+	if (events & EPOLLIN) {
+		struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_in;
 
-		/* Only queue a new callback if no event has fired yet */
+		/* Check that callback isn't busy */
 		spin_lock_irq(&dmabuf->poll.lock);
 		if (dcb->active)
-			events &= ~EPOLLOUT;
+			events &= ~EPOLLIN;
 		else
-			dcb->active = EPOLLOUT;
+			dcb->active = EPOLLIN;
 		spin_unlock_irq(&dmabuf->poll.lock);
 
-		if (!(events & EPOLLOUT))
-			goto out;
-
-		for (i = 0; i < shared_count; ++i) {
-			struct dma_fence *fence = rcu_dereference(fobj->shared[i]);
-
-			if (!dma_fence_get_rcu(fence)) {
-				/*
-				 * fence refcount dropped to zero, this means
-				 * that fobj has been freed
-				 *
-				 * call dma_buf_poll_cb and force a recheck!
-				 */
-				events &= ~EPOLLOUT;
+		if (events & EPOLLIN) {
+			if (!dma_buf_poll_excl(resv, dcb))
+				/* No callback queued, wake up any other waiters */
 				dma_buf_poll_cb(NULL, &dcb->cb);
-				break;
-			}
-			if (!dma_fence_add_callback(fence, &dcb->cb,
-						    dma_buf_poll_cb)) {
-				dma_fence_put(fence);
-				events &= ~EPOLLOUT;
-				break;
-			}
-			dma_fence_put(fence);
+			else
+				events &= ~EPOLLIN;
 		}
-
-		/* No callback queued, wake up any additional waiters. */
-		if (i == shared_count)
-			dma_buf_poll_cb(NULL, &dcb->cb);
 	}
 
-out:
-	rcu_read_unlock();
+	dma_resv_unlock(resv);
 	return events;
 }
 
@@ -562,8 +550,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
 	dmabuf->owner = exp_info->owner;
 	spin_lock_init(&dmabuf->name_lock);
 	init_waitqueue_head(&dmabuf->poll);
-	dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
-	dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
+	dmabuf->cb_in.poll = dmabuf->cb_out.poll = &dmabuf->poll;
+	dmabuf->cb_in.active = dmabuf->cb_out.active = 0;
 
 	if (!resv) {
 		resv = (struct dma_resv *)&dmabuf[1];
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index efdc56b9d95f..7e747ad54c81 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -329,7 +329,7 @@ struct dma_buf {
 		wait_queue_head_t *poll;
 
 		__poll_t active;
-	} cb_excl, cb_shared;
+	} cb_in, cb_out;
 };
 
 /**
-- 
2.25.1


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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-07-20 13:11 [PATCH] dma-buf: fix and rework dma_buf_poll v7 Christian König
@ 2021-07-23  8:04 ` Michel Dänzer
  2021-09-22 11:08   ` Christian König
  0 siblings, 1 reply; 8+ messages in thread
From: Michel Dänzer @ 2021-07-23  8:04 UTC (permalink / raw)
  To: Christian König; +Cc: daniel.vetter, dri-devel

On 2021-07-20 3:11 p.m., Christian König wrote:
> Daniel pointed me towards this function and there are multiple obvious problems
> in the implementation.
> 
> First of all the retry loop is not working as intended. In general the retry
> makes only sense if you grab the reference first and then check the sequence
> values.
> 
> Then we should always also wait for the exclusive fence.
> 
> It's also good practice to keep the reference around when installing callbacks
> to fences you don't own.
> 
> And last the whole implementation was unnecessary complex and rather hard to
> understand which could lead to probably unexpected behavior of the IOCTL.
> 
> Fix all this by reworking the implementation from scratch. Dropping the
> whole RCU approach and taking the lock instead.
> 
> Only mildly tested and needs a thoughtful review of the code.
> 
> v2: fix the reference counting as well
> v3: keep the excl fence handling as is for stable
> v4: back to testing all fences, drop RCU
> v5: handle in and out separately
> v6: add missing clear of events
> v7: change coding style as suggested by Michel, drop unused variables
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> CC: stable@vger.kernel.org

Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880

Tested-by: Michel Dänzer <mdaenzer@redhat.com>


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer

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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-07-23  8:04 ` Michel Dänzer
@ 2021-09-22 11:08   ` Christian König
  2021-09-30  9:00     ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: Christian König @ 2021-09-22 11:08 UTC (permalink / raw)
  To: daniel.vetter; +Cc: dri-devel, Michel Dänzer

Totally forgotten to ping once more about that.

Michel has tested this now and I think we should push it ASAP. So can I 
get an rb?

Thanks,
Christian.

Am 23.07.21 um 10:04 schrieb Michel Dänzer:
> On 2021-07-20 3:11 p.m., Christian König wrote:
>> Daniel pointed me towards this function and there are multiple obvious problems
>> in the implementation.
>>
>> First of all the retry loop is not working as intended. In general the retry
>> makes only sense if you grab the reference first and then check the sequence
>> values.
>>
>> Then we should always also wait for the exclusive fence.
>>
>> It's also good practice to keep the reference around when installing callbacks
>> to fences you don't own.
>>
>> And last the whole implementation was unnecessary complex and rather hard to
>> understand which could lead to probably unexpected behavior of the IOCTL.
>>
>> Fix all this by reworking the implementation from scratch. Dropping the
>> whole RCU approach and taking the lock instead.
>>
>> Only mildly tested and needs a thoughtful review of the code.
>>
>> v2: fix the reference counting as well
>> v3: keep the excl fence handling as is for stable
>> v4: back to testing all fences, drop RCU
>> v5: handle in and out separately
>> v6: add missing clear of events
>> v7: change coding style as suggested by Michel, drop unused variables
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> CC: stable@vger.kernel.org
> Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
>
> Tested-by: Michel Dänzer <mdaenzer@redhat.com>
>
>


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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-09-22 11:08   ` Christian König
@ 2021-09-30  9:00     ` Daniel Vetter
  2021-09-30  9:48       ` Christian König
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Vetter @ 2021-09-30  9:00 UTC (permalink / raw)
  To: Christian König; +Cc: daniel.vetter, dri-devel, Michel Dänzer

On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote:
> Totally forgotten to ping once more about that.
> 
> Michel has tested this now and I think we should push it ASAP. So can I get
> an rb?

		spin_lock_irq(&dmabuf->poll.lock);
		if (dcb->active)
			events &= ~EPOLLIN;
		else
			dcb->active = EPOLLIN;
		spin_unlock_irq(&dmabuf->poll.lock);


This pattern (and same for EPOLLOUT) makes no sense to me. I guess the
intent is that this filters out events for which we're already listening,
but:

- it checks for any active event, not the specific one
- if we're waiting already and new fences have been added, wont we miss
  them?

Or does this all work because the poll machinery restarts everything
again?

I'm totally confused here for sure. The other changes in the patch look
good though.
-Daniel

> 
> Thanks,
> Christian.
> 
> Am 23.07.21 um 10:04 schrieb Michel Dänzer:
> > On 2021-07-20 3:11 p.m., Christian König wrote:
> > > Daniel pointed me towards this function and there are multiple obvious problems
> > > in the implementation.
> > > 
> > > First of all the retry loop is not working as intended. In general the retry
> > > makes only sense if you grab the reference first and then check the sequence
> > > values.
> > > 
> > > Then we should always also wait for the exclusive fence.
> > > 
> > > It's also good practice to keep the reference around when installing callbacks
> > > to fences you don't own.
> > > 
> > > And last the whole implementation was unnecessary complex and rather hard to
> > > understand which could lead to probably unexpected behavior of the IOCTL.
> > > 
> > > Fix all this by reworking the implementation from scratch. Dropping the
> > > whole RCU approach and taking the lock instead.
> > > 
> > > Only mildly tested and needs a thoughtful review of the code.
> > > 
> > > v2: fix the reference counting as well
> > > v3: keep the excl fence handling as is for stable
> > > v4: back to testing all fences, drop RCU
> > > v5: handle in and out separately
> > > v6: add missing clear of events
> > > v7: change coding style as suggested by Michel, drop unused variables
> > > 
> > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > CC: stable@vger.kernel.org
> > Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
> > 
> > Tested-by: Michel Dänzer <mdaenzer@redhat.com>
> > 
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-09-30  9:00     ` Daniel Vetter
@ 2021-09-30  9:48       ` Christian König
  2021-09-30 10:26         ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: Christian König @ 2021-09-30  9:48 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: daniel.vetter, dri-devel, Michel Dänzer



Am 30.09.21 um 11:00 schrieb Daniel Vetter:
> On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote:
>> Totally forgotten to ping once more about that.
>>
>> Michel has tested this now and I think we should push it ASAP. So can I get
>> an rb?
> 		spin_lock_irq(&dmabuf->poll.lock);
> 		if (dcb->active)
> 			events &= ~EPOLLIN;
> 		else
> 			dcb->active = EPOLLIN;
> 		spin_unlock_irq(&dmabuf->poll.lock);
>
>
> This pattern (and same for EPOLLOUT) makes no sense to me. I guess the
> intent is that this filters out events for which we're already listening,
> but:
>
> - it checks for any active event, not the specific one

Which is correct. We now use one dcb for EPOLLIN and another one for 
EPOLLOUT.

We could make that a boolean instead if that makes it cleaner.

> - if we're waiting already and new fences have been added, wont we miss
>    them?

No, when we are already waiting the callback will sooner or later fire 
and result in a re-check.

> Or does this all work because the poll machinery restarts everything
> again?

Yes, exactly that. Otherwise waiting for multiple fences wouldn't work 
either.

Regards,
Christian.

>
> I'm totally confused here for sure. The other changes in the patch look
> good though.
> -Daniel
>
>> Thanks,
>> Christian.
>>
>> Am 23.07.21 um 10:04 schrieb Michel Dänzer:
>>> On 2021-07-20 3:11 p.m., Christian König wrote:
>>>> Daniel pointed me towards this function and there are multiple obvious problems
>>>> in the implementation.
>>>>
>>>> First of all the retry loop is not working as intended. In general the retry
>>>> makes only sense if you grab the reference first and then check the sequence
>>>> values.
>>>>
>>>> Then we should always also wait for the exclusive fence.
>>>>
>>>> It's also good practice to keep the reference around when installing callbacks
>>>> to fences you don't own.
>>>>
>>>> And last the whole implementation was unnecessary complex and rather hard to
>>>> understand which could lead to probably unexpected behavior of the IOCTL.
>>>>
>>>> Fix all this by reworking the implementation from scratch. Dropping the
>>>> whole RCU approach and taking the lock instead.
>>>>
>>>> Only mildly tested and needs a thoughtful review of the code.
>>>>
>>>> v2: fix the reference counting as well
>>>> v3: keep the excl fence handling as is for stable
>>>> v4: back to testing all fences, drop RCU
>>>> v5: handle in and out separately
>>>> v6: add missing clear of events
>>>> v7: change coding style as suggested by Michel, drop unused variables
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>> CC: stable@vger.kernel.org
>>> Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
>>>
>>> Tested-by: Michel Dänzer <mdaenzer@redhat.com>
>>>
>>>


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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-09-30  9:48       ` Christian König
@ 2021-09-30 10:26         ` Daniel Vetter
  2021-09-30 11:32           ` Christian König
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Vetter @ 2021-09-30 10:26 UTC (permalink / raw)
  To: Christian König
  Cc: Daniel Vetter, daniel.vetter, dri-devel, Michel Dänzer

On Thu, Sep 30, 2021 at 11:48:42AM +0200, Christian König wrote:
> 
> 
> Am 30.09.21 um 11:00 schrieb Daniel Vetter:
> > On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote:
> > > Totally forgotten to ping once more about that.
> > > 
> > > Michel has tested this now and I think we should push it ASAP. So can I get
> > > an rb?
> > 		spin_lock_irq(&dmabuf->poll.lock);
> > 		if (dcb->active)
> > 			events &= ~EPOLLIN;
> > 		else
> > 			dcb->active = EPOLLIN;
> > 		spin_unlock_irq(&dmabuf->poll.lock);
> > 
> > 
> > This pattern (and same for EPOLLOUT) makes no sense to me. I guess the
> > intent is that this filters out events for which we're already listening,
> > but:
> > 
> > - it checks for any active event, not the specific one
> 
> Which is correct. We now use one dcb for EPOLLIN and another one for
> EPOLLOUT.
> 
> We could make that a boolean instead if that makes it cleaner.

Ha yes I missed that. Boolean sounds much better.
> 
> > - if we're waiting already and new fences have been added, wont we miss
> >    them?
> 
> No, when we are already waiting the callback will sooner or later fire and
> result in a re-check.
> 
> > Or does this all work because the poll machinery restarts everything
> > again?
> 
> Yes, exactly that. Otherwise waiting for multiple fences wouldn't work
> either.

Ok with that clarified can you cut a v8 with booleans and I whack an r-b
on that? Or just include it, I'm massively burried here and trying to dig
out :-/

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (with the booleans)

-Daniel
> 
> Regards,
> Christian.
> 
> > 
> > I'm totally confused here for sure. The other changes in the patch look
> > good though.
> > -Daniel
> > 
> > > Thanks,
> > > Christian.
> > > 
> > > Am 23.07.21 um 10:04 schrieb Michel Dänzer:
> > > > On 2021-07-20 3:11 p.m., Christian König wrote:
> > > > > Daniel pointed me towards this function and there are multiple obvious problems
> > > > > in the implementation.
> > > > > 
> > > > > First of all the retry loop is not working as intended. In general the retry
> > > > > makes only sense if you grab the reference first and then check the sequence
> > > > > values.
> > > > > 
> > > > > Then we should always also wait for the exclusive fence.
> > > > > 
> > > > > It's also good practice to keep the reference around when installing callbacks
> > > > > to fences you don't own.
> > > > > 
> > > > > And last the whole implementation was unnecessary complex and rather hard to
> > > > > understand which could lead to probably unexpected behavior of the IOCTL.
> > > > > 
> > > > > Fix all this by reworking the implementation from scratch. Dropping the
> > > > > whole RCU approach and taking the lock instead.
> > > > > 
> > > > > Only mildly tested and needs a thoughtful review of the code.
> > > > > 
> > > > > v2: fix the reference counting as well
> > > > > v3: keep the excl fence handling as is for stable
> > > > > v4: back to testing all fences, drop RCU
> > > > > v5: handle in and out separately
> > > > > v6: add missing clear of events
> > > > > v7: change coding style as suggested by Michel, drop unused variables
> > > > > 
> > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > CC: stable@vger.kernel.org
> > > > Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
> > > > 
> > > > Tested-by: Michel Dänzer <mdaenzer@redhat.com>
> > > > 
> > > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-09-30 10:26         ` Daniel Vetter
@ 2021-09-30 11:32           ` Christian König
  2021-09-30 14:13             ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: Christian König @ 2021-09-30 11:32 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: daniel.vetter, dri-devel, Michel Dänzer

Am 30.09.21 um 12:26 schrieb Daniel Vetter:
> On Thu, Sep 30, 2021 at 11:48:42AM +0200, Christian König wrote:
>>
>> Am 30.09.21 um 11:00 schrieb Daniel Vetter:
>>> On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote:
>>>> Totally forgotten to ping once more about that.
>>>>
>>>> Michel has tested this now and I think we should push it ASAP. So can I get
>>>> an rb?
>>> 		spin_lock_irq(&dmabuf->poll.lock);
>>> 		if (dcb->active)
>>> 			events &= ~EPOLLIN;
>>> 		else
>>> 			dcb->active = EPOLLIN;
>>> 		spin_unlock_irq(&dmabuf->poll.lock);
>>>
>>>
>>> This pattern (and same for EPOLLOUT) makes no sense to me. I guess the
>>> intent is that this filters out events for which we're already listening,
>>> but:
>>>
>>> - it checks for any active event, not the specific one
>> Which is correct. We now use one dcb for EPOLLIN and another one for
>> EPOLLOUT.
>>
>> We could make that a boolean instead if that makes it cleaner.
> Ha yes I missed that. Boolean sounds much better.
>>> - if we're waiting already and new fences have been added, wont we miss
>>>     them?
>> No, when we are already waiting the callback will sooner or later fire and
>> result in a re-check.
>>
>>> Or does this all work because the poll machinery restarts everything
>>> again?
>> Yes, exactly that. Otherwise waiting for multiple fences wouldn't work
>> either.
> Ok with that clarified can you cut a v8 with booleans and I whack an r-b
> on that? Or just include it, I'm massively burried here and trying to dig
> out :-/
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (with the booleans)

My bad, boolean won't work because we also use the flags for the call to 
"wake_up_locked_poll(dcb->poll, dcb->active);".

Anyway that doesn't really change anything on the logic and I inherited 
that handling from the existing code, just moved it around a bit.

Christian.

>
> -Daniel
>> Regards,
>> Christian.
>>
>>> I'm totally confused here for sure. The other changes in the patch look
>>> good though.
>>> -Daniel
>>>
>>>> Thanks,
>>>> Christian.
>>>>
>>>> Am 23.07.21 um 10:04 schrieb Michel Dänzer:
>>>>> On 2021-07-20 3:11 p.m., Christian König wrote:
>>>>>> Daniel pointed me towards this function and there are multiple obvious problems
>>>>>> in the implementation.
>>>>>>
>>>>>> First of all the retry loop is not working as intended. In general the retry
>>>>>> makes only sense if you grab the reference first and then check the sequence
>>>>>> values.
>>>>>>
>>>>>> Then we should always also wait for the exclusive fence.
>>>>>>
>>>>>> It's also good practice to keep the reference around when installing callbacks
>>>>>> to fences you don't own.
>>>>>>
>>>>>> And last the whole implementation was unnecessary complex and rather hard to
>>>>>> understand which could lead to probably unexpected behavior of the IOCTL.
>>>>>>
>>>>>> Fix all this by reworking the implementation from scratch. Dropping the
>>>>>> whole RCU approach and taking the lock instead.
>>>>>>
>>>>>> Only mildly tested and needs a thoughtful review of the code.
>>>>>>
>>>>>> v2: fix the reference counting as well
>>>>>> v3: keep the excl fence handling as is for stable
>>>>>> v4: back to testing all fences, drop RCU
>>>>>> v5: handle in and out separately
>>>>>> v6: add missing clear of events
>>>>>> v7: change coding style as suggested by Michel, drop unused variables
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> CC: stable@vger.kernel.org
>>>>> Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
>>>>>
>>>>> Tested-by: Michel Dänzer <mdaenzer@redhat.com>
>>>>>
>>>>>


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

* Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
  2021-09-30 11:32           ` Christian König
@ 2021-09-30 14:13             ` Daniel Vetter
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Vetter @ 2021-09-30 14:13 UTC (permalink / raw)
  To: Christian König
  Cc: Daniel Vetter, daniel.vetter, dri-devel, Michel Dänzer

On Thu, Sep 30, 2021 at 01:32:28PM +0200, Christian König wrote:
> Am 30.09.21 um 12:26 schrieb Daniel Vetter:
> > On Thu, Sep 30, 2021 at 11:48:42AM +0200, Christian König wrote:
> > > 
> > > Am 30.09.21 um 11:00 schrieb Daniel Vetter:
> > > > On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote:
> > > > > Totally forgotten to ping once more about that.
> > > > > 
> > > > > Michel has tested this now and I think we should push it ASAP. So can I get
> > > > > an rb?
> > > > 		spin_lock_irq(&dmabuf->poll.lock);
> > > > 		if (dcb->active)
> > > > 			events &= ~EPOLLIN;
> > > > 		else
> > > > 			dcb->active = EPOLLIN;
> > > > 		spin_unlock_irq(&dmabuf->poll.lock);
> > > > 
> > > > 
> > > > This pattern (and same for EPOLLOUT) makes no sense to me. I guess the
> > > > intent is that this filters out events for which we're already listening,
> > > > but:
> > > > 
> > > > - it checks for any active event, not the specific one
> > > Which is correct. We now use one dcb for EPOLLIN and another one for
> > > EPOLLOUT.
> > > 
> > > We could make that a boolean instead if that makes it cleaner.
> > Ha yes I missed that. Boolean sounds much better.
> > > > - if we're waiting already and new fences have been added, wont we miss
> > > >     them?
> > > No, when we are already waiting the callback will sooner or later fire and
> > > result in a re-check.
> > > 
> > > > Or does this all work because the poll machinery restarts everything
> > > > again?
> > > Yes, exactly that. Otherwise waiting for multiple fences wouldn't work
> > > either.
> > Ok with that clarified can you cut a v8 with booleans and I whack an r-b
> > on that? Or just include it, I'm massively burried here and trying to dig
> > out :-/
> > 
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (with the booleans)
> 
> My bad, boolean won't work because we also use the flags for the call to
> "wake_up_locked_poll(dcb->poll, dcb->active);".
> 
> Anyway that doesn't really change anything on the logic and I inherited that
> handling from the existing code, just moved it around a bit.

Hm yeah. I guess

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

But this poll stuff just massively confuses me.
-Daniel

> 
> Christian.
> 
> > 
> > -Daniel
> > > Regards,
> > > Christian.
> > > 
> > > > I'm totally confused here for sure. The other changes in the patch look
> > > > good though.
> > > > -Daniel
> > > > 
> > > > > Thanks,
> > > > > Christian.
> > > > > 
> > > > > Am 23.07.21 um 10:04 schrieb Michel Dänzer:
> > > > > > On 2021-07-20 3:11 p.m., Christian König wrote:
> > > > > > > Daniel pointed me towards this function and there are multiple obvious problems
> > > > > > > in the implementation.
> > > > > > > 
> > > > > > > First of all the retry loop is not working as intended. In general the retry
> > > > > > > makes only sense if you grab the reference first and then check the sequence
> > > > > > > values.
> > > > > > > 
> > > > > > > Then we should always also wait for the exclusive fence.
> > > > > > > 
> > > > > > > It's also good practice to keep the reference around when installing callbacks
> > > > > > > to fences you don't own.
> > > > > > > 
> > > > > > > And last the whole implementation was unnecessary complex and rather hard to
> > > > > > > understand which could lead to probably unexpected behavior of the IOCTL.
> > > > > > > 
> > > > > > > Fix all this by reworking the implementation from scratch. Dropping the
> > > > > > > whole RCU approach and taking the lock instead.
> > > > > > > 
> > > > > > > Only mildly tested and needs a thoughtful review of the code.
> > > > > > > 
> > > > > > > v2: fix the reference counting as well
> > > > > > > v3: keep the excl fence handling as is for stable
> > > > > > > v4: back to testing all fences, drop RCU
> > > > > > > v5: handle in and out separately
> > > > > > > v6: add missing clear of events
> > > > > > > v7: change coding style as suggested by Michel, drop unused variables
> > > > > > > 
> > > > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > > > CC: stable@vger.kernel.org
> > > > > > Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
> > > > > > 
> > > > > > Tested-by: Michel Dänzer <mdaenzer@redhat.com>
> > > > > > 
> > > > > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

end of thread, other threads:[~2021-09-30 14:13 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-20 13:11 [PATCH] dma-buf: fix and rework dma_buf_poll v7 Christian König
2021-07-23  8:04 ` Michel Dänzer
2021-09-22 11:08   ` Christian König
2021-09-30  9:00     ` Daniel Vetter
2021-09-30  9:48       ` Christian König
2021-09-30 10:26         ` Daniel Vetter
2021-09-30 11:32           ` Christian König
2021-09-30 14:13             ` Daniel Vetter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).