From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: David Laight <david.laight.linux@gmail.com>,
Julian Orth <ju.orth@gmail.com>
Cc: "Michel Dänzer" <michel.daenzer@mailbox.org>,
"Christian König" <christian.koenig@amd.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Rob Clark" <robin.clark@oss.qualcomm.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack
Date: Wed, 4 Mar 2026 11:35:40 +0100 [thread overview]
Message-ID: <12090ced-c0fd-47db-9f36-9dbf3c4b3ca6@linux.intel.com> (raw)
In-Reply-To: <20260303195835.4c23be7a@pumpkin>
Hey,
Den 2026-03-03 kl. 20:58, skrev David Laight:
> On Tue, 3 Mar 2026 18:44:59 +0100
> Julian Orth <ju.orth@gmail.com> wrote:
>
>> On Tue, Mar 3, 2026 at 6:41 PM Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com> wrote:
>>>
>>> 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.
>>
>> But it's not newly written. The example is, say, 5 year old code. The
>> binary that was compiled 5 years ago works fine as you say. But if you
>> take the same code and just run gcc again, the new binary will no
>> longer work.
>>
>
> Worse, the recompiled version may well work when you test it, and even
> when deployed.
> But you'll get non-obvious random failures - a support nightmare.
I believe in a lot of cases the headers are simply copied to the project,
so it will continue to work.
I don't see a difference between moving to a new compiler. Compiling code
from 5 years ago might also run into new compiler warnings that didn't
exist on the older version of the compiler.
> Probably best code is something like:
> case OLD_IOCTL_CODE:
> if (ioc->flag & NEW_FLAG)
> return -EINVAL;
> /* FALLTHROUGH *.
> case NEW_IOCTL_CODE:
> if (!(ioc->flag & NEW_FLAG))
> ioc->new_field = 0;
>
> David
Yeah, that is what we do by explicitly checking the size parameter. Any
undefined members are zero'd. If you define the new member in userspace,
you're also taking on the responsibility for having it contained defined
information, even if you only zero the struct.
Kind regards,
~Maarten Lankhorst
next prev parent reply other threads:[~2026-03-04 10:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-01 12:34 [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack Julian Orth
2026-03-02 11:27 ` Christian König
2026-03-02 11:54 ` Dmitry Osipenko
2026-03-03 11:17 ` Michel Dänzer
2026-03-03 11:23 ` Julian Orth
2026-03-03 11:38 ` Michel Dänzer
2026-03-03 11:41 ` Julian Orth
2026-03-03 14:53 ` Maarten Lankhorst
2026-03-03 14:59 ` Christian König
2026-03-03 15:15 ` Maarten Lankhorst
2026-03-03 15:21 ` Julian Orth
2026-03-03 17:02 ` Michel Dänzer
2026-03-03 15:29 ` Michel Dänzer
2026-03-03 15:36 ` Julian Orth
2026-03-03 16:40 ` Maarten Lankhorst
2026-03-03 16:54 ` Julian Orth
2026-03-03 17:04 ` Michel Dänzer
2026-03-03 17:11 ` Julian Orth
2026-03-03 17:18 ` Michel Dänzer
2026-03-03 17:30 ` Julian Orth
2026-03-03 17:44 ` Maarten Lankhorst
2026-03-03 18:53 ` Michel Dänzer
2026-03-03 19:12 ` Julian Orth
2026-03-04 9:57 ` Maarten Lankhorst
2026-03-04 11:15 ` Michel Dänzer
2026-03-04 11:25 ` Julian Orth
2026-03-04 11:47 ` Michel Dänzer
2026-03-04 12:32 ` Julian Orth
2026-03-04 14:29 ` Michel Dänzer
2026-03-04 14:35 ` Julian Orth
2026-03-05 9:47 ` Maarten Lankhorst
2026-03-03 17:40 ` Maarten Lankhorst
2026-03-03 17:44 ` Julian Orth
2026-03-03 19:58 ` David Laight
2026-03-04 10:35 ` Maarten Lankhorst [this message]
2026-03-03 17:05 ` Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12090ced-c0fd-47db-9f36-9dbf3c4b3ca6@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=david.laight.linux@gmail.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ju.orth@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel.daenzer@mailbox.org \
--cc=mripard@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox