mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Rob Clark" <robdclark@gmail.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: dri-devel@lists.freedesktop.org,
	Rob Clark <robdclark@chromium.org>,
	Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Gustavo Padovan <gustavo@padovan.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	"open list:SYNC FILE FRAMEWORK" <linux-media@vger.kernel.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK" 
	<linaro-mm-sig@lists.linaro.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH v2] dma-buf/sw_sync: Avoid recursive lock during fence signal
Date: Mon, 28 Aug 2023 07:56:45 +0200	[thread overview]
Message-ID: <7cc6172e-b068-341c-f4b0-e6a8d1b968e7@amd.com> (raw)
In-Reply-To: <CAF6AEGs+6cveKbv=onEJSZJERk8m56YJzza6A2+eLd3+6MuWMg@mail.gmail.com>

Am 22.08.23 um 19:15 schrieb Rob Clark:
> On Tue, Aug 22, 2023 at 6:01 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Am 18.08.23 um 16:59 schrieb Rob Clark:
>>> From: Rob Clark <robdclark@chromium.org>
>>>
>>> If a signal callback releases the sw_sync fence, that will trigger a
>>> deadlock as the timeline_fence_release recurses onto the fence->lock
>>> (used both for signaling and the the timeline tree).
>>>
>>> To avoid that, temporarily hold an extra reference to the signalled
>>> fences until after we drop the lock.
>>>
>>> (This is an alternative implementation of https://patchwork.kernel.org/patch/11664717/
>>> which avoids some potential UAF issues with the original patch.)
>>>
>>> v2: Remove now obsolete comment, use list_move_tail() and
>>>       list_del_init()
>>>
>>> Reported-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
>>> Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
>>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
> Thanks, any chance you could take this via drm-misc?

I've already pushed this quite a while ago.

At the moment I have problem answering because AMD has a new security 
policy which makes it impossible to push patches and access mails at the 
same time.

We are working with our IT to get this fixed, but at the moment its 
eating my time.

Sorry for the delay,
Christian.

>
> BR,
> -R
>
>>> ---
>>>    drivers/dma-buf/sw_sync.c | 18 +++++++++---------
>>>    1 file changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
>>> index 63f0aeb66db6..f0a35277fd84 100644
>>> --- a/drivers/dma-buf/sw_sync.c
>>> +++ b/drivers/dma-buf/sw_sync.c
>>> @@ -191,6 +191,7 @@ static const struct dma_fence_ops timeline_fence_ops = {
>>>     */
>>>    static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
>>>    {
>>> +     LIST_HEAD(signalled);
>>>        struct sync_pt *pt, *next;
>>>
>>>        trace_sync_timeline(obj);
>>> @@ -203,21 +204,20 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
>>>                if (!timeline_fence_signaled(&pt->base))
>>>                        break;
>>>
>>> -             list_del_init(&pt->link);
>>> +             dma_fence_get(&pt->base);
>>> +
>>> +             list_move_tail(&pt->link, &signalled);
>>>                rb_erase(&pt->node, &obj->pt_tree);
>>>
>>> -             /*
>>> -              * A signal callback may release the last reference to this
>>> -              * fence, causing it to be freed. That operation has to be
>>> -              * last to avoid a use after free inside this loop, and must
>>> -              * be after we remove the fence from the timeline in order to
>>> -              * prevent deadlocking on timeline->lock inside
>>> -              * timeline_fence_release().
>>> -              */
>>>                dma_fence_signal_locked(&pt->base);
>>>        }
>>>
>>>        spin_unlock_irq(&obj->lock);
>>> +
>>> +     list_for_each_entry_safe(pt, next, &signalled, link) {
>>> +             list_del_init(&pt->link);
>>> +             dma_fence_put(&pt->base);
>>> +     }
>>>    }
>>>
>>>    /**


      reply	other threads:[~2023-08-28  5:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-18 14:59 Rob Clark
2023-08-22 13:01 ` [Linaro-mm-sig] " Christian König
2023-08-22 17:15   ` Rob Clark
2023-08-28  5:56     ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cc6172e-b068-341c-f4b0-e6a8d1b968e7@amd.com \
    --to=christian.koenig@amd.com \
    --cc=bas@basnieuwenhuizen.nl \
    --cc=chris@chris-wilson.co.uk \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®