1. 20 7月, 2018 1 次提交
    • M
      MIPS: Correct the 64-bit DSP accumulator register size · f5958b4c
      Maciej W. Rozycki 提交于
      Use the `unsigned long' rather than `__u32' type for DSP accumulator
      registers, like with the regular MIPS multiply/divide accumulator and
      general-purpose registers, as all are 64-bit in 64-bit implementations
      and using a 32-bit data type leads to contents truncation on context
      saving.
      
      Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing
      casts that are similarly not used with multiply/divide accumulator or
      general-purpose register accesses.
      Signed-off-by: NMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: e50c0a8f ("Support the MIPS32 / MIPS64 DSP ASE.")
      Patchwork: https://patchwork.linux-mips.org/patch/19329/
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # 2.6.15+
      f5958b4c
  2. 09 10月, 2017 1 次提交
  3. 17 11月, 2016 1 次提交
  4. 16 11月, 2016 2 次提交
    • C
      locking/core, arch: Remove cpu_relax_lowlatency() · 5bd0b85b
      Christian Borntraeger 提交于
      As there are no users left, we can remove cpu_relax_lowlatency()
      implementations from every architecture.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Cc: <linux-arch@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1477386195-32736-6-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5bd0b85b
    • C
      locking/core: Introduce cpu_relax_yield() · 79ab11cd
      Christian Borntraeger 提交于
      For spinning loops people do often use barrier() or cpu_relax().
      For most architectures cpu_relax and barrier are the same, but on
      some architectures cpu_relax can add some latency.
      For example on power,sparc64 and arc, cpu_relax can shift the CPU
      towards other hardware threads in an SMT environment.
      On s390 cpu_relax does even more, it uses an hypercall to the
      hypervisor to give up the timeslice.
      In contrast to the SMT yielding this can result in larger latencies.
      In some places this latency is unwanted, so another variant
      "cpu_relax_lowlatency" was introduced. Before this is used in more
      and more places, lets revert the logic and provide a cpu_relax_yield
      that can be called in places where yielding is more important than
      latency. By default this is the same as cpu_relax on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1477386195-32736-2-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79ab11cd
  5. 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
  6. 13 5月, 2016 2 次提交
    • L
      MIPS64: Support of at least 48 bits of SEGBITS · 1e321fa9
      Leonid Yegoshin 提交于
      SEGBITS is 40 bits or more, depending on CPU type.  Introduces optional
      support for 48 bits of application virtual address space.  Only 16K and
      64K pages are supported.
      
      Enabling will result in a memory overhead of a small number of pages for
      small applications.  For 64K pages a 3rd level of page tables is required
      which has some impact during software TLB refill.
      
      [ralf@linux-mips.org: Fixed things raised in the review of the version
      posted and changed kconfig to be a bit more userfriendly.]
      Signed-off-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: aleksey.makarov@auriga.com
      Cc: james.hogan@imgtec.com
      Cc: paul.burton@imgtec.com
      Cc: david.daney@cavium.com
      Cc: peterz@infradead.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: davidlohr@hp.com
      Cc: kirill@shutemov.name
      Cc: akpm@linux-foundation.org
      Cc: mingo@kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10051/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1e321fa9
    • R
      MIPS: Make flush_thread · 04cc89d1
      Ralf Baechle 提交于
      Avoids function calls to an empty function.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      04cc89d1
  7. 04 2月, 2016 1 次提交
  8. 11 11月, 2015 1 次提交
    • A
      MIPS: Initial implementation of a VDSO · ebb5e78c
      Alex Smith 提交于
      Add an initial implementation of a proper (i.e. an ELF shared library)
      VDSO. With this commit it does not export any symbols, it only replaces
      the current signal return trampoline page. A later commit will add user
      implementations of gettimeofday()/clock_gettime().
      
      To support both new toolchains and old ones which don't generate ABI
      flags section, we define its content manually and then use a tool
      (genvdso) to patch up the section to have the correct name and type.
      genvdso also extracts symbol offsets ({,rt_}sigreturn) needed by the
      kernel, and generates a C file containing a "struct mips_vdso_image"
      containing both the VDSO data and these offsets. This C file is
      compiled into the kernel.
      
      On 64-bit kernels we require a different VDSO for each supported ABI,
      so we may build up to 3 different VDSOs. The VDSO to use is selected by
      the mips_abi structure.
      
      A kernel/user shared data page is created and mapped below the VDSO
      image. This is currently empty, but will be used by the user time
      function implementations which are added later.
      
      [markos.chandras@imgtec.com:
      - Add more comments
      - Move abi detection in genvdso.h since it's the get_symbol function
      that needs it.
      - Add an R6 specific way to calculate the base address of VDSO in order
      to avoid the branch instruction which affects performance.
      - Do not patch .gnu.attributes since it's not needed for dynamic linking.
      - Simplify Makefile a little bit.
      - checkpatch fixes
      - Restrict VDSO support for binutils < 2.25 for pre-R6
      - Include atomic64.h for O32 variant on MIPS64]
      Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/11337/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ebb5e78c
  9. 03 9月, 2015 1 次提交
  10. 28 3月, 2015 1 次提交
  11. 20 2月, 2015 2 次提交
  12. 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
  13. 24 9月, 2014 1 次提交
  14. 02 8月, 2014 1 次提交
    • P
      MIPS: 16 byte align MSA vector context · 37cddff8
      Paul Burton 提交于
      The MSA specification upon first read appears to suggest that it is safe
      to perform vector loads & stores with arbitrary alignment. However it
      leaves provision for "address-dependent exceptions"... Align the vector
      context to a 16 byte boundary to ensure that the kernel cannot cause any
      such exceptions.
      
      Note that the fpu field of struct thread_struct was already at a 16 byte
      boundary within the struct, the introduction of FPU_ALIGN simply makes
      the requirement explicit. The only part of this impacting the generated
      kernel binary is ARCH_MIN_TASKALIGN.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7308/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      37cddff8
  15. 17 7月, 2014 1 次提交
    • D
      arch, locking: Ciao arch_mutex_cpu_relax() · 3a6bfbc9
      Davidlohr Bueso 提交于
      The arch_mutex_cpu_relax() function, introduced by 34b133f8, is
      hacky and ugly. It was added a few years ago to address the fact
      that common cpu_relax() calls include yielding on s390, and thus
      impact the optimistic spinning functionality of mutexes. Nowadays
      we use this function well beyond mutexes: rwsem, qrwlock, mcs and
      lockref. Since the macro that defines the call is in the mutex header,
      any users must include mutex.h and the naming is misleading as well.
      
      This patch (i) renames the call to cpu_relax_lowlatency  ("relax, but
      only if you can do it with very low latency") and (ii) defines it in
      each arch's asm/processor.h local header, just like for regular cpu_relax
      functions. On all archs, except s390, cpu_relax_lowlatency is simply cpu_relax,
      and thus we can take it out of mutex.h. While this can seem redundant,
      I believe it is a good choice as it allows us to move out arch specific
      logic from generic locking primitives and enables future(?) archs to
      transparently define it, similarly to System Z.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharat Bhushan <r65777@freescale.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Joseph Myers <joseph@codesourcery.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Qiaowei Ren <qiaowei.ren@intel.com>
      Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Stratos Karafotis <stratosk@semaphore.gr>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Kulikov <segoon@openwall.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: adi-buildroot-devel@lists.sourceforge.net
      Cc: linux390@de.ibm.com
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-cris-kernel@axis.com
      Cc: linux-hexagon@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux@lists.openrisc.net
      Cc: linux-m32r-ja@ml.linux-m32r.org
      Cc: linux-m32r@ml.linux-m32r.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-metag@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: sparclinux@vger.kernel.org
      Link: http://lkml.kernel.org/r/1404079773.2619.4.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3a6bfbc9
  16. 27 3月, 2014 3 次提交
  17. 01 7月, 2013 1 次提交
  18. 13 6月, 2013 2 次提交
  19. 22 5月, 2013 1 次提交
  20. 08 5月, 2013 1 次提交
  21. 01 2月, 2013 1 次提交
  22. 12 12月, 2012 1 次提交
  23. 15 10月, 2012 1 次提交
  24. 17 5月, 2012 1 次提交
    • S
      fork: move the real prepare_to_copy() users to arch_dup_task_struct() · 55ccf3fe
      Suresh Siddha 提交于
      Historical prepare_to_copy() is mostly a no-op, duplicated for majority of
      the architectures and the rest following the x86 model of flushing the extended
      register state like fpu there.
      
      Remove it and use the arch_dup_task_struct() instead.
      Suggested-by: NOleg Nesterov <oleg@redhat.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1336692811-30576-1-git-send-email-suresh.b.siddha@intel.comAcked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      55ccf3fe
  25. 29 3月, 2012 1 次提交
  26. 31 3月, 2011 1 次提交
  27. 30 10月, 2010 1 次提交
    • D
      MIPS: Make TASK_SIZE reflect proper size for both 32 and 64 bit processes. · 949e51be
      David Daney 提交于
      The TASK_SIZE macro should reflect the size of a user process virtual
      address space.  Previously for 64-bit kernels, this was not the case.
      The immediate cause of pain was in
      hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes
      trying to mmap a huge page would be served a page with an address
      outside of the 32-bit address range.  But there are other uses of
      TASK_SIZE in the kernel as well that would like an accurate value.
      
      The new definition is nice because it now makes TASK_SIZE and
      TASK_SIZE_OF() yield the same value for any given process.
      
      For 32-bit kernels there should be no change, although I did factor
      out some code in asm/processor.h that became identical for the 32-bit and
      64-bit cases.
      
      __UA_LIMIT is now set to ~((1 << SEGBITS) - 1) for 64-bit kernels.
      This should eliminate the possibility of getting a
      AddressErrorException in the kernel for addresses that pass the
      access_ok() test.
      
      With the patch applied, I can still run o32, n32 and n64 processes,
      and have an o32 shell fork/exec both n32 and n64 processes.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      To: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/1701/
      949e51be
  28. 05 8月, 2010 2 次提交
  29. 22 5月, 2010 1 次提交
  30. 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
  31. 04 8月, 2009 1 次提交
    • D
      MIPS: Avoid clobbering struct pt_regs in kthreads · 484889fc
      David Daney 提交于
      The resume() implementation octeon_switch.S examines the saved cp0_status
      register.  We were clobbering the entire pt_regs structure in kernel
      threads leading to random crashes.
      
      When switching away from a kernel thread, the saved cp0_status is examined
      and if bit 30 is set it is cleared and the CP2 state saved into the pt_regs
      structure.  Since the kernel thread stack overlaid the pt_regs structure
      this resulted in a corrupt stack.  When the kthread with the corrupt stack
      was resumed, it could crash if it used any of the data in the stack that was
      clobbered.
      
      We fix it by moving the kernel thread stack down so it doesn't overlay
      pt_regs.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      484889fc
  32. 11 1月, 2009 1 次提交
  33. 11 10月, 2008 1 次提交