linux-toradex.git/drivers/infiniband, branch v2.6.25.10

IB/mthca: Clear ICM pages before handing to FW

2008-07-03T03:46:15+00:00

commit 87afd448b186c885d67a08b7417cd46253b6a9d6 upstream

Current memfree FW has a bug which in some cases, assumes that ICM
pages passed to it are cleared.  This patch uses __GFP_ZERO to
allocate all ICM pages passed to the FW.  Once firmware with a fix is
released, we can make the workaround conditional on firmware version.

This fixes the bug reported by Arthur Kepner  here:
http://lists.openfabrics.org/pipermail/general/2008-May/050026.html

[ Rewritten to be a one-liner using __GFP_ZERO instead of vmap()ing
  ICM memory and memset()ing it to 0. - Roland ]

Signed-off-by: Eli Cohen 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

IB/umem: Avoid sign problems when demoting npages to integer

2008-06-16T20:20:03+00:00

commit 8079ffa0e18baaf2940e52e0c118eef420a473a4 upstream

On a 64-bit architecture, if ib_umem_get() is called with a size value
that is so big that npages is negative when cast to int, then the
length of the page list passed to get_user_pages(), namely

	min_t(int, npages, PAGE_SIZE / sizeof (struct page *))

will be negative, and get_user_pages() will immediately return 0 (at
least since 900cf086, "Be more robust about bad arguments in
get_user_pages()").  This leads to an infinite loop in ib_umem_get(),
since the code boils down to:

	while (npages) {
		ret = get_user_pages(...);
		npages -= ret;
	}

Fix this by taking the minimum as unsigned longs, so that the value of
npages is never truncated.

The impact of this bug isn't too severe, since the value of npages is
checked against RLIMIT_MEMLOCK, so a process would need to have an
astronomical limit or have CAP_IPC_LOCK to be able to trigger this,
and such a process could already cause lots of mischief.  But it does
let buggy userspace code cause a kernel lock-up; for example I hit
this with code that passes a negative value into a memory registartion
function where it is promoted to a huge u64 value.

Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

IPoIB: Test for NULL broadcast object in ipiob_mcast_join_finish()

2008-06-09T18:27:02+00:00

upstream commit: e1d50dce5af77cb6d33555af70e2b8748dd84009

We saw a kernel oops in our regression testing when a multicast "join
finish" occurred just after the interface was -- this is
.  The test
randomly causes the HCA physical port to go down then up.

The cause of this is that ipoib_mcast_join_finish() processing happen
just after ipoib_mcast_dev_flush() was invoked (in which case the
broadcast pointer is NULL).  This patch tests for and handles the case
where priv->broadcast is NULL.

Cc: 
Signed-off-by: Jack Morgenstein 
Signed-off-by: Roland Dreier 
Signed-off-by: Chris Wright

RDMA/nes: Fix adapter reset after PXE boot

2008-05-01T21:44:38+00:00

commit: bc5698f3ecc9587e1edb343a2878f8d228c49e0e upstream

After PXE boot, the iw_nes driver does a full reset to ensure the card
is in a clean state.  However, it doesn't wait for firmware to
complete its work before issuing a port reset to enable the ports,
which leads to problems bringing up the ports.

The solution is to wait for firmware to complete its work before
proceeding with port reset.

This bug was flagged by Roland Dreier .

Signed-off-by: Chien Tung 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

RDMA/nes: Free IRQ before killing tasklet

2008-05-01T21:44:34+00:00

commit: 4cd1e5eb3cbe6e0cc934959770b4c60eac6ecf66

Move the free_irq() call in nes_remove() to before the tasklet_kill();
otherwise there is a window after tasklet_kill() where a new interrupt
can be handled and reschedule the tasklet, leading to a use-after-free
crash.

Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

trivial endianness annotations: infiniband core

2008-03-30T21:20:24+00:00

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

RDMA/cxgb3: Program hardware IRD with correct value

2008-03-28T17:45:32+00:00

Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth).  In particular this means that if an application passes in IRD
> 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.

Fix this by using "ep->ird" instead of "ep->ord" in the intended place.

Signed-off-by: Roland Dreier 
Acked-by: Steve Wise 
Signed-off-by: Linus Torvalds

RDMA/nes: Fix MSS calculation on RDMA path

2008-03-21T20:59:28+00:00

Fix the calculation of the MSS for RDMA connections: we need to
allow space in frames for a VLAN tag too.

Signed-off-by: Chien Tung 
Signed-off-by: Glenn Streiff 
Signed-off-by: Roland Dreier

IPoIB: Allocate priv->tx_ring with vmalloc()

2008-03-12T14:51:03+00:00

Commit 7143740d ("IPoIB: Add send gather support") made struct
ipoib_tx_buf significantly larger, since the mapping member changed
from a single u64 to an array with MAX_SKB_FRAGS + 1 entries.  This
means that allocating tx_rings with kzalloc() may fail because there
is not enough contiguous memory for the new, much bigger size.  Fix
this regression by allocating the rings with vmalloc() instead.

Signed-off-by: Roland Dreier

IPoIB/cm: Set tx_wr.num_sge in connected mode post_send()

2008-03-12T01:35:20+00:00

Commit 7143740d ("IPoIB: Add send gather support") made it possible
for tx_wr.num_sge to be != 1 -- this happens if send gather support is
enabled.  However, the code in the connected mode post_send() function
assumes the old invariant, namely that tx_wr.num_sge is always 1.  Fix
this by explicitly setting tx_wr.num_sge to 1 in the CM post_send().

Signed-off-by: Roland Dreier