1. 13 Sep, 2017 5 commits
    • Douglas Anderson's avatar
      USB: core: Avoid race of async_completed() w/ usbdev_release() · 812e4841
      Douglas Anderson authored
      commit ed62ca2f upstream.
      
      While running reboot tests w/ a specific set of USB devices (and
      slub_debug enabled), I found that once every few hours my device would
      be crashed with a stack that looked like this:
      
      [   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
      [   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
      [   14.012460] /1025536097, .owner_cpu: 0
      [   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
      [   14.012468] Hardware name: Google Kevin (DT)
      [   14.012471] Call trace:
      [   14.012483] [<....>] dump_backtrace+0x0/0x160
      [   14.012487] [<....>] show_stack+0x20/0x28
      [   14.012494] [<....>] dump_stack+0xb4/0xf0
      [   14.012500] [<....>] spin_dump+0x8c/0x98
      [   14.012504] [<....>] spin_bug+0x30/0x3c
      [   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
      [   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
      [   14.012521] [<....>] __wake_up+0x2c/0x60
      [   14.012528] [<....>] async_completed+0x2d0/0x300
      [   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
      [   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
      [   14.012544] [<....>] xhci_irq+0x1314/0x1348
      [   14.012548] [<....>] usb_hcd_irq+0x40/0x50
      [   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
      [   14.012556] [<....>] handle_irq_event+0x4c/0x7c
      [   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
      [   14.012564] [<....>] generic_handle_irq+0x30/0x44
      [   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
      [   14.012572] [<....>] gic_handle_irq+0xcc/0x18c
      
      Investigation using kgdb() found that the wait queue that was passed
      into wake_up() had been freed (it was filled with slub_debug poison).
      
      I analyzed and instrumented the code and reproduced.  My current
      belief is that this is happening:
      
      1. async_completed() is called (from IRQ).  Moves "as" onto the
         completed list.
      2. On another CPU, proc_reapurbnonblock_compat() calls
         async_getcompleted().  Blocks on spinlock.
      3. async_completed() releases the lock; keeps running; gets blocked
         midway through wake_up().
      4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
         lock; removes "as" from completed list and frees it.
      5. usbdev_release() is called.  Frees "ps".
      6. async_completed() finally continues running wake_up().  ...but
         wake_up() has a pointer to the freed "ps".
      
      The instrumentation that led me to believe this was based on adding
      some trace_printk() calls in a select few functions and then using
      kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
      below I cheated a little bit and added a udelay(1000) in
      async_completed() after releasing the spinlock because I wanted it to
      trigger quicker):
      
      <...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
      mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
      mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
      mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
      mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
      mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
      mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
      mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
      <...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200
      
      To fix this problem we can just move the wake_up() under the ps->lock.
      There should be no issues there that I'm aware of.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      812e4841
    • Sandeep Singh's avatar
      usb:xhci:Fix regression when ATI chipsets detected · 9f1d78c6
      Sandeep Singh authored
      commit e6b422b8 upstream.
      
      The following commit cause a regression on ATI chipsets.
      'commit e788787e ("usb:xhci:Add quirk for Certain
      failing HP keyboard on reset after resume")'
      
      This causes pinfo->smbus_dev to be wrongly set to NULL on
      systems with the ATI chipset that this function checks for first.
      
      Added conditional check for AMD chipsets to avoid the overwriting
      pinfo->smbus_dev.
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Fixes: e788787e ("usb:xhci:Add quirk for Certain
      failing HP keyboard on reset after resume")
      cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      Signed-off-by: default avatarSandeep Singh <Sandeep.Singh@amd.com>
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f1d78c6
    • Dmitry Fleytman's avatar
      usb: Add device quirk for Logitech HD Pro Webcam C920-C · b3e92cd7
      Dmitry Fleytman authored
      commit a1279ef7 upstream.
      
      Commit e0429362
      ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
      introduced quirk to workaround an issue with some Logitech webcams.
      
      Apparently model C920-C has the same issue so applying
      the same quirk as well.
      
      See aforementioned commit message for detailed explanation of the problem.
      Signed-off-by: default avatarDmitry Fleytman <dmitry@daynix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3e92cd7
    • Maciej S. Szmigiero's avatar
      USB: serial: option: add support for D-Link DWM-157 C1 · 6e957a81
      Maciej S. Szmigiero authored
      commit 169e8654 upstream.
      
      This commit adds support (an ID, really) for D-Link DWM-157 hardware
      version C1 USB modem to option driver.
      
      According to manufacturer-provided Windows INF file the device has four
      serial ports:
      "D-Link HSPA+DataCard Diagnostics Interface" (interface 2; modem port),
      "D-Link HSPA+DataCard NMEA Device" (interface 3),
      "D-Link HSPA+DataCard Speech Port" (interface 4),
      "D-Link HSPA+DataCard Debug Port" (interface 5).
      
      usb-devices output:
      T:  Bus=05 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7d0e Rev=03.00
      S:  Manufacturer=D-Link,Inc
      S:  Product=D-Link DWM-157
      C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      Signed-off-by: default avatarMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e957a81
    • Kai-Heng Feng's avatar
      usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard · f7a0f731
      Kai-Heng Feng authored
      commit de3af5bf upstream.
      
      Corsair Strafe RGB keyboard has trouble to initialize:
      
      [ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
      [ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
      [ 6.871138] usb 3-6: can't read configurations, error -110
      [ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
      [ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
      [ 12.246644] usb 3-6: can't read configurations, error -110
      [ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
      [ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
      [ 17.622147] usb 3-6: can't read configurations, error -110
      [ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
      [ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
      [ 22.997716] usb 3-6: can't read configurations, error -110
      
      Although it may work after several times unpluging/pluging:
      
      [ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
      [ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
      [ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      [ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
      [ 68.337468] usb 3-6: Manufacturer: Corsair
      [ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941
      
      Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
      USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone
      can workaround this issue. Hence add the quirk for Corsair Strafe RGB.
      
      BugLink: https://bugs.launchpad.net/bugs/1678477Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7a0f731
  2. 07 Sep, 2017 17 commits
  3. 02 Sep, 2017 16 commits
  4. 30 Aug, 2017 2 commits