Hi,
On Wed, Nov 26, 2025 at 10:08:44AM +0100, Florian Weimer wrote:
Is this really the right direction? This implies that the ioctl constants change as the structs get extended. At present, this impacts struct pidfd_info and PIDFD_GET_INFO.
I think this is a deparature from the previous design, where (low-level) userspace did not have not worry about the internal structure of ioctl commands and could treat them as opaque bit patterns. With the new approach, we have to dissect some of the commands in the same way extensible_ioctl_valid does it above.
So far, this impacts glibc ABI tests. Looking at the strace sources, it doesn't look to me as if the ioctl handler is prepared to deal with this situation, either, because it uses the full ioctl command for lookups.
The sanitizers could implement generic ioctl checking with the embedded size information in the ioctl command, but the current code structure is not set up to handle this because it's indexed by the full ioctl command, not the type. I think in some cases, the size is required to disambiguate ioctl commands because the type field is not unique across devices. In some cases, the sanitizers would have to know the exact command (not just the size), to validate points embedded in the struct passed to the ioctl. So I don't think changing ioctl constants when extensible structs change is obviously beneficial to the sanitizers, either.
Same for valgrind memcheck handling of ioctls.
I would prefer if the ioctl commands could be frozen and decoupled from the structs. As far as I understand it, there is no requirement that the embedded size matches what the kernel deals with.
Yes please.
Thanks,
Mark