Re: [PATCH] IB/core: Allocating larger memory than required for cma_configfs

[Bart Van Assche]

On 12/30/2015 03:14 PM, Matan Barak wrote:

We were allocating larger memory space than requried for
cma_dev_group->default_ports_group.


Please change the subject into something like "Do not allocate more 
...". Please also fix the spelling error in the patch description.


Thanks,

Bart.
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

[ira.weiny]

On Wed, Dec 30, 2015 at 03:01:33AM -0800, Christoph Hellwig wrote:
> Hi Ira,
> 
> please take a look at the patches I've attached - they are just WIP
> that hasn't been tested as I'm on a vacation without access to my
> IB setup until New Year's Eve.

I have them on a branch.

I'll try and do some testing over the weekend.

Ira

> 
> Patch 1 is I think a genuine bug fix caused by the madness (pun
> intendended) of the wr_id abuses.
> 
> Patch 2: passes the mad_send_buf explicitily to mad handlers to get rid
> of that mess.
> 
> Patch 3 is the CQ API conversion which becomes relatively simple once
> the prior issues above are sorted out.
> 

> From a22609131ca353278015b6b4aec3077db06ad9f5 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig 
> Date: Wed, 30 Dec 2015 11:49:22 +0100
> Subject: IB/mad: pass send buf in wr_id in local_completions
> 
> The sa_query recv_handler expects the send_buf in wr_id, and all other recv
> handlers ignore wr_id.  It seems this is what we should pass, please confirm.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/infiniband/core/mad.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> index d4d2a61..e0859e5 100644
> --- a/drivers/infiniband/core/mad.c
> +++ b/drivers/infiniband/core/mad.c
> @@ -2734,7 +2734,7 @@ static void local_completions(struct work_struct *work)
>* before request
>*/
>   build_smp_wc(recv_mad_agent->agent.qp,
> -  (unsigned long) local->mad_send_wr,
> +  (unsigned long) 
> >mad_send_wr->send_buf,
>be16_to_cpu(IB_LID_PERMISSIVE),
>local->mad_send_wr->send_wr.pkey_index,
>recv_mad_agent->agent.port_num, );
> -- 
> 1.9.1
> 

> From c6101bfa6543d0b35c2ca2fa0add09341f456e88 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig 
> Date: Wed, 30 Dec 2015 11:54:02 +0100
> Subject: IB/mad: pass ib_mad_send_buf explicitly to the recv_handler
> 
> Stop abusing wr_id and just pass the parameter explicitly.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/infiniband/core/cm.c  |  1 +
>  drivers/infiniband/core/mad.c | 18 ++
>  drivers/infiniband/core/sa_query.c|  7 ++-
>  drivers/infiniband/core/user_mad.c|  1 +
>  drivers/infiniband/ulp/srpt/ib_srpt.c |  1 +
>  include/rdma/ib_mad.h |  2 ++
>  6 files changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
> index e3a95d1..ad3726d 100644
> --- a/drivers/infiniband/core/cm.c
> +++ b/drivers/infiniband/core/cm.c
> @@ -3503,6 +3503,7 @@ int ib_cm_notify(struct ib_cm_id *cm_id, enum 
> ib_event_type event)
>  EXPORT_SYMBOL(ib_cm_notify);
>  
>  static void cm_recv_handler(struct ib_mad_agent *mad_agent,
> + struct ib_mad_send_buf *send_buf,
>   struct ib_mad_recv_wc *mad_recv_wc)
>  {
>   struct cm_port *port = mad_agent->context;
> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> index e0859e5..f15fcd6 100644
> --- a/drivers/infiniband/core/mad.c
> +++ b/drivers/infiniband/core/mad.c
> @@ -693,7 +693,7 @@ static void snoop_recv(struct ib_mad_qp_info *qp_info,
>  
>   atomic_inc(_snoop_priv->refcount);
>   spin_unlock_irqrestore(_info->snoop_lock, flags);
> - mad_snoop_priv->agent.recv_handler(_snoop_priv->agent,
> + mad_snoop_priv->agent.recv_handler(_snoop_priv->agent, NULL,
>  mad_recv_wc);
>   deref_snoop_agent(mad_snoop_priv);
>   spin_lock_irqsave(_info->snoop_lock, flags);
> @@ -1994,9 +1994,9 @@ static void ib_mad_complete_recv(struct 
> ib_mad_agent_private *mad_agent_priv,
>   /* user rmpp is in effect
>* and this is an active RMPP MAD
>*/
> - mad_recv_wc->wc->wr_id = 0;
> - 
> mad_agent_priv->agent.recv_handler(_agent_priv->agent,
> -mad_recv_wc);
> + mad_agent_priv->agent.recv_handler(
> + _agent_priv->agent, NULL,
> + mad_recv_wc);
>   atomic_dec(_agent_priv->refcount);
>   } else {
>   /* not user rmpp, revert to normal behavior and
> @@ -2010,9 +2010,10 @@ static void ib_mad_complete_recv(struct 
> ib_mad_agent_private *mad_agent_priv,
>   spin_unlock_irqrestore(_agent_priv->lock, 

Re: [PATCH for-next 3/7] IB/mlx4: Configure device to work in RoCEv2

[Matan Barak]

On 12/29/2015 4:37 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

From: Moni Shoua 

Some mlx4 adapters are RoCEv2 capable. To enable this feature some
hardware configuration is required. This is

1. Set port general parameters
2. Configure the outgoing UDP destination port
3. Configure the QP that work with RoCEv2

Signed-off-by: Moni Shoua 
---
  drivers/infiniband/hw/mlx4/main.c | 19 ++---
  drivers/infiniband/hw/mlx4/qp.c   | 35
---
  drivers/net/ethernet/mellanox/mlx4/fw.c   | 16 +-
  drivers/net/ethernet/mellanox/mlx4/mlx4.h |  7 +--
  drivers/net/ethernet/mellanox/mlx4/port.c |  8 +++
  drivers/net/ethernet/mellanox/mlx4/qp.c   | 28
+
  include/linux/mlx4/device.h   |  1 +
  include/linux/mlx4/qp.h   | 15 +++--
  include/rdma/ib_verbs.h   |  2 ++
  9 files changed, 120 insertions(+), 11 deletions(-)


Better put (please do...) functionality which is plain mlx4 corish (such
as new/modified FW commands, new SW/FW fields of structs and such) into
mlx4_core patch.



diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 988fa33..44e5699 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -384,6 +384,7 @@ int mlx4_ib_gid_index_to_real_index(struct
mlx4_ib_dev *ibdev,
  int i;
  int ret;
  unsigned long flags;
+struct ib_gid_attr attr;
  if (port_num > MLX4_MAX_PORTS)
  return -EINVAL;
@@ -394,10 +395,13 @@ int mlx4_ib_gid_index_to_real_index(struct
mlx4_ib_dev *ibdev,
  if (!rdma_cap_roce_gid_table(>ib_dev, port_num))
  return index;
-ret = ib_get_cached_gid(>ib_dev, port_num, index, ,
NULL);
+ret = ib_get_cached_gid(>ib_dev, port_num, index, ,
);
  if (ret)
  return ret;
+if (attr.ndev)
+dev_put(attr.ndev);
+
  if (!memcmp(, , sizeof(gid)))
  return -EINVAL;
@@ -405,7 +409,8 @@ int mlx4_ib_gid_index_to_real_index(struct
mlx4_ib_dev *ibdev,
  port_gid_table = >gids[port_num - 1];
  for (i = 0; i < MLX4_MAX_PORT_GIDS; ++i)
-if (!memcmp(_gid_table->gids[i].gid, , sizeof(gid))) {
+if (!memcmp(_gid_table->gids[i].gid, , sizeof(gid)) &&
+attr.gid_type == port_gid_table->gids[i].gid_type) {
  ctx = port_gid_table->gids[i].ctx;
  break;
  }
@@ -2481,7 +2486,8 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
  if (mlx4_ib_init_sriov(ibdev))
  goto err_mad;
-if (dev->caps.flags & MLX4_DEV_CAP_FLAG_IBOE) {
+if (dev->caps.flags & MLX4_DEV_CAP_FLAG_IBOE ||
+dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_ROCE_V1_V2) {
  if (!iboe->nb.notifier_call) {
  iboe->nb.notifier_call = mlx4_ib_netdev_event;
  err = register_netdevice_notifier(>nb);
@@ -2490,6 +2496,13 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
  goto err_notif;
  }
  }
+if (!mlx4_is_slave(dev) &&
+dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_ROCE_V1_V2) {
+err = mlx4_config_roce_v2_port(dev, ROCE_V2_UDP_DPORT);
+if (err) {
+goto err_notif;
+}
+}
  }
  for (j = 0; j < ARRAY_SIZE(mlx4_class_attributes); ++j) {
diff --git a/drivers/infiniband/hw/mlx4/qp.c
b/drivers/infiniband/hw/mlx4/qp.c
index 8d28059..c0dee79 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1508,6 +1508,24 @@ static int create_qp_lb_counter(struct
mlx4_ib_dev *dev, struct mlx4_ib_qp *qp)
  return 0;
  }
+enum {
+MLX4_QPC_ROCE_MODE_1 = 0,
+MLX4_QPC_ROCE_MODE_2 = 2,
+MLX4_QPC_ROCE_MODE_MAX = 0xff
+};
+
+static u8 gid_type_to_qpc(enum ib_gid_type gid_type)
+{
+switch (gid_type) {
+case IB_GID_TYPE_ROCE:
+return MLX4_QPC_ROCE_MODE_1;
+case IB_GID_TYPE_ROCE_UDP_ENCAP:
+return MLX4_QPC_ROCE_MODE_2;
+default:
+return MLX4_QPC_ROCE_MODE_MAX;
+}
+}
+
  static int __mlx4_ib_modify_qp(struct ib_qp *ibqp,
 const struct ib_qp_attr *attr, int attr_mask,
 enum ib_qp_state cur_state, enum ib_qp_state
new_state)
@@ -1651,9 +1669,10 @@ static int __mlx4_ib_modify_qp(struct ib_qp *ibqp,
  u16 vlan = 0x;
  u8 smac[ETH_ALEN];
  int status = 0;
+int is_eth = rdma_cap_eth_ah(>ib_dev, port_num) &&
+attr->ah_attr.ah_flags & IB_AH_GRH;
-if (rdma_cap_eth_ah(>ib_dev, port_num) &&
-attr->ah_attr.ah_flags & IB_AH_GRH) {
+if (is_eth && attr->ah_attr.ah_flags & IB_AH_GRH) {
  int index = attr->ah_attr.grh.sgid_index;
  status = ib_get_cached_gid(ibqp->device, port_num,
@@ -1675,6 +1694,16 @@ static int __mlx4_ib_modify_qp(struct ib_qp *ibqp,
  optpar |= 

Re: [PATCH for-next 6/7] IB/mlx4: Create and use another QP1 for RoCEv2

[Matan Barak]

On 12/29/2015 4:42 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

The mlx4 driver uses a special QP to implement the GSI QP. This kind
of QP allows to build the InfiniBand headers in SW to be put before
the payload that comes in with the WR. The mlx4 HW builds the packet,
calculates the ICRC and puts it at the end of the payload. This ICRC
calculation however depends on the QP configuration which is
determined when QP is modified (roce_mode during INIT->RTR).
On the other hand, ICRC verification when packet is received does to
depend on this configuration.


I don't understand the part of the sentence saying "when packet is
received does to depend on this configuration"
maybe some typo/s there?



I'll rephrase Moni's commit message for V2:

The mlx4 driver uses a special QP to implement the GSI QP. This kind of 
QP allows to build the InfiniBand headers in software.
When mlx4 hadware builds the packet, it calculates the ICRC and puts it 
at the end of the payload. However, this ICRC calculation depends
on the QP configuration, which is determined when the QP is modified 
(roce_mode during INIT->RTR).
When receiving a packet, the ICRC verification doesn't depend on this 
configuration.
Therefore, using two GSI QPs for send (one for each RoCE version) and 
one GSI QP for receive are required.



Therefore, using 2 GSI QPs for send (one for each RoCE version) and 1
GSI QP for receive are required.


s/2/two/ and s/1/one/ please



No problem


Or.



Matan
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 3/7] IB/mlx4: Configure device to work in RoCEv2

[Or Gerlitz]

On 12/30/2015 10:23 AM, Matan Barak wrote:


int mlx4_CONFIG_DEV_wrapper(struct mlx4_dev *dev, int slave,
struct mlx4_vhcr *vhcr,
struct mlx4_cmd_mailbox *inbox,
struct mlx4_cmd_mailbox *outbox,
struct mlx4_cmd_info *cmd)
{
int err;
u8 get = vhcr->op_modifier;

if (get != 1)
return -EPERM;

err = mlx4_DMA_wrapper(dev, slave, vhcr, inbox, outbox, cmd);

return err;
}

Only "get" is permitted in multi-function setups.


good, thanks for clarifying this out.



Anyway, mlx4_config_roce_v2_port is not called for these setups 
because of this condition:

if (mlx4_is_mfunc(dev)) {
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;
dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
mlx4_dbg(dev, "RoCE V2 is not supported when SR-IOV is enabled\n");
} 


wrong again, you assume your Linux VF driver, but the VM can run other 
driver.



--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/7] IB/mlx4: Add RoCE per GID support for add_gid and del_gid

[Matan Barak]

On 12/29/2015 5:24 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

[...] We use a new firmware command in order to populate the GID table
and store the type along with the GID value.


Its a new value to existing command.. so better say we use a new value
to the SET_PORT firmware command to do X



Ok


Also here, break out mlx4_core new functionality e.g the changes to
include/linux/mlx4/cmd.h into mlx4_core only patch. You don't need any
change to mlx4_core to have it's own patch, I guess one up to three mlx4
core patches would be OK.



I'll split mlx4_core logically.


Did you make sure (at the resource tracker) that VFs can't do this new
set port command flavor?



In mlx4_common_set_port:
if (slave != dev->caps.function &&
in_modifier != MLX4_SET_PORT_GENERAL &&
 in_modifier != MLX4_SET_PORT_GID_TABLE) {
mlx4_warn(dev, "denying SET_PORT for slave:%d\n", slave);
return -EINVAL;
}




Also find some spot to put blank line in the change-log, it's hard to
read this way.



No problem


Or.


Matan




--
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  http://vger.kernel.org/majordomo-info.html

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next V3 00/11] Add RoCE v2 support

[Matan Barak]

On 12/30/2015 8:04 AM, Or Gerlitz wrote:

Hi Matan,

I see these two smatch complaints on code added with this series, can
you please take a look?

drivers/infiniband/core/addr.c:503 rdma_resolve_ip_route() warn:
variable dereferenced before check 'src_addr' (see line 500)
drivers/infiniband/core/cma_configfs.c:172 make_cma_ports() warn: double
check that we're allocating correct size: 8 vs 128



I'll send fixes for both of them. Thanks for posting this.



Or.


Matan


--
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  http://vger.kernel.org/majordomo-info.html

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

[Christoph Hellwig]

Hi Ira,

please take a look at the patches I've attached - they are just WIP
that hasn't been tested as I'm on a vacation without access to my
IB setup until New Year's Eve.

Patch 1 is I think a genuine bug fix caused by the madness (pun
intendended) of the wr_id abuses.

Patch 2: passes the mad_send_buf explicitily to mad handlers to get rid
of that mess.

Patch 3 is the CQ API conversion which becomes relatively simple once
the prior issues above are sorted out.

>From a22609131ca353278015b6b4aec3077db06ad9f5 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Wed, 30 Dec 2015 11:49:22 +0100
Subject: IB/mad: pass send buf in wr_id in local_completions

The sa_query recv_handler expects the send_buf in wr_id, and all other recv
handlers ignore wr_id.  It seems this is what we should pass, please confirm.

Signed-off-by: Christoph Hellwig 
---
 drivers/infiniband/core/mad.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index d4d2a61..e0859e5 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -2734,7 +2734,7 @@ static void local_completions(struct work_struct *work)
 * before request
 */
build_smp_wc(recv_mad_agent->agent.qp,
-(unsigned long) local->mad_send_wr,
+(unsigned long) 
>mad_send_wr->send_buf,
 be16_to_cpu(IB_LID_PERMISSIVE),
 local->mad_send_wr->send_wr.pkey_index,
 recv_mad_agent->agent.port_num, );
-- 
1.9.1

>From c6101bfa6543d0b35c2ca2fa0add09341f456e88 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Wed, 30 Dec 2015 11:54:02 +0100
Subject: IB/mad: pass ib_mad_send_buf explicitly to the recv_handler

Stop abusing wr_id and just pass the parameter explicitly.

Signed-off-by: Christoph Hellwig 
---
 drivers/infiniband/core/cm.c  |  1 +
 drivers/infiniband/core/mad.c | 18 ++
 drivers/infiniband/core/sa_query.c|  7 ++-
 drivers/infiniband/core/user_mad.c|  1 +
 drivers/infiniband/ulp/srpt/ib_srpt.c |  1 +
 include/rdma/ib_mad.h |  2 ++
 6 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index e3a95d1..ad3726d 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -3503,6 +3503,7 @@ int ib_cm_notify(struct ib_cm_id *cm_id, enum 
ib_event_type event)
 EXPORT_SYMBOL(ib_cm_notify);
 
 static void cm_recv_handler(struct ib_mad_agent *mad_agent,
+   struct ib_mad_send_buf *send_buf,
struct ib_mad_recv_wc *mad_recv_wc)
 {
struct cm_port *port = mad_agent->context;
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index e0859e5..f15fcd6 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -693,7 +693,7 @@ static void snoop_recv(struct ib_mad_qp_info *qp_info,
 
atomic_inc(_snoop_priv->refcount);
spin_unlock_irqrestore(_info->snoop_lock, flags);
-   mad_snoop_priv->agent.recv_handler(_snoop_priv->agent,
+   mad_snoop_priv->agent.recv_handler(_snoop_priv->agent, NULL,
   mad_recv_wc);
deref_snoop_agent(mad_snoop_priv);
spin_lock_irqsave(_info->snoop_lock, flags);
@@ -1994,9 +1994,9 @@ static void ib_mad_complete_recv(struct 
ib_mad_agent_private *mad_agent_priv,
/* user rmpp is in effect
 * and this is an active RMPP MAD
 */
-   mad_recv_wc->wc->wr_id = 0;
-   
mad_agent_priv->agent.recv_handler(_agent_priv->agent,
-  mad_recv_wc);
+   mad_agent_priv->agent.recv_handler(
+   _agent_priv->agent, NULL,
+   mad_recv_wc);
atomic_dec(_agent_priv->refcount);
} else {
/* not user rmpp, revert to normal behavior and
@@ -2010,9 +2010,10 @@ static void ib_mad_complete_recv(struct 
ib_mad_agent_private *mad_agent_priv,
spin_unlock_irqrestore(_agent_priv->lock, flags);
 
/* Defined behavior is to complete response before 
request */
-   mad_recv_wc->wc->wr_id = (unsigned long) 
_send_wr->send_buf;
-   
mad_agent_priv->agent.recv_handler(_agent_priv->agent,
-  

Re: [PATCH for-next 1/7] IB/mlx4: Query RoCE support

[Matan Barak]

On 12/30/2015 10:44 AM, Or Gerlitz wrote:

On 12/30/2015 10:27 AM, Matan Barak wrote:



On 12/29/2015 5:19 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

@@ -905,6 +906,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev,
struct mlx4_dev_cap *dev_cap)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
  MLX4_GET(dev_cap->bmme_flags, outbox,
   QUERY_DEV_CAP_BMME_FLAGS_OFFSET);
+if (dev_cap->bmme_flags & MLX4_FLAG_ROCE_V1_V2)
+dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;


Did you make sure that the query dev cap wrapper unsets this bit when
proxing VF queries?


In mlx4_dev_cap:
if (mlx4_is_mfunc(dev)) {
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;
dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
mlx4_dbg(dev, "RoCE V2 is not supported when SR-IOV is enabled\n");
}

mlx4_slave_cap calls mlx4_dev_cap and uses the dev_caps it queried, so
we should be safe here.


mlx4_slave_cap is part of the Linux VF driver flow, right?

So...  NO, this is the Linux implementation.

You should make things robust against any guest driver.

The only way to do that is patch the command wrapper used by the PF
to filter out unwanted cap bits, see other filtering we do in
mlx4_QUERY_DEV_CAP_wrapper



I agree, thanks


Or.


Matan









  if (dev_cap->bmme_flags & MLX4_FLAG_PORT_REMAP)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_PORT_REMAP;
  MLX4_GET(field, outbox, QUERY_DEV_CAP_CONFIG_DEV_OFFSET);






--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next V3 00/11] Add RoCE v2 support

[Matan Barak]

On 12/30/2015 1:05 PM, Or Gerlitz wrote:

On 12/30/2015 12:48 PM, Matan Barak wrote:



On 12/30/2015 8:04 AM, Or Gerlitz wrote:

Hi Matan,

I see these two smatch complaints on code added with this series, can
you please take a look?

drivers/infiniband/core/addr.c:503 rdma_resolve_ip_route() warn:
variable dereferenced before check 'src_addr' (see line 500)
drivers/infiniband/core/cma_configfs.c:172 make_cma_ports() warn: double
check that we're allocating correct size: 8 vs 128



I'll send fixes for both of them. Thanks for posting this.


when the same smatch runs on older gcc, it produces more warnings, are
they false-positives?




Yeah, false positives - cma_configfs_params_get returns 0 iff both 
cma_dev and group are valid.



drivers/infiniband/core/cma_configfs.c: In function
?default_roce_mode_store?:
drivers/infiniband/core/cma_configfs.c:123: warning: ?cma_dev? may be
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c:124: warning: ?group? may be
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c: In function
?default_roce_mode_show?:
drivers/infiniband/core/cma_configfs.c:102: warning: ?cma_dev? may be
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c:103: warning: ?group? may be
used uninitialized in this function


--
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  http://vger.kernel.org/majordomo-info.html

--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] IB/uapi: expose uverbs WC opcodes

[Leon Romanovsky]

On Wed, Dec 30, 2015 at 10:44:29AM +0100, Christoph Hellwig wrote:
> On Tue, Dec 29, 2015 at 01:02:54PM +0200, Sagi Grimberg wrote:
> >> As you did it in the first patch, just don't assign after IB_WC_LOCAL_INV.
> >> Compiler will handle IB_UVERS_WC_SEND_END + X calculations by itself.
> >
> > I disagree, I'd say its better to keep the code verbosity level here...
> 
> I really don't like enum auto assignment for constants that are fixe
> as part of an ABI.  There is too much chance of things going wrong.

It is up to you, just be constant in your enums assignments.

Thanks.

> --
> 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  http://vger.kernel.org/majordomo-info.html
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next V3 00/11] Add RoCE v2 support

[Or Gerlitz]

On 12/30/2015 12:48 PM, Matan Barak wrote:



On 12/30/2015 8:04 AM, Or Gerlitz wrote:

Hi Matan,

I see these two smatch complaints on code added with this series, can
you please take a look?

drivers/infiniband/core/addr.c:503 rdma_resolve_ip_route() warn:
variable dereferenced before check 'src_addr' (see line 500)
drivers/infiniband/core/cma_configfs.c:172 make_cma_ports() warn: double
check that we're allocating correct size: 8 vs 128



I'll send fixes for both of them. Thanks for posting this.


when the same smatch runs on older gcc, it produces more warnings, are 
they false-positives?



drivers/infiniband/core/cma_configfs.c: In function 
?default_roce_mode_store?:
drivers/infiniband/core/cma_configfs.c:123: warning: ?cma_dev? may be 
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c:124: warning: ?group? may be 
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c: In function 
?default_roce_mode_show?:
drivers/infiniband/core/cma_configfs.c:102: warning: ?cma_dev? may be 
used uninitialized in this function
drivers/infiniband/core/cma_configfs.c:103: warning: ?group? may be 
used uninitialized in this function


--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 5/7] IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers

[Moni Shoua]

>
> The last hunk that you removed had a role and was by no means
> dead-code, right? so... (1) why it's correct to remove it? (2) if you
> want to introduce different way to implement what was done here, why
> in this patch? maybe add pre-patch for that

In a way you are right. This hunk does not insert a bug and even
improves correctness but it acutally belongs to an earlier patch
(dbf727de7440f73c4b92be4b958cbc24977e8ca2 IB/core: Use GID table in AH
creation and dmac resolution)
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/3] IB/core: Change per-entry lock in RoCE GID table to one lock

[Matan Barak]

On 12/30/2015 9:36 AM, Bart Van Assche wrote:

On 12/30/2015 07:01 AM, Or Gerlitz wrote:

On 10/28/2015 4:52 PM, Matan Barak wrote:

@@ -134,16 +138,14 @@ static int write_gid(struct ib_device *ib_dev,
u8 port,
  {
  int ret = 0;
  struct net_device *old_net_dev;
-unsigned long flags;
  /* in rdma_cap_roce_gid_table, this funciton should be protected
by a
   * sleep-able lock.
   */
-write_lock_irqsave(>data_vec[ix].lock, flags);
  if (rdma_cap_roce_gid_table(ib_dev, port)) {
  table->data_vec[ix].props |= GID_TABLE_ENTRY_INVALID;
-write_unlock_irqrestore(>data_vec[ix].lock, flags);
+write_unlock_irq(>rwlock);
  /* GID_TABLE_WRITE_ACTION_MODIFY currently isn't supported by
   * RoCE providers and thus only updates the cache.
   */
@@ -153,7 +155,7 @@ static int write_gid(struct ib_device *ib_dev, u8
port,
  else if (action == GID_TABLE_WRITE_ACTION_DEL)
  ret = ib_dev->del_gid(ib_dev, port, ix,
>data_vec[ix].context);
-write_lock_irqsave(>data_vec[ix].lock, flags);
+write_lock_irq(>rwlock);
  }


sparse complains on

drivers/infiniband/core/cache.c:186:17: warning: context imbalance in
'write_gid' - unexpected unlock

is this false positive?




It is false positive.


Hello Or,

sparse expects __release() and __acquire() annotations for functions
that unlock a lock object that has been locked by its caller. See e.g.
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-October/003541.html.



Thanks - adding __releases and __acquires eliminates this sparse warning.



Bart.


Matan
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 ib-next 0/3] IB core uverbs support for leagacy commands

[Leon Romanovsky]

On Tue, Nov 10, 2015 at 08:00:07PM +0200, Eli Cohen wrote:
> Hi Doug,
> 
> this patcheset is addresses comments from the community. Specifically if the 
> verbs is not supported by a hardware driver, we return -EOPNOTSUPP.
> 
> Eli
> 
> Eli Cohen (3):
>   IB/core: Avoid duplicate code
>   IB/core: IB/core: Allow legacy verbs through extended interfaces
>   IB/core: Modify conditional on ucontext existence
> 
>  drivers/infiniband/core/uverbs_main.c | 70 
> +--
>  1 file changed, 34 insertions(+), 36 deletions(-)

Doug,
I remember that you experienced the issues with your email setup and I
wonder if this patchset was left behind.
https://patchwork.kernel.org/patch/7591731/
https://patchwork.kernel.org/patch/7591741/
https://patchwork.kernel.org/patch/7591751/

It is important patchset which enables create_qp_ex() interface
for already merged patches.

Thanks.

> 
> -- 
> 2.6.3
> 
> --
> 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  http://vger.kernel.org/majordomo-info.html
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 1/7] IB/mlx4: Query RoCE support

[Matan Barak]

On 12/29/2015 5:19 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

@@ -905,6 +906,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev,
struct mlx4_dev_cap *dev_cap)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
  MLX4_GET(dev_cap->bmme_flags, outbox,
   QUERY_DEV_CAP_BMME_FLAGS_OFFSET);
+if (dev_cap->bmme_flags & MLX4_FLAG_ROCE_V1_V2)
+dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;


Did you make sure that the query dev cap wrapper unsets this bit when
proxing VF queries?


In mlx4_dev_cap:
if (mlx4_is_mfunc(dev)) {
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;
dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
mlx4_dbg(dev, "RoCE V2 is not supported when SR-IOV is enabled\n");
}

mlx4_slave_cap calls mlx4_dev_cap and uses the dev_caps it queried, so 
we should be safe here.





  if (dev_cap->bmme_flags & MLX4_FLAG_PORT_REMAP)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_PORT_REMAP;
  MLX4_GET(field, outbox, QUERY_DEV_CAP_CONFIG_DEV_OFFSET);




--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 1/7] IB/mlx4: Query RoCE support

[Or Gerlitz]

On 12/30/2015 10:27 AM, Matan Barak wrote:



On 12/29/2015 5:19 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

@@ -905,6 +906,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev,
struct mlx4_dev_cap *dev_cap)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
  MLX4_GET(dev_cap->bmme_flags, outbox,
   QUERY_DEV_CAP_BMME_FLAGS_OFFSET);
+if (dev_cap->bmme_flags & MLX4_FLAG_ROCE_V1_V2)
+dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;


Did you make sure that the query dev cap wrapper unsets this bit when
proxing VF queries?


In mlx4_dev_cap:
if (mlx4_is_mfunc(dev)) {
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;
dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
mlx4_dbg(dev, "RoCE V2 is not supported when SR-IOV is enabled\n");
}

mlx4_slave_cap calls mlx4_dev_cap and uses the dev_caps it queried, so 
we should be safe here.


mlx4_slave_cap is part of the Linux VF driver flow, right?

So...  NO, this is the Linux implementation.

You should make things robust against any guest driver.

The only way to do that is patch the command wrapper used by the PF
to filter out unwanted cap bits, see other filtering we do in 
mlx4_QUERY_DEV_CAP_wrapper


Or.







  if (dev_cap->bmme_flags & MLX4_FLAG_PORT_REMAP)
  dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_PORT_REMAP;
  MLX4_GET(field, outbox, QUERY_DEV_CAP_CONFIG_DEV_OFFSET);





--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/13] IB/srpt: chain RDMA READ/WRITE requests

[Christoph Hellwig]

On Tue, Dec 29, 2015 at 10:58:24AM +0100, Bart Van Assche wrote:
> On 12/07/2015 09:51 PM, Christoph Hellwig wrote:
> > Remove struct rdma_iu and instead allocate the struct ib_rdma_wr array
> > early and fill out directly.  This allows us to chain the WRs, and thus
> > archive both less lock contention on the HCA workqueue as well as much
> > simpler error handling.
> 
> Please consider folding the patch below into this patch.

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next V3 10/11] IB/core: Initialize UD header structure with IP and UDP headers

[Matan Barak]

On 12/30/2015 7:57 AM, Or Gerlitz wrote:

On 12/23/2015 2:56 PM, Matan Barak wrote:

+__be16 ib_ud_ip4_csum(struct ib_ud_header *header)
+{
+struct iphdr iph;
+
+iph.ihl= 5;
+iph.version= 4;
+iph.tos= header->ip4.tos;
+iph.tot_len= header->ip4.tot_len;
+iph.id= header->ip4.id;
+iph.frag_off= header->ip4.frag_off;
+iph.ttl= header->ip4.ttl;
+iph.protocol= header->ip4.protocol;
+iph.check= 0;
+iph.saddr= header->ip4.saddr;
+iph.daddr= header->ip4.daddr;
+
+return ip_fast_csum((u8 *), iph.ihl);
+}
+EXPORT_SYMBOL(ib_ud_ip4_csum);


You have introduced here this sparse warning, please fix



Thanks, we'll fix this.


drivers/infiniband/core/ud_header.c:299:28: warning: incorrect type in
return expression (different base types)
drivers/infiniband/core/ud_header.c:299:28:expected restricted __be16
drivers/infiniband/core/ud_header.c:299:28:got restricted __sum16

Or.


Matan
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/13] irq_poll: fold irq_poll_sched_prep into irq_poll_sched

[Christoph Hellwig]

On Tue, Dec 29, 2015 at 10:54:18AM +0100, Bart Van Assche wrote:
> After having applied these changes the SRP initiator didn't receive any 
> RDMA completions anymore. I could remedy that by changing 
> "!test_and_set_bit()" into "test_and_set_bit()":

Yes.  I actually had this bug earlier, fixed it and managed to get
it back during a rebase, d'oh.

Reviewed-by: Christoph Hellwig 

Can you resend it with a proper signoff?
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/core: Remove a set-but-not-used variable from ib_sg_to_pages()

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] IB/uapi: expose uverbs WC opcodes

[Christoph Hellwig]

On Tue, Dec 29, 2015 at 01:02:54PM +0200, Sagi Grimberg wrote:
>> As you did it in the first patch, just don't assign after IB_WC_LOCAL_INV.
>> Compiler will handle IB_UVERS_WC_SEND_END + X calculations by itself.
>
> I disagree, I'd say its better to keep the code verbosity level here...

I really don't like enum auto assignment for constants that are fixe
as part of an ABI.  There is too much chance of things going wrong.
--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 7/7] IB/mlx4: Advertise RoCE support

[Matan Barak]

On 12/29/2015 4:44 PM, Or Gerlitz wrote:

On 12/29/2015 3:24 PM, Matan Barak wrote:

Advertise RoCE support in port_immutable according to the hardware
capabilities. This enables the verbs stack to use RoCE v2 mode.


Advertise RoCE V2 support



Signed-off-by: Matan Barak 


I guess you wanted  "IB/mlx4: Advertise RoCE V2 support" for the patch
title? since we did
advertise RDMA_CORE_PORT_IBA_ROCE prior to this patch.



Correct, thanks!


Or.

---
  drivers/infiniband/hw/mlx4/main.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 44e5699..8cf2575 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2183,6 +2183,7 @@ static int mlx4_port_immutable(struct ib_device
*ibdev, u8 port_num,
 struct ib_port_immutable *immutable)
  {
  struct ib_port_attr attr;
+struct mlx4_ib_dev *mdev = to_mdev(ibdev);
  int err;
  err = mlx4_ib_query_port(ibdev, port_num, );
@@ -2192,10 +2193,15 @@ static int mlx4_port_immutable(struct
ib_device *ibdev, u8 port_num,
  immutable->pkey_tbl_len = attr.pkey_tbl_len;
  immutable->gid_tbl_len = attr.gid_tbl_len;
-if (mlx4_ib_port_link_layer(ibdev, port_num) ==
IB_LINK_LAYER_INFINIBAND)
+if (mlx4_ib_port_link_layer(ibdev, port_num) ==
IB_LINK_LAYER_INFINIBAND) {
  immutable->core_cap_flags = RDMA_CORE_PORT_IBA_IB;
-else
-immutable->core_cap_flags = RDMA_CORE_PORT_IBA_ROCE;
+} else {
+if (mdev->dev->caps.flags & MLX4_DEV_CAP_FLAG_IBOE)
+immutable->core_cap_flags = RDMA_CORE_PORT_IBA_ROCE;
+if (mdev->dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_ROCE_V1_V2)
+immutable->core_cap_flags = RDMA_CORE_PORT_IBA_ROCE |
+RDMA_CORE_PORT_IBA_ROCE_UDP_ENCAP;
+}
  immutable->max_mad_size = IB_MGMT_MAD_SIZE;



--
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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

[Eli Cohen]

On Mon, Dec 28, 2015 at 07:35:14PM -0500, ira.weiny wrote:
> 
> I'm still confused.  Here is the code with the patch applied:
> 
> 
> /* 
>  * IB MAD completion callback 
>  */ 
> static void ib_mad_completion_handler(struct work_struct *work) 
> { 
> struct ib_mad_port_private *port_priv; 
> struct ib_wc wc; 
> int count = 0; 
> 
> port_priv = container_of(work, struct ib_mad_port_private, work);
> ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP);
> 
> while (ib_poll_cq(port_priv->cq, 1, ) == 1) {
> if (wc.status == IB_WC_SUCCESS) {
> switch (wc.opcode) {
> case IB_WC_SEND:
> ib_mad_send_done_handler(port_priv, );
> break;
> case IB_WC_RECV:
> ib_mad_recv_done_handler(port_priv, );
> break;
> default:
> BUG_ON(1);
> break;
> }
> } else
> mad_error_handler(port_priv, );
> 
> if (++count > MAD_COMPLETION_PROC_LIMIT) {
> queue_work(port_priv->wq, _priv->work);
> break;
> }
> }
> }
> 
> 
> How is "return" any different than "break"?  Calling return will still result
> in a rearm on the next work task.

My argument is that if you break the loop since you exahsuted the quota you 
don't need to call ib_req_notify_cq(). If you think about this you will see 
that this was the original logic of this function. Only after you exhasted the 
quota you need to call ib_req_notify_cq() so the next completion will trigger 
the interrupt handler which calls the completion handler. The result is that 
you are generating less interrupts in the system.

To achieve that you do like this:

/*
 * IB MAD completion callback
 */
static void ib_mad_completion_handler(struct work_struct *work)
{
struct ib_mad_port_private *port_priv;
struct ib_wc wc;
int count = 0;

port_priv = container_of(work, struct ib_mad_port_private, work);

while (ib_poll_cq(port_priv->cq, 1, ) == 1) {
if (wc.status == IB_WC_SUCCESS) {
switch (wc.opcode) {  
case IB_WC_SEND:
ib_mad_send_done_handler(port_priv, );
break;
case IB_WC_RECV:
ib_mad_recv_done_handler(port_priv, );
break;
default:
BUG_ON(1);
break;
}   

  
} else  

  
mad_error_handler(port_priv, );

if (++count > MAD_COMPLETION_PROC_LIMIT) {
queue_work(port_priv->wq, _priv->work);
return;  <== return and avoid requesting for 
notification
}   

  
}   

  
ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP); <== only called if 
there are no more completions to process
}  

I hope my point is clear now.

> 
> Perhaps this code is wrong in the first place?  Should it call 
> ib_req_notify_cq
> after the while loop?  This code has been this way forever...
> 
> 1da177e4c3f41   (Linus Torvalds 2005-04-16 15:20:36 -0700   2568) 
> ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP);
> 1da177e4c3f41   (Linus Torvalds 2005-04-16 15:20:36 -0700   2569)
> 1da177e4c3f41   (Linus Torvalds 2005-04-16 15:20:36 -0700   2570)   while 
> (ib_poll_cq(port_priv->cq, 1, ) == 1) {
> 
> 
> Ira
> 
> 
> > 
> > > 
> > > I'm not quite sure what you mean about moving the ib_req_notify_cq 
> > > outside of
> > > the while loop.  It seems like to do what you say we would need another 
> > > work
> > > item which just does ib_poll_cq.  Is that what you meant?
> > > 
> > > Ira
> > > 
> > > > 
> > > > > @@ -2574,6 +2587,11 @@ static void ib_mad_completion_handler(struct 
> > > > > work_struct *work)
> > > > >   }
> > > > > 

[PATCH] IB/core: Allocating larger memory than required for cma_configfs

[Matan Barak]

We were allocating larger memory space than requried for
cma_dev_group->default_ports_group.

Fixes: 045959db65c6 ('IB/cma: Add configfs for rdma_cm')
Signed-off-by: Matan Barak 
---
Hi Doug,

This patch fixes a small issue, where we allocated more space than we
actually needed. This was introduces in the RoCE v2 series.

Regards,
Matan

 drivers/infiniband/core/cma_configfs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/core/cma_configfs.c 
b/drivers/infiniband/core/cma_configfs.c
index bd1d640..ab554df 100644
--- a/drivers/infiniband/core/cma_configfs.c
+++ b/drivers/infiniband/core/cma_configfs.c
@@ -169,9 +169,10 @@ static int make_cma_ports(struct cma_dev_group 
*cma_dev_group,
ports = kcalloc(ports_num, sizeof(*cma_dev_group->ports),
GFP_KERNEL);
 
-   cma_dev_group->default_ports_group = kcalloc(ports_num + 1,
-
sizeof(*cma_dev_group->ports),
-GFP_KERNEL);
+   cma_dev_group->default_ports_group =
+   kcalloc(ports_num + 1,
+   sizeof(*cma_dev_group->default_ports_group),
+   GFP_KERNEL);
 
if (!ports || !cma_dev_group->default_ports_group) {
err = -ENOMEM;
-- 
2.1.0

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH] IB/core: Fix dereference before check

[Matan Barak]

Sparse complains about dereference before check. Fixing this by
moving the check before the dereference.

Fixes: 200298326b27 ('IB/core: Validate route when we init ah')
Signed-off-by: Matan Barak 
---
Hi Doug,

This patch eliminates a deference before check sparse false warning.
This was introduced in the RoCE v2 series.

Regards,
Matan

 drivers/infiniband/core/addr.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 0b5f245..791cc98 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -497,13 +497,14 @@ int rdma_resolve_ip_route(struct sockaddr *src_addr,
struct sockaddr_storage ssrc_addr = {};
struct sockaddr *src_in = (struct sockaddr *)_addr;
 
-   if (src_addr->sa_family != dst_addr->sa_family)
-   return -EINVAL;
+   if (src_addr) {
+   if (src_addr->sa_family != dst_addr->sa_family)
+   return -EINVAL;
 
-   if (src_addr)
memcpy(src_in, src_addr, rdma_addr_size(src_addr));
-   else
+   } else {
src_in->sa_family = dst_addr->sa_family;
+   }
 
return addr_resolve(src_in, dst_addr, addr, false);
 }
-- 
2.1.0

--
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  http://vger.kernel.org/majordomo-info.html

[PATCH] IB/core: Eliminate sparse false positive warning on context imbalance

[Matan Barak]

When write_gid function needs to do a sleep-able operation, it unlocks
table->rwlock and then relocks it. Sparse complains about context
imbalance.

This is safe as write_gid is always called with table->rwlock.
write_gid protects from simultaneous writes to this GID entry
by setting the GID_TABLE_ENTRY_INVALID flag.

Fixes: 9c584f049596 ('IB/core: Change per-entry lock in RoCE GID table to
 one lock')
Signed-off-by: Matan Barak 

---
Hi Doug,

This patch eliminates a sparse false-positive warning about context
imbalance. We use __releases and __acquires in order to do so.

Regards,
Matan

 drivers/infiniband/core/cache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/core/cache.c b/drivers/infiniband/core/cache.c
index 92cadbd..53343ff 100644
--- a/drivers/infiniband/core/cache.c
+++ b/drivers/infiniband/core/cache.c
@@ -174,6 +174,7 @@ static int write_gid(struct ib_device *ib_dev, u8 port,
 const struct ib_gid_attr *attr,
 enum gid_table_write_action action,
 bool  default_gid)
+   __releases(>rwlock) __acquires(>rwlock)
 {
int ret = 0;
struct net_device *old_net_dev;
-- 
2.1.0

--
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  http://vger.kernel.org/majordomo-info.html

git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/k.o/for-4.5 crash during boot

[Bart Van Assche]

Hello Christoph,

Can you check whether the branch in the subject of this e-mail works 
fine on your setup (commit 59caaed7a7) ? On my test setup (Dell R430 
with two ConnectX-3 adapters) this branch crashes during boot in 
get_counter_table() (see also the attached screenshot).


Thanks,

Bart.

Re: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/k.o/for-4.5 crash during boot

[Or Gerlitz]

On 12/30/2015 2:04 PM, Bart Van Assche wrote:

Hello Christoph,

Can you check whether the branch in the subject of this e-mail works 
fine on your setup (commit 59caaed7a7) ? On my test setup (Dell R430 
with two ConnectX-3 adapters) this branch crashes during boot in 
get_counter_table() (see also the attached screenshot).


Can you please check with Hal's fix that was posted here 1-2 days ago, 
hopefully this should make your system to work


Or.
--
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  http://vger.kernel.org/majordomo-info.html

Re: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/k.o/for-4.5 crash during boot

[Leon Romanovsky]

On Wed, Dec 30, 2015 at 02:22:23PM +0200, Or Gerlitz wrote:
> On 12/30/2015 2:04 PM, Bart Van Assche wrote:
> >Hello Christoph,
> >
> >Can you check whether the branch in the subject of this e-mail works fine
> >on your setup (commit 59caaed7a7) ? On my test setup (Dell R430 with two
> >ConnectX-3 adapters) this branch crashes during boot in
> >get_counter_table() (see also the attached screenshot).
> 
> Can you please check with Hal's fix that was posted here 1-2 days ago,
> hopefully this should make your system to work

Or referenced to this patch [1], it should fix your crash.

[1] https://patchwork.kernel.org/patch/7929551/

> 
> Or.
> --
> 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  http://vger.kernel.org/majordomo-info.html
--
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  http://vger.kernel.org/majordomo-info.html