Received-SPF: pass (google.com: domain of linux-kernel+bounces-193524-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 29 May 2024 07:36:48 +0100
From: Al Viro <viro@zeniv.linux.org.uk>
To: Nick Bowler <nbowler@draconx.ca>
Cc: linux-kernel@vger.kernel.org,
	Linux regressions mailing list <regressions@lists.linux.dev>,
	Alexey Gladkov <legion@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: PROBLEM: kbd busted in linux 6.10-rc1 (regression)
Message-ID: <20240529063648.GM2118490@ZenIV>
References: <ad4e561c-1d49-4f25-882c-7a36c6b1b5c0@draconx.ca>
 <20240529052543.GL2118490@ZenIV>
 <d7412ef9-8e25-4f55-aac9-8ec479fb6775@draconx.ca>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d7412ef9-8e25-4f55-aac9-8ec479fb6775@draconx.ca>
Sender: Al Viro <viro@ftp.linux.org.uk>

On Wed, May 29, 2024 at 01:36:28AM -0400, Nick Bowler wrote:
> On 2024-05-29 01:25, Al Viro wrote:
> > On Wed, May 29, 2024 at 12:45:56AM -0400, Nick Bowler quoted:
> > 
> >>        All other headers use _IOC() macros to describe ioctls for a long time
> >>        now. This header is stuck in the last century.
> >>    
> >>        Simply use the _IO() macro. No other changes.
> > 
> > ... are needed, since _IO() is arch-dependent; this is quite enough to fuck
> > alpha and sparc over.  _IO(x,y) is (1<<29) + 256*x + y there; both ports
> > got started with compat userland support, so _IO...() family there is
> > modelled after OSF/1 and Solaris resp.
> >
> > kbd ioctls predate all of that.
> > 
> > Please, revert 8c467f330059 - commit in question breaks userland on alpha
> > and on sparc for no reason whatsoever.  Might be worth adding a comment
> > to those definitions at some point, but that can go on top of revert.
> 
> FWIW I see exactly the same problem with 6.10-rc1 on powerpc too.
> 
> > Folks, 0xXYZW is *not* an uncool way to spell _IO(0xXY,0xZW) - if there's
> > any chance that those definitions are seen on all architectures, they
> > should be left alone.

arch/alpha/include/uapi/asm/ioctl.h:36:#define _IOC_NONE        1U
arch/mips/include/uapi/asm/ioctl.h:22:#define _IOC_NONE 1U
arch/powerpc/include/uapi/asm/ioctl.h:8:#define _IOC_NONE       1U
arch/sparc/include/uapi/asm/ioctl.h:35:#define _IOC_NONE        1U
include/uapi/asm-generic/ioctl.h:57:#ifndef _IOC_NONE
include/uapi/asm-generic/ioctl.h:58:# define _IOC_NONE  0U

FWIW, ioctl number is bits 0..7 and type - 8..15 on everything.
The fun is in upper 16 bits:

alpha, powerpc, mips - bits 29..31 are for direction (001 - none,
010 - read, 100 - write, 110 - read/write) and bits 28..16 are
for argument size.

sparc - bits 29..31 are for direction (001 - none, 010 - read,
100 - write, 110 - read/write) and bits 29..16 are used for
for argument size if bit 30 or bit 31 are set (i.e. when it's
not "none").  Uses the fact that "none" does not combine with
"read" or "write", so we can treat 011.... as "write with argument
size in range 8K..16K".

everything else - bits 30..31 are for direction (again, bit 30
is for read, bit 31 - write), bits 29..16 for size.

You get the arch-independent values from _IOR, _IOW and _IOWR
(with argument size limited by 8Kb on alpha, powerpc and mips,
and by 16Kb everywhere).  Upper halfword in range 0xc000--0xffff 
is read/write, 0x8000--0xbfff - write, 0x4000--0x7fff - read.

_IO, however, is arch-dependent - you get 0x2000 in upper halfword
on alpha, powerpc, mips and sparc and 0 on everything else.

Rationale: compatibility with definitions on other Unices on
the same platform; not sure about powerpc, but alpha, mips
and sparc ports used to have binary compatibility with OSF/1,
IRIX and Solaris resp.  Incomplete, but having compatible
ioctl numbers layout avoided a lot of needless PITA...