1. 19 1月, 2018 1 次提交
  2. 14 11月, 2017 3 次提交
  3. 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
  4. 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
  5. 06 10月, 2017 1 次提交
    • A
      PCI/ASPM: Deal with missing root ports in link state handling · ee8bdfb6
      Ard Biesheuvel 提交于
      Even though it is unconventional, some PCIe host implementations omit the
      root ports entirely, and simply consist of a host bridge (which is not
      modeled as a device in the PCI hierarchy) and a link.
      
      When the downstream device is an endpoint, our current code does not seem
      to mind this unusual configuration. However, when PCIe switches are
      involved, the ASPM code assumes that any downstream switch port has a
      parent, and blindly dereferences the bus->parent->self field of the pci_dev
      struct to chain the downstream link state to the link state of the root
      port. Given that the root port is missing, the link is not modeled at all,
      and nor is the link state, and attempting to access it results in a NULL
      pointer dereference and a crash.
      
      Avoid this by allowing the link state chain to terminate at the downstream
      port if no root port exists.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      ee8bdfb6
  6. 08 3月, 2017 1 次提交
    • Y
      PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove · 3bd7db63
      Yinghai Lu 提交于
      We call pcie_aspm_exit_link_state() when we remove a device.  If the device
      is the last PCIe function to be removed below a bridge and the bridge has
      an ASPM link_state struct, we disable ASPM on the link.  Disabling ASPM
      requires link->downstream (used in pcie_config_aspm_link()).
      
      We previously set link->downstream in pcie_aspm_cap_init(), but only if the
      device was not blacklisted.  Removing the blacklisted device caused a NULL
      pointer dereference in the pcie_aspm_exit_link_state() ->
      pcie_config_aspm_link() path:
      
        # echo 1 > /sys/bus/pci/devices/0000\:0b\:00.0/remove
        ...
         BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
         IP: pcie_config_aspm_link+0x5d/0x2b0
         Call Trace:
          pcie_aspm_exit_link_state+0x75/0x130
          pci_stop_bus_device+0xa4/0xb0
          pci_stop_and_remove_bus_device_locked+0x1a/0x30
          remove_store+0x50/0x70
          dev_attr_store+0x18/0x30
          sysfs_kf_write+0x44/0x60
          kernfs_fop_write+0x10e/0x190
          __vfs_write+0x28/0x110
          ? rcu_read_lock_sched_held+0x5d/0x80
          ? rcu_sync_lockdep_assert+0x2c/0x60
          ? __sb_start_write+0x173/0x1a0
          ? vfs_write+0xb3/0x180
          vfs_write+0xc4/0x180
          SyS_write+0x49/0xa0
          do_syscall_64+0xa6/0x1c0
          entry_SYSCALL64_slow_path+0x25/0x25
         ---[ end trace bd187ee0267df5d9 ]---
      
      To avoid this, set link->downstream in alloc_pcie_link_state(), so every
      pcie_link_state structure has a valid link->downstream pointer.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRajat Jain <rajatja@google.com>
      CC: stable@vger.kernel.org
      3bd7db63
  7. 15 2月, 2017 5 次提交
  8. 28 1月, 2017 1 次提交
  9. 09 12月, 2016 1 次提交
  10. 15 11月, 2016 1 次提交
    • J
      PCI/ASPM: Use permission-specific DEVICE_ATTR variants · fc4f57fa
      Julia Lawall 提交于
      Use DEVICE_ATTR_RW for read-write attributes.  This simplifies the source
      code, improves readability, and reduces the chance of inconsistencies.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @rw@
      declarer name DEVICE_ATTR;
      identifier x,x_show,x_store;
      @@
      
      DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
      
      @script:ocaml@
      x << rw.x;
      x_show << rw.x_show;
      x_store << rw.x_store;
      @@
      
      if not (x^"_show" = x_show && x^"_store" = x_store)
      then Coccilib.include_match false
      
      @@
      declarer name DEVICE_ATTR_RW;
      identifier rw.x,rw.x_show,rw.x_store;
      @@
      
      - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
      + DEVICE_ATTR_RW(x);
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc4f57fa
  11. 11 6月, 2016 1 次提交
  12. 04 12月, 2015 1 次提交
    • A
      PCI/ASPM: Make sysfs link_state_store() consistent with link_state_show() · 57d86a04
      Andy Lutomirski 提交于
      If CONFIG_PCIEASPM_DEBUG is set, then PCI devices have a link_state
      attribute.  Reading that attribute shows the state as a bit mask: 1
      means L0S upstream, 2 means L0S downstream, and 4 means L1.
      
      Oddly, writing to link_state is inconsistent and gets translated, leading
      to mysterious results in which the value you store isn't comparable the
      value you load back out.
      
      Fix it by making link_state_store() match link_state_show().
      
      [bhelgaas: Check "aspm_disabled" *before* validating input.  When
      "aspm_disabled" is set, this changes the error for invalid input from
      -EINVAL to -EPERM.]
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      57d86a04
  13. 11 6月, 2015 1 次提交
  14. 27 5月, 2015 1 次提交
    • Y
      PCI/ASPM: Use dev->has_secondary_link to find downstream links · c8fc9339
      Yijing Wang 提交于
      We allocate pcie_link_state for the component at the upstream end of a
      Link.  Previously we did this by allocating pcie_link_state for Root Ports
      and Downstream Ports.  This works fine for the typical topology:
      
        00:1c.0 Root Port       [bridge to bus 02]
        02:00.0 Upstream Port   [bridge to bus 03]
        03:00.0 Downstream Port [bridge to bus 04]
        04:00.0 Endpoint or Switch Port
      
      However, it is possible to have a Root Port connected to a Downstream Port
      instead of an Upstream Port, as in Robert White's ATCA system:
      
        00:1c.0 Root Port       [bridge to bus 02]
        02:00.0 Downstream Port [bridge to bus 03]
        03:01.0 Downstream Port [bridge to bus 04]
        04:00.0 Endpoint or Switch Port
      
      In this topology, we wrongly allocated pcie_link_state for the 02:00.0
      Downstream Port, which is actually the *downstream* end of a link.  This
      led to the following NULL pointer dereference when we tried to connect this
      link into the tree of links starting at the 00:1c.0 Root Port:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
        IP: [<ffffffff81550324>] pcie_aspm_init_link_state+0x744/0x850
        Hardware name: Kontron B3001/B3001, BIOS 4.6.3 08/07/2012
        Call Trace:
         [<ffffffff8153b865>] pci_scan_slot+0xd5/0x120
         [<ffffffff8153ca1d>] pci_scan_child_bus+0x2d/0xd0
         ...
      
      Instead of relying on the component type to identify the upstream end of a
      link, use the "dev->has_secondary_link" field.
      
      This means it's now possible for an Upstream Port to have a link on its
      secondary side, so alloc_pcie_link_state() needs to connect links
      originating from both Upstream and Downstream Ports into the tree.
      
      [bhelgaas: changelog, add comment]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
      Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.comReported-by: NRobert White <rwhite@pobox.com>
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c8fc9339
  15. 21 5月, 2015 2 次提交
  16. 10 4月, 2015 1 次提交
  17. 10 1月, 2015 1 次提交
  18. 14 1月, 2014 1 次提交
  19. 15 11月, 2013 1 次提交
  20. 29 5月, 2013 1 次提交
  21. 22 5月, 2013 1 次提交
  22. 02 2月, 2013 2 次提交
  23. 15 1月, 2013 1 次提交
  24. 08 12月, 2012 1 次提交
  25. 08 11月, 2012 1 次提交
  26. 24 8月, 2012 1 次提交
  27. 23 8月, 2012 1 次提交
  28. 01 4月, 2012 1 次提交
    • M
      ASPM: Fix pcie devices with non-pcie children · c9651e70
      Matthew Garrett 提交于
      Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
      Some other systems using the pata_jmicron driver fail to boot because no
      disks are detected.  Passing pcie_aspm=force on the kernel command line
      works around it.
      
      The cause: commit 4949be16 ("PCI: ignore pre-1.1 ASPM quirking when
      ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
      always return 0 if aspm is disabled, in order to avoid cases where we
      changed ASPM state on pre-PCIe 1.1 devices.
      
      This skipped the secondary function of pcie_aspm_sanity_check which was
      to avoid us enabling ASPM on devices that had non-PCIe children, causing
      trouble later on.  Move the aspm_disabled check so we continue to honour
      that scenario.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
                http://bugs.debian.org/665420
      
      Reported-by: Romain Francoise <romain@orebokech.com> # kernel panic
      Reported-by: Chris Holland <bandidoirlandes@gmail.com> # disk detection trouble
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Cc: stable@vger.kernel.org
      Tested-by: Hatem Masmoudi <hatem.masmoudi@gmail.com> # Dell Latitude E5520
      Tested-by: janek <jan0x6c@gmail.com> # pata_jmicron with JMB362/JMB363
      [jn: with more symptoms in log message]
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c9651e70
  29. 08 3月, 2012 1 次提交
  30. 18 2月, 2012 1 次提交
  31. 07 1月, 2012 1 次提交
    • M
      PCI: Rework ASPM disable code · 10f6dc7e
      Matthew Garrett 提交于
      Right now we forcibly clear ASPM state on all devices if the BIOS indicates
      that the feature isn't supported. Based on the Microsoft presentation
      "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
      that this may be an error. The implication is that unless the platform
      grants full control via _OSC, Windows will not touch any PCIe features -
      including ASPM. In that case clearing ASPM state would be an error unless
      the platform has granted us that control.
      
      This patch reworks the ASPM disabling code such that the actual clearing
      of state is triggered by a successful handoff of PCIe control to the OS.
      The general ASPM code undergoes some changes in order to ensure that the
      ability to clear the bits isn't overridden by ASPM having already been
      disabled. Further, this theoretically now allows for situations where
      only a subset of PCIe roots hand over control, leaving the others in the
      BIOS state.
      
      It's difficult to know for sure that this is the right thing to do -
      there's zero public documentation on the interaction between all of these
      components. But enough vendors enable ASPM on platforms and then set this
      bit that it seems likely that they're expecting the OS to leave them alone.
      
      Measured to save around 5W on an idle Thinkpad X220.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      10f6dc7e
  32. 06 12月, 2011 1 次提交
    • M
      PCI: Rework ASPM disable code · 3c076351
      Matthew Garrett 提交于
      Right now we forcibly clear ASPM state on all devices if the BIOS indicates
      that the feature isn't supported. Based on the Microsoft presentation
      "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
      that this may be an error. The implication is that unless the platform
      grants full control via _OSC, Windows will not touch any PCIe features -
      including ASPM. In that case clearing ASPM state would be an error unless
      the platform has granted us that control.
      
      This patch reworks the ASPM disabling code such that the actual clearing
      of state is triggered by a successful handoff of PCIe control to the OS.
      The general ASPM code undergoes some changes in order to ensure that the
      ability to clear the bits isn't overridden by ASPM having already been
      disabled. Further, this theoretically now allows for situations where
      only a subset of PCIe roots hand over control, leaving the others in the
      BIOS state.
      
      It's difficult to know for sure that this is the right thing to do -
      there's zero public documentation on the interaction between all of these
      components. But enough vendors enable ASPM on platforms and then set this
      bit that it seems likely that they're expecting the OS to leave them alone.
      
      Measured to save around 5W on an idle Thinkpad X220.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3c076351