wireguard-linux/arch/um/kernel/trap.c, branch jd/unified-crypt-queue

mm: allow VM_FAULT_RETRY for multiple times

2020-04-02T16:35:30Z

The idea comes from a discussion between Linus and Andrea [1]. Before this patch we only allow a page fault to retry once. We achieved this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing handle_mm_fault() the second time. This was majorly used to avoid unexpected starvation of the system by looping over forever to handle the page fault on a single page. However that should hardly happen, and after all for each code path to return a VM_FAULT_RETRY we'll first wait for a condition (during which time we should possibly yield the cpu) to happen before VM_FAULT_RETRY is really returned. This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY flag when we receive VM_FAULT_RETRY. It means that the page fault handler now can retry the page fault for multiple times if necessary without the need to generate another page fault event. Meanwhile we still keep the FAULT_FLAG_TRIED flag so page fault handler can still identify whether a page fault is the first attempt or not. Then we'll have these combinations of fault flags (only considering ALLOW_RETRY flag and TRIED flag): - ALLOW_RETRY and !TRIED: this means the page fault allows to retry, and this is the first try - ALLOW_RETRY and TRIED: this means the page fault allows to retry, and this is not the first try - !ALLOW_RETRY and !TRIED: this means the page fault does not allow to retry at all - !ALLOW_RETRY and TRIED: this is forbidden and should never be used In existing code we have multiple places that has taken special care of the first condition above by checking against (fault_flags & FAULT_FLAG_ALLOW_RETRY). This patch introduces a simple helper to detect the first retry of a page fault by checking against both (fault_flags & FAULT_FLAG_ALLOW_RETRY) and !(fault_flag & FAULT_FLAG_TRIED) because now even the 2nd try will have the ALLOW_RETRY set, then use that helper in all existing special paths. One example is in __lock_page_or_retry(), now we'll drop the mmap_sem only in the first attempt of page fault and we'll keep it in follow up retries, so old locking behavior will be retained. This will be a nice enhancement for current code [2] at the same time a supporting material for the future userfaultfd-writeprotect work, since in that work there will always be an explicit userfault writeprotect retry for protected pages, and if that cannot resolve the page fault (e.g., when userfaultfd-writeprotect is used in conjunction with swapped pages) then we'll possibly need a 3rd retry of the page fault. It might also benefit other potential users who will have similar requirement like userfault write-protection. GUP code is not touched yet and will be covered in follow up patch. Please read the thread below for more information. [1] https://lore.kernel.org/lkml/20171102193644.GB22686@redhat.com/ [2] https://lore.kernel.org/lkml/20181230154648.GB9832@redhat.com/ Suggested-by: Linus Torvalds Suggested-by: Andrea Arcangeli Signed-off-by: Peter Xu Signed-off-by: Andrew Morton Tested-by: Brian Geffon Cc: Bobby Powers Cc: David Hildenbrand Cc: Denis Plotnikov Cc: "Dr . David Alan Gilbert" Cc: Hugh Dickins Cc: Jerome Glisse Cc: Johannes Weiner Cc: "Kirill A . Shutemov" Cc: Martin Cracauer Cc: Marty McFadden Cc: Matthew Wilcox Cc: Maya Gokhale Cc: Mel Gorman Cc: Mike Kravetz Cc: Mike Rapoport Cc: Pavel Emelyanov Link: http://lkml.kernel.org/r/20200220160246.9790-1-peterx@redhat.com Signed-off-by: Linus Torvalds

mm: introduce FAULT_FLAG_DEFAULT

2020-04-02T16:35:29Z

Although there're tons of arch-specific page fault handlers, most of them are still sharing the same initial value of the page fault flags. Say, merely all of the page fault handlers would allow the fault to be retried, and they also allow the fault to respond to SIGKILL. Let's define a default value for the fault flags to replace those initial page fault flags that were copied over. With this, it'll be far easier to introduce new fault flag that can be used by all the architectures instead of touching all the archs. Signed-off-by: Peter Xu Signed-off-by: Andrew Morton Tested-by: Brian Geffon Reviewed-by: David Hildenbrand Cc: Andrea Arcangeli Cc: Bobby Powers Cc: Denis Plotnikov Cc: "Dr . David Alan Gilbert" Cc: Hugh Dickins Cc: Jerome Glisse Cc: Johannes Weiner Cc: "Kirill A . Shutemov" Cc: Martin Cracauer Cc: Marty McFadden Cc: Matthew Wilcox Cc: Maya Gokhale Cc: Mel Gorman Cc: Mike Kravetz Cc: Mike Rapoport Cc: Pavel Emelyanov Link: http://lkml.kernel.org/r/20200220160238.9694-1-peterx@redhat.com Signed-off-by: Linus Torvalds

um: add support for folded p4d page tables

2019-12-05T03:44:15Z

The UML port uses 4 and 5 level fixups to support higher level page table directories in the generic VM code. Implement primitives necessary for the 4th level folding, add walks of p4d level where appropriate and drop usage of __ARCH_USE_5LEVEL_HACK. Link: http://lkml.kernel.org/r/1572938135-31886-13-git-send-email-rppt@kernel.org Signed-off-by: Mike Rapoport Cc: Anatoly Pugachev Cc: Anton Ivanov Cc: Arnd Bergmann Cc: "David S. Miller" Cc: Geert Uytterhoeven Cc: Greentime Hu Cc: Greg Ungerer Cc: Helge Deller Cc: "James E.J. Bottomley" Cc: Jeff Dike Cc: "Kirill A. Shutemov" Cc: Mark Salter Cc: Matt Turner Cc: Michal Simek Cc: Peter Rosin Cc: Richard Weinberger Cc: Rolf Eike Beer Cc: Russell King Cc: Russell King Cc: Sam Creasey Cc: Vincent Chen Cc: Vineet Gupta Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

um: Add SPDX headers to files in arch/um/kernel/

2019-09-15T19:37:17Z

Convert files to use SPDX header. All files are licensed under the GPLv2. Signed-off-by: Alex Dewar Signed-off-by: Richard Weinberger

signal: Remove the task parameter from force_sig_fault

2019-05-29T14:31:43Z

As synchronous exceptions really only make sense against the current task (otherwise how are you synchronous) remove the task parameter from from force_sig_fault to make it explicit that is what is going on. The two known exceptions that deliver a synchronous exception to a stopped ptraced task have already been changed to force_sig_fault_to_task. The callers have been changed with the following emacs regular expression (with obvious variations on the architectures that take more arguments) to avoid typos: force_sig_fault[(]\([^,]+\)[,]\([^,]+\)[,]\([^,]+\)[,]\W+current[)] -> force_sig_fault(\1,\2,\3) Signed-off-by: "Eric W. Biederman"

signal: Remove task parameter from force_sig

2019-05-27T14:36:28Z

All of the remaining callers pass current into force_sig so remove the task parameter to make this obvious and to make misuse more difficult in the future. This also makes it clear force_sig passes current into force_sig_info. Signed-off-by: "Eric W. Biederman"

signal: Remove task parameter from force_sigsegv

2019-05-27T14:36:28Z

The function force_sigsegv is always called on the current task so passing in current is redundant and not passing in current makes this fact obvious. This also makes it clear force_sigsegv always calls force_sig on the current task. Signed-off-by: "Eric W. Biederman"

um: trap: fix spelling mistake, EACCESS -> EACCES

2018-10-29T21:34:15Z

Trivial fix to a spelling mistake of the error access name EACCESS, rename to EACCES Signed-off-by: Colin Ian King Signed-off-by: Richard Weinberger

mm: convert return type of handle_mm_fault() caller to vm_fault_t

2018-08-17T23:20:28Z

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t") In this patch all the caller of handle_mm_fault() are changed to return vm_fault_t type. Link: http://lkml.kernel.org/r/20180617084810.GA6730@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder Cc: Matthew Wilcox Cc: Richard Henderson Cc: Tony Luck Cc: Matt Turner Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Richard Kuo Cc: Geert Uytterhoeven Cc: Michal Simek Cc: James Hogan Cc: Ley Foon Tan Cc: Jonas Bonn Cc: James E.J. Bottomley Cc: Benjamin Herrenschmidt Cc: Palmer Dabbelt Cc: Yoshinori Sato Cc: David S. Miller Cc: Richard Weinberger Cc: Guan Xuetao Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: "Levin, Alexander (Sasha Levin)" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

signal/um: More carefully relay signals in relay_signal.

2018-04-28T13:46:49Z

There is a bug in relay signal. It assumes that when a signal is relayed the signal never uses a signal independent si_code, such as SI_USER, SI_KERNEL, SI_QUEUE, ... SI_SIGIO etc. In practice siginfo was assuming it was relaying a signal with the SIL_FAULT layout. As that is the common cases for the signals it supported that is a reasonable assumption. Further user mode linux must be very careful when relaying different kinds of signals to prevent an information leak. This means simply increasing the kinds of signals that are handled in relay_signal is non-trivial. Therefore use siginfo_layout and force_sig_fault to simplify the signal relaying in relay_signal. By taking advantage of the fact that user mode linux only works on x86 and x86_64 we can assume that si_trapno can be ignored, and that si_errno is always zero. For the signals SIGLL, SIGFPE, SIGSEGV, SIGBUS, and SIGTRAP the only fault handler I know of that sets si_errno is SIGTRAP TRAP_HWBKPT on a few oddball architectures. Those architectures have been modified to use force_sig_ptrace_errno_trap. Similarly only a few architectures set __ARCH_SI_TRAPNO. At the point uml supports those architectures again these additional cases can be examined and supported if desired in relay_signal. Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Cc: Martin Pärtel Cc: user-mode-linux-devel@lists.sourceforge.net Cc: linux-um@lists.infradead.org Fixes: d3c1cfcdb43e ("um: pass siginfo to guest process") Signed-off-by: "Eric W. Biederman"