Documentation/gpu/todo.rst | 16 ------------ drivers/gpu/drm/drm_syncobj.c | 49 ++++++++++++++++++++++++++++++----- include/uapi/drm/drm.h | 11 ++++++++ 3 files changed, 54 insertions(+), 22 deletions(-)
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. 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? --- Changes: v3: * Fixed inline comments by converting to multi-line comments in accordance to kernel style guidelines. * No longer using a separate superfluous function to walk the fence chain, and instead queries the last signaled fence in in the chain for its error code * Fixed types for error and handles array. * Used dma_fence_get_status to query error instead of getting it directly. v2: https://lore.kernel.org/dri-devel/20260220022631.2205037-1-yiconghui@gmail.com/T/#m6ab4f94a19c769193895d7728383f84e452cbbfa * Went from adding a new ioctl to implementing flags for existing ones. v1: * https://lore.kernel.org/all/20260213120836.81283-1-yiconghui@gmail.com/T/#mfdbc7f97e91ca5731b51b69c8cf8173cb0b2fb3e Yicong Hui (3): drm/syncobj: Add flag DRM_SYNCOBJ_QUERY_FLAGS_ERROR to query errors drm/syncobj: Add DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR ioctl flag drm/syncobj/doc: Remove starter task from todo list Documentation/gpu/todo.rst | 16 ------------ drivers/gpu/drm/drm_syncobj.c | 49 ++++++++++++++++++++++++++++++----- include/uapi/drm/drm.h | 11 ++++++++ 3 files changed, 54 insertions(+), 22 deletions(-) -- 2.53.0
On Wed, Feb 25, 2026 at 12:46:06PM +0000, Yicong Hui wrote: I thought it was a very intentional choice that fences are a completion mechanism only—they are not a mechanism to report or propagate errors. This series seems to change that way of thinking—why? Also consider these cases: - An input dependency to a job has an error in its fence, and the output of the job is installed in a syncobj. The job successfully runs but produces garbage because of the bad input. The job’s fence will not indicate an error because we don’t propagate input dependency errors to the job. This makes DRM_SYNCOBJ_QUERY_FLAGS_ERROR seem a bit pointless now. - A driver, for whatever reason, sets fence->error, and this fence is installed in a syncobj. Now user space starts using this new uAPI on syncobjs and everything breaks. This is odd behavior from the driver, but it was completely valid because fence->error never propagated to user space. I could probably come up with more examples of potential issues, but let’s start with the above. Matt > 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. > > 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? > > --- > Changes: > v3: > * Fixed inline comments by converting to multi-line comments in > accordance to kernel style guidelines. > * No longer using a separate superfluous function to walk the fence > chain, and instead queries the last signaled fence in in the chain for > its error code > * Fixed types for error and handles array. > * Used dma_fence_get_status to query error instead of getting it > directly. > > v2: > https://lore.kernel.org/dri-devel/20260220022631.2205037-1-yiconghui@gmail.com/T/#m6ab4f94a19c769193895d7728383f84e452cbbfa > * Went from adding a new ioctl to implementing flags for existing > ones. > > v1: > * https://lore.kernel.org/all/20260213120836.81283-1-yiconghui@gmail.com/T/#mfdbc7f97e91ca5731b51b69c8cf8173cb0b2fb3e > > Yicong Hui (3): > drm/syncobj: Add flag DRM_SYNCOBJ_QUERY_FLAGS_ERROR to query errors > drm/syncobj: Add DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR ioctl flag > drm/syncobj/doc: Remove starter task from todo list > > Documentation/gpu/todo.rst | 16 ------------ > drivers/gpu/drm/drm_syncobj.c | 49 ++++++++++++++++++++++++++++++----- > include/uapi/drm/drm.h | 11 ++++++++ > 3 files changed, 54 insertions(+), 22 deletions(-) > > -- > 2.53.0 >
On 2/27/26 00:56, Matthew Brost wrote: > On Wed, Feb 25, 2026 at 12:46:06PM +0000, Yicong Hui wrote: > > I thought it was a very intentional choice that fences are a completion > mechanism only—they are not a mechanism to report or propagate errors. > > This series seems to change that way of thinking—why? We have already changed that a long long time ago. See the whole error reporting for syncfiles. It was just missing for drm_syncobj which this patch set here fixes. Regards, Christian. > > Also consider these cases: > > - An input dependency to a job has an error in its fence, and the output > of the job is installed in a syncobj. The job successfully runs but > produces garbage because of the bad input. The job’s fence will not > indicate an error because we don’t propagate input dependency errors to > the job. This makes DRM_SYNCOBJ_QUERY_FLAGS_ERROR seem a bit pointless > now. > > - A driver, for whatever reason, sets fence->error, and this fence is > installed in a syncobj. Now user space starts using this new uAPI on > syncobjs and everything breaks. This is odd behavior from the driver, > but it was completely valid because fence->error never propagated to > user space. > > I could probably come up with more examples of potential issues, but > let’s start with the above. > > Matt > >> 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. >> >> 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? >> >> --- >> Changes: >> v3: >> * Fixed inline comments by converting to multi-line comments in >> accordance to kernel style guidelines. >> * No longer using a separate superfluous function to walk the fence >> chain, and instead queries the last signaled fence in in the chain for >> its error code >> * Fixed types for error and handles array. >> * Used dma_fence_get_status to query error instead of getting it >> directly. >> >> v2: >> https://lore.kernel.org/dri-devel/20260220022631.2205037-1-yiconghui@gmail.com/T/#m6ab4f94a19c769193895d7728383f84e452cbbfa >> * Went from adding a new ioctl to implementing flags for existing >> ones. >> >> v1: >> * https://lore.kernel.org/all/20260213120836.81283-1-yiconghui@gmail.com/T/#mfdbc7f97e91ca5731b51b69c8cf8173cb0b2fb3e >> >> Yicong Hui (3): >> drm/syncobj: Add flag DRM_SYNCOBJ_QUERY_FLAGS_ERROR to query errors >> drm/syncobj: Add DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR ioctl flag >> drm/syncobj/doc: Remove starter task from todo list >> >> Documentation/gpu/todo.rst | 16 ------------ >> drivers/gpu/drm/drm_syncobj.c | 49 ++++++++++++++++++++++++++++++----- >> include/uapi/drm/drm.h | 11 ++++++++ >> 3 files changed, 54 insertions(+), 22 deletions(-) >> >> -- >> 2.53.0 >>
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. Thanks, Christian. > > --- > Changes: > v3: > * Fixed inline comments by converting to multi-line comments in > accordance to kernel style guidelines. > * No longer using a separate superfluous function to walk the fence > chain, and instead queries the last signaled fence in in the chain for > its error code > * Fixed types for error and handles array. > * Used dma_fence_get_status to query error instead of getting it > directly. > > v2: > https://lore.kernel.org/dri-devel/20260220022631.2205037-1-yiconghui@gmail.com/T/#m6ab4f94a19c769193895d7728383f84e452cbbfa > * Went from adding a new ioctl to implementing flags for existing > ones. > > v1: > * https://lore.kernel.org/all/20260213120836.81283-1-yiconghui@gmail.com/T/#mfdbc7f97e91ca5731b51b69c8cf8173cb0b2fb3e > > Yicong Hui (3): > drm/syncobj: Add flag DRM_SYNCOBJ_QUERY_FLAGS_ERROR to query errors > drm/syncobj: Add DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR ioctl flag > drm/syncobj/doc: Remove starter task from todo list > > Documentation/gpu/todo.rst | 16 ------------ > drivers/gpu/drm/drm_syncobj.c | 49 ++++++++++++++++++++++++++++++----- > include/uapi/drm/drm.h | 11 ++++++++ > 3 files changed, 54 insertions(+), 22 deletions(-) >
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. 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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
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.
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
On 05/03/2026 16:23, Yicong Hui wrote: > 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 I wasn't following closely the userspace angle of the discussion to be sure, nor I know enough about what are all the userspaces which may want to use it, but in general, if there is more than one potential userspace, perhaps you could try to interest some of them into the feature. Or add support for it yourself, submit to them and say this improves this or that and I have the kernel feature waiting already. One other thing, so that your effort is not lost should someone want to work on it in the future, perhaps a patch for the TODO file which links to your latest series on lore (once all review comments are addressed) and noting that the kernel implementation exists but is waiting on userspace? Not sure if we ever done something like that but maybe we should to avoid work duplication in the future. And also to preserve some credit if someone picks up the work 1-2-3 years down the road. Regards, Tvrtko > Regardless, thank you to Christian and all the maintainers for being > welcoming and all your work reviewing this patch series so far! > > Thanks > Yicong
© 2016 - 2026 Red Hat, Inc.