Hey,
Den 2026-03-03 kl. 18:30, skrev Julian Orth:
> On Tue, Mar 3, 2026 at 6:18 PM Michel Dänzer <[email protected]>
> 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
