On 10/12/26 13:42, Julian Orth wrote:
> On Mon, Oct 12, 2026 at 9:51 AM Christian König
> <[email protected]> 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 <[email protected]>
>>> ---
>>> 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;
>>
