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

[Julian Orth]

On Tue, Mar 3, 2026 at 6:04 PM Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote:
>
> On 3/3/26 17:54, Julian Orth wrote:
> > On Tue, Mar 3, 2026 at 5:40 PM Maarten Lankhorst
> > <maarten.lankhorst@xxxxxxxxxxxxxxx> wrote:
> >>
> >> There is precedence in the ioctl, the pad member is checked against zero for the same reason.
> >
> > I don't believe that this is comparable. Developers of code developed
> > against an older kernel could look at the kernel and see that the pad
> > field was checked against zero. They could not see the same for fields
> > that didn't exist at the time.
>
> "Initialize only known fields" isn't a valid approach here. The full struct must be initialized to 0, including any fields added in the future.

It worked from the introduction of the ioctl until the new field was
added. How could anyone know about this requirement if it is not
documented? Some people might not even know that ioctl numbers encode
the size of the argument and therefore assume that the argument
structure is fixed. I think this is quite different from syscalls such
as clone3 which make the size argument explicit and where it can be
expected that the developer knows that the struct might grow when the
application is recompiled.

The new flag was added so that userspace can detect older kernels that
don't support the point field, such kernels return EINVAL when they
see the new flag.
Then why should the kernel not also use the absence of the flag to
detect older userspace that might be unaware of the point field?

>
>
> --
> Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
> https://redhat.com             \               Libre software enthusiast