mirror of
https://github.com/torvalds/linux.git
synced 2024-12-30 14:52:05 +00:00
85ecd0322b
[Description written by Alan Stern] Soeren tracked down a very difficult bug in ehci-hcd's DMA pool management of iTD and siTD structures. Some background: ehci-hcd gives each isochronous endpoint its own set of active and free itd's (or sitd's for full-speed devices). When a new itd is needed, it is taken from the head of the free list, if possible. However, itd's must not be used twice in a single frame because the hardware continues to access the data structure for the entire duration of a frame. Therefore if the itd at the head of the free list has its "frame" member equal to the current value of ehci->now_frame, it cannot be reused and instead a new itd is allocated from the DMA pool. The entries on the free list are not released back to the pool until the endpoint is no longer in use. The bug arises from the fact that sometimes an itd can be moved back onto the free list before itd->frame has been set properly. In Soeren's case, this happened because ehci-hcd can allocate one more itd than it actually needs for an URB; the extra itd may or may not be required depending on how the transfer aligns with a frame boundary. For example, an URB with 8 isochronous packets will cause two itd's to be allocated. If the URB is scheduled to start in microframe 3 of frame N then it will require both itds: one for microframes 3 - 7 of frame N and one for microframes 0 - 2 of frame N+1. But if the URB had been scheduled to start in microframe 0 then it would require only the first itd, which could cover microframes 0 - 7 of frame N. The second itd would be returned to the end of the free list. The itd allocation routine initializes the entire structure to 0, so the extra itd ends up on the free list with itd->frame set to 0 instead of a meaningful value. After a while the itd reaches the head of the list, and occasionally this happens when ehci->now_frame is equal to 0. Then, even though it would be okay to reuse this itd, the driver thinks it must get another itd from the DMA pool. For as long as the isochronous endpoint remains in use, this flaw in the mechanism causes more and more itd's to be taken slowly from the DMA pool. Since none are released back, the pool eventually becomes exhausted. This reuslts in memory allocation failures, which typically show up during a long-running audio stream. Video might suffer the same effect. The fix is very simple. To prevent allocations from the pool when they aren't needed, make sure that itd's sent back to the free list prematurely have itd->frame set to an invalid value which can never be equal to ehci->now_frame. This should be applied to -stable kernels going back to 3.6. Signed-off-by: Soeren Moch <smoch@web.de> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
|---|---|---|
| .. | ||
| whci | ||
| bcma-hcd.c | ||
| ehci-atmel.c | ||
| ehci-dbg.c | ||
| ehci-fsl.c | ||
| ehci-fsl.h | ||
| ehci-grlib.c | ||
| ehci-hcd.c | ||
| ehci-hub.c | ||
| ehci-mem.c | ||
| ehci-msm.c | ||
| ehci-mv.c | ||
| ehci-mxc.c | ||
| ehci-octeon.c | ||
| ehci-omap.c | ||
| ehci-orion.c | ||
| ehci-pci.c | ||
| ehci-platform.c | ||
| ehci-pmcmsp.c | ||
| ehci-ppc-of.c | ||
| ehci-ps3.c | ||
| ehci-q.c | ||
| ehci-s5p.c | ||
| ehci-sched.c | ||
| ehci-sead3.c | ||
| ehci-sh.c | ||
| ehci-spear.c | ||
| ehci-sysfs.c | ||
| ehci-tegra.c | ||
| ehci-tilegx.c | ||
| ehci-timer.c | ||
| ehci-vt8500.c | ||
| ehci-w90x900.c | ||
| ehci-xilinx-of.c | ||
| ehci.h | ||
| fhci-dbg.c | ||
| fhci-hcd.c | ||
| fhci-hub.c | ||
| fhci-mem.c | ||
| fhci-q.c | ||
| fhci-sched.c | ||
| fhci-tds.c | ||
| fhci.h | ||
| fsl-mph-dr-of.c | ||
| hwa-hc.c | ||
| imx21-dbg.c | ||
| imx21-hcd.c | ||
| imx21-hcd.h | ||
| isp116x-hcd.c | ||
| isp116x.h | ||
| isp1362-hcd.c | ||
| isp1362.h | ||
| isp1760-hcd.c | ||
| isp1760-hcd.h | ||
| isp1760-if.c | ||
| Kconfig | ||
| Makefile | ||
| octeon2-common.c | ||
| ohci-at91.c | ||
| ohci-da8xx.c | ||
| ohci-dbg.c | ||
| ohci-ep93xx.c | ||
| ohci-exynos.c | ||
| ohci-hcd.c | ||
| ohci-hub.c | ||
| ohci-jz4740.c | ||
| ohci-mem.c | ||
| ohci-nxp.c | ||
| ohci-octeon.c | ||
| ohci-omap3.c | ||
| ohci-omap.c | ||
| ohci-pci.c | ||
| ohci-platform.c | ||
| ohci-ppc-of.c | ||
| ohci-ps3.c | ||
| ohci-pxa27x.c | ||
| ohci-q.c | ||
| ohci-s3c2410.c | ||
| ohci-sa1111.c | ||
| ohci-sm501.c | ||
| ohci-spear.c | ||
| ohci-tilegx.c | ||
| ohci-tmio.c | ||
| ohci.h | ||
| oxu210hp-hcd.c | ||
| oxu210hp.h | ||
| pci-quirks.c | ||
| pci-quirks.h | ||
| r8a66597-hcd.c | ||
| r8a66597.h | ||
| sl811_cs.c | ||
| sl811-hcd.c | ||
| sl811.h | ||
| ssb-hcd.c | ||
| u132-hcd.c | ||
| uhci-debug.c | ||
| uhci-grlib.c | ||
| uhci-hcd.c | ||
| uhci-hcd.h | ||
| uhci-hub.c | ||
| uhci-pci.c | ||
| uhci-platform.c | ||
| uhci-q.c | ||
| xhci-dbg.c | ||
| xhci-ext-caps.h | ||
| xhci-hub.c | ||
| xhci-mem.c | ||
| xhci-pci.c | ||
| xhci-plat.c | ||
| xhci-ring.c | ||
| xhci.c | ||
| xhci.h | ||