dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig@amd.com>
To: "Zhou, David(ChunMing)" <David1.Zhou@amd.com>"Zhou,
	David(ChunMing)" <David1.Zhou@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Cc: "Christian König" <easy2remember.chk@googlemail.com>,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Date: Fri, 26 Oct 2018 12:13:16 +0000	[thread overview]
Message-ID: <adeb8b1c-6976-eb83-0167-622e5d9b4dfa@amd.com> (raw)
In-Reply-To: <6ff5b159-3b51-25a4-4146-b81e279e6b2b@amd.com>

Am 26.10.18 um 10:28 schrieb zhoucm1:
> Thanks, Could you help to submit to drm-misc again?

Done.

Christian.

>
> -David
>
>
> On 2018年10月26日 15:43, Christian König wrote:
>> Am 26.10.18 um 08:20 schrieb Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function 
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock 
>>> on line 389 but uses GFP_KERNEL
>>>
>>>    Find functions that refer to GFP_KERNEL but are called with locks 
>>> held.
>>>
>>> Generated by: scripts/coccinelle/locks/call_kern.cocci
>>>
>>> v2:
>>> syncobj->timeline still needs protect.
>>>
>>> v3:
>>> use a global signaled fence instead of re-allocation.
>>>
>>> v4:
>>> Don't need moving lock.
>>> Don't expose func.
>>>
>>> v5:
>>> rename func and directly return.
>>>
>>> Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
>>> lock debug kernel options enabled.
>>>
>>> Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: intel-gfx@lists.freedesktop.org
>>> Cc: Christian König <easy2remember.chk@googlemail.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> CC: Julia Lawall <julia.lawall@lip6.fr>
>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>
>>> ---
>>>   drivers/gpu/drm/drm_syncobj.c | 36 
>>> ++++++++++++++++++-----------------
>>>   1 file changed, 19 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c 
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index b7eaa603f368..d1c6f21c72b5 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -80,6 +80,23 @@ struct drm_syncobj_signal_pt {
>>>       struct list_head list;
>>>   };
>>>   +static DEFINE_SPINLOCK(signaled_fence_lock);
>>> +static struct dma_fence signaled_fence;
>>> +
>>> +static struct dma_fence *drm_syncobj_get_stub_fence(void)
>>> +{
>>> +    spin_lock(&signaled_fence_lock);
>>> +    if (!signaled_fence.ops) {
>>> +        dma_fence_init(&signaled_fence,
>>> +                   &drm_syncobj_stub_fence_ops,
>>> +                   &signaled_fence_lock,
>>> +                   0, 0);
>>> +        dma_fence_signal_locked(&signaled_fence);
>>> +    }
>>> +    spin_unlock(&signaled_fence_lock);
>>> +
>>> +    return dma_fence_get(&signaled_fence);
>>> +}
>>>   /**
>>>    * drm_syncobj_find - lookup and reference a sync object.
>>>    * @file_private: drm file private pointer
>>> @@ -113,23 +130,8 @@ static struct dma_fence
>>>       struct drm_syncobj_signal_pt *signal_pt;
>>>         if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
>>> -        (point <= syncobj->timeline)) {
>>> -        struct drm_syncobj_stub_fence *fence =
>>> -            kzalloc(sizeof(struct drm_syncobj_stub_fence),
>>> -                GFP_KERNEL);
>>> -
>>> -        if (!fence)
>>> -            return NULL;
>>> -        spin_lock_init(&fence->lock);
>>> -        dma_fence_init(&fence->base,
>>> -                   &drm_syncobj_stub_fence_ops,
>>> -                   &fence->lock,
>>> -                   syncobj->timeline_context,
>>> -                   point);
>>> -
>>> -        dma_fence_signal(&fence->base);
>>> -        return &fence->base;
>>> -    }
>>> +        (point <= syncobj->timeline))
>>> +        return drm_syncobj_get_stub_fence();
>>>         list_for_each_entry(signal_pt, &syncobj->signal_pt_list, 
>>> list) {
>>>           if (point > signal_pt->value)
>>
>

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

  reply	other threads:[~2018-10-26 12:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26  6:20 [PATCH] drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock Chunming Zhou
2018-10-26  7:43 ` Christian König
2018-10-26  8:28   ` zhoucm1
2018-10-26 12:13     ` Koenig, Christian [this message]
2018-10-26 11:49 ` Maarten Lankhorst
  -- strict thread matches above, loose matches on Subject: below --
2018-10-25 15:08 Chunming Zhou
2018-10-25 16:31 ` Chris Wilson
2018-10-25 18:58 ` Christian König

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=adeb8b1c-6976-eb83-0167-622e5d9b4dfa@amd.com \
    --to=christian.koenig@amd.com \
    --cc=David1.Zhou@amd.com \
    --cc=easy2remember.chk@googlemail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=julia.lawall@lip6.fr \
    /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