RE: [PATCH 0/2] update to autotools

2013-05-21 Thread Yann Droneaud
Hi, Le 21.05.2013 02:26, Weiny, Ira a écrit : [PATCH 0/2] update to autotools How are these different (if at all) from the patches submitted by Jeff previously? Patches from Jeff are already applied on libibverbs. My patches apply on top to improve a bit the way autotools are used for

Re: MLX4 Cq Question

2013-05-21 Thread Or Gerlitz
On 20/05/2013 17:53, Jack Morgenstein wrote: === net/mlx4_core: Fix racy flow in the driver CQ completion handler The mlx4 CQ completion handler, mlx4_cq_completion, doesn't bother to lock the radix tree which is used to manage the table of CQs,

Re: MLX4 Cq Question

2013-05-21 Thread Bart Van Assche
On 05/21/13 11:40, Or Gerlitz wrote: 2. is possible in the Linux kernel for one hard irq callback to flash on CPU X while another hard irq callback is running on the same CPU? I think that from kernel 2.6.35 on MSI IRQs are no longer nested. See also

Re: MLX4 Cq Question

2013-05-21 Thread Or Gerlitz
On 21/05/2013 13:42, Bart Van Assche wrote: On 05/21/13 11:40, Or Gerlitz wrote: 2. is possible in the Linux kernel for one hard irq callback to flash on CPU X while another hard irq callback is running on the same CPU? I think that from kernel 2.6.35 on MSI IRQs are no longer nested. See

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

2013-05-21 Thread Sebastian Riemer
On 17.05.2013 16:16, Jack Wang wrote: unable to handle kernel paging request Hi Jack, this should be related to the list corruption in IPoIB as list_del() sets the LIST_POISON1 and LIST_POISON2 pointers. Referencing these results in page faults according to the documentation in the code.

Re: MLX4 Cq Question

2013-05-21 Thread Jack Morgenstein
On Tuesday 21 May 2013 13:43, Or Gerlitz wrote: On 21/05/2013 13:42, Bart Van Assche wrote: On 05/21/13 11:40, Or Gerlitz wrote: 2. is possible in the Linux kernel for one hard irq callback to flash on CPU X while another hard irq callback is running on the same CPU? I think that from

better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

2013-05-21 Thread Or Gerlitz
Hi Sean, We have a user space application which is made of M (clients) x N (servers) RC connectivity pattern using librdmacm. Basically, there are N nodes, each running M client process and each client connects to all N servers. So under some unknown conditions, many of the clients

Re: MLX4 Cq Question

2013-05-21 Thread Or Gerlitz
On 21/05/2013 17:13, Jack Morgenstein wrote: I just need to verify that the patch can be applied correctly on the upstream kernel. The use of RCU (and not spinlock) makes sense from a performance standpoint in any case. We do NOT want to force mlx4_cq_completion to have a spinlock which is

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

2013-05-21 Thread Jack Wang
On 05/21/2013 02:51 PM, Sebastian Riemer wrote: On 17.05.2013 16:16, Jack Wang wrote: unable to handle kernel paging request Hi Jack, this should be related to the list corruption in IPoIB as list_del() sets the LIST_POISON1 and LIST_POISON2 pointers. Referencing these results in page

RE: better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

2013-05-21 Thread Hefty, Sean
So under some unknown conditions, many of the clients connection attempts fail with RDMA_CM_EVENT_UNREACHABLE event and the status is -ETIMEDOUT. Looking on the rdma-cm kernel code, I see that the only location which generates this event is in cma_ib_handler when getting IB_CM_REQ_ERROR (or

Re: better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

2013-05-21 Thread Or Gerlitz
On 21/05/2013 18:24, Hefty, Sean wrote: I don't remember this patch at all. Alex, can you please send Sean this patch -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

2013-05-21 Thread Or Gerlitz
On Tue, May 21, 2013 at 6:24 PM, Hefty, Sean sean.he...@intel.com wrote: One thing seen in the nodes dmesg is a message from an old patch of yours which exists in ofed1.5.3 but didn't hit (or wasn't accepted?) upstream saying ib_cm: calculated mra timeout 67584 8192, decreasing used

RE: better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

2013-05-21 Thread Hefty, Sean
One thing seen in the nodes dmesg is a message from an old patch of yours which exists in ofed1.5.3 but didn't hit (or wasn't accepted?) upstream saying ib_cm: calculated mra timeout 67584 8192, decreasing used timeout_ms does this provides any insight into the problem? I don't

Re: [PATCH 0/4] add RAW Packet QP type

2013-05-21 Thread Or Gerlitz
On Tue, May 21, 2013 at 1:43 AM, Shawn Bohrer shawn.boh...@gmail.com wrote: I appologize if I missed it, but did any support for L3/L4 CSUM generation get added? Doesn't look like the upstream libibverbs has it, and I don't seem to see any patches floating around. Roland commented that he

[PATCHv3 infiniband-diags] saquery: Add SwitchInfoRecord support

2013-05-21 Thread Hal Rosenstock
This patch is the combination of the 2 patches supplied by Husam Kahalah [v2] infiniband-diags/saquery.c: switchinfo support added switchinfo support added manual In addition, this version changes the field names to match those in Vol1 v1.2.1 and Errata. Signed-off-by: Husam

Re: [PATCH for-next 0/9] Add receive Flow Steering support

2013-05-21 Thread Or Gerlitz
On Tue, May 21, 2013 at 1:54 AM, Shawn Bohrer shawn.boh...@gmail.com wrote: Are there any patches for libibverbs to add ibv_create_flow/ibv_destroy_flow? And are there any needed patches for libmlx4? I'm building up a stack so we can begin testing this series. YES there are patches NO I

Re: [PATCH 3/3] read_config: skip file/directory with unsecure permissions

2013-05-21 Thread Jason Gunthorpe
On Mon, May 20, 2013 at 11:43:05PM +0200, Yann Droneaud wrote: libibverbs must refuse to load arbitrary shared objects. This patch check the configuration directory and files for - being owned by root; - not being writable by others. I really don't like this. Is there some exploit against