1. 13 1月, 2016 1 次提交
  2. 28 12月, 2015 1 次提交
  3. 22 12月, 2015 3 次提交
    • J
      MIPS: uaccess: Take EVA into account in [__]clear_user · d6a428fb
      James Hogan 提交于
      __clear_user() (and clear_user() which uses it), always access the user
      mode address space, which results in EVA store instructions when EVA is
      enabled even if the current user address limit is KERNEL_DS.
      
      Fix this by adding a new symbol __bzero_kernel for the normal kernel
      address space bzero in EVA mode, and call that from __clear_user() if
      eva_kernel_access().
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10844/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d6a428fb
    • J
      MIPS: uaccess: Take EVA into account in __copy_from_user() · 6f06a2c4
      James Hogan 提交于
      When EVA is in use, __copy_from_user() was unconditionally using the EVA
      instructions to read the user address space, however this can also be
      used for kernel access. If the address isn't a valid user address it
      will cause an address error or TLB exception, and if it is then user
      memory may be read instead of kernel memory.
      
      For example in the following stack trace from Linux v3.10 (changes since
      then will prevent this particular one still happening) kernel_sendmsg()
      set the user address limit to KERNEL_DS, and tcp_sendmsg() goes on to
      use __copy_from_user() with a kernel address in KSeg0.
      
      [<8002d434>] __copy_fromuser_common+0x10c/0x254
      [<805710e0>] tcp_sendmsg+0x5f4/0xf00
      [<804e8e3c>] sock_sendmsg+0x78/0xa0
      [<804e8f28>] kernel_sendmsg+0x24/0x38
      [<804ee0f8>] sock_no_sendpage+0x70/0x7c
      [<8017c820>] pipe_to_sendpage+0x80/0x98
      [<8017c6b0>] splice_from_pipe_feed+0xa8/0x198
      [<8017cc54>] __splice_from_pipe+0x4c/0x8c
      [<8017e844>] splice_from_pipe+0x58/0x78
      [<8017e884>] generic_splice_sendpage+0x20/0x2c
      [<8017d690>] do_splice_from+0xb4/0x110
      [<8017d710>] direct_splice_actor+0x24/0x30
      [<8017d394>] splice_direct_to_actor+0xd8/0x208
      [<8017d51c>] do_splice_direct+0x58/0x7c
      [<8014eaf4>] do_sendfile+0x1dc/0x39c
      [<8014f82c>] SyS_sendfile+0x90/0xf8
      
      Add the eva_kernel_access() check in __copy_from_user() like the one in
      copy_from_user().
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10843/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      6f06a2c4
    • J
      MIPS: uaccess: Fix strlen_user with EVA · 5dc62fdd
      James Hogan 提交于
      The strlen_user() function calls __strlen_kernel_asm in both branches of
      the eva_kernel_access() conditional. For EVA it should be calling
      __strlen_user_eva for user accesses, otherwise it will load from the
      kernel address space instead of the user address space, and the access
      checking will likely be ineffective at preventing it due to EVA's
      overlapping user and kernel address spaces.
      
      This was found after extending the test_user_copy module to cover user
      string access functions, which gave the following error with EVA:
      
      test_user_copy: illegal strlen_user passed
      
      Fortunately the use of strlen_user() has been all but eradicated from
      the mainline kernel, so only out of tree modules could be affected.
      
      Fixes: e3a9b07a ("MIPS: asm: uaccess: Add EVA support for str*_user operations")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.15.x-
      Patchwork: https://patchwork.linux-mips.org/patch/10842/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5dc62fdd
  4. 16 11月, 2015 1 次提交
  5. 12 11月, 2015 2 次提交
  6. 11 11月, 2015 17 次提交
  7. 10 11月, 2015 1 次提交
  8. 05 11月, 2015 1 次提交
  9. 26 10月, 2015 7 次提交
  10. 23 10月, 2015 2 次提交
  11. 13 10月, 2015 1 次提交
  12. 06 10月, 2015 1 次提交
  13. 27 9月, 2015 2 次提交
    • P
      MIPS: Initialise MAARs on secondary CPUs · e060f6ed
      Paul Burton 提交于
      MAARs should be initialised on each CPU (or rather, core) in the system
      in order to achieve consistent behaviour & performance. Previously they
      have only been initialised on the boot CPU which leads to performance
      problems if tasks are later scheduled on a secondary CPU, particularly
      if those tasks make use of unaligned vector accesses where some CPUs
      don't handle any cases in hardware for non-speculative memory regions.
      Fix this by recording the MAAR configuration from the boot CPU and
      applying it to secondary CPUs as part of their bringup.
      Reported-by: NDoug Gilmore <doug.gilmore@imgtec.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Andrew Bresticker <abrestic@chromium.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Hemmo Nieminen <hemmo.nieminen@iki.fi>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Patchwork: https://patchwork.linux-mips.org/patch/11239/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e060f6ed
    • P
      MIPS: CM: Provide a function to map from CPU to VP ID. · 7573b94e
      Paul Burton 提交于
      The VP ID of a given CPU may not match up with the CPU number used by
      Linux. For example, if the width of the VP part of the VP ID is wider
      than log2(number of VPs per core) and the system has multiple cores then
      this will be the case. Alternatively, if a pre-r6 system implements the
      MT ASE with multiple VPEs per core and Linux is built without support
      for the MT ASE then the numbers won't match up either. Provide a
      function to convert from CPU number to VP ID.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/11211/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      7573b94e