linux-kernel - Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMz4ku+hOiFGq7v6FbcN+NES9xZAm9TiXRQgE2gRxVKhVGrGkA@mail.gmail.com>
Date:   Thu, 1 Dec 2016 15:35:19 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     mathias.nyman@...el.com, Greg KH <gregkh@...uxfoundation.org>,
        USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command
 timer to watch stop endpoint command

On 1 December 2016 at 14:35, Lu Baolu <baolu.lu@...ux.intel.com> wrote:
> Hi,
>
> On 12/01/2016 02:04 PM, Baolin Wang wrote:
>> Hi Baolu,
>>
>> On 1 December 2016 at 13:45, Lu Baolu <baolu.lu@...ux.intel.com> wrote:
>>> Hi,
>>>
>>> On 11/30/2016 05:02 PM, Baolin Wang wrote:
>>>> If the hardware never responds to the stop endpoint command, the
>>>> URBs will never be completed, and we might hang the USB subsystem.
>>>> The original watchdog timer is used to watch if one stop endpoint
>>>> command is timeout, if timeout, then the watchdog timer will set
>>>> XHCI_STATE_DYING, try to halt the xHCI host, and give back all
>>>> pending URBs.
>>>>
>>>> But now we already have one command timer to control command timeout,
>>>> thus we can also use the command timer to watch the stop endpoint
>>>> command, instead of one duplicate watchdog timer which need to be
>>>> removed.
>>>>
>>>> Meanwhile we don't need the 'stop_cmds_pending' flag to identy if
>>>> this is the last stop endpoint command of one endpoint. Since we
>>>> can make sure we only set one stop endpoint command for one endpoint
>>>> by 'EP_HALT_PENDING' flag in xhci_urb_dequeue() function. Thus remove
>>>> this flag.
>>> I am afraid you can't do this. "stop_cmds_pending" was added
>>> to fix the problem described in the comments that you want to
>>> remove. But I didn't find any fix of this problem in your patch.
>> Now we can not pending another stop endpoint command for the same one
>> endpoint, since will check 'EP_HALT_PENDING' flag in
>> xhci_urb_dequeue() function to avoid this. But after some
>> investigation, I think I missed the stop endpoint command in
>> xhci_stop_device() which did not check the 'EP_HALT_PENDING' flag,
>> maybe need to add 'EP_HALT_PENDING' flag checking in
>> xhci_stop_device() function. DId I miss something else? Thanks.
>
> Consider below three threads running on different CPUs at the same time.
>
> Thread A: xhci_handle_cmd_stop_ep()  --- in interrupt handler
> Thread B: xhci_stop_endpoint_command_timeout() --- timer expired
> Thread C: xhci_urb_dequeue --- called by usb core
>
> They are serialized by xhci->lock. Let's consider below sequence:
>
> Thread A:
>     - delete xhci->cmd_timer), but will fail due to Thread B.
>     - clear EP_HALT_PENDING bit
>
> Thread B:
>     - halt the host controller
>
> Thread C:
>     - set EP_HALT_PENDING bit
>     - enqueue another stop endpoint command
>     - add the timer back

Ah, thanks for you comments.
If thread B halted the host, then the thread C xhci_urb_dequeue() will
check host state failed, then just return and can not set another stop
endpoint command. But from your example, I think your meaning is we
should not halt the host by thread B, since we have handled the stop
endpoint command event.

So I think we need to check the xhci command of this stop endpoint
command in xhci_stop_endpoint_command_timeout(), if the xhci command
of this stop endpoint command is not in the command list (which means
the stop endpoint command event has been handled), then just return
and do not halt the controller. Right?

-- 
Baolin.wang
Best Regards