Re: lsattr: incorrect size for ioctl result

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Jun 29, 2021 at 11:24:26AM -0400, Theodore Ts'o wrote:
> 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".

Why don't we deprecate FS_IOC_[GS]ETFLAGS and tell everyone to use
FS[GS]ETXATTR?  They use the same code paths and vfs helpers now.

--D

> 
> Cheers,
> 
> 					- Ted