Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Hey,

Den 2026-03-03 kl. 18:30, skrev Julian Orth:
> On Tue, Mar 3, 2026 at 6:18 PM Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>>
>> I wrote in my first post in this thread that I don't object to your patch, so you can relax and stop trying to convince me not to object to it. :)
>>
>> I'm just pointing out that this is working around broken user-space code, and that there are other similar cases where that kind of broken users-space code couldn't be worked around in the kernel, so it's better to also fix the user-space code anyway.
> 
> At this point I think we're arguing about "how can ioctls be extended"
> and "does userspace have to use memset" in general, not just about
> this particular ioctl. You've made the argument that ioctls are not
> extensible in general unless userspace uses memset. However, I'm not
> yet convinced of this. As you've also said above, drm_ioctl happily
> truncates or zero-extends ioctl arguments without returning an error
> due to size mismatch. Therefore, the only way for userspace to detect
> if the kernel supports the "extended" ioctl is to add a flag so that
> the kernel can return an error if it doesn't know the flag. And then
> that flag could also be used by the kernel to detect which fields of
> the argument are potentially uninitialized.
> 
> That is why I asked above if you knew of any other examples where an
> ioctl was extended and where memset(0) became effectively required due
> to the extension.

You don't even need to use memset, this would work too:

struct drm_syncobj_handle args = {
	.flags = 0
};

Or simply struct drm_syncobj_handle args = { };

Kind regards,
~Maarten Lankhorst