1. 15 3月, 2018 1 次提交
  2. 14 3月, 2018 2 次提交
    • T
      EDAC: Add new memory type for non-volatile DIMMs · 001f8613
      Tony Luck 提交于
      There are now non-volatile versions of DIMMs. Add a new entry to "enum
      mem_type" and a new string in edac_mem_types[].
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jean Delvare <jdelvare@suse.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/20180312182430.10335-3-tony.luck@intel.comSigned-off-by: NBorislav Petkov <bp@suse.de>
      001f8613
    • T
      EDAC: Drop duplicated array of strings for memory type names · d6dd77eb
      Tony Luck 提交于
      Somehow we ended up with two separate arrays of strings to describe the
      "enum mem_type" values.
      
      In edac_mc.c we have an exported list edac_mem_types[] that is used
      by a couple of drivers in debug messaged.
      
      In edac_mc_sysfs.c we have a private list that is used to display
      values in:
        /sys/devices/system/edac/mc/mc*/dimm*/dimm_mem_type
        /sys/devices/system/edac/mc/mc*/csrow*/mem_type
      
      This list was missing a value for MEM_LRDDR3.
      
      The string values in the two lists were different :-(
      
      Combining the lists, I kept the values so that the sysfs output
      will be unchanged as some scripts may depend on that.
      Reported-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jean Delvare <jdelvare@suse.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/20180312182430.10335-2-tony.luck@intel.comSigned-off-by: NBorislav Petkov <bp@suse.de>
      d6dd77eb
  3. 27 2月, 2018 1 次提交
  4. 23 2月, 2018 1 次提交
  5. 15 2月, 2018 1 次提交
  6. 10 1月, 2018 1 次提交
  7. 27 11月, 2017 2 次提交
  8. 02 11月, 2017 1 次提交
    • 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
  9. 31 10月, 2017 1 次提交
    • K
      treewide: Fix function prototypes for module_param_call() · e4dca7b7
      Kees Cook 提交于
      Several function prototypes for the set/get functions defined by
      module_param_call() have a slightly wrong argument types. This fixes
      those in an effort to clean up the calls when running under type-enforced
      compiler instrumentation for CFI. This is the result of running the
      following semantic patch:
      
      @match_module_param_call_function@
      declarer name module_param_call;
      identifier _name, _set_func, _get_func;
      expression _arg, _mode;
      @@
      
       module_param_call(_name, _set_func, _get_func, _arg, _mode);
      
      @fix_set_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._set_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _set_func(
      -_val_type _val
      +const char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      @fix_get_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._get_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _get_func(
      -_val_type _val
      +char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      Two additional by-hand changes are included for places where the above
      Coccinelle script didn't notice them:
      
      	drivers/platform/x86/thinkpad_acpi.c
      	fs/lockd/svc.c
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      e4dca7b7
  10. 25 10月, 2017 1 次提交
    • M
      locking/atomics, EDAC/altera: Convert ACCESS_ONCE() to READ_ONCE()/WRITE_ONCE() · 332efa63
      Mark Rutland 提交于
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't currently harmful.
      
      However, for some features it is necessary to instrument reads and
      writes separately, which is not possible with ACCESS_ONCE(). This
      distinction is critical to correct operation.
      
      It's possible to transform the bulk of kernel code using the Coccinelle
      script below. However, this doesn't handle comments, leaving references
      to ACCESS_ONCE() instances which have been removed. As a preparatory
      step, this patch converts the Altera EDAC code and comments to use
      {READ,WRITE}_ONCE() consistently.
      
      ----
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: NThor Thayer <thor.thayer@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-2-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      332efa63
  11. 19 10月, 2017 1 次提交
  12. 11 10月, 2017 1 次提交
  13. 29 9月, 2017 1 次提交
  14. 27 9月, 2017 3 次提交
  15. 25 9月, 2017 5 次提交
  16. 21 9月, 2017 1 次提交
  17. 21 8月, 2017 3 次提交
  18. 20 8月, 2017 1 次提交
  19. 19 8月, 2017 5 次提交
  20. 04 8月, 2017 1 次提交
  21. 02 8月, 2017 1 次提交
    • Q
      EDAC, sb_edac: Classify memory mirroring modes · 039d7af6
      Qiuxu Zhuo 提交于
      Basically, there are full memory mirroring and address range partial
      memory mirroring (supported by Haswell EX and Broadwell EX) modes.
      
      a) In full memory mirroring, the memory behind each memory controller
         is mirrored, i.e. the memory is split into two identical mirrors
         (primary and secondary), half of the memory is reserved for redundancy.
      
      b) In address range partial memory mirroring, the memory size (range)
         of primary and secondary behind each memory controller can be user
         defined by the TAD0 register. The rest of memory ranges defined by
         TAD1/TAD2/... in that memory controller are non-mirrored.
      
      For more detail on memory mirroring, see the following link written by Tony Luck:
      
        https://01.org/lkp/blogs/tonyluck/2016/address-range-partial-memory-mirroring-linux
      
      Currently the sb_edac driver only supports address decoding in full
      memory mirroring and non-mirroring modes. In address range partial
      memory mirroring mode, it may fail to decode an address that falls in a
      non-mirroring area (the following was one of this kind of failed logs).
      
        mce: Uncorrected hardware memory error in user-access at 566d53a400
        Memory failure: 0x566d53a8: Killing einj_mem_uc:4647 due to hardware memory corruption
        Memory failure: 0x566d53a8: recovery action for dirty LRU page: Recovered
        mce: [Hardware Error]: Machine check events logged
        EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
        EDAC sbridge MC1: CPU 48: Machine Check Event: 0 Bank 7: ec00000000010090
        EDAC sbridge MC1: TSC 4b914aa5a99dab
        EDAC sbridge MC1: ADDR 566d53a400
        EDAC sbridge MC1: MISC 1443a0c86
        EDAC sbridge MC1: PROCESSOR 0:406f1 TIME 1499712764 SOCKET 2 APIC 80
        EDAC MC1: 0 UE Can't discover the memory rank for ch addr 0x7fb54e900 on any memory ( page:0x0 offset:0x0 grain:32)
        mce: [Hardware Error]: Machine check events logged
      
      Therefore, classify memory mirroring modes and make the address decoding
      in address range partial memory mode correct.
      Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20170730180651.30060-1-qiuxu.zhuo@intel.comSigned-off-by: NBorislav Petkov <bp@suse.de>
      039d7af6
  22. 19 7月, 2017 1 次提交
  23. 17 7月, 2017 3 次提交
  24. 29 6月, 2017 1 次提交