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

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Den 2026-03-03 kl. 18:18, skrev 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@mailbox.org> wrote:
>>> On 3/3/26 17:54, Julian Orth wrote:
>>>> On Tue, Mar 3, 2026 at 5:40 PM Maarten Lankhorst
>>>> <maarten.lankhorst@linux.intel.com> 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.


My point is that it works for old userspace without problems. It's only
newly compiled userspace with new headers that will run into problems.
The code as written would have continued to work, but if you update to
the new header and don't initialise the new members then it's a userspace
problem. It should not be worked around in the kernel, since it's newly
written bad userspace code, not old bad userspace code that stopped working
when the kernel changed.