On Tue, 3 Mar 2026 18:44:59 +0100 Julian Orth <[email protected]> wrote:
> On Tue, Mar 3, 2026 at 6:41 PM Maarten Lankhorst > <[email protected]> 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. 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
