On Tue, Feb 3, 2026 at 11:35 AM Michael S. Tsirkin <[email protected]> wrote: > > On Mon, Feb 02, 2026 at 11:54:17PM +0100, Arnd Bergmann wrote: > > On Mon, Feb 2, 2026, at 17:45, Michael S. Tsirkin wrote: > > > On Mon, Feb 02, 2026 at 12:59:03PM +0100, Arnd Bergmann wrote: > > > > > > I think .compat_ioctl would be cleaner frankly. Just look at > > > all the ifdefery. And who knows what broken-ness userspace > > > comes up with with this approach. Better use the standard approach. > > > > Sent now. > > > > I'm not sure it's much better because there is quite a bit of > > code duplication, and reducing that would be a larger rework. > > yes but on the flip side, we can put it all inside ifdef CONFIG_COMPAT > (which this code did not do, but should IMHO). > > > It may be best to hold off on patch 2 for the coming merge window > > since the compat ioctl code has apparently always been broken for > > x86 here. > > And it needs testing. > > > I hope we can at least get patch 1/2 merged along with the > > new code though, otherwise it would get a lot harder to sort > > it out properly, with the v2 struct members overlapping the > > old padding fields. > > > > Arnd > > Along with it or no, surely before the release. > Given 32 on 64 with this apparently has been broken forever, > I will merge this just based on even you did not bother testing compat, I am > inclined to say I am merging this but not rebasing because > of this. > > Oh and we got lucky this didn't leak kernel stack info. > > Eugenio, note for the future: please help make sure UAPI > structs do not have hidden padding. >
Sure. I'm trying to find an automatic way to check for this but with no luck :(. Arnd, did you use some tool for this or you just found it by visual inspection? I'm trying pahole and -Wpadded but the output includes a lot of struct not related to uapi. I guess it is possible to filter it with some clang or awk machinery, but I'm asking in case I avoid developing something already existing. Thanks!
