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

["Christian König" <christian.koenig@amd.com>]

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.