linux-kernel - Re: [PATCH v3 5/5] usb: xhci: Handle USB transaction error on address command

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5997F5FD.1080502@linux.intel.com>
Date:   Sat, 19 Aug 2017 16:25:33 +0800
From:   Lu Baolu <baolu.lu@...ux.intel.com>
To:     Mathias Nyman <mathias.nyman@...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

Hi,

On 08/18/2017 09:31 PM, Mathias Nyman wrote:
> On 16.08.2017 05:15, Lu Baolu wrote:
>> Hi,
>>
>> On 08/15/2017 07:30 PM, Mathias Nyman wrote:
>>> 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
>>>
>>
>> I will apply xhci->mutex in this patch for code consistency, but I think
>> we can drop xhci->mutex (in a separated patch) anyway.
>>
>> xhci->mutex was introduced to protect two race sources of xhci->slot_id
>> and xhci->addr_dev by below commit:
>>
>> commit a00918d0521df1c7a2ec9143142a3ea998c8526d
>>      usb: host: xhci: add mutex for non-thread-safe data
>>
>>
>> c2d3d49 usb: xhci: move slot_id from xhci_hcd to xhci_command structure
>> 87e44f2 usb: xhci: remove the use of xhci->addr_dev
>>
>> So we don't need xhci->mutex any more. I will try to do this in a separated
>> patch with more tests. For now, I will add xhci->mutex for code consistency.
>
> Fixing xhci->mutex sounds like a good idea, and you are right, it's no longer
> needed for slot_id or addr_dev.
> But it's use was extended to protect xhci_stop() and xhci_setup_device()
> from racing at fast xhci host hotplug/removes in this patch.
>
> commit 85ac90f8953a58f6a057b727bc9db97721e3fb8e
> Author: Roger Quadros <rogerq@...com>
> Date:   Mon Sep 21 17:46:12 2015 +0300
>
>     usb: xhci: lock mutex on xhci_stop
>  
>     Else it races with xhci_setup_device
>
> But I think it's safe to remove xhci->mutex  from xhci_alloc_dev()
>
> There's no huurry with the patch 5/5 so would be nice to get that mutex
> cleaned up before.

Okay.

Best regards,
Lu Baolu