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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240915095514.6b01fefb@foxbook>
Date: Sun, 15 Sep 2024 09:55:14 +0200
From: Michał Pecio <michal.pecio@...il.com>
To: Wesley Cheng <quic_wcheng@...cinc.com>
Cc: <mathias.nyman@...ux.intel.com>, <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,

> 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.

Yes, the cancellation machinery will return immediately if there are
no TDs queued by xhci_hcd itself.

But xhci_handle_cmd_stop_ep() does a few more things for you - it
checks if the command has actually succeeded, clears any halt condition
which may be preventing stopping the endpoint, and it sometimes retries
the command (only on "bad" chips, AFAIK).

This new code does none of the above, so in the general case it can't
even guarantee that the endpoint is stopped when it returns zero. This
should ideally be documented in some way, or fixed, before somebody is
tempted to call it with unrealistically high expectations ;)

As far as I see, it only works for you because isochronous never halts
and Qualcomm HW is (hopefully) free of those stop-after-restart bugs.
There will be problems if the SB tries to use any other endpoint type.

Regards,
Michal