[patch 15/50] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

2007-01-05 Thread Chris Wright
-stable review patch.  If anyone has any objections, please let us know.
--

From: Roland Dreier <[EMAIL PROTECTED]>

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures.  Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain <[EMAIL PROTECTED]> and David McMillen
<[EMAIL PROTECTED]> for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
I just asked Linus to pull this.  It fixes nasty corruption/crash
problems on 32-bit systems with > 4G of memory.

 drivers/infiniband/ulp/srp/ib_srp.c |2 +-
 drivers/infiniband/ulp/srp/ib_srp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.19.1.orig/drivers/infiniband/ulp/srp/ib_srp.c
+++ linux-2.6.19.1/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1879,7 +1879,7 @@ static void srp_add_one(struct ib_device
 */
srp_dev->fmr_page_shift = max(9, ffs(dev_attr->page_size_cap) - 1);
srp_dev->fmr_page_size  = 1 << srp_dev->fmr_page_shift;
-   srp_dev->fmr_page_mask  = ~((unsigned long) srp_dev->fmr_page_size - 1);
+   srp_dev->fmr_page_mask  = ~((u64) srp_dev->fmr_page_size - 1);
 
INIT_LIST_HEAD(_dev->dev_list);
 
--- linux-2.6.19.1.orig/drivers/infiniband/ulp/srp/ib_srp.h
+++ linux-2.6.19.1/drivers/infiniband/ulp/srp/ib_srp.h
@@ -87,7 +87,7 @@ struct srp_device {
struct ib_fmr_pool *fmr_pool;
int fmr_page_shift;
int fmr_page_size;
-   unsigned long   fmr_page_mask;
+   u64 fmr_page_mask;
 };
 
 struct srp_host {

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 15/50] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

2007-01-05 Thread Chris Wright
-stable review patch.  If anyone has any objections, please let us know.
--

From: Roland Dreier [EMAIL PROTECTED]

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures.  Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain [EMAIL PROTECTED] and David McMillen
[EMAIL PROTECTED] for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
I just asked Linus to pull this.  It fixes nasty corruption/crash
problems on 32-bit systems with  4G of memory.

 drivers/infiniband/ulp/srp/ib_srp.c |2 +-
 drivers/infiniband/ulp/srp/ib_srp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.19.1.orig/drivers/infiniband/ulp/srp/ib_srp.c
+++ linux-2.6.19.1/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1879,7 +1879,7 @@ static void srp_add_one(struct ib_device
 */
srp_dev-fmr_page_shift = max(9, ffs(dev_attr-page_size_cap) - 1);
srp_dev-fmr_page_size  = 1  srp_dev-fmr_page_shift;
-   srp_dev-fmr_page_mask  = ~((unsigned long) srp_dev-fmr_page_size - 1);
+   srp_dev-fmr_page_mask  = ~((u64) srp_dev-fmr_page_size - 1);
 
INIT_LIST_HEAD(srp_dev-dev_list);
 
--- linux-2.6.19.1.orig/drivers/infiniband/ulp/srp/ib_srp.h
+++ linux-2.6.19.1/drivers/infiniband/ulp/srp/ib_srp.h
@@ -87,7 +87,7 @@ struct srp_device {
struct ib_fmr_pool *fmr_pool;
int fmr_page_shift;
int fmr_page_size;
-   unsigned long   fmr_page_mask;
+   u64 fmr_page_mask;
 };
 
 struct srp_host {

--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/