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

[Michel Dänzer]

On 3/3/26 18:11, Julian Orth wrote:
> 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?

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.


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