From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Peter Xu <peterx@redhat.com>,
linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, Michal Simek <monstr@monstr.eu>,
Dinh Nguyen <dinguyen@kernel.org>,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org
Subject: Re: [RFC][PATCHSET] VM_FAULT_RETRY fixes
Date: Tue, 31 Jan 2023 13:19:59 -0800 [thread overview]
Message-ID: <CAHk-=wjiwFzEGd_60H3nbgVB=R_8KTcfUJmXy=hSXCvLrXQRFA@mail.gmail.com> (raw)
In-Reply-To: <Y9mD1qp/6zm+jOME@ZenIV>
On Tue, Jan 31, 2023 at 1:10 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Umm... What about the semantics of get_user() of unmapped address?
> Some architectures do quiet EFAULT; some (including alpha) hit
> the sucker with SIGBUS, no matter what.
I think we should strive to just make this all common.
The reason alpha is different is almost certainly not intentional, but
a combination of "pure accident" and "nobody actually cares".
> Are we free to modify that behaviour, or is that part of arch-specific
> ABI?
I'd just unify this all, probably with a preference for existing
semantics on x86 (because of "biggest and most varied user base").
That whole "send SIGBUS even for kernel faults" is certainly bogus and
against the usual rules. And I may well be to blame for it (I have
this memory of disliking how EFAULT as a return code didn't actually
return the faulting address). And realistically, it's also just not
something that any normal application will ever hit. Giving invalid
addresses to system calls is basically always a bug, although there
are always special software that do all the crazy corner cases (ie
things like emulators tend to do odd things).
I doubt such special software exists on Linux/alpha, though.
So I wouldn't worry about those kinds of oddities overmuch.
*If* somebody then finds a load that cares, we can always fix it
later, and I'll go "mea culpa, I didn't think it would matter, and I
was wrong".
Linus
next prev parent reply other threads:[~2023-01-31 21:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 20:02 [RFC][PATCHSET] VM_FAULT_RETRY fixes Al Viro
2023-01-31 20:03 ` [PATCH 01/10] alpha: fix livelock in uaccess Al Viro
2023-03-07 0:48 ` patchwork-bot+linux-riscv
2023-01-31 20:03 ` [PATCH 02/10] hexagon: " Al Viro
2023-02-10 2:59 ` Brian Cain
2023-01-31 20:04 ` [PATCH 03/10] ia64: " Al Viro
2023-01-31 20:04 ` [PATCH 04/10] m68k: " Al Viro
2023-02-05 6:18 ` Finn Thain
2023-02-05 18:51 ` Linus Torvalds
2023-02-07 3:07 ` Finn Thain
2023-02-05 20:39 ` Al Viro
2023-02-05 20:41 ` Linus Torvalds
2023-02-06 12:08 ` Geert Uytterhoeven
2023-01-31 20:05 ` [PATCH 05/10] microblaze: " Al Viro
2023-01-31 20:05 ` [PATCH 06/10] nios2: " Al Viro
2023-01-31 20:06 ` [PATCH 07/10] openrisc: " Al Viro
2023-01-31 20:06 ` [PATCH 08/10] parisc: " Al Viro
2023-02-06 16:58 ` Helge Deller
2023-02-28 17:34 ` Al Viro
2023-02-28 15:22 ` Guenter Roeck
2023-02-28 19:18 ` Michael Schmitz
2023-01-31 20:06 ` [PATCH 09/10] riscv: " Al Viro
2023-02-06 20:06 ` Björn Töpel
2023-02-07 16:11 ` Geert Uytterhoeven
2023-01-31 20:07 ` [PATCH 10/10] sparc: " Al Viro
2023-01-31 20:24 ` [RFC][PATCHSET] VM_FAULT_RETRY fixes Linus Torvalds
2023-01-31 21:10 ` Al Viro
2023-01-31 21:19 ` Linus Torvalds [this message]
2023-01-31 21:49 ` Al Viro
2023-02-01 0:00 ` Linus Torvalds
2023-02-01 19:48 ` Peter Xu
2023-02-01 22:18 ` Al Viro
2023-02-02 0:57 ` Al Viro
2023-02-02 22:56 ` Peter Xu
2023-02-04 0:26 ` Al Viro
2023-02-05 5:10 ` Al Viro
2023-02-01 8:21 ` Helge Deller
2023-02-01 19:51 ` Linus Torvalds
2023-02-01 10:50 ` Mark Rutland
2023-02-06 12:08 ` Geert Uytterhoeven
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='CAHk-=wjiwFzEGd_60H3nbgVB=R_8KTcfUJmXy=hSXCvLrXQRFA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dinguyen@kernel.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=monstr@monstr.eu \
--cc=openrisc@lists.librecores.org \
--cc=peterx@redhat.com \
--cc=sparclinux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).