linux-stable.git/drivers/pci, branch v3.0.52

intel-iommu: Fix AB-BA lockdep report

2012-11-17T21:14:26+00:00

commit 3e7abe2556b583e87dabda3e0e6178a67b20d06f upstream.

When unbinding a device so that I could pass it through to a KVM VM, I
got the lockdep report below.  It looks like a legitimate lock
ordering problem:

 - domain_context_mapping_one() takes iommu->lock and calls
   iommu_support_dev_iotlb(), which takes device_domain_lock (inside
   iommu->lock).

 - domain_remove_one_dev_info() starts by taking device_domain_lock
   then takes iommu->lock inside it (near the end of the function).

So this is the classic AB-BA deadlock.  It looks like a safe fix is to
simply release device_domain_lock a bit earlier, since as far as I can
tell, it doesn't protect any of the stuff accessed at the end of
domain_remove_one_dev_info() anyway.

BTW, the use of device_domain_lock looks a bit unsafe to me... it's
at least not obvious to me why we aren't vulnerable to the race below:

  iommu_support_dev_iotlb()
                                          domain_remove_dev_info()

  lock device_domain_lock
    find info
  unlock device_domain_lock

                                          lock device_domain_lock
                                            find same info
                                          unlock device_domain_lock

                                          free_devinfo_mem(info)

  do stuff with info after it's free

However I don't understand the locking here well enough to know if
this is a real problem, let alone what the best fix is.

Anyway here's the full lockdep output that prompted all of this:

     =======================================================
     [ INFO: possible circular locking dependency detected ]
     2.6.39.1+ #1
     -------------------------------------------------------
     bash/13954 is trying to acquire lock:
      (&(&iommu->lock)->rlock){......}, at: [] domain_remove_one_dev_info+0x121/0x230

     but task is already holding lock:
      (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230

     which lock already depends on the new lock.

     the existing dependency chain (in reverse order) is:

     -> #1 (device_domain_lock){-.-...}:
            [] lock_acquire+0x9d/0x130
            [] _raw_spin_lock_irqsave+0x55/0xa0
            [] domain_context_mapping_one+0x600/0x750
            [] domain_context_mapping+0x3f/0x120
            [] iommu_prepare_identity_map+0x1c5/0x1e0
            [] intel_iommu_init+0x88e/0xb5e
            [] pci_iommu_init+0x16/0x41
            [] do_one_initcall+0x45/0x190
            [] kernel_init+0xe3/0x168
            [] kernel_thread_helper+0x4/0x10

     -> #0 (&(&iommu->lock)->rlock){......}:
            [] __lock_acquire+0x195e/0x1e10
            [] lock_acquire+0x9d/0x130
            [] _raw_spin_lock_irqsave+0x55/0xa0
            [] domain_remove_one_dev_info+0x121/0x230
            [] device_notifier+0x72/0x90
            [] notifier_call_chain+0x8c/0xc0
            [] __blocking_notifier_call_chain+0x78/0xb0
            [] blocking_notifier_call_chain+0x16/0x20
            [] __device_release_driver+0xbc/0xe0
            [] device_release_driver+0x2f/0x50
            [] driver_unbind+0xa3/0xc0
            [] drv_attr_store+0x2c/0x30
            [] sysfs_write_file+0xe6/0x170
            [] vfs_write+0xce/0x190
            [] sys_write+0x54/0xa0
            [] system_call_fastpath+0x16/0x1b

     other info that might help us debug this:

     6 locks held by bash/13954:
      #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x44/0x170
      #1:  (s_active#3){++++.+}, at: [] sysfs_write_file+0xcd/0x170
      #2:  (&__lockdep_no_validate__){+.+.+.}, at: [] driver_unbind+0x9b/0xc0
      #3:  (&__lockdep_no_validate__){+.+.+.}, at: [] device_release_driver+0x27/0x50
      #4:  (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x5f/0xb0
      #5:  (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230

     stack backtrace:
     Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1
     Call Trace:
      [] print_circular_bug+0xf7/0x100
      [] __lock_acquire+0x195e/0x1e10
      [] ? trace_hardirqs_off+0xd/0x10
      [] ? trace_hardirqs_on_caller+0x13d/0x180
      [] lock_acquire+0x9d/0x130
      [] ? domain_remove_one_dev_info+0x121/0x230
      [] _raw_spin_lock_irqsave+0x55/0xa0
      [] ? domain_remove_one_dev_info+0x121/0x230
      [] ? trace_hardirqs_off+0xd/0x10
      [] domain_remove_one_dev_info+0x121/0x230
      [] device_notifier+0x72/0x90
      [] notifier_call_chain+0x8c/0xc0
      [] __blocking_notifier_call_chain+0x78/0xb0
      [] blocking_notifier_call_chain+0x16/0x20
      [] __device_release_driver+0xbc/0xe0
      [] device_release_driver+0x2f/0x50
      [] driver_unbind+0xa3/0xc0
      [] drv_attr_store+0x2c/0x30
      [] sysfs_write_file+0xe6/0x170
      [] vfs_write+0xce/0x190
      [] sys_write+0x54/0xa0
      [] system_call_fastpath+0x16/0x1b

Signed-off-by: Roland Dreier 
Signed-off-by: David Woodhouse 
Cc: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

PCI: Check P2P bridge for invalid secondary/subordinate range

2012-10-12T20:28:09+00:00

commit 1965f66e7db08d1ebccd24a59043eba826cc1ce8 upstream.

For bridges with "secondary > subordinate", i.e., invalid bus number
apertures, we don't enumerate anything behind the bridge unless the
user specified "pci=assign-busses".

This patch makes us automatically try to reassign the downstream bus
numbers in this case (just for that bridge, not for all bridges as
"pci=assign-busses" does).

We don't discover all the devices on the Intel DP43BF motherboard
without this change (or "pci=assign-busses") because its BIOS configures
a bridge as:

    pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode)

[bhelgaas: changelog, change message to dev_info]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754
Reported-by: Brian C. Huffman 
Reported-by: VL 
Tested-by: VL 
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas

PCI: acpiphp: check whether _ADR evaluation succeeded

2012-10-12T20:28:03+00:00

commit dfb117b3e50c52c7b3416db4a4569224b8db80bb upstream.

Check whether we evaluated _ADR successfully.  Previously we ignored
failure, so we would have used garbage data from the stack as the device
and function number.

We return AE_OK so that we ignore only this slot and continue looking
for other slots.

Found by Coverity (CID 113981).

Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 2.6.32/3.0: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

PCI: honor child buses add_size in hot plug configuration

2012-10-07T15:27:27+00:00

commit be768912a49b10b68e96fbd8fa3cab0adfbd3091 upstream.

git commit c8adf9a3e873eddaaec11ac410a99ef6b9656938
    "PCI: pre-allocate additional resources to devices only after
	successful allocation of essential resources."

fails to take into consideration the optional-resources needed by children
devices while calculating the optional-resource needed by the bridge.

This can be a problem on some setup. For example, if a hotplug bridge has 8
children hotplug bridges, the bridge should have enough resources to accomodate
the hotplug requirements for each of its children hotplug bridges.  Currently
this is not the case.

This patch fixes the problem.

Signed-off-by: Yinghai Lu 
Reviewed-by: Ram Pai 
Signed-off-by: Jesse Barnes 
Cc: Andrew Worsley 
Signed-off-by: Greg Kroah-Hartman

PCI: EHCI: Fix crash during hibernation on ASUS computers

2012-09-14T17:00:39+00:00

commit 0b68c8e2c3afaf9807eb1ebe0ccfb3b809570aa4 upstream.

Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS
computers) added a workaround for an ASUS suspend issue related to
USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut
down the EHCI controller during system suspend if its PCI command
register doesn't contain 0 at that time.

It turns out that the same workaround is necessary in the analogous
hibernation code path, so add it.

References: https://bugzilla.kernel.org/show_bug.cgi?id=45811
Reported-and-tested-by: Oleksij Rempel 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: EHCI: fix crash during suspend on ASUS computers

2012-07-16T15:47:50+00:00

commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream.

Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend.  It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.

It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working.  Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.

Now we know the actual cause of the problem.  Thanks to AceLan Kao for
tracking it down.

According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows.  When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state.  If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so.  This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3.  The end result is
a system hang or memory corruption.

Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend.  This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.

In theory we could do this for every PCI device.  However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.

Finally the affected systems can suspend with USB wakeup working
properly.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao 
Signed-off-by: Alan Stern 
Tested-by: Dâniel Fraga 
Tested-by: Javier Marcet 
Tested-by: Andrey Rahmatullin 
Tested-by: Oleksij Rempel 
Tested-by: Pavel Pisa 
Acked-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2

2012-06-22T18:34:15+00:00

commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b upstream.

This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers).  The patch supersedes that one and reverts
it.  There are two differences:

	The old patch added the flag at the USB level; this patch
	adds it at the PCI level.

	The old patch applied to all chipsets with the same vendor,
	subsystem vendor, and product IDs; this patch makes an
	exception for a known-good system (based on DMI information).

Signed-off-by: Alan Stern 
Tested-by: Dâniel Fraga 
Tested-by: Andrey Rahmatullin 
Tested-by: Steven Rostedt 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs

2012-04-27T16:51:08+00:00

commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.

Some BIOS implementations leave the Intel GPU interrupts enabled,
even though no one is handling them (f.e. i915 driver is never loaded).
Additionally the interrupt destination is not set up properly
and the interrupt ends up -somewhere-.

These spurious interrupts are "sticky" and the kernel disables
the (shared) interrupt line after 100.000+ generated interrupts.

Fix it by disabling the still enabled interrupts.
This resolves crashes often seen on monitor unplug.

Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash.
  Probably the IRQ ends up somewhere unnoticed.

According to reports on the net, the Intel DH61WW board is also affected.

Many thanks to Jesse Barnes from Intel for helping
with the register configuration and to Intel in general
for providing public hardware documentation.

Signed-off-by: Thomas Jarosch 
Tested-by: Charlie Suffin 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

ASPM: Fix pcie devices with non-pcie children

2012-04-02T16:27:22+00:00

commit c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 upstream.

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 4949be16822e ("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  # kernel panic
Reported-by: Chris Holland  # disk detection trouble
Signed-off-by: Matthew Garrett 
Tested-by: Hatem Masmoudi  # Dell Latitude E5520
Tested-by: janek  # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: Jonathan Nieder 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled

2012-03-19T15:57:43+00:00

commit 4949be16822e92a18ea0cc1616319926628092ee upstream.

Right now we won't touch ASPM state if ASPM is disabled, except in the case
where we find a device that appears to be too old to reliably support ASPM.
Right now we'll clear it in that case, which is almost certainly the wrong
thing to do. The easiest way around this is just to disable the blacklisting
when ASPM is disabled.

Signed-off-by: Matthew Garrett 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman