Re: lsattr: incorrect size for ioctl result

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Jun 28, 2021 at 02:35:24PM -0500, Rob Landley wrote:
> 
> Let me see if I understand:
> 
> 1) The API the kernel exports is not what the kernel is doing.
> 2) Userspace can't reliably use the API the way it's currently exported.
> 3) Even other kernel devs "didn't understand" it.
> 4) Fixing it would involve scare quotes and result from a pearl clutching fit.
> 
> ... no, I'm pretty sure I don't understand.
> 
> *shrug* I've cc'd Michael Kerrisk in hopes he can update the man pages. "man
> ioctl_list" already documents these ioctls correctishly (modulo the
> signed/unsigned part) but might benefit from some sort of "warning, do not trust
> the kernel headers here, they are wrong" comment.

The philosophical question is whether the encoding of _IO* is actually
part of an exported "API", or just a way of encoding codepoints such
that when data structures change size, the codepoint automatically
changes/breaks.

We have historically speaking, a non-trivial number of ioctl's which
don't follow the _IO[RW] convention.  For example, most of the block
ioctls predate the _IO[RW] convention, and they set or get memory
without specifying the size of the type that is set or get.  Oh, noos!
The kernel is (clutchign pearls) *violating* an API "promise".
(Although, in reality, these code points existed for long before we
imposed this _IO[RW] "API".)  Should we break userspace to "fix" this
supposed API violation?  Or should we go through a huge amount of
effort to fix them all?

At one point, I had made an attempt to define the "correct" codepoint
via a definition of EXT4_IOC_GETVERSION and EXT4_IOC_GETVERSION_OLD,
so the kernel would support the "correct" and "wrong" ioctl codepoint.
Unfortunate, this got broken when other folks tried to unify
everything to use FS_IOC_GETVERSION defined in
include/uapi/linux/fs.h.  And given that we would have to support the
"wrong" codepoint for a decade or more, personally, I've stopped
caring about it, especially since we've lived with it for a decade or
more, and very few people been harmed.

If someone wants to fix up all of the ioctl code points, perhaps so it
would make life easier for strace, or some such, it's not a *terrible*
idea.  (At the very least, it's more useful than KPI-hacking folks
submitting whitespace fixes that don't even fix all of the
checkpatch.pl "violations".)  But forcing all of the ioctl codepoints
into the procrustean bed of the _IO[RW] covention is a huge amount of
work, and would take years before userspace could depend on this
"API".

Cheers,

					- Ted