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)
Date: Wed, 29 May 2024 07:36:48 +0100 [thread overview]
Message-ID: <20240529063648.GM2118490@ZenIV> (raw)
In-Reply-To: <d7412ef9-8e25-4f55-aac9-8ec479fb6775@draconx.ca>
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...
next prev parent reply other threads:[~2024-05-29 6:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 4:45 PROBLEM: kbd busted in linux 6.10-rc1 (regression) Nick Bowler
2024-05-29 5:25 ` Al Viro
2024-05-29 5:36 ` Nick Bowler
2024-05-29 6:36 ` Al Viro [this message]
2024-05-29 6:39 ` Al Viro
2024-05-29 6:04 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240529063648.GM2118490@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nbowler@draconx.ca \
--cc=regressions@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.