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: [PATCH 05/10] microblaze: fix livelock in uaccess Date: Tue, 31 Jan 2023 20:05:17 +0000 [thread overview] Message-ID: <Y9l0fUyGRidMrTqV@ZenIV> (raw) In-Reply-To: <Y9lz6yk113LmC9SI@ZenIV> microblaze equivalent of 26178ec11ef3 "x86: mm: consolidate VM_FAULT_RETRY handling" If e.g. get_user() triggers a page fault and a fatal signal is caught, we might end up with handle_mm_fault() returning VM_FAULT_RETRY and not doing anything to page tables. In such case we must *not* return to the faulting insn - that would repeat the entire thing without making any progress; what we need instead is to treat that as failed (user) memory access. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/microblaze/mm/fault.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/microblaze/mm/fault.c b/arch/microblaze/mm/fault.c index 5c40c3ebe52f..32d9717039ba 100644 --- a/arch/microblaze/mm/fault.c +++ b/arch/microblaze/mm/fault.c @@ -219,8 +219,11 @@ void do_page_fault(struct pt_regs *regs, unsigned long address, */ fault = handle_mm_fault(vma, address, flags, regs); - if (fault_signal_pending(fault, regs)) + if (fault_signal_pending(fault, regs)) { + if (!user_mode(regs)) + goto no_context; return; + } /* The fault is fully completed (including releasing mmap lock) */ if (fault & VM_FAULT_COMPLETED) -- 2.30.2
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: [PATCH 05/10] microblaze: fix livelock in uaccess Date: Tue, 31 Jan 2023 20:05:17 +0000 [thread overview] Message-ID: <Y9l0fUyGRidMrTqV@ZenIV> (raw) In-Reply-To: <Y9lz6yk113LmC9SI@ZenIV> microblaze equivalent of 26178ec11ef3 "x86: mm: consolidate VM_FAULT_RETRY handling" If e.g. get_user() triggers a page fault and a fatal signal is caught, we might end up with handle_mm_fault() returning VM_FAULT_RETRY and not doing anything to page tables. In such case we must *not* return to the faulting insn - that would repeat the entire thing without making any progress; what we need instead is to treat that as failed (user) memory access. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/microblaze/mm/fault.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/microblaze/mm/fault.c b/arch/microblaze/mm/fault.c index 5c40c3ebe52f..32d9717039ba 100644 --- a/arch/microblaze/mm/fault.c +++ b/arch/microblaze/mm/fault.c @@ -219,8 +219,11 @@ void do_page_fault(struct pt_regs *regs, unsigned long address, */ fault = handle_mm_fault(vma, address, flags, regs); - if (fault_signal_pending(fault, regs)) + if (fault_signal_pending(fault, regs)) { + if (!user_mode(regs)) + goto no_context; return; + } /* The fault is fully completed (including releasing mmap lock) */ if (fault & VM_FAULT_COMPLETED) -- 2.30.2 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-01-31 20:05 UTC|newest] Thread overview: 120+ 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:02 ` 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 ` Al Viro [this message] 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: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=Y9l0fUyGRidMrTqV@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.