1. 22 6月, 2018 3 次提交
    • A
      x86/mce: Always use 64-bit timestamps · bc39f010
      Arnd Bergmann 提交于
      The machine check timestamp uses get_seconds(), which returns an
      'unsigned long' number that might overflow on 32-bit architectures (in
      the distant future) and is therefore deprecated.
      
      The normal replacement would be ktime_get_real_seconds(), but that needs
      to use a sequence lock that might cause a deadlock if the MCE happens at
      just the wrong moment. The __ktime_get_real_seconds() skips that lock
      and is safer here, but has a miniscule risk of returning the wrong time
      when we read it on a 32-bit architecture at the same time as updating
      the epoch, i.e. from before y2106 overflow time to after, or vice versa.
      
      This seems to be an acceptable risk in this particular case, and is the
      same thing we do in kdb.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: y2038@lists.linaro.org
      Link: http://lkml.kernel.org/r/20180618100759.1921750-1-arnd@arndb.de
      bc39f010
    • T
      x86/mce: Fix incorrect "Machine check from unknown source" message · 40c36e27
      Tony Luck 提交于
      Some injection testing resulted in the following console log:
      
        mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134
        mce: [Hardware Error]: RIP 10:<ffffffffc05292dd> {pmem_do_bvec+0x11d/0x330 [nd_pmem]}
        mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88
        mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043
        mce: [Hardware Error]: Run the above through 'mcelog --ascii'
        Kernel panic - not syncing: Machine check from unknown source
      
      This confused everybody because the first line quite clearly shows
      that we found a logged error in "Bank 1", while the last line says
      "unknown source".
      
      The problem is that the Linux code doesn't do the right thing
      for a local machine check that results in a fatal error.
      
      It turns out that we know very early in the handler whether the
      machine check is fatal. The call to mce_no_way_out() has checked
      all the banks for the CPU that took the local machine check. If
      it says we must crash, we can do so right away with the right
      messages.
      
      We do scan all the banks again. This means that we might initially
      not see a problem, but during the second scan find something fatal.
      If this happens we print a slightly different message (so I can
      see if it actually every happens).
      
      [ bp: Remove unneeded severity assignment. ]
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: stable@vger.kernel.org # 4.2
      Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.1527283897.git.tony.luck@intel.com
      40c36e27
    • B
      x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out() · 1f74c8a6
      Borislav Petkov 提交于
      mce_no_way_out() does a quick check during #MC to see whether some of
      the MCEs logged would require the kernel to panic immediately. And it
      passes a struct mce where MCi_STATUS gets written.
      
      However, after having saved a valid status value, the next iteration
      of the loop which goes over the MCA banks on the CPU, overwrites the
      valid status value because we're using struct mce as storage instead of
      a temporary variable.
      
      Which leads to MCE records with an empty status value:
      
        mce: [Hardware Error]: CPU 0: Machine Check Exception: 6 Bank 0: 0000000000000000
        mce: [Hardware Error]: RIP 10:<ffffffffbd42fbd7> {trigger_mce+0x7/0x10}
      
      In order to prevent the loss of the status register value, return
      immediately when severity is a panic one so that we can panic
      immediately with the first fatal MCE logged. This is also the intention
      of this function and not to noodle over the banks while a fatal MCE is
      already logged.
      
      Tony: read the rest of the MCA bank to populate the struct mce fully.
      Suggested-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20180622095428.626-8-bp@alien8.de
      1f74c8a6
  2. 08 6月, 2018 1 次提交
    • T
      x86/mce: Improve error message when kernel cannot recover · c7d606f5
      Tony Luck 提交于
      Since we added support to add recovery from some errors inside the kernel in:
      
      commit b2f9d678 ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
      
      we have done a less than stellar job at reporting the cause of recoverable
      machine checks that occur in other parts of the kernel. The user just gets
      the unhelpful message:
      
      	mce: [Hardware Error]: Machine check: Action required: unknown MCACOD
      
      doubly unhelpful when they check the manual for the reported IA32_MSR_STATUS.MCACOD
      and see that it is listed as one of the standard recoverable values.
      
      Add an extra rule to the MCE severity table to catch this case and report it
      as:
      
      	mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
      
      Fixes: b2f9d678 ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: stable@vger.kernel.org # 4.6+
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/4cc7c465150a9a48b8b9f45d0b840278e77eb9b5.1527283897.git.tony.luck@intel.com
      c7d606f5
  3. 19 5月, 2018 2 次提交
  4. 06 5月, 2018 2 次提交
  5. 29 3月, 2018 1 次提交
  6. 24 3月, 2018 1 次提交
  7. 08 3月, 2018 2 次提交
    • S
      x86/MCE: Serialize sysfs changes · b3b7c479
      Seunghun Han 提交于
      The check_interval file in
      
        /sys/devices/system/machinecheck/machinecheck<cpu number>
      
      directory is a global timer value for MCE polling. If it is changed by one
      CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
      the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
      mce_timer variable.
      
      If more than one CPU writes a specific value to the check_interval file
      concurrently, mce_timer is not protected from such concurrent accesses and
      all kinds of explosions happen. Since only root can write to those sysfs
      variables, the issue is not a big deal security-wise.
      
      However, concurrent writes to these configuration variables is void of
      reason so the proper thing to do is to serialize the access with a mutex.
      
      Boris:
      
       - Make store_int_with_restart() use device_store_ulong() to filter out
         negative intervals
       - Limit min interval to 1 second
       - Correct locking
       - Massage commit message
      Signed-off-by: NSeunghun Han <kkamagui@gmail.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180302202706.9434-1-kkamagui@gmail.com
      b3b7c479
    • T
      x86/MCE: Save microcode revision in machine check records · fa94d0c6
      Tony Luck 提交于
      Updating microcode used to be relatively rare. Now that it has become
      more common we should save the microcode version in a machine check
      record to make sure that those people looking at the error have this
      important information bundled with the rest of the logged information.
      
      [ Borislav: Simplify a bit. ]
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Yazen Ghannam <yazen.ghannam@amd.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180301233449.24311-1-tony.luck@intel.com
      fa94d0c6
  8. 22 2月, 2018 8 次提交
  9. 14 2月, 2018 1 次提交
  10. 13 2月, 2018 1 次提交
    • 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
  11. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  12. 11 2月, 2018 1 次提交
  13. 24 1月, 2018 1 次提交
  14. 19 1月, 2018 1 次提交
  15. 05 1月, 2018 1 次提交
    • S
      x86: do not use print_symbol() · 7b606162
      Sergey Senozhatsky 提交于
      print_symbol() is a very old API that has been obsoleted by %pS format
      specifier in a normal printk() call.
      
      Replace print_symbol() with a direct printk("%pS") call and correctly
      handle continuous lines.
      
      Link: http://lkml.kernel.org/r/20171211125025.2270-9-sergey.senozhatsky@gmail.com
      To: Andrew Morton <akpm@linux-foundation.org>
      To: Russell King <linux@armlinux.org.uk>
      To: Catalin Marinas <catalin.marinas@arm.com>
      To: Mark Salter <msalter@redhat.com>
      To: Tony Luck <tony.luck@intel.com>
      To: David Howells <dhowells@redhat.com>
      To: Yoshinori Sato <ysato@users.sourceforge.jp>
      To: Guan Xuetao <gxt@mprc.pku.edu.cn>
      To: Borislav Petkov <bp@alien8.de>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      To: Thomas Gleixner <tglx@linutronix.de>
      To: Peter Zijlstra <peterz@infradead.org>
      To: Vineet Gupta <vgupta@synopsys.com>
      To: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-sh@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: x86@kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: Borislav Petkov <bp@suse.de> # mce.c part
      [pmladek@suse.com: updated commit message]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      7b606162
  16. 18 12月, 2017 3 次提交
  17. 05 12月, 2017 2 次提交
  18. 28 11月, 2017 1 次提交
  19. 07 11月, 2017 2 次提交
  20. 02 11月, 2017 2 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
    • B
      x86/mcelog: Get rid of RCU remnants · 7298f08e
      Borislav Petkov 提交于
      Jeremy reported a suspicious RCU usage warning in mcelog.
      
      /dev/mcelog is called in process context now as part of the notifier
      chain and doesn't need any of the fancy RCU and lockless accesses which
      it did in atomic context.
      
      Axe it all in favor of a simple mutex synchronization which cures the
      problem reported.
      
      Fixes: 5de97c9f ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
      Reported-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-and-tested-by: NTony Luck <tony.luck@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: linux-edac@vger.kernel.org
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969
      7298f08e
  21. 05 10月, 2017 2 次提交
  22. 29 8月, 2017 1 次提交