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. 16 9月, 2019 1 次提交
  3. 14 3月, 2019 1 次提交
  4. 20 2月, 2019 1 次提交
  5. 06 12月, 2018 1 次提交
  6. 01 12月, 2018 1 次提交
    • O
      RISC-V: Silence some module warnings on 32-bit · 021e2f3f
      Olof Johansson 提交于
      [ Upstream commit ef3a61406618291c46da168ff91acaa28d85944c ]
      
      Fixes:
      
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_32_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:23:27: note: format string is defined here
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_pcrel_hi20_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:104:23: note: format string is defined here
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_hi20_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:146:23: note: format string is defined here
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_got_hi20_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:190:60: note: format string is defined here
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_plt_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:214:24: note: format string is defined here
      arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_rela':
      ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
      arch/riscv/kernel/module.c:236:23: note: format string is defined here
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      021e2f3f
  7. 03 10月, 2018 1 次提交
  8. 05 9月, 2018 1 次提交
  9. 29 8月, 2018 1 次提交
  10. 21 8月, 2018 1 次提交
    • P
      RISC-V: Define sys_riscv_flush_icache when SMP=n · 7847e705
      Palmer Dabbelt 提交于
      This would be necessary to make non-SMP builds work, but there is
      another error in the implementation of our syscall linkage that actually
      just causes sys_riscv_flush_icache to never build.  I've build tested
      this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
      normal.
      
      CC: Christoph Hellwig <hch@infradead.org>
      CC: Guenter Roeck <linux@roeck-us.net>
      In-Reply-To: <20180809055830.GA17533@infradead.org>
      In-Reply-To: <20180809132612.GA31058@roeck-us.net>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      7847e705
  11. 13 8月, 2018 9 次提交
  12. 05 7月, 2018 5 次提交
  13. 12 6月, 2018 2 次提交
  14. 10 6月, 2018 1 次提交
    • L
      riscv: split the declaration of __copy_user · 86406d51
      Luc Van Oostenryck 提交于
      We use a single __copy_user assembly function to copy memory both from
      and to userspace. While this works, it triggers sparse errors because
      we're implicitly casting between the kernel and user address spaces by
      calling __copy_user.
      
      This patch splits the C declaration into a pair of functions,
      __asm_copy_{to,from}_user, that have sane semantics WRT __user. This
      split make things fine from sparse's point of view. The assembly
      implementation keeps a single definition but add a double ENTRY() for it,
      one for __asm_copy_to_user and another one for __asm_copy_from_user.
      The result is a spare-safe implementation that pays no performance
      or code size penalty.
      Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      86406d51
  15. 07 6月, 2018 1 次提交
  16. 05 6月, 2018 1 次提交
    • A
      perf: riscv: preliminary RISC-V support · 178e9fc4
      Alan Kao 提交于
      This patch provide a basic PMU, riscv_base_pmu, which supports two
      general hardware event, instructions and cycles.  Furthermore, this
      PMU serves as a reference implementation to ease the portings in
      the future.
      
      riscv_base_pmu should be able to run on any RISC-V machine that
      conforms to the Priv-Spec.  Note that the latest qemu model hasn't
      fully support a proper behavior of Priv-Spec 1.10 yet, but work
      around should be easy with very small fixes.  Please check
      https://github.com/riscv/riscv-qemu/pull/115 for future updates.
      
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Greentime Hu <greentime@andestech.com>
      Signed-off-by: NAlan Kao <alankao@andestech.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      178e9fc4
  17. 19 5月, 2018 1 次提交
    • C
      riscv: add swiotlb support · 10314e09
      Christoph Hellwig 提交于
      All RISC-V platforms today lack an IOMMU. However, legacy PCI devices
      sometimes require DMA-memory to be in the low 32 bits.  To make this work,
      we enable the software-based bounce buffers from swiotlb.  They only impose
      overhead when the device in question cannot address the full 64-bit address
      space, so a perfect fit.
      
      This patch assumes that DMA is coherent with the processor and the PCI
      bus.  It also assumes that the processor and devices share a common
      address space. This is true for all RISC-V platforms so far.
      
      [changelog stolen from an earlier patch by Palmer Dabbelt that did the
       more complicated swiotlb wireup before the recent consolidation]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
      10314e09
  18. 18 5月, 2018 1 次提交
  19. 25 4月, 2018 4 次提交
    • E
      signal/riscv: Replace do_trap_siginfo with force_sig_fault · 7ff3a762
      Eric W. Biederman 提交于
      The function force_sig_fault is just the generic version of
      do_trap_siginfo with a (void __user *) instead of an unsigned long
      parameter for the address.
      
      So just use force_sig_fault to simplify the code.
      
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: linux-riscv@lists.infradead.org
      Suggested-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7ff3a762
    • E
      signal/riscv: Use force_sig_fault where appropriate · 4d6a20b1
      Eric W. Biederman 提交于
      Filling in struct siginfo before calling force_sig_info a tedious and
      error prone process, where once in a great while the wrong fields
      are filled out, and siginfo has been inconsistently cleared.
      
      Simplify this process by using the helper force_sig_fault.  Which
      takes as a parameters all of the information it needs, ensures
      all of the fiddly bits of filling in struct siginfo are done properly
      and then calls force_sig_info.
      
      In short about a 5 line reduction in code for every time force_sig_info
      is called, which makes the calling function clearer.
      
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: linux-riscv@lists.infradead.org
      Acked-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      4d6a20b1
    • E
      signal: Ensure every siginfo we send has all bits initialized · 3eb0f519
      Eric W. Biederman 提交于
      Call clear_siginfo to ensure every stack allocated siginfo is properly
      initialized before being passed to the signal sending functions.
      
      Note: It is not safe to depend on C initializers to initialize struct
      siginfo on the stack because C is allowed to skip holes when
      initializing a structure.
      
      The initialization of struct siginfo in tracehook_report_syscall_exit
      was moved from the helper user_single_step_siginfo into
      tracehook_report_syscall_exit itself, to make it clear that the local
      variable siginfo gets fully initialized.
      
      In a few cases the scope of struct siginfo has been reduced to make it
      clear that siginfo siginfo is not used on other paths in the function
      in which it is declared.
      
      Instances of using memset to initialize siginfo have been replaced
      with calls clear_siginfo for clarity.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      3eb0f519
    • A
      RISC-V: build vdso-dummy.o with -no-pie · 85602bea
      Aurelien Jarno 提交于
      Debian toolcahin defaults to PIE, and I guess that will also be the case
      of most distributions. This causes the following build failure:
      
        AS      arch/riscv/kernel/vdso/getcpu.o
        AS      arch/riscv/kernel/vdso/flush_icache.o
        VDSOLD  arch/riscv/kernel/vdso/vdso.so.dbg
        OBJCOPY arch/riscv/kernel/vdso/vdso.so
        AS      arch/riscv/kernel/vdso/vdso.o
        VDSOLD  arch/riscv/kernel/vdso/vdso-dummy.o
        LD      arch/riscv/kernel/vdso/vdso-syms.o
      riscv64-linux-gnu-ld: attempted static link of dynamic object `arch/riscv/kernel/vdso/vdso-dummy.o'
      make[2]: *** [arch/riscv/kernel/vdso/Makefile:43: arch/riscv/kernel/vdso/vdso-syms.o] Error 1
      make[1]: *** [scripts/Makefile.build:575: arch/riscv/kernel/vdso] Error 2
      make: *** [Makefile:1018: arch/riscv/kernel] Error 2
      
      While the root Makefile correctly passes "-fno-PIE" to build individual
      object files, the RISC-V kernel also builds vdso-dummy.o as an
      executable, which is therefore linked as PIE. Fix that by updating this
      specific link rule to also include "-no-pie".
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      85602bea
  20. 03 4月, 2018 5 次提交