1. 26 10月, 2015 2 次提交
    • P
      MIPS: Allow 24Hz timer frequency · 67596573
      Paul Burton 提交于
      A boundary exists beyond which the timer frequency becomes high enough
      that timer interrupts saturate the system and either cause it to slow to
      a crawl or stop functioning entirely. Where that boundary lies depends
      upon a number of factors such as the overhead of each interrupt and the
      overall speed of the CPU, but correlates strongly with the clock
      frequency at which the CPU runs. When running on emulators during
      bringup or debug of a CPU that clock frequency is very low, which
      results in the boundary at which the timer frequency becomes
      unsustainable being very low. The current minimum of 48Hz pushes against
      boundary in certain situations in current systems. Allow the kernel to
      be configured for a 24Hz timer frequency in order to avoid problems on
      such slow running systems.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11184/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      67596573
    • R
      MIPS: Use ARCH_USE_BUILTIN_BSWAP. · 1ee3630a
      Ralf Baechle 提交于
      ARCH_USE_BUILTIN_BSWAP will use __builtin_bswap16(), __builtin_bswap32()
      and __builtin_bswap64() where available.  This allows better instruction
      scheduling.  On pre-R2 processors it will result in 32 bit and 64 bit
      swapping being performed in a call to a __bswapsi2() rsp. __bswapdi2()
      functions, so we add these, too.
      
      For a 4.2 kernel with GCC 4.9 this yields the following kernel sizes:
      
         text    data     bss     dec     hex filename
      3996071  155804   88992 4240867  40b5e3 vmlinux         ip22 baseline
      3985687  159900   88992 4234579  409d53 vmlinux         ip22 + bswap patch
      6913157  378552  251024 7542733  7317cd vmlinux         ip27 baseline
      6878581  378552  251024 7508157  7290bd vmlinux         ip27 + bswap patch
      5773777  268752  187424 6229953  5f0fc1 vmlinux         malta baseline
      5773401  268752  187424 6229577  5f0e49 vmlinux         malta + bswap patch
      
      Presumably the code size improvments yield better cache hit rate thus
      better performance compensating for the extra function call but this
      will still need to be benchmarked.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1ee3630a
  2. 11 9月, 2015 1 次提交
    • D
      kexec: split kexec_load syscall from kexec core code · 2965faa5
      Dave Young 提交于
      There are two kexec load syscalls, kexec_load another and kexec_file_load.
       kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
      split kexec_load syscall code to kernel/kexec.c.
      
      And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
      use kexec_file_load only, or vice verse.
      
      The original requirement is from Ted Ts'o, he want kexec kernel signature
      being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
      kexec_load syscall can bypass the checking.
      
      Vivek Goyal proposed to create a common kconfig option so user can compile
      in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
      KEXEC_CORE so that old config files still work.
      
      Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
      architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
      KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
      kexec_load syscall.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2965faa5
  3. 03 9月, 2015 9 次提交
  4. 26 8月, 2015 1 次提交
  5. 04 8月, 2015 1 次提交
  6. 03 8月, 2015 1 次提交
  7. 01 8月, 2015 1 次提交
  8. 15 7月, 2015 1 次提交
    • R
      MIPS: SB1: Remove support for Pass 1 parts. · dd0bc75e
      Ralf Baechle 提交于
      Pass 1 parts had a number of significant erratas and were only available
      in small numbers and under NDA.  Full support also required the use of a
      special toolchain that kept branches properly aligned.  These workarounds
      were never upstreamed and the only toolchain known to have them is
      Montavista's GCC 3.0-based toolchain which completly obsoleted if not
      useless these days.
      
      So now that automated testing has tripped over the user of the
      -msb1-pass1-workarounds option, rather than fixing it remove support for
      pass 1 parts.
      
      Probably nobody will notice.  I seem to own the last know pass 1 board
      and I haven't noticed another one in the wild in the past decade, at
      least.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      dd0bc75e
  9. 14 7月, 2015 1 次提交
    • P
      MIPS: Require O32 FP64 support for MIPS64 with O32 compat · 4e9d324d
      Paul Burton 提交于
      MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with
      support for MIPS32r6 binaries but without support for O32 with FP64 is
      therefore a problem which can lead to incorrectly executed userland.
      
      CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is
      configured for MIPS32r6, but not when the kernel is configured for
      MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in
      such configurations to prevent building kernels which execute MIPS32r6
      userland incorrectly.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: <stable@vger.kernel.org> # v4.0-
      Cc: linux-mips@linux-mips.org
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: stable@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10674/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4e9d324d
  10. 09 7月, 2015 1 次提交
  11. 22 6月, 2015 18 次提交
  12. 28 5月, 2015 1 次提交
    • B
      EDAC: Cleanup atomic_scrub mess · b01aec9b
      Borislav Petkov 提交于
      So first of all, this atomic_scrub() function's naming is bad. It looks
      like an atomic_t helper. Change it to edac_atomic_scrub().
      
      The bigger problem is that this function is arch-specific and every new
      arch which doesn't necessarily need that functionality still needs to
      define it, otherwise EDAC doesn't compile.
      
      So instead of doing that and including arch-specific headers, have each
      arch define an EDAC_ATOMIC_SCRUB symbol which can be used in edac_mc.c
      for ifdeffery. Much cleaner.
      
      And we already are doing this with another symbol - EDAC_SUPPORT. This
      is also much cleaner than having CONFIG_EDAC enumerate all the arches
      which need/have EDAC support and drivers.
      
      This way I can kill the useless edac.h header in tile too.
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: NChris Metcalf <cmetcalf@ezchip.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-edac@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "Maciej W. Rozycki" <macro@codesourcery.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Steven J. Hill" <Steven.Hill@imgtec.com>
      Cc: x86@kernel.org
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      b01aec9b
  13. 15 4月, 2015 2 次提交
    • K
      mm: split ET_DYN ASLR from mmap ASLR · d1fd836d
      Kees Cook 提交于
      This fixes the "offset2lib" weakness in ASLR for arm, arm64, mips,
      powerpc, and x86.  The problem is that if there is a leak of ASLR from
      the executable (ET_DYN), it means a leak of shared library offset as
      well (mmap), and vice versa.  Further details and a PoC of this attack
      is available here:
      
        http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
      
      With this patch, a PIE linked executable (ET_DYN) has its own ASLR
      region:
      
        $ ./show_mmaps_pie
        54859ccd6000-54859ccd7000 r-xp  ...  /tmp/show_mmaps_pie
        54859ced6000-54859ced7000 r--p  ...  /tmp/show_mmaps_pie
        54859ced7000-54859ced8000 rw-p  ...  /tmp/show_mmaps_pie
        7f75be764000-7f75be91f000 r-xp  ...  /lib/x86_64-linux-gnu/libc.so.6
        7f75be91f000-7f75beb1f000 ---p  ...  /lib/x86_64-linux-gnu/libc.so.6
        7f75beb1f000-7f75beb23000 r--p  ...  /lib/x86_64-linux-gnu/libc.so.6
        7f75beb23000-7f75beb25000 rw-p  ...  /lib/x86_64-linux-gnu/libc.so.6
        7f75beb25000-7f75beb2a000 rw-p  ...
        7f75beb2a000-7f75beb4d000 r-xp  ...  /lib64/ld-linux-x86-64.so.2
        7f75bed45000-7f75bed46000 rw-p  ...
        7f75bed46000-7f75bed47000 r-xp  ...
        7f75bed47000-7f75bed4c000 rw-p  ...
        7f75bed4c000-7f75bed4d000 r--p  ...  /lib64/ld-linux-x86-64.so.2
        7f75bed4d000-7f75bed4e000 rw-p  ...  /lib64/ld-linux-x86-64.so.2
        7f75bed4e000-7f75bed4f000 rw-p  ...
        7fffb3741000-7fffb3762000 rw-p  ...  [stack]
        7fffb377b000-7fffb377d000 r--p  ...  [vvar]
        7fffb377d000-7fffb377f000 r-xp  ...  [vdso]
      
      The change is to add a call the newly created arch_mmap_rnd() into the
      ELF loader for handling ET_DYN ASLR in a separate region from mmap ASLR,
      as was already done on s390.  Removes CONFIG_BINFMT_ELF_RANDOMIZE_PIE,
      which is no longer needed.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reported-by: NHector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d1fd836d
    • K
      mm: expose arch_mmap_rnd when available · 2b68f6ca
      Kees Cook 提交于
      When an architecture fully supports randomizing the ELF load location,
      a per-arch mmap_rnd() function is used to find a randomized mmap base.
      In preparation for randomizing the location of ET_DYN binaries
      separately from mmap, this renames and exports these functions as
      arch_mmap_rnd(). Additionally introduces CONFIG_ARCH_HAS_ELF_RANDOMIZE
      for describing this feature on architectures that support it
      (which is a superset of ARCH_BINFMT_ELF_RANDOMIZE_PIE, since s390
      already supports a separated ET_DYN ASLR from mmap ASLR without the
      ARCH_BINFMT_ELF_RANDOMIZE_PIE logic).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b68f6ca