1. 05 10月, 2017 7 次提交
  2. 20 7月, 2017 2 次提交
    • S
      xhci: fix memleak in xhci_run() · d6f5f071
      Shu Wang 提交于
      Found this issue by kmemleak.
      xhci_run() did not check return val and free command for
      xhci_queue_vendor_command()
      
      unreferenced object 0xffff88011c0be500 (size 64):
        comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s)
        hex dump (first 32 bytes):
        backtrace:
          [<ffffffff8176166a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffff8121801a>] kmem_cache_alloc_trace+0xca/0x1d0
          [<ffffffff81576bf4>] xhci_alloc_command+0x44/0x130
          [<ffffffff8156f1cc>] xhci_run+0x4cc/0x630
          [<ffffffff8153b84b>] usb_add_hcd+0x3bb/0x950
          [<ffffffff8154eac8>] usb_hcd_pci_probe+0x188/0x500
          [<ffffffff815851ac>] xhci_pci_probe+0x2c/0x220
          [<ffffffff813d2ca5>] local_pci_probe+0x45/0xa0
          [<ffffffff810a54e4>] work_for_cpu_fn+0x14/0x20
          [<ffffffff810a8409>] process_one_work+0x149/0x360
          [<ffffffff810a8d08>] worker_thread+0x1d8/0x3c0
          [<ffffffff810ae7d9>] kthread+0x109/0x140
          [<ffffffff8176d585>] ret_from_fork+0x25/0x30
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NShu Wang <shuwang@redhat.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6f5f071
    • J
      xhci: Bad Ethernet performance plugged in ASM1042A host · 9da5a109
      Jiahau Chang 提交于
      When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
      performance was manifesting in Web browser use (like download
      large file such as ISO image). It is known limitation of
      ASM1042A that is not compatible with driver scheduling,
      As a workaround we can modify flow control handling of ASM1042A.
      The register we modify is changes the behavior
      
      [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJiahau Chang <Lars_chang@asmedia.com.tw>
      Signed-off-by: NIan Pilcher <arequipeno@gmail.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9da5a109
  3. 16 6月, 2017 2 次提交
  4. 03 6月, 2017 1 次提交
  5. 18 5月, 2017 2 次提交
  6. 20 4月, 2017 1 次提交
  7. 08 4月, 2017 10 次提交
  8. 29 3月, 2017 1 次提交
    • M
      xhci: Manually give back cancelled URB if we can't queue it for cancel · d3519b9d
      Mathias Nyman 提交于
      xhci needs to take care of four scenarios when asked to cancel a URB.
      
      1 URB is not queued or already given back.
        usb_hcd_check_unlink_urb() will return an error, we pass the error on
      
      2 We fail to find xhci internal structures from urb private data such as
        virtual device and endpoint ring.
        Give back URB immediately, can't do anything about internal structures.
      
      3 URB private data has valid pointers to xhci internal data, but host is
        not  responding.
        give back URB immedately and remove the URB from the endpoint lists.
      
      4 Everyting is working
        add URB to cancel list, queue a command to stop the endpoint, after
        which the URB can be turned to no-op or skipped, removed from lists,
        and given back.
      
      We failed to give back the urb in case 2 where the correct device and
      endpoint pointers could not be retrieved from URB private data.
      
      This caused a hang on Dell Inspiron 5558/0VNM2T at resume from suspend
      as urb was never returned.
      
      [  245.270505] INFO: task rtsx_usb_ms_1:254 blocked for more than 120 seconds.
      [  245.272244]       Tainted: G        W       4.11.0-rc3-ARCH #2
      [  245.273983] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  245.275737] rtsx_usb_ms_1   D    0   254      2 0x00000000
      [  245.277524] Call Trace:
      [  245.279278]  __schedule+0x2d3/0x8a0
      [  245.281077]  schedule+0x3d/0x90
      [  245.281961]  usb_kill_urb.part.3+0x6c/0xa0 [usbcore]
      [  245.282861]  ? wake_atomic_t_function+0x60/0x60
      [  245.283760]  usb_kill_urb+0x21/0x30 [usbcore]
      [  245.284649]  usb_start_wait_urb+0xe5/0x170 [usbcore]
      [  245.285541]  ? try_to_del_timer_sync+0x53/0x80
      [  245.286434]  usb_bulk_msg+0xbd/0x160 [usbcore]
      [  245.287326]  rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb]
      
      Reported-by: diego.viola@gmail.com
      Tested-by: diego.viola@gmail.com
      Cc: stable@vger.kernel.org
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3519b9d
  9. 23 3月, 2017 1 次提交
  10. 17 3月, 2017 1 次提交
  11. 10 3月, 2017 1 次提交
  12. 25 1月, 2017 10 次提交
  13. 11 1月, 2017 1 次提交
    • M
      xhci: fix deadlock at host remove by running watchdog correctly · d6169d04
      Mathias Nyman 提交于
      If a URB is killed while the host is removed we can end up in a situation
      where the hub thread takes the roothub device lock, and waits for
      the URB to be given back by xhci-hcd, blocking the host remove code.
      
      xhci-hcd tries to stop the endpoint and give back the urb, but can't
      as the host is removed from PCI bus at the same time, preventing the normal
      way of giving back urb.
      
      Instead we need to rely on the stop command timeout function to give back
      the urb. This xhci_stop_endpoint_command_watchdog() timeout function
      used a XHCI_STATE_DYING flag to indicate if the timeout function is already
      running, but later this flag has been taking into use in other places to
      mark that xhci is dying.
      
      Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
      checking that reading from pci state does not return 0xffffffff or that
      host is not halted before trying to stop the endpoint.
      
      This whole area of stopping endpoints, giving back URBs, and the wathdog
      timeout need rework, this fix focuses on solving a specific deadlock
      issue that we can then send to stable before any major rework.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6169d04