Messages in this thread | | | Subject | Re: [PATCH] xhci: use iopoll for xhci_handshake | From | Mathias Nyman <> | Date | Thu, 28 Feb 2019 10:55:44 +0200 |
| |
On 28.2.2019 9.09, Greg Kroah-Hartman wrote: > On Wed, Feb 27, 2019 at 03:19:17PM -0700, Daniel Kurtz wrote: >> In cases such as xhci_abort_cmd_ring(), xhci_handshake() is called with >> a spin lock held (and local interrupts disabled) with a huge 5 second >> timeout. This can translates to 5 million calls to udelay(1). By its >> very nature, udelay() is not meant to be precise, it only guarantees to >> delay a minimum of 1 microsecond. Therefore the actual delay of >> xhci_handshake() can be significantly longer. If the average udelay(1) >> is greater than 2.2 us, the total time in xhci_handshake() - with >> interrupts disabled can be > 11 seconds triggering the kernel's soft lockup >> detector. >> >> To avoid this, let's replace the open coded io polling loop with one from >> iopoll.h that uses a loop timed with the more presumably reliable ktime >> infrastructure. >> >> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> > > Looks sane to me, nice fixup. > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Is this causing problems on older kernels/devices today such that we > should backport this? >
A very similar patch was submitted some weeks ago by Andrey Smirnov.
https://lore.kernel.org/lkml/20190208014816.21869-1-andrew.smirnov@gmail.com/
His commit message only mentions that readl_poll_timeout_atomic() does the same job, not about any issues with the loop, so I was going to send it forward to usb-next after 5.1-rc (to 5.2).
-Mathias
| |