Re: [RFC PATCH v3 0/3] Querying errors from drm_syncobj

[Yicong Hui <yiconghui@gmail.com>]

On 2/25/26 1:57 PM, Christian König wrote:
> On 2/25/26 14:37, Michel Dänzer wrote:
>> On 2/25/26 14:25, Christian König wrote:
>>> On 2/25/26 13:46, Yicong Hui wrote:
>>>> This patch series adds 2 new flags, DRM_SYNCOBJ_QUERY_FLAGS_ERROR and
>>>> DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR for 3 ioctl operations
>>>> DRM_IOCTL_SYNCOBJ_QUERY, DRM_IOCTL_SYNCOBJ_WAIT and
>>>> DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT to allow them to batch-request error
>>>> codes from multiple syncobjs and abort early upon error of any of them.
>>>
>>> Patch #1 looks good enough to add my rb.
>>>
>>> Patch #2 looks good as well, but I'm not familiar enough with the code and have no time to wrap my head around it to give a review.
>>>
>>> Adding a few people on CC, maybe somebody has time to take another look.
>>>
>>>>
>>>> Based on discussions from Michel Dänzer and Christian König, and a
>>>> starter task from the DRM todo documentation.
>>>>
>>>> See https://gitlab.gnome.org/GNOME/mutter/-/issues/4624 for discussions
>>>> on userspace implementation.
>>>>
>>>> I have looked into adding sub test cases into syncobj_wait.c and
>>>> syncobj_timeline.c, igt-tests for this and I think I understand the
>>>> process for writing tests and submitting them, however, these ioctls
>>>> only trigger in the case that there is an error, but I am not sure what
>>>> is the best way to artifically trigger an error from userspace in order
>>>> to test that these ioctl flags work. What's the recommended way to
>>>> approach this?
>>>
>>> When Michel agrees that this is the way to go then we either need an in-kernel selftest (see directory drivers/gpu/drm/tests/) or an userspace IGT test.
>>>
>>> Not sure what is more appropriate, maybe somebody on CC has more experience with that.
>>
>> I'd advise against landing this in the kernel before there's a corresponding display server implementation making use of it, in a mergeable state.
> 
> Yeah we clearly have the rule that this can't be pushed into the kernel without userspace code as well.
> 
>> Otherwise you might end up with the kernel having to support UAPI which no real-world user space actually uses. Been there, done that myself.
>>
>>
>> I don't have the capacity to contribute anything more than advice at this point.
> 
> Oh that is sad. Do you know anybody who could work on that?
> 
> It is a clear improvement to error handling and I don't like to keep Yicong's work only on the mailing list.
> 
> Thanks,
> Christian.
> 

Hello

Is there anything else I can do? Or will we have to just leave all of this here unmerged

I have read the emails from Tvrtko and Matthew and I'm absolutely happy to send a v4 to ameliorate these issues, but there might not be a need to do so if the series won't get merged in the end

Regardless, thank you to Christian and all the maintainers for being welcoming and all your work reviewing this patch series so far!

Thanks
Yicong