1. 12 10月, 2019 1 次提交
    • V
      riscv: Avoid interrupts being erroneously enabled in handle_exception() · d286a374
      Vincent Chen 提交于
      [ Upstream commit c82dd6d078a2bb29d41eda032bb96d05699a524d ]
      
      When the handle_exception function addresses an exception, the interrupts
      will be unconditionally enabled after finishing the context save. However,
      It may erroneously enable the interrupts if the interrupts are disabled
      before entering the handle_exception.
      
      For example, one of the WARN_ON() condition is satisfied in the scheduling
      where the interrupt is disabled and rq.lock is locked. The WARN_ON will
      trigger a break exception and the handle_exception function will enable the
      interrupts before entering do_trap_break function. During the procedure, if
      a timer interrupt is pending, it will be taken when interrupts are enabled.
      In this case, it may cause a deadlock problem if the rq.lock is locked
      again in the timer ISR.
      
      Hence, the handle_exception() can only enable interrupts when the state of
      sstatus.SPIE is 1.
      
      This patch is tested on HiFive Unleashed board.
      Signed-off-by: NVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
      [paul.walmsley@sifive.com: updated to apply]
      Fixes: bcae803a ("RISC-V: Enable IRQ during exception handling")
      Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d286a374
  2. 13 8月, 2018 1 次提交
  3. 15 3月, 2018 1 次提交
  4. 21 2月, 2018 1 次提交
    • Z
      RISC-V: Enable IRQ during exception handling · bcae803a
      zongbox@gmail.com 提交于
      Interrupt is allowed during exception handling.
      There are warning messages if the kernel enables the configuration
      'CONFIG_DEBUG_ATOMIC_SLEEP=y'.
      
      BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:23
      in_atomic(): 0, irqs_disabled(): 1, pid: 43, name: ash
      CPU: 0 PID: 43 Comm: ash Tainted:  G	 W	 4.15.0-rc8-00089-g89ffdae-dirty #17
      Call Trace:
      [<000000009abb1587>] walk_stackframe+0x0/0x7a
      [<00000000d4f3d088>] ___might_sleep+0x102/0x11a
      [<00000000b1fd792a>] down_read+0x18/0x28
      [<000000000289ec01>] do_page_fault+0x86/0x2f6
      [<00000000012441f6>] _do_fork+0x1b4/0x1e0
      [<00000000f46c3e3b>] ret_from_syscall+0xa/0xe
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NZong Li <zong@andestech.com>
      Signed-off-by: NPalmer Dabbelt <palmer@dabbelt.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      bcae803a
  5. 31 1月, 2018 1 次提交
    • C
      riscv: disable SUM in the exception handler · fe9b842f
      Christoph Hellwig 提交于
      The SUM bit is enabled at the beginning of the copy_{to,from}_user and
      {get,put}_user routines, and cleared before they return.  But these user
      copy helper can be interrupted by exceptions, in which case the SUM bit
      will remain set, which leads to elevated privileges for the code running
      in exception context, as that can now access userspace address space
      unconditionally.  This frequently happens when the user copy routines
      access freshly allocated user memory that hasn't been faulted in, and a
      pagefault needs to be taken before the user copy routines can continue.
      
      Fix this by unconditionally clearing SUM when the exception handler is
      called - the restore code will automatically restore it based on the
      saved value.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      fe9b842f
  6. 08 1月, 2018 1 次提交
  7. 27 9月, 2017 1 次提交