linux-kernel - Re: [PATCH v27 01/32] xhci: add helper to stop endpoint and wait for completion

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: <a9dcaa5a-4f5d-451a-93aa-7457798fc243@quicinc.com>
Date: Fri, 13 Sep 2024 15:14:00 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Michał Pecio <michal.pecio@...il.com>,
        <mathias.nyman@...ux.intel.com>
CC: <Thinh.Nguyen@...opsys.com>, <alsa-devel@...a-project.org>,
        <bgoswami@...cinc.com>, <broonie@...nel.org>, <conor+dt@...nel.org>,
        <corbet@....net>, <devicetree@...r.kernel.org>,
        <dmitry.torokhov@...il.com>, <gregkh@...uxfoundation.org>,
        <krzk+dt@...nel.org>, <lgirdwood@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-sound@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <mathias.nyman@...el.com>, <perex@...ex.cz>,
        <pierre-louis.bossart@...ux.intel.com>, <robh@...nel.org>,
        <srinivas.kandagatla@...aro.org>, <tiwai@...e.com>
Subject: Re: [PATCH v27 01/32] xhci: add helper to stop endpoint and wait for
 completion

Hi Michal,

On 9/13/2024 1:32 AM, Michał Pecio wrote:
> Hi,
>
>> Expose xhci_stop_endpoint_sync() which is a synchronous variant of
>> xhci_queue_stop_endpoint().  This is useful for client drivers that are
>> using the secondary interrupters, and need to stop/clean up the current
>> session.  The stop endpoint command handler will also take care of
>> cleaning up the ring.
> I'm not entirely sure what you meant by "cleaning up the ring" (maybe a
> comment would be in order?), but I see nothing being done here after the
> command completes and FYI xhci-ring.c will not run the default handler if
> the command is queued with a completion, like here.
>
> At least that's the case for certain command types and there is probably
> a story behind each of them. I know that xhci_stop_device() queues a
> Stop EP with completion (and also a few without(?)). Maybe it's a bug...

Maybe the last sentence is not needed.  When we are using the secondary interrupters, at least in the offload use case that I've verified with, the XHCI is completely unaware of what TDs have been queued, etc...  So technically, even if we did call the default handler (ie xhci_handle_cmd_stop_ep), most of the routines to invalidate TDs are going to be no-ops.

Thanks

Wesley Cheng