linux-stable.git/drivers/usb/core, branch v3.2.18 Linux kernel stable tree USB: EHCI: fix crash during suspend on ASUS computers 2012-05-11T12:14:42+00:00 Alan Stern stern@rowland.harvard.edu 2012-04-24T18:07:22+00:00 f845dfabaf943e9d1bd97c1c023ee5c58ba04352 commit 151b61284776be2d6f02d48c23c3625678960b97 upstream. This patch (as1545) 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. This fixes Bugzilla #42728. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.

This patch (as1545) 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.

This fixes Bugzilla #42728.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
USB: fix deadlock in bConfigurationValue attribute method 2012-05-11T12:14:03+00:00 Alan Stern stern@rowland.harvard.edu 2012-04-17T19:22:39+00:00 90114113b4dc19abc832f03f1c1b7b837ba00af0 commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
USB: fix bug of device descriptor got from superspeed device 2012-04-22T22:31:03+00:00 Elric Fu elricfu1@gmail.com 2012-03-26T13:16:02+00:00 3277b4abfab889a877d0c30edf1209dff035a559 commit d8aec3dbdfd02627e198e7956ab4aaeba2a349fa upstream. When the Seagate Goflex USB3.0 device is attached to VIA xHCI host, sometimes the device will downgrade mode to high speed. By the USB analyzer, I found the device finished the link training process and worked at superspeed mode. But the device descriptor got from the device shows the device works at 2.1. It is very strange and seems like the device controller of Seagate Goflex has a little confusion. The first 8 bytes of device descriptor should be: 12 01 00 03 00 00 00 09 But the first 8 bytes of wrong device descriptor are: 12 01 10 02 00 00 00 40 The wrong device descriptor caused the initialization of mass storage failed. After a while, the device would be recognized as a high speed device and works fine. This patch will warm reset the device to fix the issue after finding the bcdUSB field of device descriptor isn't 0x0300 but the speed mode of device is superspeed. This patch should be backported to kernels as old as 3.2, or ones that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Elric Fu <elricfu1@gmail.com> Acked-by: Andiry Xu <Andiry.Xu@amd.com> Acked-by: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d8aec3dbdfd02627e198e7956ab4aaeba2a349fa upstream.

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore:
refine warm reset logic".

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Acked-by: Andiry Xu <Andiry.Xu@amd.com>
Acked-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: don't ignore suspend errors for root hubs 2012-04-22T22:31:03+00:00 Alan Stern stern@rowland.harvard.edu 2012-03-28T19:56:17+00:00 933ec440ffb8b188ab415b67ce975058ef795dbe commit cd4376e23a59a2adf3084cb5f4a523e6d5fd4e49 upstream. This patch (as1532) fixes a mistake in the USB suspend code. When the system is going to sleep, we should ignore errors in powering down USB devices, because they don't really matter. The devices will go to low power anyway when the entire USB bus gets suspended (except for SuperSpeed devices; maybe they will need special treatment later). However we should not ignore errors in suspending root hubs, especially if the error indicates that the suspend raced with a wakeup request. Doing so might leave the bus powered on while the system was supposed to be asleep, or it might cause the suspend of the root hub's parent controller device to fail, or it might cause a wakeup request to be ignored. The patch fixes the problem by ignoring errors only when the device in question is not a root hub. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Chen Peter <B29397@freescale.com> Tested-by: Chen Peter <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cd4376e23a59a2adf3084cb5f4a523e6d5fd4e49 upstream.

This patch (as1532) fixes a mistake in the USB suspend code.  When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter.  The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request.  Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Chen Peter <B29397@freescale.com>
Tested-by: Chen Peter <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: don't clear urb->dev in scatter-gather library 2012-04-22T22:31:02+00:00 Alan Stern stern@rowland.harvard.edu 2012-03-22T15:00:21+00:00 5199257b1b2849e1e6bb73e323bd61e6beb8de45 commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream. This patch (as1517b) fixes an error in the USB scatter-gather library. The library code uses urb->dev to determine whether or nor an URB is currently active; the completion handler sets urb->dev to NULL. However the core unlinking routines need to use urb->dev. Since unlinking always racing with completion, the completion handler must not clear urb->dev -- it can lead to invalid memory accesses when a transfer has to be cancelled. This patch fixes the problem by getting rid of the lines that clear urb->dev after urb has been submitted. As a result we may end up trying to unlink an URB that failed in submission or that has already completed, so an extra check is added after each unlink to avoid printing an error message when this happens. The checks are updated in both sg_complete() and sg_cancel(), and the second is updated to match the first (currently it prints out unnecessary warning messages if a device is unplugged while a transfer is in progress). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Illia Zaitsev <I.Zaitsev@adbglobal.com> CC: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream.

This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb->dev to determine whether or nor an URB is
currently active; the completion handler sets urb->dev to NULL.
However the core unlinking routines need to use urb->dev.  Since
unlinking always racing with completion, the completion handler must
not clear urb->dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.

This patch fixes the problem by getting rid of the lines that clear
urb->dev after urb has been submitted.  As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens.  The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Illia Zaitsev <I.Zaitsev@adbglobal.com>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: Set hub depth after USB3 hub reset 2012-03-01T00:31:08+00:00 Elric Fu elricfu1@gmail.com 2012-02-18T05:32:27+00:00 1a624979096199f383fc7785a509d1e38b608986 commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream. The superspeed device attached to a USB 3.0 hub(such as VIA's) doesn't respond the address device command after resume. The root cause is the superspeed hub will miss the Hub Depth value that is used as an offset into the route string to locate the bits it uses to determine the downstream port number after reset, and all packets can't be routed to the device attached to the superspeed hub. Hub driver sends a Set Hub Depth request to the superspeed hub except for USB 3.0 root hub when the hub is initialized and doesn't send the request again after reset due to the resume process. So moving the code that sends the Set Hub Depth request to the superspeed hub from hub_configure() to hub_activate() is to cover those situations include initialization and reset. The patch should be backported to kernels as old as 2.6.39. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: Don't fail USB3 probe on missing legacy PCI IRQ. 2012-03-01T00:31:08+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2012-02-14T00:25:57+00:00 4d5845033ef313d6d1008ac5dafe69dbab23cc11 commit 68d07f64b8a11a852d48d1b05b724c3e20c0d94b upstream. Intel has a PCI USB xhci host controller on a new platform. It doesn't have a line IRQ definition in BIOS. The Linux driver refuses to initialize this controller, but Windows works well because it only depends on MSI. Actually, Linux also can work for MSI. This patch avoids the line IRQ checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver to try to enable MSI or MSI-X first. It will fail the probe if MSI enabling failed and there's no legacy PCI IRQ. This patch should be backported to kernels as old as 2.6.32. Signed-off-by: Alex Shi <alex.shi@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 68d07f64b8a11a852d48d1b05b724c3e20c0d94b upstream.

Intel has a PCI USB xhci host controller on a new platform. It doesn't
have a line IRQ definition in BIOS.  The Linux driver refuses to
initialize this controller, but Windows works well because it only depends
on MSI.

Actually, Linux also can work for MSI.  This patch avoids the line IRQ
checking for USB3 HCDs in usb core PCI probe.  It allows the xHCI driver
to try to enable MSI or MSI-X first.  It will fail the probe if MSI
enabling failed and there's no legacy PCI IRQ.

This patch should be backported to kernels as old as 2.6.32.

Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: fix number of mapped SG DMA entries 2012-01-12T19:29:43+00:00 Clemens Ladisch clemens@ladisch.de 2011-12-03T22:41:31+00:00 4781ace0ddff8057f2c1bf1811ae4886f8b88876 commit bc677d5b64644c399cd3db6a905453e611f402ab upstream. Add a new field num_mapped_sgs to struct urb so that we have a place to store the number of mapped entries and can also retain the original value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma() would overwrite this with the number of mapped entries, which would break dma_unmap_sg() because it requires the original number of entries. This fixes warnings like the following when using USB storage devices: ------------[ cut here ]------------ WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695() ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1] Modules linked in: ohci_hcd ehci_hcd Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319 Call Trace: <IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98 [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43 [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695 [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50 [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117 [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188 [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22 [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0 [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd] [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd] [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd] ... ---[ end trace f29ac88a5a48c580 ]--- Mapped at: [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139 [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478 [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161 Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
  <IRQ>  [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
  [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
  [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
  [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
  [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
  [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
  [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
  [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
  [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
  [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
  [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
  [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
  [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add quirk for another camera 2012-01-12T19:29:40+00:00 Oliver Neukum oliver@neukum.org 2012-01-03T08:58:54+00:00 dd857f5b4dc1d8d010da1711b71be789054fbcbe commit 35284b3d2f68a8a3703745e629999469f78386b5 upstream. The Guillemot Webcam Hercules Dualpix Exchange camera has been reported with a second ID. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 35284b3d2f68a8a3703745e629999469f78386b5 upstream.

The Guillemot Webcam Hercules Dualpix Exchange camera
has been reported with a second ID.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usbfs: Fix oops related to user namespace conversion. 2012-01-12T19:29:34+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2011-12-16T19:26:30+00:00 7f35a6941c20af66dde1148b491e2f501192179b commit 1b41c8321e495337e877ca02d0b9680bc4112eff upstream. When running the Point Grey "flycap" program for their USB 3.0 camera (which was running as a USB 2.0 device for some reason), I trigger this oops whenever I try to open a video stream: Dec 15 16:48:34 puck kernel: [ 1798.715559] BUG: unable to handle kernel NULL pointer dereference at (null) Dec 15 16:48:34 puck kernel: [ 1798.719153] IP: [<ffffffff8147841e>] free_async+0x1e/0x70 Dec 15 16:48:34 puck kernel: [ 1798.720991] PGD 6f833067 PUD 6fc56067 PMD 0 Dec 15 16:48:34 puck kernel: [ 1798.722815] Oops: 0002 [#1] SMP Dec 15 16:48:34 puck kernel: [ 1798.724627] CPU 0 Dec 15 16:48:34 puck kernel: [ 1798.724636] Modules linked in: ecryptfs encrypted_keys sha1_generic trusted binfmt_misc sha256_generic aesni_intel cryptd aes_x86_64 aes_generic parport_pc dm_crypt ppdev joydev snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer btusb uvcvideo snd_seq_device bluetooth videodev psmouse snd v4l2_compat_ioctl32 serio_raw tpm_tis cfg80211 tpm tpm_bios nvram soundcore snd_page_alloc lp parport i915 xhci_hcd ahci libahci drm_kms_helper drm sdhci_pci sdhci e1000e i2c_algo_bit video Dec 15 16:48:34 puck kernel: [ 1798.734212] Dec 15 16:48:34 puck kernel: [ 1798.736162] Pid: 2713, comm: FlyCap2 Not tainted 3.2.0-rc5+ #28 LENOVO 4286CTO/4286CTO Dec 15 16:48:34 puck kernel: [ 1798.738148] RIP: 0010:[<ffffffff8147841e>] [<ffffffff8147841e>] free_async+0x1e/0x70 Dec 15 16:48:34 puck kernel: [ 1798.740134] RSP: 0018:ffff88005715fd78 EFLAGS: 00010296 Dec 15 16:48:34 puck kernel: [ 1798.742118] RAX: 00000000fffffff4 RBX: ffff88006fe8f900 RCX: 0000000000004118 Dec 15 16:48:34 puck kernel: [ 1798.744116] RDX: 0000000001000000 RSI: 0000000000016390 RDI: 0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.746087] RBP: ffff88005715fd88 R08: 0000000000000000 R09: ffffffff8146f22e Dec 15 16:48:34 puck kernel: [ 1798.748018] R10: ffff88006e520ac0 R11: 0000000000000001 R12: ffff88005715fe28 Dec 15 16:48:34 puck kernel: [ 1798.749916] R13: ffff88005d31df00 R14: ffff88006fe8f900 R15: 00007f688c995cb8 Dec 15 16:48:34 puck kernel: [ 1798.751785] FS: 00007f68a366da40(0000) GS:ffff880100200000(0000) knlGS:0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.753659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 15 16:48:34 puck kernel: [ 1798.755509] CR2: 0000000000000000 CR3: 00000000706bb000 CR4: 00000000000406f0 Dec 15 16:48:34 puck kernel: [ 1798.757334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.759124] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Dec 15 16:48:34 puck kernel: [ 1798.760871] Process FlyCap2 (pid: 2713, threadinfo ffff88005715e000, task ffff88006c675b80) Dec 15 16:48:34 puck kernel: [ 1798.762605] Stack: Dec 15 16:48:34 puck kernel: [ 1798.764297] ffff88005715fe28 0000000000000000 ffff88005715fe08 ffffffff81479058 Dec 15 16:48:34 puck kernel: [ 1798.766020] 0000000000000000 ffffea0000004000 ffff880000004118 0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.767750] ffff880000000001 ffff88006e520ac0 fffffff46fd81180 0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.769472] Call Trace: Dec 15 16:48:34 puck kernel: [ 1798.771147] [<ffffffff81479058>] proc_do_submiturb+0x778/0xa00 Dec 15 16:48:34 puck kernel: [ 1798.772798] [<ffffffff8147a5fd>] usbdev_do_ioctl+0x24d/0x1200 Dec 15 16:48:34 puck kernel: [ 1798.774410] [<ffffffff8147b5de>] usbdev_ioctl+0xe/0x20 Dec 15 16:48:34 puck kernel: [ 1798.775975] [<ffffffff81189259>] do_vfs_ioctl+0x99/0x600 Dec 15 16:48:34 puck kernel: [ 1798.777534] [<ffffffff81189851>] sys_ioctl+0x91/0xa0 Dec 15 16:48:34 puck kernel: [ 1798.779088] [<ffffffff816247c2>] system_call_fastpath+0x16/0x1b ec 15 16:48:34 puck kernel: [ 1798.780634] Code: 51 ff ff ff e9 29 ff ff ff 0f 1f 40 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 8b 7f 18 e8 a6 ea c0 ff 4 8 8b 7b 20 <f0> ff 0f 0f 94 c0 84 c0 74 05 e8 d3 99 c1 ff 48 8b 43 40 48 8b Dec 15 16:48:34 puck kernel: [ 1798.783970] RIP [<ffffffff8147841e>] free_async+0x1e/0x70 Dec 15 16:48:34 puck kernel: [ 1798.785630] RSP <ffff88005715fd78> Dec 15 16:48:34 puck kernel: [ 1798.787274] CR2: 0000000000000000 Dec 15 16:48:34 puck kernel: [ 1798.794728] ---[ end trace 52894d3355f88d19 ]--- markup_oops.pl says the oops is in put_cred: ffffffff81478401: 48 89 e5 mov %rsp,%rbp ffffffff81478404: 53 push %rbx ffffffff81478405: 48 83 ec 08 sub $0x8,%rsp ffffffff81478409: e8 f2 c0 1a 00 callq ffffffff81624500 <mcount> ffffffff8147840e: 48 89 fb mov %rdi,%rbx | %ebx => ffff88006fe8f900 put_pid(as->pid); ffffffff81478411: 48 8b 7f 18 mov 0x18(%rdi),%rdi ffffffff81478415: e8 a6 ea c0 ff callq ffffffff81086ec0 <put_pid> put_cred(as->cred); ffffffff8147841a: 48 8b 7b 20 mov 0x20(%rbx),%rdi | %edi => 0 %ebx = ffff88006fe8f900 */ static inline int atomic_dec_and_test(atomic_t *v) { unsigned char c; asm volatile(LOCK_PREFIX "decl %0; sete %1" *ffffffff8147841e: f0 ff 0f lock decl (%rdi) | %edi = 0 <--- faulting instruction ffffffff81478421: 0f 94 c0 sete %al static inline void put_cred(const struct cred *_cred) { struct cred *cred = (struct cred *) _cred; validate_creds(cred); if (atomic_dec_and_test(&(cred)->usage)) ffffffff81478424: 84 c0 test %al,%al ffffffff81478426: 74 05 je ffffffff8147842d <free_async+0x2d> __put_cred(cred); ffffffff81478428: e8 d3 99 c1 ff callq ffffffff81091e00 <__put_cred> kfree(as->urb->transfer_buffer); ffffffff8147842d: 48 8b 43 40 mov 0x40(%rbx),%rax ffffffff81478431: 48 8b 78 68 mov 0x68(%rax),%rdi ffffffff81478435: e8 a6 e1 ce ff callq ffffffff811665e0 <kfree> kfree(as->urb->setup_packet); ffffffff8147843a: 48 8b 43 40 mov 0x40(%rbx),%rax ffffffff8147843e: 48 8b b8 90 00 00 00 mov 0x90(%rax),%rdi ffffffff81478445: e8 96 e1 ce ff callq ffffffff811665e0 <kfree> usb_free_urb(as->urb); ffffffff8147844a: 48 8b 7b 40 mov 0x40(%rbx),%rdi ffffffff8147844e: e8 0d 6b ff ff callq ffffffff8146ef60 <usb_free_urb> This bug seems to have been introduced by commit d178bc3a708f39cbfefc3fab37032d3f2511b4ec "user namespace: usb: make usb urbs user namespace aware (v2)" I'm not sure if this is right fix, but it does stop the oops. Unfortunately, the Point Grey software still refuses to work, but it's a closed source app, so I can't fix it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1b41c8321e495337e877ca02d0b9680bc4112eff upstream.

When running the Point Grey "flycap" program for their USB 3.0 camera
(which was running as a USB 2.0 device for some reason), I trigger this
oops whenever I try to open a video stream:

Dec 15 16:48:34 puck kernel: [ 1798.715559] BUG: unable to handle kernel NULL pointer dereference at           (null)
Dec 15 16:48:34 puck kernel: [ 1798.719153] IP: [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.720991] PGD 6f833067 PUD 6fc56067 PMD 0
Dec 15 16:48:34 puck kernel: [ 1798.722815] Oops: 0002 [#1] SMP
Dec 15 16:48:34 puck kernel: [ 1798.724627] CPU 0
Dec 15 16:48:34 puck kernel: [ 1798.724636] Modules linked in: ecryptfs encrypted_keys sha1_generic trusted binfmt_misc sha256_generic aesni_intel cryptd aes_x86_64 aes_generic parport_pc dm_crypt ppdev joydev snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer btusb uvcvideo snd_seq_device bluetooth videodev psmouse snd v4l2_compat_ioctl32 serio_raw tpm_tis cfg80211 tpm tpm_bios nvram soundcore snd_page_alloc lp parport i915 xhci_hcd ahci libahci drm_kms_helper drm sdhci_pci sdhci e1000e i2c_algo_bit video
Dec 15 16:48:34 puck kernel: [ 1798.734212]
Dec 15 16:48:34 puck kernel: [ 1798.736162] Pid: 2713, comm: FlyCap2 Not tainted 3.2.0-rc5+ #28 LENOVO 4286CTO/4286CTO
Dec 15 16:48:34 puck kernel: [ 1798.738148] RIP: 0010:[<ffffffff8147841e>]  [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.740134] RSP: 0018:ffff88005715fd78  EFLAGS: 00010296
Dec 15 16:48:34 puck kernel: [ 1798.742118] RAX: 00000000fffffff4 RBX: ffff88006fe8f900 RCX: 0000000000004118
Dec 15 16:48:34 puck kernel: [ 1798.744116] RDX: 0000000001000000 RSI: 0000000000016390 RDI: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.746087] RBP: ffff88005715fd88 R08: 0000000000000000 R09: ffffffff8146f22e
Dec 15 16:48:34 puck kernel: [ 1798.748018] R10: ffff88006e520ac0 R11: 0000000000000001 R12: ffff88005715fe28
Dec 15 16:48:34 puck kernel: [ 1798.749916] R13: ffff88005d31df00 R14: ffff88006fe8f900 R15: 00007f688c995cb8
Dec 15 16:48:34 puck kernel: [ 1798.751785] FS:  00007f68a366da40(0000) GS:ffff880100200000(0000) knlGS:0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.753659] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 15 16:48:34 puck kernel: [ 1798.755509] CR2: 0000000000000000 CR3: 00000000706bb000 CR4: 00000000000406f0
Dec 15 16:48:34 puck kernel: [ 1798.757334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.759124] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec 15 16:48:34 puck kernel: [ 1798.760871] Process FlyCap2 (pid: 2713, threadinfo ffff88005715e000, task ffff88006c675b80)
Dec 15 16:48:34 puck kernel: [ 1798.762605] Stack:
Dec 15 16:48:34 puck kernel: [ 1798.764297]  ffff88005715fe28 0000000000000000 ffff88005715fe08 ffffffff81479058
Dec 15 16:48:34 puck kernel: [ 1798.766020]  0000000000000000 ffffea0000004000 ffff880000004118 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.767750]  ffff880000000001 ffff88006e520ac0 fffffff46fd81180 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.769472] Call Trace:
Dec 15 16:48:34 puck kernel: [ 1798.771147]  [<ffffffff81479058>] proc_do_submiturb+0x778/0xa00
Dec 15 16:48:34 puck kernel: [ 1798.772798]  [<ffffffff8147a5fd>] usbdev_do_ioctl+0x24d/0x1200
Dec 15 16:48:34 puck kernel: [ 1798.774410]  [<ffffffff8147b5de>] usbdev_ioctl+0xe/0x20
Dec 15 16:48:34 puck kernel: [ 1798.775975]  [<ffffffff81189259>] do_vfs_ioctl+0x99/0x600
Dec 15 16:48:34 puck kernel: [ 1798.777534]  [<ffffffff81189851>] sys_ioctl+0x91/0xa0
Dec 15 16:48:34 puck kernel: [ 1798.779088]  [<ffffffff816247c2>] system_call_fastpath+0x16/0x1b
ec 15 16:48:34 puck kernel: [ 1798.780634] Code: 51 ff ff ff e9 29 ff ff ff 0f 1f 40 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 8b 7f 18 e8 a6 ea c0 ff 4
8 8b 7b 20 <f0> ff 0f 0f 94 c0 84 c0 74 05 e8 d3 99 c1 ff 48 8b 43 40 48 8b
Dec 15 16:48:34 puck kernel: [ 1798.783970] RIP  [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.785630]  RSP <ffff88005715fd78>
Dec 15 16:48:34 puck kernel: [ 1798.787274] CR2: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.794728] ---[ end trace 52894d3355f88d19 ]---

markup_oops.pl says the oops is in put_cred:

 ffffffff81478401:      48 89 e5                mov    %rsp,%rbp
 ffffffff81478404:      53                      push   %rbx
 ffffffff81478405:      48 83 ec 08             sub    $0x8,%rsp
 ffffffff81478409:      e8 f2 c0 1a 00          callq  ffffffff81624500 <mcount>
 ffffffff8147840e:      48 89 fb                mov    %rdi,%rbx   |  %ebx => ffff88006fe8f900
        put_pid(as->pid);
 ffffffff81478411:      48 8b 7f 18             mov    0x18(%rdi),%rdi
 ffffffff81478415:      e8 a6 ea c0 ff          callq  ffffffff81086ec0 <put_pid>
        put_cred(as->cred);
 ffffffff8147841a:      48 8b 7b 20             mov    0x20(%rbx),%rdi |  %edi => 0  %ebx = ffff88006fe8f900
  */
 static inline int atomic_dec_and_test(atomic_t *v)
 {
        unsigned char c;

        asm volatile(LOCK_PREFIX "decl %0; sete %1"
*ffffffff8147841e:      f0 ff 0f                lock decl (%rdi)   |  %edi = 0 <--- faulting instruction
 ffffffff81478421:      0f 94 c0                sete   %al
 static inline void put_cred(const struct cred *_cred)
 {
        struct cred *cred = (struct cred *) _cred;

        validate_creds(cred);
        if (atomic_dec_and_test(&(cred)->usage))
 ffffffff81478424:      84 c0                   test   %al,%al
 ffffffff81478426:      74 05                   je     ffffffff8147842d <free_async+0x2d>
                __put_cred(cred);
 ffffffff81478428:      e8 d3 99 c1 ff          callq  ffffffff81091e00 <__put_cred>
        kfree(as->urb->transfer_buffer);
 ffffffff8147842d:      48 8b 43 40             mov    0x40(%rbx),%rax
 ffffffff81478431:      48 8b 78 68             mov    0x68(%rax),%rdi
 ffffffff81478435:      e8 a6 e1 ce ff          callq  ffffffff811665e0 <kfree>
        kfree(as->urb->setup_packet);
 ffffffff8147843a:      48 8b 43 40             mov    0x40(%rbx),%rax
 ffffffff8147843e:      48 8b b8 90 00 00 00    mov    0x90(%rax),%rdi
 ffffffff81478445:      e8 96 e1 ce ff          callq  ffffffff811665e0 <kfree>
        usb_free_urb(as->urb);
 ffffffff8147844a:      48 8b 7b 40             mov    0x40(%rbx),%rdi
 ffffffff8147844e:      e8 0d 6b ff ff          callq  ffffffff8146ef60 <usb_free_urb>

This bug seems to have been introduced by commit
d178bc3a708f39cbfefc3fab37032d3f2511b4ec "user namespace: usb: make usb
urbs user namespace aware (v2)"

I'm not sure if this is right fix, but it does stop the oops.

Unfortunately, the Point Grey software still refuses to work, but it's a
closed source app, so I can't fix it.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>