On Fri, Aug 31, 2012 at 1:35 AM, Roland Dreier rol...@kernel.org wrote:
On Thu, Aug 30, 2012 at 3:17 PM, Or Gerlitz or.gerl...@gmail.com wrote:
1. on the time CQ A is deleted an interrupt that relates to CQ B
takes place and a radix
tree lookup is running while an element is being deleted
Roland Dreier rol...@kernel.org wrote:
Can you be explicit about the race you're worried about?
Roland,
This patch was made after we got the below report from the field.
Dotan, can we get Roland access to the full vmcore image?
Here's the report I got:
[...] box panic'ed when trying to
On Fri, Aug 31, 2012 at 1:35 AM, Roland Dreier rol...@kernel.org wrote:
I don't think this is a real problem; the radix tree code is [...]
So maybe this patch wouldn't land in 3.7, we'll see, however, so far
no other patch sits in the for-next branch of your tree for the next
window... any plan
Removed duplicate definition for SGE_PF_KDOORBELL, SGE_INT_ENABLE3,
PCIE_MEM_ACCESS_OFFSET registers.
Moved the register field definitions around the register definition.
Signed-off-by: Santosh Rastapur sant...@chelsio.com
Signed-off-by: Vipul Pandya vi...@chelsio.com
Reviewed-by: Sivakumar
From: Dongsu Park dongsu.p...@profitbricks.com
Unter circumstances, srp_rport_add() can make conflicts with
srp_rport_delete(), dumping the call trace written below.
That does not always occur. But its possible reason is adding
sysfs entries for the SRP target too fast, even before the
deletion
From: Dongsu Park dongsu.p...@profitbricks.com
After removing rport_delete(), rport-lld_data has to be set to NULL.
In addition to that, both srp_rport_delete() and
rport_dev_loss_timedout() must check if rport-lld_data is NULL,
before accessing to rport-lld_data or any rport's target area.
From: Dongsu Park dongsu.p...@profitbricks.com
Signed-off-By: Sebastian Riemer sebastian.rie...@profitbricks.com
---
drivers/infiniband/ulp/srp/ib_srp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index
