linux-kernel - Re: [PATCH v2] drm/syncobj: Fix sync syncobj issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9aa8538b-d535-4de5-6e07-fd81d2b3db33@amd.com>
Date:   Wed, 13 Jul 2022 11:15:59 +0200
From:   Christian König <christian.koenig@....com>
To:     "Das, Nirmoy" <nirmoy.das@...ux.intel.com>,
        jie1zhan <jesse.zhang@....com>, broonie@...nel.org,
        dri-devel-bounces@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org
Cc:     Vijendar.Mukunda@....com, Basavaraj.Hiregoudar@....com,
        Sunil-kumar.Dommati@....com, ajitkumar.pandey@....com,
        lucas.demarchi@...el.com, lionel.g.landwerlin@...el.com,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm/syncobj: Fix sync syncobj issue

Am 13.07.22 um 10:42 schrieb Das, Nirmoy:
> Hi Christian,
>
> On 7/12/2022 12:26 PM, Christian König wrote:
>> Ping to the Intel guys here. Especially Lucas/Nirmoy/Lionel.
>>
>> IIRC you stumbled over that problem as well, have you found any 
>> solution?
>
> I might be wrong but  I think you are talking about 
> igt@...cobj_timeline@...nsfer-timeline-point testcase which seems to be
>
> green in CI now 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fintel-gfx-ci.01.org%2Ftree%2Fdrm-tip%2Figt%40syncobj_timeline%40transfer-timeline-point.html&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C722fc33842734ef5c05108da64abac60%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637932985747614383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=q8JygSVZfGA8cEZn%2BdxVXX79pkpXRjZTS8kBQ6Lq%2Bmw%3D&amp;reserved=0
>
> Lucas found out that the issues got fixed after ec8d985ff26f ("drm: 
> use dma_fence_unwrap_merge() in drm_syncobj")

Yeah, but that's just coincident. The original bug that we fail to 
enable signaling in the syncobj is still there.

No that this is any major problem, but it would still be nice to have 
that fixed.

Regards,
Christian.

>
>
> Regards,
>
> Nirmoy
>
>>
>> Regards,
>> Christian.
>>
>> Am 07.07.22 um 12:29 schrieb jie1zhan:
>>> enable signaling after flatten dma_fence_chains on transfer
>>>
>>> Signed-off-by: jie1zhan <jesse.zhang@....com>
>>> ---
>>>   drivers/gpu/drm/drm_syncobj.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c 
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index 7e48dcd1bee4..0d9d3577325f 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -920,6 +920,7 @@ static int 
>>> drm_syncobj_transfer_to_timeline(struct drm_file *file_private,
>>>       if (ret)
>>>           goto err_free_fence;
>>>   +    dma_fence_enable_sw_signaling(fence);
>>>       chain = dma_fence_chain_alloc();
>>>       if (!chain) {
>>>           ret = -ENOMEM;
>>