1. 14 6月, 2018 1 次提交
    • L
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds 提交于
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      supported.
      
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      directly.
      
      HOWEVER.
      
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_NONE is not set
        # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_STACKPROTECTOR_AUTO=y
      
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_STACKPROTECTOR=y
        CONFIG_STACKPROTECTOR_STRONG=y
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  2. 29 8月, 2017 1 次提交
  3. 12 4月, 2017 1 次提交
  4. 03 1月, 2017 1 次提交
  5. 13 5月, 2016 1 次提交
  6. 03 9月, 2015 1 次提交
    • P
      MIPS: Tidy up FPU context switching · 1a3d5957
      Paul Burton 提交于
      Rather than saving the scalar FP or vector context in the assembly
      resume function, reuse the existing C code we have in fpu.h to do
      exactly that. This reduces duplication, results in a much easier to read
      resume function & should allow the compiler to optimise out more MSA
      code due to is_msa_enabled()/cpu_has_msa being known-zero at compile
      time for kernels without MSA support.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Manuel Lauss <manuel.lauss@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/10830/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1a3d5957
  7. 08 4月, 2015 1 次提交
  8. 17 2月, 2015 1 次提交
  9. 07 11月, 2014 1 次提交
    • M
      MIPS: Fix build with binutils 2.24.51+ · 842dfc11
      Manuel Lauss 提交于
      Starting with version 2.24.51.20140728 MIPS binutils complain loudly
      about mixing soft-float and hard-float object files, leading to this
      build failure since GCC is invoked with "-msoft-float" on MIPS:
      
      {standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
        LD      arch/mips/alchemy/common/built-in.o
      mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
       uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
       arch/mips/alchemy/common/sleeper.o uses -mhard-float
      
      To fix this, we detect if GAS is new enough to support "-msoft-float" command
      option, and if it does, we can let GCC pass it to GAS;  but then we also need
      to sprinkle the files which make use of floating point registers with the
      necessary ".set hardfloat" directives.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Cc: Linux-MIPS <linux-mips@linux-mips.org>
      Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
      Cc: Markos Chandras <Markos.Chandras@imgtec.com>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/8355/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      842dfc11
  10. 02 8月, 2014 2 次提交
  11. 31 5月, 2014 1 次提交
  12. 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
  13. 01 4月, 2014 1 次提交
    • R
      MIPS: Fix gigaton of warning building with microMIPS. · a809d460
      Ralf Baechle 提交于
      With binutils 2.24 the attempt to switch with microMIPS mode to MIPS III
      mode through .set mips3 results in *lots* of warnings like
      
      {standard input}: Assembler messages:
      {standard input}:397: Warning: the 64-bit MIPS architecture does not support the `smartmips' extension
      
      during a kernel build.  Fixed by using .set arch=r4000 instead.
      
      This breaks support for building the kernel with binutils 2.13 which
      was supported for 32 bit kernels only anyway and 2.14 which was a bad
      vintage for MIPS anyway.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a809d460
  14. 27 3月, 2014 1 次提交
    • P
      MIPS: Basic MSA context switching support · 1db1af84
      Paul Burton 提交于
      This patch adds support for context switching the MSA vector registers.
      These 128 bit vector registers are aliased with the FP registers - an
      FP register accesses the least significant bits of the vector register
      with which it is aliased (ie. the register with the same index). Due to
      both this & the requirement that the scalar FPU must be 64-bit (FR=1) if
      enabled at the same time as MSA the kernel will enable MSA & scalar FP
      at the same time for tasks which use MSA. If we restore the MSA vector
      context then we might as well enable the scalar FPU since the reason it
      was left disabled was to allow for lazy FP context restoring - but we
      just restored the FP context as it's a subset of the vector context. If
      we restore the FP context and have previously used MSA then we have to
      restore the whole vector context anyway (see comment in
      enable_restore_fp_context for details) so similarly we might as well
      enable MSA.
      
      Thus if a task does not use MSA then it will continue to behave as
      without this patch - the scalar FP context will be saved & restored as
      usual. But if a task executes an MSA instruction then it will save &
      restore the vector context forever more.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6431/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1db1af84
  15. 14 1月, 2014 1 次提交
    • P
      MIPS: Support for 64-bit FP with O32 binaries · 597ce172
      Paul Burton 提交于
      CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
      do. In order to preserve backwards compatibility a 64-bit FPU will act
      like a 32-bit FPU (by accessing doubles from the least significant 32
      bits of an even-odd pair of FP registers) when the Status.FR bit is
      zero, again just like a mips64 CPU. The standard O32 ABI is defined
      expecting a 32-bit FPU, however recent toolchains support use of a
      64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
      built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
      header.
      
      With this patch the kernel will check the EF_MIPS_FP64 flag when
      executing an O32 binary, and set Status.FR accordingly. The addition
      of O32 64-bit FP support lessens the opportunity for optimisation in
      the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
      introduced to allow this support to be disabled for those that don't
      require it.
      
      Inspired by an earlier patch by Leonid Yegoshin, but implemented more
      cleanly & correctly.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      597ce172
  16. 07 10月, 2013 1 次提交
    • J
      MIPS: stack protector: Fix per-task canary switch · 8b3c569a
      James Hogan 提交于
      Commit 1400eb65 (MIPS: r4k,octeon,r2300: stack protector: change canary
      per task) was merged in v3.11 and introduced assembly in the MIPS resume
      functions to update the value of the current canary in
      __stack_chk_guard. However it used PTR_L resulting in a load of the
      canary value, instead of PTR_LA to construct its address. The value is
      intended to be random but is then treated as an address in the
      subsequent LONG_S (store).
      
      This was observed to cause a fault and panic:
      
      CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
      Oops[#1]:
      ...
      $24   : 139fea20 1e1f7cb6
      ...
      Call Trace:
      [<8000cc0c>] resume+0xac/0x118
      [<8034f2a4>] __schedule+0x5f8/0x78c
      [<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
      [<80348eec>] rest_init+0x74/0x84
      [<804dc990>] start_kernel+0x43c/0x454
      Code: 3c18804b  8f184030  8cb901f8 <af190000> 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc
      
      This can also be forced by modifying
      arch/mips/include/asm/stackprotector.h so that the default
      __stack_chk_guard value is more likely to be a bad (or unaligned)
      pointer.
      
      Fix it to use PTR_LA instead, to load the address of the canary value,
      which the LONG_S can then use to write into it.
      
      Reported-by: bobjones (via #mipslinux on IRC)
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Gregory Fong <gregory.0xf0@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/6026/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8b3c569a
  17. 01 7月, 2013 1 次提交
  18. 01 2月, 2013 1 次提交
  19. 29 12月, 2012 1 次提交
  20. 19 7月, 2012 1 次提交
  21. 06 4月, 2011 1 次提交
  22. 18 9月, 2009 1 次提交
  23. 13 7月, 2007 1 次提交
  24. 07 6月, 2007 1 次提交
  25. 20 4月, 2007 1 次提交
  26. 17 3月, 2007 1 次提交
  27. 02 11月, 2006 1 次提交
  28. 01 7月, 2006 1 次提交
  29. 30 6月, 2006 1 次提交
  30. 20 6月, 2006 1 次提交
    • A
      [MIPS] Fix fpu_save_double on 64-bit. · c138e12f
      Atsushi Nemoto 提交于
      > Without this fix, _save_fp() in 64-bit kernel is seriously broken.
      >
      > ffffffff8010bec0 <_save_fp>:
      > ffffffff8010bec0:       400d6000        mfc0    t1,c0_status
      > ffffffff8010bec4:       000c7140        sll     t2,t0,0x5
      > ffffffff8010bec8:       05c10011        bgez    t2,ffffffff8010bf10 <_save_fp+0x50>
      > ffffffff8010becc:       00000000        nop
      > ffffffff8010bed0:       f4810328        sdc1    $f1,808(a0)
      > ...
      
      Fix register usage in fpu_save_double() and make fpu_restore_double()
      more symmetric with fpu_save_double().
      Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c138e12f
  31. 19 4月, 2006 1 次提交
  32. 30 10月, 2005 2 次提交
  33. 10 9月, 2005 1 次提交
  34. 05 9月, 2005 2 次提交
  35. 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