linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Lutomirski <luto@kernel.org>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <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>,
	vapier@gentoo.org, Rich Felker <dalias@libc.org>,
	x32@buildd.debian.org, Will Deacon <will.deacon@arm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Can we drop upstream Linux x32 support?
Date: Tue, 11 Dec 2018 11:32:31 +0000	[thread overview]
Message-ID: <20181211113230.GB35824@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAK8P3a0adxnXr9JLfpR5MBeEJXSCK2Rt4w7NFLUUwO6s6LBVPQ@mail.gmail.com>

On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski <luto@kernel.org> wrote:
> > I tried to understand what's going on.  As far as I can tell, most of
> > the magic is the fact that __kernel_long_t and __kernel_ulong_t are
> > 64-bit as seen by x32 user code.  This means that a decent number of
> > uapi structures are the same on x32 and x86_64.  Syscalls that only
> > use structures like this should route to the x86_64 entry points.  But
> > the implementation is still highly dubious -- in_compat_syscall() will
> > be *true* in such system calls,
> 
> I think the fundamental issue was that the intention had always been
> to use only the 64-bit entry points for system calls, but the most
> complex one we have -- ioctl() -- has to use the compat entry point
> because device drivers define their own data structures using 'long'
> and pointer members and they need translation, as well as
> matching in_compat_syscall() checks. This in turn breaks down
> again whenever a driver defines an ioctl command that takes
> a __kernel_long_t or a derived type like timespec as its argument.

With arm64 ILP32 we tried to avoid the ioctl() problem by having
__kernel_long_t 32-bit, IOW mimicking the arm32 ABI (compat). The
biggest pain point is signals where the state is completely different
from arm32 (more, wider registers) and can't be dealt with by the compat
layer.

Fortunately, we haven't merge it yet as we have the same dilemma about
real users and who's going to regularly test the ABI in the long run. In
the meantime, watching this thread with interest ;).

-- 
Catalin

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

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  1:23 Can we drop upstream Linux x32 support? Andy Lutomirski
2018-12-11  1:40 ` 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 [this message]
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=20181211113230.GB35824@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --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=luto@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).