From: Helge Deller <deller@gmx.de>
To: Linus Torvalds <torvalds@linux-foundation.org>,
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: Wed, 1 Feb 2023 09:21:03 +0100 [thread overview]
Message-ID: <8f60f7d8-3e2f-2a91-c7a3-6a005d36d7d3@gmx.de> (raw)
In-Reply-To: <CAHk-=wjiwFzEGd_60H3nbgVB=R_8KTcfUJmXy=hSXCvLrXQRFA@mail.gmail.com>
On 1/31/23 22:19, Linus Torvalds wrote:
> 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".
AFAICS, the only applications which really care about the return
code are
- testsuites like LTP (i.e. the fstat05 testcase)
- some (not just debian) packages execute tests at the end of the
build process and verify the return codes, i.e. libsigsegv.
The differences between the architectures is currently often taken care
of via #ifdefs, so if the return code is harmonized across platforms
it would at least help to simplify such testcases.
Helge
next prev parent reply other threads:[~2023-02-01 8:21 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
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 [this message]
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=8f60f7d8-3e2f-2a91-c7a3-6a005d36d7d3@gmx.de \
--to=deller@gmx.de \
--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=torvalds@linux-foundation.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).