Re: [PATCH 2/2] drm/syncobj: flatten chains when importing sync_file into timeline point

[Christian König]

On 10/12/26 13:42, Julian Orth wrote:
> On Mon, Oct 12, 2026 at 9:51 AM Christian König
> <christian.koenig@xxxxxxx> wrote:
>>
>> On 10/10/26 20:07, Julian Orth wrote:
>>> A sync_file exported from a timeline point can contain a dma_fence_chain.
>>
>> No it can't, IIRC sync files are only supposed to contain raw fences or dma_fence_array containers.
>>
>> I think we never documented that and that's why this issue here leaked in.
> 
> When I reviewed this patch before sending it in, I asked the AI if it
> would not be better to do the merging at export time. It was adamant
> that it had to be at import time because of commit 519f490d by
> yourself:
> 
>     dma-buf/sync-file: fix warning about fence containers
> 
>     The dma_fence_chain containers can show up in sync_files as well

Yeah that fix was driven by the warning but it was never a complete audit.

IIRC we later found multiple other issues as well and because of that the approach of exporting dma_fence_chain in syncfiles was dropped for at least one other occasion.

I don't mind allowing a dma_fence_chain in a syncfile, but we really need to audit the code because I can't think of a way how to do this automatically.

Mixing dma_fence_chain and dma_fence_array containers into larger data structures can trivially exhaust the kernel stack on release/cleanup because of recursion.

Regards,
Christian.

> 
>>
>> I'm not sure if that doesn't break anywhere else as well, so I think we should fix the exporting side instead.
>>
>> Alternatively we need to audit everywhere where fences from syncfiles can be imported somewhere else.
>>
>> Regards,
>> Christian.
>>
>>> Importing such a sync_file into a timeline point with
>>> DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE |
>>> DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE passes the chain directly to
>>> dma_fence_chain_init() and triggers
>>>
>>>   WARNING: drivers/dma-buf/dma-fence-chain.c:286 at dma_fence_chain_init
>>>
>>> because chain fences must not be wrapped in other chain fences.
>>>
>>> Flatten the fence with dma_fence_unwrap_merge() before adding it to the
>>> timeline, as drm_syncobj_transfer_to_timeline() already does.
>>>
>>> Reproducer:
>>>
>>> 1. Export a sync_file from a point > 0 of a timeline syncobj with
>>>    DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD.
>>> 2. Import it into a point > 0 of another timeline syncobj with
>>>    DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE.
>>>
>>> Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs")
>>> Assisted-by: Claude:claude-opus-5-5
>>> Signed-off-by: Julian Orth <ju.orth@xxxxxxxxx>
>>> ---
>>>  drivers/gpu/drm/drm_syncobj.c | 12 +++++++++++-
>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>>> index 5ca5163d0..c545af77e 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -742,8 +742,18 @@ static int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
>>>       }
>>>
>>>       if (point) {
>>> -             struct dma_fence_chain *chain = dma_fence_chain_alloc();
>>> +             struct dma_fence_chain *chain;
>>> +             struct dma_fence *tmp;
>>> +
>>> +             tmp = dma_fence_unwrap_merge(fence);
>>> +             dma_fence_put(fence);
>>> +             fence = tmp;
>>> +             if (!fence) {
>>> +                     drm_syncobj_put(syncobj);
>>> +                     return -ENOMEM;
>>> +             }
>>>
>>> +             chain = dma_fence_chain_alloc();
>>>               if (!chain) {
>>>                       ret = -ENOMEM;
>>>                       goto out;
>>