[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110330210637.E9F6D3E1A05@tassilo.jf.intel.com>
Date: Wed, 30 Mar 2011 14:06:37 -0700 (PDT)
From: Andi Kleen <andi@...stfloor.org>
To: Paul.Zimmerman@...opsys.com, paulz@...opsys.com,
sarah.a.sharp@...ux.intel.com, gregkh@...e.de, ak@...ux.intel.com,
linux-kernel@...r.kernel.org, stable@...nel.org,
tim.bird@...sony.com
Subject: [PATCH] [156/275] xhci: Fix errors in the running total calculations in the TRB math
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Paul Zimmerman <Paul.Zimmerman@...opsys.com>
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 <paulz@...opsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
Signed-off-by: Andi Kleen <ak@...ux.intel.com>
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists