linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	Florian Weimer <fweimer@redhat.com>,
	Mike Frysinger <vapier@gentoo.org>,
	"H. J. Lu" <hjl.tools@gmail.com>, Rich Felker <dalias@libc.org>,
	x32@buildd.debian.org, Arnd Bergmann <arnd@arndb.de>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Can we drop upstream Linux x32 support?
Date: Mon, 10 Dec 2018 17:23:39 -0800	[thread overview]
Message-ID: <CALCETrXoRAibsbWa9nfbDrt0iEuebMnCMhSFg-d9W-J2g8mDjw@mail.gmail.com> (raw)

Hi all-

I'm seriously considering sending a patch to remove x32 support from
upstream Linux.  Here are some problems with it:

1. It's not entirely clear that it has users.  As far as I know, it's
supported on Gentoo and Debian, and the Debian popcon graph for x32
has been falling off dramatically.  I don't think that any enterprise
distro has ever supported x32.

2. The way that system calls work is very strange.  Most syscalls on
x32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE)
entry point, and this is intentional.  For example, adjtimex() uses
the native entry, not the compat entry, because x32's struct timex
matches the x86_64 layout.  But a handful of syscalls have separate
entry points -- these are the syscalls starting at 512.  These enter
through the COMPAT_SYSCALL_DEFINE entry points.

The x32 syscalls that are *not* in the 512 range violate all semblance
of kernel syscall convention.  In the syscall handlers,
in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entry
is not invoked.   This is nutty and risks breaking things when people
refactor their syscall implementations.  And no one tests these
things.  Similarly, if someone calls any of the syscalls below 512 but
sets bit 31 in RAX, then the native entry will be called with
in_compat_set().

Conversely, if you call a syscall in the 512 range with bit 31
*clear*, then the compat entry is set with in_compat_syscall()
*clear*.  This is also nutty.

Finally, the kernel has a weird distinction between CONFIG_X86_X32_ABI
and and CONFIG_X86_X32, which I suspect results in incorrect builds if
the host doesn't have an x32 toolchain installed.

I propose that we make CONFIG_X86_X32 depend on BROKEN for a release
or two and then remove all the code if no one complains.  If anyone
wants to re-add it, IMO they're welcome to do so, but they need to do
it in a way that is maintainable.

--Andy

             reply	other threads:[~2018-12-11  1:23 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  1:23 Andy Lutomirski [this message]
2018-12-11  1:40 ` Can we drop upstream Linux x32 support? Linus Torvalds
2018-12-11  2:22   ` hpa
2018-12-11  8:16   ` Florian Weimer
2018-12-11 21:53   ` Thorsten Glaser
2018-12-11 23:22     ` Andy Lutomirski
2018-12-11 23:35       ` Thorsten Glaser
2018-12-11 23:55         ` Arnd Bergmann
2018-12-12  2:24         ` Andy Lutomirski
2018-12-12  2:33           ` Thorsten Glaser
2018-12-12  9:04             ` Arnd Bergmann
2018-12-12 18:14               ` Joseph Myers
2018-12-12 18:50                 ` Ivan Ivanov
2018-12-12 19:12                   ` Andy Lutomirski
2018-12-12 19:18                     ` Ivan Ivanov
2018-12-12 16:39             ` Andy Lutomirski
2018-12-12 16:52               ` Rich Felker
2018-12-12 18:03                 ` Andy Lutomirski
2018-12-13 12:40                   ` Catalin Marinas
2018-12-13 15:57                     ` Rich Felker
2018-12-13 16:04                       ` Florian Weimer
2018-12-13 16:28                         ` Rich Felker
2018-12-14 11:42                           ` Florian Weimer
2018-12-14 16:13                             ` Rich Felker
2018-12-13 18:42                         ` Joseph Myers
2018-12-15  4:53               ` Thorsten Glaser
2018-12-11 23:38       ` Rich Felker
2018-12-11 23:40     ` Maciej W. Rozycki
2018-12-13 14:38   ` Olof Johansson
2018-12-13 15:46     ` Lance Richardson
2018-12-13 16:11   ` Richard Purdie
2018-12-11  3:14 ` H.J. Lu
2018-12-11  5:35   ` Andy Lutomirski
2018-12-11  9:02     ` Arnd Bergmann
2018-12-11 11:32       ` Catalin Marinas
2018-12-11 11:37         ` Florian Weimer
2018-12-11 11:52           ` Catalin Marinas
2018-12-11  5:46 ` Christian Brauner
2018-12-11 10:29 ` John Paul Adrian Glaubitz
2018-12-11 10:37   ` Florian Weimer
2018-12-11 10:44     ` John Paul Adrian Glaubitz
2018-12-11 21:59   ` Thorsten Glaser
2018-12-11 23:33     ` Rich Felker
2018-12-13  5:03   ` Kevin Easton
2018-12-13  9:05     ` Richard Weinberger
2018-12-13  9:37       ` Sven Hartrumpf
2018-12-13  9:57         ` Adam Borowski
2018-12-13 18:50         ` Sven Hartrumpf
2018-12-13 12:12       ` Kevin Easton
2018-12-14 14:38       ` David Laight
2018-12-14 15:17         ` Richard Weinberger
2018-12-13 16:02   ` Rich Felker
2018-12-14 14:13     ` Bernd Petrovitsch
2018-12-14 16:17       ` Rich Felker
2018-12-14 16:29         ` Bernd Petrovitsch
2018-12-14 16:38         ` Florian Weimer
2018-12-14 16:55           ` Rich Felker
2018-12-14 18:58             ` Andy Lutomirski
2018-12-14 19:59               ` Lance Richardson
2018-12-14 20:13               ` Linus Torvalds
2018-12-14 21:27                 ` Andy Lutomirski
2018-12-14 21:16 ` Thomas Schöbel-Theuer
2018-12-14 21:24   ` Andy Lutomirski
2018-12-14 21:41     ` Thomas Schöbel-Theuer
2018-12-15  7:41       ` Thomas Schoebel-Theuer
2018-12-15 15:30         ` Andy Lutomirski
2019-01-09 12:41   ` Florian Weimer
2019-01-09 16:02     ` Rich Felker
2019-01-22 13:34   ` Enrico Weigelt, metux IT consult
2018-12-11 20:38 Shawn Rutledge
2018-12-12  0:00 ` Maciej W. Rozycki
2018-12-12  9:12 Steven Newbury
2018-12-12 10:48 ` Thorsten Glaser
2018-12-12 13:27   ` Steven Newbury
2018-12-12 14:01 ` Rich Felker
2018-12-12 14:46   ` Steven Newbury
2018-12-12 16:05     ` Rich Felker
2018-12-13 16:17 tedheadster

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=CALCETrXoRAibsbWa9nfbDrt0iEuebMnCMhSFg-d9W-J2g8mDjw@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vapier@gentoo.org \
    --cc=will.deacon@arm.com \
    --cc=x32@buildd.debian.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).