Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 05 3月, 2018 1 次提交
    • J
      MIPS: Expand help text to list generic defconfigs · cccd0b9a
      由 James Hogan 提交于 
      Expand the MIPS Makefile help text to list generic board names, generic
defconfigs, and legacy defconfigs which have been converted to generic
and are still usable.

Here's a snippet of the new "make ARCH=mips help" output:
  ...
  If you are targeting a system supported by generic kernels you may
  configure the kernel for a given architecture target like so:

  {micro32,32,64}{r1,r2,r6}{el,}_defconfig <BOARDS="list of boards">

  Where BOARDS is some subset of the following:
    boston
    ni169445
    ranchu
    sead-3
    xilfpga

  Specifically the following generic default configurations are
  supported:

  32r1_defconfig           - Build generic kernel for MIPS32 r1
  32r1el_defconfig         - Build generic kernel for MIPS32 r1 little endian
  32r2_defconfig           - Build generic kernel for MIPS32 r2
  32r2el_defconfig         - Build generic kernel for MIPS32 r2 little endian
  32r6_defconfig           - Build generic kernel for MIPS32 r6
  32r6el_defconfig         - Build generic kernel for MIPS32 r6 little endian
  64r1_defconfig           - Build generic kernel for MIPS64 r1
  64r1el_defconfig         - Build generic kernel for MIPS64 r1 little endian
  64r2_defconfig           - Build generic kernel for MIPS64 r2
  64r2el_defconfig         - Build generic kernel for MIPS64 r2 little endian
  64r6_defconfig           - Build generic kernel for MIPS64 r6
  64r6el_defconfig         - Build generic kernel for MIPS64 r6 little endian
  micro32r2_defconfig      - Build generic kernel for microMIPS32 r2
  micro32r2el_defconfig    - Build generic kernel for microMIPS32 r2 little endian

  The following legacy default configurations have been converted to
  generic and can still be used:

  sead3_defconfig          - Build 32r2el_defconfig BOARDS=sead-3
  sead3micro_defconfig     - Build micro32r2el_defconfig BOARDS=sead-3
  xilfpga_defconfig        - Build 32r2el_defconfig BOARDS=xilfpga
  ...
Signed-off-by: NJames Hogan <jhogan@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Matt Redfearn <matt.redfearn@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/18598/
      cccd0b9a
  3. 20 2月, 2018 4 次提交
  5. 19 2月, 2018 10 次提交
  7. 17 2月, 2018 3 次提交
  9. 16 2月, 2018 5 次提交
  11. 15 2月, 2018 14 次提交
  13. 13 2月, 2018 3 次提交
    • T
      x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages · fd0e786d
      由 Tony Luck 提交于 
      In the following commit:

  ce0fa3e5 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages")

... we added code to memory_failure() to unmap the page from the
kernel 1:1 virtual address space to avoid speculative access to the
page logging additional errors.

But memory_failure() may not always succeed in taking the page offline,
especially if the page belongs to the kernel.  This can happen if
there are too many corrected errors on a page and either mcelog(8)
or drivers/ras/cec.c asks to take a page offline.

Since we remove the 1:1 mapping early in memory_failure(), we can
end up with the page unmapped, but still in use. On the next access
the kernel crashes :-(

There are also various debug paths that call memory_failure() to simulate
occurrence of an error. Since there is no actual error in memory, we
don't need to map out the page for those cases.

Revert most of the previous attempt and keep the solution local to
arch/x86/kernel/cpu/mcheck/mce.c. Unmap the page only when:

	1) there is a real error
	2) memory_failure() succeeds.

All of this only applies to 64-bit systems. 32-bit kernel doesn't map
all of memory into kernel space. It isn't worth adding the code to unmap
the piece that is mapped because nobody would run a 32-bit kernel on a
machine that has recoverable machine checks.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave <dave.hansen@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert (Persistent Memory) <elliott@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Cc: stable@vger.kernel.org #v4.14
Fixes: ce0fa3e5 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages")
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      fd0e786d
    • A
      x86/error_inject: Make just_return_func() globally visible · 01684e72
      由 Arnd Bergmann 提交于 
      With link time optimizations enabled, I get a link failure:

  ./ccLbOEHX.ltrans19.ltrans.o: In function `override_function_with_return':
  <artificial>:(.text+0x7f3): undefined reference to `just_return_func'

Marking the symbol .globl makes it work as expected.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes: 540adea3 ("error-injection: Separate error-injection from kprobe")
Link: http://lkml.kernel.org/r/20180202145634.200291-3-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      01684e72
    • M
      x86/platform/UV: Fix GAM Range Table entries less than 1GB · c25d99d2
      由 mike.travis@hpe.com 提交于 
      The latest UV platforms include the new ApachePass NVDIMMs into the
UV address space.  This has introduced address ranges in the Global
Address Map Table that are less than the previous lowest range, which
was 2GB.  Fix the address calculation so it accommodates address ranges
from bytes to exabytes.
Signed-off-by: NMike Travis <mike.travis@hpe.com>
Reviewed-by: NAndrew Banman <andrew.banman@hpe.com>
Reviewed-by: NDimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russ Anderson <russ.anderson@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180205221503.190219903@stormcage.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c25d99d2