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

[Julian Orth]

On Tue, Mar 3, 2026 at 12:38 PM Michel Dänzer
<michel.daenzer@xxxxxxxxxxx> wrote:
>
> On 3/3/26 12:23, Julian Orth wrote:
> > On Tue, Mar 3, 2026 at 12:17 PM Michel Dänzer
> > <michel.daenzer@xxxxxxxxxxx> wrote:
> >>
> >> While I don't object to this change, I'd argue that this is really a workaround for broken user space, not a fix for a kernel regression.
> >>
> >> User space must initialize the full struct to 0, except for the fields it wants to have other values. This kind of kernel-side workaround for neglecting that won't be possible in all cases.
> >
> > When the code in my example was written, the points field did not
> > exist. Therefore, as far as that code is concerned, the authors
> > believed that the struct was fully initialized, since they manually
> > initialized all fields that were contained in the struct at that time.
> > The code was then later recompiled against a version of drm/drm.h that
> > contained the new field.
> >
> > Or are you saying that userspace must always use memset(&arg, 0,
> > sizeof(arg)) to initialize ioctl arguments?
>
> Yes, it must. Any approach which results in newly-added fields not being initialized to 0 is broken.

Do you know of any other case where access to the new fields is not
guarded by some kind of flag that exists in all versions of the
struct?

>
>
> To prevent a potential follow-up concern: What if the kernel uses a larger size of the struct than user space? That's fine, user space encodes the size it uses in the parameters to the ioctl system call, and the kernel uses 0 for all fields beyond that size.
>
>
> --
> Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
> https://redhat.com             \               Libre software enthusiast