linux/arch/microblaze
Linus Torvalds 1a8d05a726 VM_FAULT_RETRY fixes
Some of the page fault handlers do not deal with the following case
 correctly:
 	* handle_mm_fault() has returned VM_FAULT_RETRY
 	* there is a pending fatal signal
 	* fault had happened in kernel mode
 Correct action in such case is not "return unconditionally" - fatal
 signals are handled only upon return to userland and something like
 copy_to_user() would end up retrying the faulting instruction and
 triggering the same fault again and again.
 
 What we need to do in such case is to make the caller to treat that
 as failed uaccess attempt - handle exception if there is an exception
 handler for faulting instruction or oops if there isn't one.
 
 Over the years some architectures had been fixed and now are handling
 that case properly; some still do not.  This series should fix the
 remaining ones.
 
 Status:
 	m68k, riscv, hexagon, parisc: tested/acked by maintainers.
 	alpha, sparc32, sparc64: tested locally - bug has been
 reproduced on the unpatched kernel and verified to be fixed by
 this series.
 	ia64, microblaze, nios2, openrisc: build, but otherwise
 completely untested.
 
 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQQqUNBr3gm4hGXdBJlZ7Krx/gZQ6wUCZAP54AAKCRBZ7Krx/gZQ
 6/IjAP92oS8kDuodAtT7WorV+GETWr2HFKfvDiPSmEGiSnXIigD9Hj9svXyeeAgl
 /TqGR50Yrvn3IUQ0A0bUDpBAG1qyVwY=
 =9+Bd
 -----END PGP SIGNATURE-----

Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

Pull VM_FAULT_RETRY fixes from Al Viro:
 "Some of the page fault handlers do not deal with the following case
  correctly:

   - handle_mm_fault() has returned VM_FAULT_RETRY

   - there is a pending fatal signal

   - fault had happened in kernel mode

  Correct action in such case is not "return unconditionally" - fatal
  signals are handled only upon return to userland and something like
  copy_to_user() would end up retrying the faulting instruction and
  triggering the same fault again and again.

  What we need to do in such case is to make the caller to treat that as
  failed uaccess attempt - handle exception if there is an exception
  handler for faulting instruction or oops if there isn't one.

  Over the years some architectures had been fixed and now are handling
  that case properly; some still do not. This series should fix the
  remaining ones.

  Status:

   - m68k, riscv, hexagon, parisc: tested/acked by maintainers.

   - alpha, sparc32, sparc64: tested locally - bug has been reproduced
     on the unpatched kernel and verified to be fixed by this series.

   - ia64, microblaze, nios2, openrisc: build, but otherwise completely
     untested"

* tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  openrisc: fix livelock in uaccess
  nios2: fix livelock in uaccess
  microblaze: fix livelock in uaccess
  ia64: fix livelock in uaccess
  sparc: fix livelock in uaccess
  alpha: fix livelock in uaccess
  parisc: fix livelock in uaccess
  hexagon: fix livelock in uaccess
  riscv: fix livelock in uaccess
  m68k: fix livelock in uaccess
2023-03-05 11:07:58 -08:00
..
boot kbuild: unify cmd_copy and cmd_shipped 2022-02-14 10:37:32 +09:00
configs microblaze/PCI: Remove support for Xilinx PCI host bridge 2022-11-25 11:39:23 +01:00
include mm, arch: add generic implementation of pfn_valid() for FLATMEM 2023-02-09 16:51:41 -08:00
kernel arch/idle: Change arch_cpu_idle() behavior: always exit with IRQs disabled 2023-01-13 11:48:15 +01:00
lib microblaze: fix typos in comments 2022-05-02 08:36:10 +02:00
mm microblaze: fix livelock in uaccess 2023-03-02 12:32:31 -05:00
pci microblaze/PCI: Moving PCI iounmap and dependent code 2022-11-25 11:39:23 +01:00
Kbuild kbuild: use more subdir- for visiting subdirectories while cleaning 2021-10-24 13:49:46 +09:00
Kconfig microblaze/PCI: Remove support for Xilinx PCI host bridge 2022-11-25 11:39:23 +01:00
Kconfig.debug tracing: Refactor TRACE_IRQFLAGS_SUPPORT in Kconfig 2021-08-16 11:37:21 -04:00
Kconfig.platform
Makefile kbuild: fix "cat: .version: No such file or directory" 2022-11-24 09:26:02 +09:00