1. 28 4月, 2017 15 次提交
  2. 12 4月, 2017 7 次提交
  3. 04 4月, 2017 12 次提交
  4. 24 3月, 2017 2 次提交
  5. 10 3月, 2017 1 次提交
    • B
      PCI: iproc: Save host bridge window resource in struct iproc_pcie · 6e347b5e
      Bjorn Helgaas 提交于
      The host bridge memory window resource is inserted into the iomem_resource
      tree and cannot be deallocated until the host bridge itself is removed.
      
      Previously, the window was on the stack, which meant the iomem_resource
      entry pointed into the stack and was corrupted as soon as the probe
      function returned, which caused memory corruption and errors like this:
      
        pcie_iproc_bcma bcma0:8: resource collision: [mem 0x40000000-0x47ffffff] conflicts with PCIe MEM space [mem 0x40000000-0x47ffffff]
      
      Move the memory window resource from the stack into struct iproc_pcie so
      its lifetime matches that of the host bridge.
      
      Fixes: c3245a56 ("PCI: iproc: Request host bridge window resources")
      Reported-and-tested-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v4.8+
      6e347b5e
  6. 08 3月, 2017 3 次提交
    • 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
    • E
      PCI: Prevent VPD access for QLogic ISP2722 · 0d5370d1
      Ethan Zhao 提交于
      QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
      access issue too, while read the common pci-sysfs access interface shown as
      
       /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd
      
      with simple 'cat' could cause system hang and panic:
      
        Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
        1. Integrated Management Log (IML)
        2. OA Syslog
        3. OA Forward Progress Log
        4. iLO Event Log
        CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
        Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
         0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
         ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
         0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
        Call Trace:
         <NMI>  [<ffffffff817193de>] dump_stack+0x63/0x81
         [<ffffffff81714072>] panic+0xd0/0x20e
         [<ffffffffa00b390d>] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
         [<ffffffff81021fc9>] ? sched_clock+0x9/0x10
         [<ffffffff8101c101>] nmi_handle+0x91/0x170
         [<ffffffff8101c10c>] ? nmi_handle+0x9c/0x170
         [<ffffffff8101c5fe>] io_check_error+0x1e/0xa0
         [<ffffffff8101c719>] default_do_nmi+0x99/0x140
         [<ffffffff8101c8b4>] do_nmi+0xf4/0x170
         [<ffffffff817232c5>] end_repeat_nmi+0x1a/0x1e
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         <<EOE>>  [<ffffffff815db4b3>] raw_pci_read+0x23/0x40
         [<ffffffff815db4fc>] pci_read+0x2c/0x30
         [<ffffffff8136f612>] pci_user_read_config_word+0x72/0x110
         [<ffffffff8136f746>] pci_vpd_pci22_wait+0x96/0x130
         [<ffffffff8136ff9b>] pci_vpd_pci22_read+0xdb/0x1a0
         [<ffffffff8136ea30>] pci_read_vpd+0x20/0x30
         [<ffffffff8137d590>] read_vpd_attr+0x30/0x40
         [<ffffffff8128e037>] sysfs_kf_bin_read+0x47/0x70
         [<ffffffff8128d24e>] kernfs_fop_read+0xae/0x180
         [<ffffffff8120dd97>] __vfs_read+0x37/0x100
         [<ffffffff812ba7e4>] ? security_file_permission+0x84/0xa0
         [<ffffffff8120e366>] ? rw_verify_area+0x56/0xe0
         [<ffffffff8120e476>] vfs_read+0x86/0x140
         [<ffffffff8120f3f5>] SyS_read+0x55/0xd0
         [<ffffffff81720f2e>] system_call_fastpath+0x12/0x71
        Shutting down cpus with NMI
        Kernel Offset: disabled
        drm_kms_helper: panic occurred, switching back to text console
      
      So blacklist the access to its VPD.
      Signed-off-by: NEthan Zhao <ethan.zhao@oracle.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v4.6+
      0d5370d1
    • J
      PCI: exynos: Initialize elbi_base even when using PHY framework · 544714d8
      Jaehoon Chung 提交于
      Even when using the PHY framework, we need the elbi_base.  Before this
      patch, we didn't initialize elbi_base, which caused NULL pointer
      dereferences later.
      
      Fixes: e7cd7ef5 ("PCI: exynos: Support the PHY generic framework")
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      544714d8