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
| ||
|
Message-ID: <2f12beb1-ff94-4806-8ed7-e78eb8474a7d@gmail.com> Date: Mon, 23 Oct 2023 18:23:37 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Douglas Anderson <dianders@...omium.org>, Jakub Kicinski <kuba@...nel.org>, Hayes Wang <hayeswang@...ltek.com>, "David S . Miller" <davem@...emloft.net> Cc: Edward Hill <ecgh@...omium.org>, Laura Nao <laura.nao@...labora.com>, Alan Stern <stern@...land.harvard.edu>, Simon Horman <horms@...nel.org>, linux-usb@...r.kernel.org, Grant Grundler <grundler@...omium.org>, Bjørn Mork <bjorn@...k.no>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH v5 1/8] r8152: Increase USB control msg timeout to 5000ms as per spec On 10/20/2023 2:06 PM, Douglas Anderson wrote: > According to the comment next to USB_CTRL_GET_TIMEOUT and > USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is > usually quite fast, the spec allows them to take up to 5 seconds. > Let's increase the timeout in the Realtek driver from 500ms to 5000ms > (using the #defines) to account for this. > > This is not just a theoretical change. The need for the longer timeout > was seen in testing. Specifically, if you drop a sc7180-trogdor based > Chromebook into the kdb debugger and then "go" again after sitting in > the debugger for a while, the next USB control message takes a long > time. Out of ~40 tests the slowest USB control message was 4.5 > seconds. > > While dropping into kdb is not exactly an end-user scenario, the above > is similar to what could happen due to an temporary interrupt storm, > what could happen if there was a host controller (HW or SW) issue, or > what could happen if the Realtek device got into a confused state and > needed time to recover. > > This change is fairly critical since the r8152 driver in Linux doesn't > expect register reads/writes (which are backed by USB control > messages) to fail. > > Fixes: ac718b69301c ("net/usb: new driver for RTL8152") > Suggested-by: Hayes Wang <hayeswang@...ltek.com> > Signed-off-by: Douglas Anderson <dianders@...omium.org> Reviewed-by: Florian Fainelli <florian.fainelli@...adcom.com> -- Florian
Powered by blists - more mailing lists