lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5992DB45.80803@linux.intel.com>
Date:   Tue, 15 Aug 2017 14:30:13 +0300
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        zhengjun.xing@...ux.intel.com
Subject: Re: [PATCH v3 5/5] usb: xhci: Handle USB transaction error on address
 command

On 11.08.2017 05:41, Lu Baolu wrote:
> Xhci driver handles USB transaction errors on transfer events,
> but transaction errors are possible on address device command
> completion events as well.
>
> The xHCI specification (section 4.6.5) says: A USB Transaction
> Error Completion Code for an Address Device Command may be due
> to a Stall response from a device. Software should issue a Disable
> Slot Command for the Device Slot then an Enable Slot Command to
> recover from this error.
>
> This patch handles USB transaction errors on address command
> completion events. The related discussion threads can be found
> through below links.
>
> http://marc.info/?l=linux-usb&m=149362010728921&w=2
> http://marc.info/?l=linux-usb&m=149252752825755&w=2
>
> Suggested-by: Mathias Nyman <mathias.nyman@...ux.intel.com>
> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
> ---
>   drivers/usb/host/xhci.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index d6b728d..95780f8 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
>   		break;
>   	case COMP_USB_TRANSACTION_ERROR:
>   		dev_warn(&udev->dev, "Device not responding to setup %s.\n", act);
> +
> +		ret = xhci_disable_slot(xhci, udev->slot_id);
> +		if (!ret)
> +			xhci_alloc_dev(hcd, udev);

Might be a xhci->mutex locking issue here,
both xhci_setup_device() and xhci_alloc_dev() take xhci->mutex

-Mathias
  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ