[PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal generation

arm64_notify_segfault() was written to decide on the si_code from the assembly emulation of the swp_handler(), but was also used for the signal generation from failed access_ok() and unaligned instructions. When access_ok() fails, there is no need to search for the offending address in the VMA spa

[PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn() sometime returns the wrong signals

arm64_notify_segfault() was used to force a SIGSEGV in all error cases in sigreturn() and rt_sigreturn() to avoid writing a new sig handler. There is now a better sig handler to use which does not search the VMA address space and return a slightly incorrect error code. Restore the older and correc

[PATCH 3/3] arch/arm64/kernel/traps: Use find_vma_intersection() in traps for setting si_code

find_vma() will continue to search upwards until the end of the virtual memory space. This means the si_code would almost never be set to SEGV_MAPERR even when the address falls outside of any VMA. The result is that the si_code is not reliable as it may or may not be set to the correct result, d

Re: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in traps for setting si_code

* Catalin Marinas [210413 14:00]: > On Tue, Apr 13, 2021 at 04:52:34PM +0000, Liam Howlett wrote: > > * Catalin Marinas [210412 13:44]: > > > On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote: > > > > find_vma() will continue to search upward

Re: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in traps for setting si_code

* Catalin Marinas [210412 13:44]: > On Wed, Apr 07, 2021 at 03:11:06PM +0000, Liam Howlett wrote: > > find_vma() will continue to search upwards until the end of the virtual > > memory space. This means the si_code would almost never be set to > > SEGV_MAPERR even when the

Re: [PATCH] arch/m68k/kernel/sys_m68k: Add missing mmap_read_lock() to sys_cacheflush()

Forgot the fixes line. * Liam Howlett [210407 16:00]: > When the superuser flushes the entire cache, the mmap_read_lock() is not > taken, but mmap_read_unlock() is called. Add the missing > mmap_read_lock() call. > > Signed-off-by: Liam R. Howlett > --- > arch/m68k/

[PATCH] arch/m68k/kernel/sys_m68k: Add missing mmap_read_lock() to sys_cacheflush()

When the superuser flushes the entire cache, the mmap_read_lock() is not taken, but mmap_read_unlock() is called. Add the missing mmap_read_lock() call. Signed-off-by: Liam R. Howlett --- arch/m68k/kernel/sys_m68k.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/m68k/kernel/sys_m68k

[PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in traps for setting si_code

find_vma() will continue to search upwards until the end of the virtual memory space. This means the si_code would almost never be set to SEGV_MAPERR even when the address falls outside of any VMA. The result is that the si_code is not reliable as it may or may not be set to the correct result, d

Re: [PATCH] alpha/kernel/traps: Use find_vma_intersection() in traps for setting si_code

on where the address lands in the virtual address space. > Just a concern I have, with 0 evidence behind it, so I hope it turns > out not to be an actual issue. > > Acked-by: Michel Lespinasse > > On Thu, Apr 1, 2021 at 12:51 PM Liam Howlett wrote: > > > >

[PATCH] alpha/kernel/traps: Use find_vma_intersection() in traps for setting si_code

find_vma() will continue to search upwards until the end of the virtual memory space. This means the si_code would almost never be set to SEGV_MAPERR even when the address falls outside of any VMA. Using find_vma_intersection() allows for what is intended by only returning a VMA if it falls withi

[PATCH] i915_vma: Rename vma_lookup to i915_vma_lookup

Use i915 prefix to avoid name collision with future vma_lookup() in mm. Signed-off-by: Liam R. Howlett Reviewed-by: Matthew Wilcox (Oracle) --- drivers/gpu/drm/i915/i915_vma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/d

[PATCH v3] mm/mmap: Don't unlock VMAs in remap_file_pages()

Since this call uses MAP_FIXED, do_mmap() will munlock the necessary range. There is also an error in the loop test expression which will evaluate as false and the loop body has never execute. Signed-off-by: Liam R. Howlett Acked-by: Hugh Dickins --- mm/mmap.c | 18 +- 1 file c

Re: [rcu:willy-maple 189/202] mm/mmap.c:2830:18: warning: variable 'ma_lock' set but not used

* kernel test robot [210202 22:08]: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > willy-maple > head: 7e346d2845b4bd77663394f39fa70456e0084c86 > commit: e40a951e09ed0e66dbd646f938df19c876915b9d [189/202] mm: Remove vma > linked list. > config: alpha-defconfi

Re: [rcu:willy-maple 134/202] mm/mmap.c:2919 do_brk_munmap() error: we previously assumed 'vma->anon_vma' could be null (see line 2884)

Hello, These are two valid issues. I had noticed one but both need to be addressed. Thank you Dan. Regards, Liam * Dan Carpenter [210203 08:15]: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > willy-maple > head: 7e346d2845b4bd77663394f39fa70456e0084c86

NFS Killable tasks request comments on patch

Signed-off-by: Liam R. Howlett <[EMAIL PROTECTED]> This patch builds on willy's TASK_INTERRUPTABLE and my own TASK_KILLABLE patches that are currently in the mm branch. ( see http://lkml.org/lkml/2007/10/18/423 and http://lkml.org/lkml/2007/11/28/127 ) This patch removes the rpc sigmask code and

[Patch 0/2] Kernel: mutex_lock_killable

Hello, This series of patches add the ability to make mutex locks killable instead of uninterruptable. This patch set builds on willys 5 patches for TASK_KILLABLE that are currently in mm (see http://lkml.org/lkml/2007/10/18/423 for more details). I have used 2.6.24-rc3 with the addition of will