1. 19 2月, 2018 1 次提交
  2. 07 2月, 2018 1 次提交
  3. 02 2月, 2018 1 次提交
  4. 31 1月, 2018 1 次提交
    • J
      x86/paravirt: Remove 'noreplace-paravirt' cmdline option · 12c69f1e
      Josh Poimboeuf 提交于
      The 'noreplace-paravirt' option disables paravirt patching, leaving the
      original pv indirect calls in place.
      
      That's highly incompatible with retpolines, unless we want to uglify
      paravirt even further and convert the paravirt calls to retpolines.
      
      As far as I can tell, the option doesn't seem to be useful for much
      other than introducing surprising corner cases and making the kernel
      vulnerable to Spectre v2.  It was probably a debug option from the early
      paravirt days.  So just remove it.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Jun Nakajima <jun.nakajima@intel.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jason Baron <jbaron@akamai.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Link: https://lkml.kernel.org/r/20180131041333.2x6blhxirc2kclrq@treble
      12c69f1e
  5. 28 1月, 2018 1 次提交
  6. 18 1月, 2018 1 次提交
  7. 12 1月, 2018 2 次提交
    • D
      x86/spectre: Add boot time option to select Spectre v2 mitigation · da285121
      David Woodhouse 提交于
      Add a spectre_v2= option to select the mitigation used for the indirect
      branch speculation vulnerability.
      
      Currently, the only option available is retpoline, in its various forms.
      This will be expanded to cover the new IBRS/IBPB microcode features.
      
      The RETPOLINE_AMD feature relies on a serializing LFENCE for speculation
      control. For AMD hardware, only set RETPOLINE_AMD if LFENCE is a
      serializing instruction, which is indicated by the LFENCE_RDTSC feature.
      
      [ tglx: Folded back the LFENCE/AMD fixes and reworked it so IBRS
        	integration becomes simple ]
      Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: thomas.lendacky@amd.com
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
      Cc: Paul Turner <pjt@google.com>
      Link: https://lkml.kernel.org/r/1515707194-20531-5-git-send-email-dwmw@amazon.co.uk
      da285121
    • =
      x86/PCI: Add "pci=big_root_window" option for AMD 64-bit windows · f32ab754
      =?UTF-8?q?Christian=20K=C3=B6nig?= 提交于
      Only try to enable a 64-bit window on AMD CPUs when "pci=big_root_window"
      is specified.
      
      This taints the kernel because the new 64-bit window uses address space we
      don't know anything about, and it may contain unreported devices or memory
      that would conflict with the window.
      
      The pci_amd_enable_64bit_bar() quirk that enables the window is specific to
      AMD CPUs.  The generic solution would be to have the firmware enable the
      window and describe it in the host bridge's _CRS method, or at least
      describe it in the _PRS method so the OS would have the option of enabling
      it.
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      [bhelgaas: changelog, extend doc, mention taint in dmesg]
      Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      f32ab754
  8. 09 1月, 2018 1 次提交
  9. 07 1月, 2018 1 次提交
  10. 04 1月, 2018 1 次提交
    • S
      printk: add console_msg_format command line option · cca10d58
      Sergey Senozhatsky 提交于
      0day and kernelCI automatically parse kernel log - basically some sort
      of grepping using the pre-defined text patterns - in order to detect
      and report regressions/errors. There are several sources they get the
      kernel logs from:
      
      a) dmesg or /proc/ksmg
      
         This is the preferred way. Because `dmesg --raw' (see later Note)
         and /proc/kmsg output contains facility and log level, which greatly
         simplifies grepping for EMERG/ALERT/CRIT/ERR messages.
      
      b) serial consoles
      
         This option is harder to maintain, because serial console messages
         don't contain facility and log level.
      
      This patch introduces a `console_msg_format=' command line option,
      to switch between different message formatting on serial consoles.
      For the time being we have just two options - default and syslog.
      The "default" option just keeps the existing format. While the
      "syslog" option makes serial console messages to appear in syslog
      format [syslog() syscall], matching the `dmesg -S --raw' and
      `cat /proc/kmsg' output formats:
      
      - facility and log level
      - time stamp (depends on printk_time/PRINTK_TIME)
      - message
      
      	<%u>[time stamp] text\n
      
      NOTE: while Kevin and Fengguang talk about "dmesg --raw", it's actually
      "dmesg -S --raw" that always prints messages in syslog format [per
      Petr Mladek]. Running "dmesg --raw" may produce output in non-syslog
      format sometimes. console_msg_format=syslog enables syslog format,
      thus in documentation we mention "dmesg -S --raw", not "dmesg --raw".
      
      Per Kevin Hilman:
      
      : Right now we can get this info from a "dmesg --raw" after bootup,
      : but it would be really nice in certain automation frameworks to
      : have a kernel command-line option to enable printing of loglevels
      : in default boot log.
      :
      : This is especially useful when ingesting kernel logs into advanced
      : search/analytics frameworks (I'm playing with and ELK stack: Elastic
      : Search, Logstash, Kibana).
      :
      : The other important reason for having this on the command line is that
      : for testing linux-next (and other bleeding edge developer branches),
      : it's common that we never make it to userspace, so can't even run
      : "dmesg --raw" (or equivalent.)  So we really want this on the primary
      : boot (serial) console.
      
      Per Fengguang Wu, 0day scripts should quickly benefit from that
      feature, because they will be able to switch to a more reliable
      parsing, based on messages' facility and log levels [1]:
      
      `#{grep} -a -E -e '^<[0123]>' -e '^kern  :(err   |crit  |alert |emerg )'
      
      instead of doing text pattern matching
      
      `#{grep} -a -F -f /lkp/printk-error-messages #{kmsg_file} |
            grep -a -v -E -f #{LKP_SRC}/etc/oops-pattern |
            grep -a -v -F -f #{LKP_SRC}/etc/kmsg-blacklist`
      
      [1] https://github.com/fengguang/lkp-tests/blob/master/lib/dmesg.rb
      
      Link: http://lkml.kernel.org/r/20171221054149.4398-1-sergey.senozhatsky@gmail.com
      To: Steven Rostedt <rostedt@goodmis.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reviewed-by: NFengguang Wu <fengguang.wu@intel.com>
      Reviewed-by: NKevin Hilman <khilman@baylibre.com>
      Tested-by: NKevin Hilman <khilman@baylibre.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      cca10d58
  11. 28 12月, 2017 1 次提交
  12. 24 12月, 2017 2 次提交
    • B
      x86/pti: Add the pti= cmdline option and documentation · 41f4c20b
      Borislav Petkov 提交于
      Keep the "nopti" optional for traditional reasons.
      
      [ tglx: Don't allow force on when running on XEN PV and made 'on'
      	printout conditional ]
      Requested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirsky <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Eduardo Valentin <eduval@amazon.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: aliguori@amazon.com
      Cc: daniel.gruss@iaik.tugraz.at
      Cc: hughd@google.com
      Cc: keescook@google.com
      Link: https://lkml.kernel.org/r/20171212133952.10177-1-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      41f4c20b
    • T
      x86/mm/pti: Add infrastructure for page table isolation · aa8c6248
      Thomas Gleixner 提交于
      Add the initial files for kernel page table isolation, with a minimal init
      function and the boot time detection for this misfeature.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Eduardo Valentin <eduval@amazon.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: aliguori@amazon.com
      Cc: daniel.gruss@iaik.tugraz.at
      Cc: hughd@google.com
      Cc: keescook@google.com
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      aa8c6248
  13. 19 12月, 2017 1 次提交
  14. 18 12月, 2017 1 次提交
  15. 16 12月, 2017 1 次提交
  16. 13 12月, 2017 1 次提交
  17. 12 12月, 2017 3 次提交
  18. 27 11月, 2017 1 次提交
    • R
      ACPI / PM: Make it possible to ignore the system sleep blacklist · 57044031
      Rafael J. Wysocki 提交于
      The ACPI code supporting system transitions to sleep states uses
      an internal blacklist to apply special handling to some machines
      reported to behave incorrectly in some ways.
      
      However, some entries of that blacklist cover problematic as well as
      non-problematic systems, so give the users of the latter a chance to
      ignore the blacklist and run their systems in the default way by
      adding acpi_sleep=nobl to the kernel command line.
      
      For example, that allows the users of Dell XPS13 9360 systems not
      affected by the issue that caused the blacklist entry for this
      machine to be added by commit 71630b7a (ACPI / PM: Blacklist Low
      Power S0 Idle _DSM for Dell XPS13 9360) to use suspend-to-idle with
      the Low Power S0 Idle _DSM interface which in principle should be
      more energy-efficient than S3 on them.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      57044031
  19. 21 11月, 2017 1 次提交
  20. 18 11月, 2017 1 次提交
  21. 16 11月, 2017 1 次提交
  22. 10 11月, 2017 1 次提交
  23. 02 11月, 2017 1 次提交
    • M
      irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface · 0962289b
      Marc Zyngier 提交于
      There is a lot of broken firmware out there that don't really
      expose the information the kernel requires when it comes with dealing
      with GICv2:
      
      (1) Firmware that only describes the first 4kB of GICv2
      (2) Firmware that describe 128kB of CPU interface, while
          the usable portion of the address space is between
          60 and 68kB
      
      So far, we only deal with (2). But we have platforms exhibiting
      behaviour (1), resulting in two sub-cases:
      (a) The GIC is occupying 8kB, as required by the GICv2 architecture
      (b) It is actually spread 128kB, and this is likely to be a version
          of (2)
      
      This patch tries to work around both (a) and (b) by poking at
      the outside of the described memory region, and try to work out
      what is actually there. This is of course unsafe, and should
      only be enabled if there is no way to otherwise fix the DT provided
      by the firmware (we provide a "irqchip.gicv2_force_probe" option
      to that effect).
      
      Note that for the time being, we restrict ourselves to GICv2
      implementations provided by ARM, since there I have no knowledge
      of an alternative implementations. This could be relaxed if such
      an implementation comes to light on a broken platform.
      Reviewed-by: NChristoffer Dall <cdall@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      0962289b
  24. 31 10月, 2017 2 次提交
  25. 25 10月, 2017 1 次提交
    • B
      locking/lockdep: Add a boot parameter allowing unwind in cross-release and disable it by default · d141babe
      Byungchul Park 提交于
      Johan Hovold reported a heavy performance regression caused by lockdep
      cross-release:
      
       > Boot time (from "Linux version" to login prompt) had in fact doubled
       > since 4.13 where it took 17 seconds (with my current config) compared to
       > the 35 seconds I now see with 4.14-rc4.
       >
       > I quick bisect pointed to lockdep and specifically the following commit:
       >
       >	28a903f6 ("locking/lockdep: Handle non(or multi)-acquisition
       >	               of a crosslock")
       >
       > which I've verified is the commit which doubled the boot time (compared
       > to 28a903f6^) (added by lockdep crossrelease series [1]).
      
      Currently cross-release performs unwind on every acquisition, but that
      is very expensive.
      
      This patch makes unwind optional and disables it by default and only
      records acquire_ip.
      
      Full stack traces are sometimes required for full analysis, in which
      case a boot paramter, crossrelease_fullstack, can be specified.
      
      On my qemu Ubuntu machine (x86_64, 4 cores, 512M), the regression was
      fixed. We measure boot times with 'perf stat --null --repeat 10 $QEMU',
      where $QEMU launches a kernel with init=/bin/true:
      
      1. No lockdep enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.756558155 seconds time elapsed                    ( +-  0.09% )
      
      2. Lockdep enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.968710420 seconds time elapsed                    ( +-  0.12% )
      
      3. Lockdep enabled + cross-release enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             3.153839636 seconds time elapsed                    ( +-  0.31% )
      
      4. Lockdep enabled + cross-release enabled + this patch applied:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.963669551 seconds time elapsed                    ( +-  0.11% )
      
      I.e. lockdep cross-release performance is now indistinguishable from
      vanilla lockdep.
      Bisected-by: NJohan Hovold <johan@kernel.org>
      Analyzed-by: NThomas Gleixner <tglx@linutronix.de>
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Reported-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NByungchul Park <byungchul.park@lge.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: amir73il@gmail.com
      Cc: axboe@kernel.dk
      Cc: darrick.wong@oracle.com
      Cc: david@fromorbit.com
      Cc: hch@infradead.org
      Cc: idryomov@gmail.com
      Cc: johannes.berg@intel.com
      Cc: kernel-team@lge.com
      Cc: linux-block@vger.kernel.org
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mm@kvack.org
      Cc: linux-xfs@vger.kernel.org
      Cc: oleg@redhat.com
      Cc: tj@kernel.org
      Link: http://lkml.kernel.org/r/1508921765-15396-5-git-send-email-byungchul.park@lge.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d141babe
  26. 20 10月, 2017 1 次提交
    • C
      powerpc/tm: Add commandline option to disable hardware transactional memory · 07fd1761
      Cyril Bur 提交于
      Currently the kernel relies on firmware to inform it whether or not the
      CPU supports HTM and as long as the kernel was built with
      CONFIG_PPC_TRANSACTIONAL_MEM=y then it will allow userspace to make
      use of the facility.
      
      There may be situations where it would be advantageous for the kernel
      to not allow userspace to use HTM, currently the only way to achieve
      this is to recompile the kernel with CONFIG_PPC_TRANSACTIONAL_MEM=n.
      
      This patch adds a simple commandline option so that HTM can be
      disabled at boot time.
      Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
      [mpe: Simplify to a bool, move to prom.c, put doco in the right place.
       Always disable, regardless of initial state, to avoid user confusion.]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      07fd1761
  27. 18 10月, 2017 1 次提交
    • V
      s390: introduce CPU alternatives · 686140a1
      Vasily Gorbik 提交于
      Implement CPU alternatives, which allows to optionally patch newer
      instructions at runtime, based on CPU facilities availability.
      
      A new kernel boot parameter "noaltinstr" disables patching.
      
      Current implementation is derived from x86 alternatives. Although
      ideal instructions padding (when altinstr is longer then oldinstr)
      is added at compile time, and no oldinstr nops optimization has to be
      done at runtime. Also couple of compile time sanity checks are done:
      1. oldinstr and altinstr must be <= 254 bytes long,
      2. oldinstr and altinstr must not have an odd length.
      
      alternative(oldinstr, altinstr, facility);
      alternative_2(oldinstr, altinstr1, facility1, altinstr2, facility2);
      
      Both compile time and runtime padding consists of either 6/4/2 bytes nop
      or a jump (brcl) + 2 bytes nop filler if padding is longer then 6 bytes.
      
      .altinstructions and .altinstr_replacement sections are part of
      __init_begin : __init_end region and are freed after initialization.
      Signed-off-by: NVasily Gorbik <gor@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      686140a1
  28. 13 10月, 2017 3 次提交
  29. 10 10月, 2017 2 次提交
  30. 08 10月, 2017 1 次提交
  31. 04 10月, 2017 1 次提交
  32. 03 10月, 2017 1 次提交