From: Al Viro <viro@zeniv.linux.org.uk> To: linux-arch@vger.kernel.org Cc: 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, Linus Torvalds <torvalds@linux-foundation.org> Subject: [RFC][PATCHSET] VM_FAULT_RETRY fixes Date: Tue, 31 Jan 2023 20:02:51 +0000 [thread overview] Message-ID: <Y9lz6yk113LmC9SI@ZenIV> (raw) Page fault handlers generally react to VM_FAULT_RETRY from handle_mm_fault() by repeating the whole thing (starting with locking mmap) with FAULT_FLAG_TRIED added to flags. However, there are two cases when that's not the right thing to do: 1) fault has happened in userland and we have a pending signal. In that case we'd better return from fault handler immediately. 2) fault has happened in kernel (e.g. in something like copy_from_user()) and we have a pending *fatal* signal. Solution is to handle that as if handle_mm_fault() had failed; we have come from kernel mode, so we'd better have an exception table entry for the fauling insn. Find it and deal with it; from the copy_from_user() (or whatever it was that triggered our fault) caller's POV it's indistinguishable from running into an unmapped area, so it will fail. The process is not going to survive anyway. Quietly returning from #PF handler in the second case is asking for livelock - one common case when handle_mm_fault() returns VM_FAULT_RETRY is when it needs to wait for page lock and gets hit by a fatal signal. Running into that in any uaccess primitive will end up repeating the faulting insn again and again, as long as we hit that case in handle_mm_fault(). Eventually it might get out (e.g. trylock manages to get page lock without hitting the "wait for it" codepath), but it's obviously not a good situation. On x86 it had been noticed and fixed back in 2014, in 26178ec11ef3 "x86: mm: consolidate VM_FAULT_RETRY handling". Some of the other architectures had it dealt with later - e.g. arm in 2017, the fix is 746a272e44141 "ARM: 8692/1: mm: abort uaccess retries upon fatal signal"; xtensa - in 2021, the fix is 7b9acbb6aad4f "xtensa: fix uaccess-related livelock in do_page_fault", etc. However, it never had been done on a bunch of architectures - the current mainline still has that bug on alpha, hexagon, itanic, m68k, microblaze, nios2, openrisc, parisc, riscv and sparc (both sparc32 and sparc64). Fixes are trivial, but I've no way to test them for most of those architectures.
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk> To: linux-arch@vger.kernel.org Cc: 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, Linus Torvalds <torvalds@linux-foundation.org> Subject: [RFC][PATCHSET] VM_FAULT_RETRY fixes Date: Tue, 31 Jan 2023 20:02:51 +0000 [thread overview] Message-ID: <Y9lz6yk113LmC9SI@ZenIV> (raw) Page fault handlers generally react to VM_FAULT_RETRY from handle_mm_fault() by repeating the whole thing (starting with locking mmap) with FAULT_FLAG_TRIED added to flags. However, there are two cases when that's not the right thing to do: 1) fault has happened in userland and we have a pending signal. In that case we'd better return from fault handler immediately. 2) fault has happened in kernel (e.g. in something like copy_from_user()) and we have a pending *fatal* signal. Solution is to handle that as if handle_mm_fault() had failed; we have come from kernel mode, so we'd better have an exception table entry for the fauling insn. Find it and deal with it; from the copy_from_user() (or whatever it was that triggered our fault) caller's POV it's indistinguishable from running into an unmapped area, so it will fail. The process is not going to survive anyway. Quietly returning from #PF handler in the second case is asking for livelock - one common case when handle_mm_fault() returns VM_FAULT_RETRY is when it needs to wait for page lock and gets hit by a fatal signal. Running into that in any uaccess primitive will end up repeating the faulting insn again and again, as long as we hit that case in handle_mm_fault(). Eventually it might get out (e.g. trylock manages to get page lock without hitting the "wait for it" codepath), but it's obviously not a good situation. On x86 it had been noticed and fixed back in 2014, in 26178ec11ef3 "x86: mm: consolidate VM_FAULT_RETRY handling". Some of the other architectures had it dealt with later - e.g. arm in 2017, the fix is 746a272e44141 "ARM: 8692/1: mm: abort uaccess retries upon fatal signal"; xtensa - in 2021, the fix is 7b9acbb6aad4f "xtensa: fix uaccess-related livelock in do_page_fault", etc. However, it never had been done on a bunch of architectures - the current mainline still has that bug on alpha, hexagon, itanic, m68k, microblaze, nios2, openrisc, parisc, riscv and sparc (both sparc32 and sparc64). Fixes are trivial, but I've no way to test them for most of those architectures. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2023-01-31 20:03 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-31 20:02 Al Viro [this message] 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-01-31 20:03 ` Al Viro 2023-03-07 0:48 ` patchwork-bot+linux-riscv 2023-03-07 0:48 ` patchwork-bot+linux-riscv 2023-01-31 20:03 ` [PATCH 02/10] hexagon: " Al Viro 2023-01-31 20:03 ` Al Viro 2023-02-10 2:59 ` Brian Cain 2023-02-10 2:59 ` Brian Cain 2023-01-31 20:04 ` [PATCH 03/10] ia64: " Al Viro 2023-01-31 20:04 ` Al Viro 2023-01-31 20:04 ` [PATCH 04/10] m68k: " Al Viro 2023-01-31 20:04 ` Al Viro 2023-02-05 6:18 ` Finn Thain 2023-02-05 6:18 ` Finn Thain 2023-02-05 6:18 ` Finn Thain 2023-02-05 18:51 ` Linus Torvalds 2023-02-05 18:51 ` Linus Torvalds 2023-02-05 18:51 ` Linus Torvalds 2023-02-07 3:07 ` Finn Thain 2023-02-07 3:07 ` Finn Thain 2023-02-07 3:07 ` Finn Thain 2023-02-05 20:39 ` Al Viro 2023-02-05 20:39 ` Al Viro 2023-02-05 20:39 ` Al Viro 2023-02-05 20:41 ` Linus Torvalds 2023-02-05 20:41 ` Linus Torvalds 2023-02-05 20:41 ` Linus Torvalds 2023-02-06 12:08 ` Geert Uytterhoeven 2023-02-06 12:08 ` Geert Uytterhoeven 2023-02-06 12:08 ` Geert Uytterhoeven 2023-01-31 20:05 ` [PATCH 05/10] microblaze: " Al Viro 2023-01-31 20:05 ` Al Viro 2023-01-31 20:05 ` [PATCH 06/10] nios2: " Al Viro 2023-01-31 20:05 ` Al Viro 2023-01-31 20:06 ` [PATCH 07/10] openrisc: " Al Viro 2023-01-31 20:06 ` Al Viro 2023-01-31 20:06 ` [PATCH 08/10] parisc: " Al Viro 2023-01-31 20:06 ` Al Viro 2023-02-06 16:58 ` Helge Deller 2023-02-06 16:58 ` Helge Deller 2023-02-06 16:58 ` Helge Deller 2023-02-28 17:34 ` Al Viro 2023-02-28 17:34 ` Al Viro 2023-02-28 18:26 ` Helge Deller 2023-02-28 19:14 ` Al Viro 2023-02-28 19:32 ` Helge Deller 2023-02-28 20:00 ` Helge Deller 2023-02-28 20:22 ` Helge Deller 2023-02-28 22:57 ` Al Viro 2023-03-01 4:00 ` Helge Deller 2023-03-02 17:53 ` Al Viro 2023-02-28 15:22 ` Guenter Roeck 2023-02-28 15:22 ` Guenter Roeck 2023-02-28 15:22 ` Guenter Roeck 2023-02-28 19:18 ` Michael Schmitz 2023-02-28 19:18 ` Michael Schmitz 2023-02-28 19:18 ` Michael Schmitz 2023-01-31 20:06 ` [PATCH 09/10] riscv: " Al Viro 2023-01-31 20:06 ` Al Viro 2023-02-06 20:06 ` Björn Töpel 2023-02-06 20:06 ` Björn Töpel 2023-02-06 20:06 ` Björn Töpel 2023-02-07 16:11 ` Geert Uytterhoeven 2023-02-07 16:11 ` Geert Uytterhoeven 2023-02-07 16:11 ` Geert Uytterhoeven 2023-01-31 20:07 ` [PATCH 10/10] sparc: " Al Viro 2023-01-31 20:07 ` Al Viro 2023-01-31 20:24 ` [RFC][PATCHSET] VM_FAULT_RETRY fixes Linus Torvalds 2023-01-31 20:24 ` Linus Torvalds 2023-01-31 20:24 ` Linus Torvalds 2023-01-31 21:10 ` Al Viro 2023-01-31 21:10 ` Al Viro 2023-01-31 21:19 ` Linus Torvalds 2023-01-31 21:19 ` Linus Torvalds 2023-01-31 21:19 ` Linus Torvalds 2023-01-31 21:49 ` Al Viro 2023-01-31 21:49 ` Al Viro 2023-02-01 0:00 ` Linus Torvalds 2023-02-01 0:00 ` Linus Torvalds 2023-02-01 0:00 ` Linus Torvalds 2023-02-01 19:48 ` Peter Xu 2023-02-01 19:48 ` Peter Xu 2023-02-01 19:48 ` Peter Xu 2023-02-01 22:18 ` Al Viro 2023-02-01 22:18 ` Al Viro 2023-02-01 22:18 ` Al Viro 2023-02-02 0:57 ` Al Viro 2023-02-02 0:57 ` Al Viro 2023-02-02 0:57 ` Al Viro 2023-02-02 22:56 ` Peter Xu 2023-02-02 22:56 ` Peter Xu 2023-02-02 22:56 ` Peter Xu 2023-02-04 0:26 ` Al Viro 2023-02-04 0:26 ` Al Viro 2023-02-04 0:26 ` Al Viro 2023-02-05 5:10 ` Al Viro 2023-02-05 5:10 ` Al Viro 2023-02-05 5:10 ` Al Viro 2023-02-04 0:47 ` [loongarch oddities] " Al Viro 2023-02-01 8:21 ` Helge Deller 2023-02-01 8:21 ` Helge Deller 2023-02-01 8:21 ` Helge Deller 2023-02-01 19:51 ` Linus Torvalds 2023-02-01 19:51 ` Linus Torvalds 2023-02-01 19:51 ` Linus Torvalds 2023-02-02 6:58 ` Al Viro 2023-02-02 6:58 ` Al Viro 2023-02-02 8:54 ` Michael Cree 2023-02-02 9:56 ` John Paul Adrian Glaubitz 2023-02-02 15:20 ` Al Viro 2023-02-02 20:20 ` Al Viro 2023-02-02 20:34 ` Linus Torvalds 2023-02-01 10:50 ` Mark Rutland 2023-02-01 10:50 ` Mark Rutland 2023-02-01 10:50 ` Mark Rutland 2023-02-06 12:08 ` Geert Uytterhoeven 2023-02-06 12:08 ` Geert Uytterhoeven 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=Y9lz6yk113LmC9SI@ZenIV \ --to=viro@zeniv.linux.org.uk \ --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=sparclinux@vger.kernel.org \ --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: linkBe 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.