1. 02 8月, 2016 1 次提交
    • P
      MIPS: Use per-mm page to execute branch delay slot instructions · 432c6bac
      Paul Burton 提交于
      In some cases the kernel needs to execute an instruction from the delay
      slot of an emulated branch instruction. These cases include:
      
        - Emulated floating point branch instructions (bc1[ft]l?) for systems
          which don't include an FPU, or upon which the kernel is run with the
          "nofpu" parameter.
      
        - MIPSr6 systems running binaries targeting older revisions of the
          architecture, which may include branch instructions whose encodings
          are no longer valid in MIPSr6.
      
      Executing instructions from such delay slots is done by writing the
      instruction to memory followed by a trap, as part of an "emuframe", and
      executing it. This avoids the requirement of an emulator for the entire
      MIPS instruction set. Prior to this patch such emuframes are written to
      the user stack and executed from there.
      
      This patch moves FP branch delay emuframes off of the user stack and
      into a per-mm page. Allocating a page per-mm leaves userland with access
      to only what it had access to previously, and compared to other
      solutions is relatively simple.
      
      When a thread requires a delay slot emulation, it is allocated a frame.
      A thread may only have one frame allocated at any one time, since it may
      only ever be executing one instruction at any one time. In order to
      ensure that we can free up allocated frame later, its index is recorded
      in struct thread_struct. In the typical case, after executing the delay
      slot instruction we'll execute a break instruction with the BRK_MEMU
      code. This traps back to the kernel & leads to a call to do_dsemulret
      which frees the allocated frame & moves the user PC back to the
      instruction that would have executed following the emulated branch.
      In some cases the delay slot instruction may be invalid, such as a
      branch, or may trigger an exception. In these cases the BRK_MEMU break
      instruction will not be hit. In order to ensure that frames are freed
      this patch introduces dsemul_thread_cleanup() and calls it to free any
      allocated frame upon thread exit. If the instruction generated an
      exception & leads to a signal being delivered to the thread, or indeed
      if a signal simply happens to be delivered to the thread whilst it is
      executing from the struct emuframe, then we need to take care to exit
      the frame appropriately. This is done by either rolling back the user PC
      to the branch or advancing it to the continuation PC prior to signal
      delivery, using dsemul_thread_rollback(). If this were not done then a
      sigreturn would return to the struct emuframe, and if that frame had
      meanwhile been used in response to an emulated branch instruction within
      the signal handler then we would execute the wrong user code.
      
      Whilst a user could theoretically place something like a compact branch
      to self in a delay slot and cause their thread to become stuck in an
      infinite loop with the frame never being deallocated, this would:
      
        - Only affect the users single process.
      
        - Be architecturally invalid since there would be a branch in the
          delay slot, which is forbidden.
      
        - Be extremely unlikely to happen by mistake, and provide a program
          with no more ability to harm the system than a simple infinite loop
          would.
      
      If a thread requires a delay slot emulation & no frame is available to
      it (ie. the process has enough other threads that all frames are
      currently in use) then the thread joins a waitqueue. It will sleep until
      a frame is freed by another thread in the process.
      
      Since we now know whether a thread has an allocated frame due to our
      tracking of its index, the cookie field of struct emuframe is removed as
      we can be more certain whether we have a valid frame. Since a thread may
      only ever have a single frame at any given time, the epc field of struct
      emuframe is also removed & the PC to continue from is instead stored in
      struct thread_struct. Together these changes simplify & shrink struct
      emuframe somewhat, allowing twice as many frames to fit into the page
      allocated for them.
      
      The primary benefit of this patch is that we are now free to mark the
      user stack non-executable where that is possible.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13764/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      432c6bac
  2. 13 5月, 2016 1 次提交
  3. 16 2月, 2015 1 次提交
    • M
      MIPS: HTW: Prevent accidental HTW start due to nested htw_{start, stop} · ed4cbc81
      Markos Chandras 提交于
      activate_mm() and switch_mm() call get_new_mmu_context() which in turn
      can enable the HTW before the entryhi is changed with the new ASID.
      Since the latter will enable the HTW in local_flush_tlb_all(),
      then there is a small timing window where the HTW is running with the
      new ASID but with an old pgd since the TLBMISS_HANDLER_SETUP_PGD
      hasn't assigned a new one yet. In order to prevent that, we introduce a
      simple htw counter to avoid starting HTW accidentally due to nested
      htw_{start,stop}() sequences. Moreover, since various IPI calls can
      enforce TLB flushing operations on a different core, such an operation
      may interrupt another htw_{stop,start} in progress leading inconsistent
      updates of the htw_seq variable. In order to avoid that, we disable the
      interrupts whenever we update that variable.
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: <stable@vger.kernel.org> # 3.17+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9118/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ed4cbc81
  4. 12 2月, 2015 1 次提交
    • P
      MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS · 9791554b
      Paul Burton 提交于
      Userland code may be built using an ABI which permits linking to objects
      that have more restrictive floating point requirements. For example,
      userland code may be built to target the O32 FPXX ABI. Such code may be
      linked with other FPXX code, or code built for either one of the more
      restrictive FP32 or FP64. When linking with more restrictive code, the
      overall requirement of the process becomes that of the more restrictive
      code. The kernel has no way to know in advance which mode the process
      will need to be executed in, and indeed it may need to change during
      execution. The dynamic loader is the only code which will know the
      overall required mode, and so it needs to have a means to instruct the
      kernel to switch the FP mode of the process.
      
      This patch introduces 2 new options to the prctl syscall which provide
      such a capability. The FP mode of the process is represented as a
      simple bitmask combining a number of mode bits mirroring those present
      in the hardware. Userland can either retrieve the current FP mode of
      the process:
      
        mode = prctl(PR_GET_FP_MODE);
      
      or modify the current FP mode of the process:
      
        err = prctl(PR_SET_FP_MODE, new_mode);
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8899/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9791554b
  5. 02 8月, 2014 1 次提交
    • M
      MIPS: mm: Use the Hardware Page Table Walker if the core supports it · f1014d1b
      Markos Chandras 提交于
      The Hardware Page Table Walker aims to speed up TLB refill exceptions
      by handling them in the hardware level instead of having a software
      TLB refill handler. However, a TLB refill exception can still be
      thrown in certain cases such as, synchronus exceptions, or address
      translation or memory errors during the HTW operation. As a result of
      which, HTW must not be considered a complete replacement for the TLB
      refill software handler, but rather a fast-path for it.
      For HTW to work, the PWBase register must contain the task's page
      global directory address so the HTW will kick in on TLB refill
      exceptions.
      
      Due to HTW being a separate engine embedded deep in the CPU pipeline,
      we need to restart the HTW everytime a PTE changes to avoid HTW
      fetching a old entry from the page tables. It's also necessary to
      restart the HTW on context switches to prevent it from fetching a
      page from the previous process. Finally, since HTW is using the
      entryhi register to write the translations to the TLB, it's necessary
      to stop the HTW whenever the entryhi changes (eg for tlb probe
      perations) and enable it back afterwards.
      
      == Performance ==
      
      The following trivial test was used to measure the performance of the
      HTW. Using the same root filesystem, the following command was used
      to measure the number of tlb refill handler executions with and
      without (using 'nohtw' kernel parameter) HTW support.  The kernel was
      modified to use a scratch register as a counter for the TLB refill
      exceptions.
      
      find /usr -type f -exec ls -lh {} \;
      
      HTW Enabled:
      TLB refill exceptions: 12306
      
      HTW Disabled:
      TLB refill exceptions: 17805
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/7336/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f1014d1b
  6. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      Ralf Baechle 提交于
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
      Which is a pity - the SMTC technology primarily developed by Kevin D.
      Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
      ASE's power and elegance.
      
      Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
      https://patchwork.linux-mips.org/patch/6719/ which while very similar did
      no longer apply cleanly when I tried to merge it plus some additional
      post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
      merge once upon a time.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  7. 02 5月, 2014 1 次提交
  8. 30 10月, 2013 2 次提交
  9. 01 7月, 2013 1 次提交
  10. 11 6月, 2013 1 次提交
  11. 17 5月, 2013 1 次提交
  12. 08 5月, 2013 3 次提交
  13. 11 4月, 2013 1 次提交
  14. 01 2月, 2013 1 次提交
  15. 14 12月, 2012 1 次提交
  16. 28 4月, 2012 1 次提交
  17. 19 1月, 2011 1 次提交
  18. 13 4月, 2010 1 次提交
    • D
      MIPS: Preliminary VDSO · c52d0d30
      David Daney 提交于
      This is a preliminary patch to add a vdso to all user processes.  Still
      missing are ELF headers and .eh_frame information.  But it is enough to
      allow us to move signal trampolines off of the stack.  Note that emulation
      of branch delay slots in the FPU emulator still requires the stack.
      
      We allocate a single page (the vdso) and write all possible signal
      trampolines into it.  The stack is moved down by one page and the vdso is
      mapped into this space.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      To: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/975/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c52d0d30
  19. 17 12月, 2009 1 次提交
    • D
      MIPS: Put PGD in C0_CONTEXT for 64-bit R2 processors. · 82622284
      David Daney 提交于
      Processors that support the mips64r2 ISA can in four instructions
      convert a shifted PGD pointer stored in the upper bits of c0_context
      into a usable pointer.  By doing this we save a memory load and
      associated potential cache miss in the TLB exception handlers.
      
      Since the upper bits of c0_context were holding the CPU number, we
      move this to the upper bits of c0_xcontext which doesn't have enough
      bits to hold the PGD pointer, but has plenty for the CPU number.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      82622284
  20. 02 11月, 2009 2 次提交
  21. 24 9月, 2009 1 次提交
  22. 25 6月, 2009 1 次提交
  23. 11 10月, 2008 1 次提交
  24. 12 10月, 2007 2 次提交
  25. 03 5月, 2007 1 次提交
    • J
      [PATCH] x86: PARAVIRT: add hooks to intercept mm creation and destruction · d6dd61c8
      Jeremy Fitzhardinge 提交于
      Add hooks to allow a paravirt implementation to track the lifetime of
      an mm.  Paravirtualization requires three hooks, but only two are
      needed in common code.  They are:
      
      arch_dup_mmap, which is called when a new mmap is created at fork
      
      arch_exit_mmap, which is called when the last process reference to an
        mm is dropped, which typically happens on exit and exec.
      
      The third hook is activate_mm, which is called from the arch-specific
      activate_mm() macro/function, and so doesn't need stub versions for
      other architectures.  It's called when an mm is first used.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: linux-arch@vger.kernel.org
      Cc: James Bottomley <James.Bottomley@SteelEye.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      d6dd61c8
  26. 27 9月, 2006 1 次提交
  27. 26 4月, 2006 1 次提交
  28. 19 4月, 2006 1 次提交
  29. 21 3月, 2006 1 次提交
  30. 30 10月, 2005 1 次提交
  31. 05 9月, 2005 1 次提交
  32. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4