2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------ From: Paul Zimmerman <[email protected]> commit 5807795bd4dececdf553719cc02869e633395787 upstream. Calculations like running_total = TRB_MAX_BUFF_SIZE - (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1)); if (running_total != 0) num_trbs++; are incorrect, because running_total can never be zero, so the if() expression will never be true. I think the intention was that running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1 to TRB_MAX_BUFF_SIZE. So adding a running_total &= TRB_MAX_BUFF_SIZE - 1; fixes the problem. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman <[email protected]> Signed-off-by: Sarah Sharp <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Andi Kleen <[email protected]> --- drivers/usb/host/xhci-ring.c | 2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6.35.y/drivers/usb/host/xhci-ring.c =================================================================== --- linux-2.6.35.y.orig/drivers/usb/host/xhci-ring.c 2011-03-29 23:03:01.485262166 -0700 +++ linux-2.6.35.y/drivers/usb/host/xhci-ring.c 2011-03-29 23:54:34.277125360 -0700 @@ -1891,6 +1891,7 @@ /* Scatter gather list entries may cross 64KB boundaries */ running_total = TRB_MAX_BUFF_SIZE - (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1)); + running_total &= TRB_MAX_BUFF_SIZE - 1; if (running_total != 0) num_trbs++; @@ -2171,6 +2172,7 @@ /* How much data is (potentially) left before the 64KB boundary? */ running_total = TRB_MAX_BUFF_SIZE - (urb->transfer_dma & (TRB_MAX_BUFF_SIZE - 1)); + running_total &= TRB_MAX_BUFF_SIZE - 1; /* If there's some data on this 64KB chunk, or we have to send a * zero-length transfer, we need at least one TRB _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
