On Tue, Mar 3, 2026 at 12:38 PM Michel Dänzer <[email protected]> wrote: > > On 3/3/26 12:23, Julian Orth wrote: > > On Tue, Mar 3, 2026 at 12:17 PM Michel Dänzer > > <[email protected]> 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
