* RE: [PATCH rdma-next 01/10] IB/core: Add raw packet protocol
From: Liran Liss @ 2016-12-04 20:38 UTC (permalink / raw)
To: Hefty, Sean, Tom Talpey, Steve Wise, 'Jason Gunthorpe'
Cc: 'Doug Ledford', 'Leon Romanovsky',
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
'Steve Wise', Marciniszyn, Mike, Dalessandro, Dennis,
'Lijun Ou', 'Wei Hu(Xavier)', Latif, Faisal,
Yishai Hadas, 'Selvin Xavier', 'Devesh Sharma',
'Mitesh Ahuja', 'Christian Benvenuti',
'Dave Goodell', Moni Shoua, Or Gerlitz
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB0BA68E-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Hefty, Sean
>
> > I'd agree that the application picks the protocol, but I'd also argue
> > that the API should have a "wildcard" mode which allows the current
> > behavior. It could be a simple extension to just add a selector
> > parameter.
>
> I agree. The QP type can be viewed as the socket type, we only need to add a
> protocol field to go along with it. I.e. the protocol should be a qp attribute
> provided on input to qp create.
>
Right.
> > The tricky part is what to do with passive endpoints. If a wildcard is
> > specified, should a multiprotocol adapter create listens on all
> > protocols? Also, what of protocols which auto-negotiate? It's my
> > understanding that some RoCE adapters will attempt to autodetect
> > whether their peer is RoCEv1 or RoCEv2 capable, and adjust their
> > protocol to suit.
>
> We could include the protocol selection, also with wildcard support, here as
> well. The rdma cm may be able to handle this, so that drivers won't need to deal
> with a wildcard endpoint. Assuming that we don't end up with some devices
> that require they implement wildcard support, while others can't...
Typically, the application will request the protocol that it wants or leave it unspecified.
In that case, I think that the rdmacm would select the device default.
Anyway, returning to the initial matter at hand: I would like to start with each port reporting a bit mask of the supported protocols on that link (RoCE v1/v2, Raw Ethernet, iWARP, etc.)
It will be used for reporting device capabilities in general for tools, as well as by applications that don't use rdmacm.
--Liran
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mlx4: Use kernel sizeof and alloc styles
From: Joe Perches @ 2016-12-04 20:11 UTC (permalink / raw)
To: Yishai Hadas, Tariq Toukan; +Cc: netdev, linux-rdma, linux-kernel
Convert sizeof foo to sizeof(foo) and allocations with multiplications
to the appropriate kcalloc/kmalloc_array styles.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/mellanox/mlx4/alloc.c | 6 +++---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 8 ++++----
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 20 +++++++++---------
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.h | 4 ++--
drivers/net/ethernet/mellanox/mlx4/intf.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mr.c | 18 ++++++++--------
drivers/net/ethernet/mellanox/mlx4/qp.c | 12 +++++------
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 24 +++++++++++-----------
15 files changed, 63 insertions(+), 65 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 249a4584401a..c25de2740c78 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -185,8 +185,8 @@ int mlx4_bitmap_init(struct mlx4_bitmap *bitmap, u32 num, u32 mask,
bitmap->avail = num - reserved_top - reserved_bot;
bitmap->effective_len = bitmap->avail;
spin_lock_init(&bitmap->lock);
- bitmap->table = kzalloc(BITS_TO_LONGS(bitmap->max) *
- sizeof (long), GFP_KERNEL);
+ bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
+ GFP_KERNEL);
if (!bitmap->table)
return -ENOMEM;
@@ -668,7 +668,7 @@ static struct mlx4_db_pgdir *mlx4_alloc_db_pgdir(struct device *dma_device,
{
struct mlx4_db_pgdir *pgdir;
- pgdir = kzalloc(sizeof *pgdir, gfp);
+ pgdir = kzalloc(sizeof(*pgdir), gfp);
if (!pgdir)
return NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index e36bebcab3f2..86e03e47ca47 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2616,9 +2616,9 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
int i;
int err = 0;
- priv->cmd.context = kmalloc(priv->cmd.max_cmds *
- sizeof (struct mlx4_cmd_context),
- GFP_KERNEL);
+ priv->cmd.context = kmalloc_array(priv->cmd.max_cmds,
+ sizeof(struct mlx4_cmd_context),
+ GFP_KERNEL);
if (!priv->cmd.context)
return -ENOMEM;
@@ -2675,7 +2675,7 @@ struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)
{
struct mlx4_cmd_mailbox *mailbox;
- mailbox = kmalloc(sizeof *mailbox, GFP_KERNEL);
+ mailbox = kmalloc(sizeof(*mailbox), GFP_KERNEL);
if (!mailbox)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_resources.c b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
index a6b0db0e0383..10966dc5792c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_resources.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
@@ -44,7 +44,7 @@ void mlx4_en_fill_qp_context(struct mlx4_en_priv *priv, int size, int stride,
struct mlx4_en_dev *mdev = priv->mdev;
struct net_device *dev = priv->dev;
- memset(context, 0, sizeof *context);
+ memset(context, 0, sizeof(*context));
context->flags = cpu_to_be32(7 << 16 | rss << MLX4_RSS_QPC_FLAG_OFFSET);
context->pd = cpu_to_be32(mdev->priv_pdn);
context->mtu_msgmax = 0xff;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6562f78b07f4..616d3febe7ce 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1235,7 +1235,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
}
qp->event = mlx4_en_sqp_event;
- memset(context, 0, sizeof *context);
+ memset(context, 0, sizeof(*context));
mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
qpn, ring->cqn, -1, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 5de3cbe24f2b..233317e5fe72 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -660,7 +660,7 @@ static void build_inline_wqe(struct mlx4_en_tx_desc *tx_desc,
void *fragptr)
{
struct mlx4_wqe_inline_seg *inl = &tx_desc->inl;
- int spc = MLX4_INLINE_ALIGN - CTRL_SIZE - sizeof *inl;
+ int spc = MLX4_INLINE_ALIGN - CTRL_SIZE - sizeof(*inl);
unsigned int hlen = skb_headlen(skb);
if (skb->len <= spc) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index cd3638e6fe25..01210cb044ed 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -259,7 +259,7 @@ int mlx4_gen_pkey_eqe(struct mlx4_dev *dev, int slave, u8 port)
if (!s_slave->active)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_PKEY_TABLE;
@@ -276,7 +276,7 @@ int mlx4_gen_guid_change_eqe(struct mlx4_dev *dev, int slave, u8 port)
/*don't send if we don't have the that slave */
if (dev->persist->num_vfs < slave)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_GUID_INFO;
@@ -295,7 +295,7 @@ int mlx4_gen_port_state_change_eqe(struct mlx4_dev *dev, int slave, u8 port,
/*don't send if we don't have the that slave */
if (dev->persist->num_vfs < slave)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_CHANGE;
eqe.subtype = port_subtype_change;
@@ -432,7 +432,7 @@ int mlx4_gen_slaves_port_mgt_ev(struct mlx4_dev *dev, u8 port, int attr)
{
struct mlx4_eqe eqe;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_PORT_INFO;
@@ -721,7 +721,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
}
memcpy(&priv->mfunc.master.comm_arm_bit_vector,
eqe->event.comm_channel_arm.bit_vec,
- sizeof eqe->event.comm_channel_arm.bit_vec);
+ sizeof(eqe->event.comm_channel_arm.bit_vec));
queue_work(priv->mfunc.master.comm_wq,
&priv->mfunc.master.comm_work);
break;
@@ -986,15 +986,15 @@ static int mlx4_create_eq(struct mlx4_dev *dev, int nent,
*/
npages = PAGE_ALIGN(eq->nent * dev->caps.eqe_size) / PAGE_SIZE;
- eq->page_list = kmalloc(npages * sizeof *eq->page_list,
- GFP_KERNEL);
+ eq->page_list = kmalloc_array(npages, sizeof(*eq->page_list),
+ GFP_KERNEL);
if (!eq->page_list)
goto err_out;
for (i = 0; i < npages; ++i)
eq->page_list[i].buf = NULL;
- dma_list = kmalloc(npages * sizeof *dma_list, GFP_KERNEL);
+ dma_list = kmalloc_array(npages, sizeof(*dma_list), GFP_KERNEL);
if (!dma_list)
goto err_out_free;
@@ -1163,7 +1163,7 @@ int mlx4_alloc_eq_table(struct mlx4_dev *dev)
struct mlx4_priv *priv = mlx4_priv(dev);
priv->eq_table.eq = kcalloc(dev->caps.num_eqs - dev->caps.reserved_eqs,
- sizeof *priv->eq_table.eq, GFP_KERNEL);
+ sizeof(*priv->eq_table.eq), GFP_KERNEL);
if (!priv->eq_table.eq)
return -ENOMEM;
@@ -1182,7 +1182,7 @@ int mlx4_init_eq_table(struct mlx4_dev *dev)
int i;
priv->eq_table.uar_map = kcalloc(mlx4_num_eq_uar(dev),
- sizeof *priv->eq_table.uar_map,
+ sizeof(*priv->eq_table.uar_map),
GFP_KERNEL);
if (!priv->eq_table.uar_map) {
err = -ENOMEM;
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 84bab9f0732e..2be6f0518baf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -57,7 +57,7 @@ MODULE_PARM_DESC(enable_qos, "Enable Enhanced QoS support (default: off)");
do { \
void *__p = (char *) (source) + (offset); \
u64 val; \
- switch (sizeof (dest)) { \
+ switch (sizeof(dest)) { \
case 1: (dest) = *(u8 *) __p; break; \
case 2: (dest) = be16_to_cpup(__p); break; \
case 4: (dest) = be32_to_cpup(__p); break; \
diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 2a9dd460a95f..84fe587d5dfe 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -396,7 +396,7 @@ int mlx4_init_icm_table(struct mlx4_dev *dev, struct mlx4_icm_table *table,
obj_per_chunk = MLX4_TABLE_CHUNK_SIZE / obj_size;
num_icm = (nobj + obj_per_chunk - 1) / obj_per_chunk;
- table->icm = kcalloc(num_icm, sizeof *table->icm, GFP_KERNEL);
+ table->icm = kcalloc(num_icm, sizeof(*table->icm), GFP_KERNEL);
if (!table->icm)
return -ENOMEM;
table->virt = virt;
diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.h b/drivers/net/ethernet/mellanox/mlx4/icm.h
index 0c7364550150..304f2f1d26a5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.h
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.h
@@ -39,8 +39,8 @@
#include <linux/mutex.h>
#define MLX4_ICM_CHUNK_LEN \
- ((256 - sizeof (struct list_head) - 2 * sizeof (int)) / \
- (sizeof (struct scatterlist)))
+ ((256 - sizeof(struct list_head) - 2 * sizeof(int)) / \
+ (sizeof(struct scatterlist)))
enum {
MLX4_ICM_PAGE_SHIFT = 12,
diff --git a/drivers/net/ethernet/mellanox/mlx4/intf.c b/drivers/net/ethernet/mellanox/mlx4/intf.c
index 0e8b7c44931f..968b4b4ee5ca 100644
--- a/drivers/net/ethernet/mellanox/mlx4/intf.c
+++ b/drivers/net/ethernet/mellanox/mlx4/intf.c
@@ -53,7 +53,7 @@ static void mlx4_add_device(struct mlx4_interface *intf, struct mlx4_priv *priv)
{
struct mlx4_device_context *dev_ctx;
- dev_ctx = kmalloc(sizeof *dev_ctx, GFP_KERNEL);
+ dev_ctx = kmalloc(sizeof(*dev_ctx), GFP_KERNEL);
if (!dev_ctx)
return;
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 6f4e67bc3538..932cd312d131 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -907,10 +907,10 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
mlx4_replace_zero_macs(dev);
dev->caps.qp0_qkey = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
- dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
+ dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
if (!dev->caps.qp0_tunnel || !dev->caps.qp0_proxy ||
!dev->caps.qp1_tunnel || !dev->caps.qp1_proxy ||
@@ -2373,7 +2373,7 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
dev->caps.rx_checksum_flags_port[2] = params.rx_csum_flags_port_2;
}
priv->eq_table.inta_pin = adapter.inta_pin;
- memcpy(dev->board_id, adapter.board_id, sizeof dev->board_id);
+ memcpy(dev->board_id, adapter.board_id, sizeof(dev->board_id));
return 0;
@@ -2845,7 +2845,7 @@ static void mlx4_enable_msi_x(struct mlx4_dev *dev)
if (nreq > MAX_MSIX)
nreq = MAX_MSIX;
- entries = kcalloc(nreq, sizeof *entries, GFP_KERNEL);
+ entries = kcalloc(nreq, sizeof(*entries), GFP_KERNEL);
if (!entries)
goto no_msi;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
index 94b891c118c1..53841aa994b7 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -161,7 +161,7 @@ static int new_steering_entry(struct mlx4_dev *dev, u8 port,
return -EINVAL;
s_steer = &mlx4_priv(dev)->steer[port - 1];
- new_entry = kzalloc(sizeof *new_entry, GFP_KERNEL);
+ new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
if (!new_entry)
return -ENOMEM;
@@ -174,7 +174,7 @@ static int new_steering_entry(struct mlx4_dev *dev, u8 port,
*/
pqp = get_promisc_qp(dev, port, steer, qpn);
if (pqp) {
- dqp = kmalloc(sizeof *dqp, GFP_KERNEL);
+ dqp = kmalloc(sizeof(*dqp), GFP_KERNEL);
if (!dqp) {
err = -ENOMEM;
goto out_alloc;
@@ -273,7 +273,7 @@ static int existing_steering_entry(struct mlx4_dev *dev, u8 port,
}
/* add the qp as a duplicate on this index */
- dqp = kmalloc(sizeof *dqp, GFP_KERNEL);
+ dqp = kmalloc(sizeof(*dqp), GFP_KERNEL);
if (!dqp)
return -ENOMEM;
dqp->qpn = qpn;
@@ -442,7 +442,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8 port,
goto out_mutex;
}
- pqp = kmalloc(sizeof *pqp, GFP_KERNEL);
+ pqp = kmalloc(sizeof(*pqp), GFP_KERNEL);
if (!pqp) {
err = -ENOMEM;
goto out_mutex;
@@ -513,7 +513,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8 port,
/* add the new qpn to list of promisc qps */
list_add_tail(&pqp->list, &s_steer->promisc_qps[steer]);
/* now need to add all the promisc qps to default entry */
- memset(mgm, 0, sizeof *mgm);
+ memset(mgm, 0, sizeof(*mgm));
members_count = 0;
list_for_each_entry(dqp, &s_steer->promisc_qps[steer], list) {
if (members_count == dev->caps.num_qp_per_mgm) {
@@ -1137,7 +1137,7 @@ int mlx4_qp_attach_common(struct mlx4_dev *dev, struct mlx4_qp *qp, u8 gid[16],
index += dev->caps.num_mgms;
new_entry = 1;
- memset(mgm, 0, sizeof *mgm);
+ memset(mgm, 0, sizeof(*mgm));
memcpy(mgm->gid, gid, 16);
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index 395b5463cfd9..f490a29b6203 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -106,16 +106,15 @@ static int mlx4_buddy_init(struct mlx4_buddy *buddy, int max_order)
buddy->max_order = max_order;
spin_lock_init(&buddy->lock);
- buddy->bits = kcalloc(buddy->max_order + 1, sizeof (long *),
- GFP_KERNEL);
- buddy->num_free = kcalloc((buddy->max_order + 1), sizeof *buddy->num_free,
- GFP_KERNEL);
+ buddy->bits = kcalloc(buddy->max_order + 1, sizeof(long *), GFP_KERNEL);
+ buddy->num_free = kcalloc(buddy->max_order + 1,
+ sizeof(*buddy->num_free), GFP_KERNEL);
if (!buddy->bits || !buddy->num_free)
goto err_out;
for (i = 0; i <= buddy->max_order; ++i) {
s = BITS_TO_LONGS(1 << (buddy->max_order - i));
- buddy->bits[i] = kcalloc(s, sizeof (long), GFP_KERNEL | __GFP_NOWARN);
+ buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL | __GFP_NOWARN);
if (!buddy->bits[i]) {
buddy->bits[i] = vzalloc(s * sizeof(long));
if (!buddy->bits[i])
@@ -706,13 +705,13 @@ static int mlx4_write_mtt_chunk(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
return -ENOMEM;
dma_sync_single_for_cpu(&dev->persist->pdev->dev, dma_handle,
- npages * sizeof (u64), DMA_TO_DEVICE);
+ npages * sizeof(u64), DMA_TO_DEVICE);
for (i = 0; i < npages; ++i)
mtts[i] = cpu_to_be64(page_list[i] | MLX4_MTT_FLAG_PRESENT);
dma_sync_single_for_device(&dev->persist->pdev->dev, dma_handle,
- npages * sizeof (u64), DMA_TO_DEVICE);
+ npages * sizeof(u64), DMA_TO_DEVICE);
return 0;
}
@@ -796,8 +795,7 @@ int mlx4_buf_write_mtt(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
int err;
int i;
- page_list = kmalloc(buf->npages * sizeof *page_list,
- gfp);
+ page_list = kmalloc_array(buf->npages, sizeof(*page_list), gfp);
if (!page_list)
return -ENOMEM;
@@ -1056,7 +1054,7 @@ int mlx4_fmr_alloc(struct mlx4_dev *dev, u32 pd, u32 access, int max_pages,
return -EINVAL;
/* All MTTs must fit in the same page */
- if (max_pages * sizeof *fmr->mtts > PAGE_SIZE)
+ if (max_pages * sizeof(*fmr->mtts) > PAGE_SIZE)
return -EINVAL;
fmr->page_shift = page_shift;
diff --git a/drivers/net/ethernet/mellanox/mlx4/qp.c b/drivers/net/ethernet/mellanox/mlx4/qp.c
index d1cd9c32a9ae..ded4109865a0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -174,7 +174,7 @@ static int __mlx4_qp_modify(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
cpu_to_be16(mlx4_qp_roce_entropy(dev, qp->qpn));
*(__be32 *) mailbox->buf = cpu_to_be32(optpar);
- memcpy(mailbox->buf + 8, context, sizeof *context);
+ memcpy(mailbox->buf + 8, context, sizeof(*context));
((struct mlx4_qp_context *) (mailbox->buf + 8))->local_qpn =
cpu_to_be32(qp->qpn);
@@ -825,10 +825,10 @@ int mlx4_init_qp_table(struct mlx4_dev *dev)
/* In mfunc, calculate proxy and tunnel qp offsets for the PF here,
* since the PF does not call mlx4_slave_caps */
- dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
+ dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
if (!dev->caps.qp0_tunnel || !dev->caps.qp0_proxy ||
!dev->caps.qp1_tunnel || !dev->caps.qp1_proxy) {
@@ -888,7 +888,7 @@ int mlx4_qp_query(struct mlx4_dev *dev, struct mlx4_qp *qp,
MLX4_CMD_QUERY_QP, MLX4_CMD_TIME_CLASS_A,
MLX4_CMD_WRAPPED);
if (!err)
- memcpy(context, mailbox->buf + 8, sizeof *context);
+ memcpy(context, mailbox->buf + 8, sizeof(*context));
mlx4_free_cmd_mailbox(dev, mailbox);
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index c548beaaf910..ff11dc01c2d5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -999,7 +999,7 @@ static struct res_common *alloc_qp_tr(int id)
{
struct res_qp *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1017,7 +1017,7 @@ static struct res_common *alloc_mtt_tr(int id, int order)
{
struct res_mtt *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1033,7 +1033,7 @@ static struct res_common *alloc_mpt_tr(int id, int key)
{
struct res_mpt *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1048,7 +1048,7 @@ static struct res_common *alloc_eq_tr(int id)
{
struct res_eq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1062,7 +1062,7 @@ static struct res_common *alloc_cq_tr(int id)
{
struct res_cq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1077,7 +1077,7 @@ static struct res_common *alloc_srq_tr(int id)
{
struct res_srq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1092,7 +1092,7 @@ static struct res_common *alloc_counter_tr(int id, int port)
{
struct res_counter *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1107,7 +1107,7 @@ static struct res_common *alloc_xrcdn_tr(int id)
{
struct res_xrcdn *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1121,7 +1121,7 @@ static struct res_common *alloc_fs_rule_tr(u64 id, int qpn)
{
struct res_fs_rule *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1233,7 +1233,7 @@ static int add_res_range(struct mlx4_dev *dev, int slave, u64 base, int count,
struct mlx4_resource_tracker *tracker = &priv->mfunc.master.res_tracker;
struct rb_root *root = &tracker->res_tree[type];
- res_arr = kzalloc(count * sizeof *res_arr, GFP_KERNEL);
+ res_arr = kcalloc(count, sizeof(*res_arr), GFP_KERNEL);
if (!res_arr)
return -ENOMEM;
@@ -1986,7 +1986,7 @@ static int mac_add_to_slave(struct mlx4_dev *dev, int slave, u64 mac, int port,
if (mlx4_grant_resource(dev, slave, RES_MAC, 1, port))
return -EINVAL;
- res = kzalloc(sizeof *res, GFP_KERNEL);
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
if (!res) {
mlx4_release_resource(dev, slave, RES_MAC, 1, port);
return -ENOMEM;
@@ -3978,7 +3978,7 @@ static int add_mcg_res(struct mlx4_dev *dev, int slave, struct res_qp *rqp,
struct res_gid *res;
int err;
- res = kzalloc(sizeof *res, GFP_KERNEL);
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
if (!res)
return -ENOMEM;
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* [PATCH V1 rdma-core 2/2] mlx5: Create and destroy address handle with kernel assistance
From: Yishai Hadas @ 2016-12-04 15:53 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
In-Reply-To: <1480866806-5052-1-git-send-email-yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Depending on kernel support and when link layer is Ethernet, call kernel
when asked to create an address handle. Kernel will return destination
mac which is required to create the address handle. The alternative,
when kernel support is missing, is to use netlink which is less
efficient. Destroying an address handle also needs kernel assistance to
clean resources that were allocated during address handle creation.
Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
providers/mlx5/mlx5-abi.h | 7 +++++++
providers/mlx5/mlx5.h | 2 ++
providers/mlx5/verbs.c | 28 +++++++++++++++++++++++-----
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/providers/mlx5/mlx5-abi.h b/providers/mlx5/mlx5-abi.h
index 4b5b577..800915d 100644
--- a/providers/mlx5/mlx5-abi.h
+++ b/providers/mlx5/mlx5-abi.h
@@ -91,6 +91,13 @@ struct mlx5_alloc_ucontext_resp {
__u64 hca_core_clock_offset;
};
+struct mlx5_create_ah_resp {
+ struct ibv_create_ah_resp ibv_resp;
+ __u32 response_length;
+ __u8 dmac[ETHERNET_LL_SIZE];
+ __u8 reserved[6];
+};
+
struct mlx5_alloc_pd_resp {
struct ibv_alloc_pd_resp ibv_resp;
__u32 pdn;
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index cb65429..cf314fc 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -217,6 +217,7 @@ enum mlx5_rsc_type {
enum {
MLX5_USER_CMDS_SUPP_UHW_QUERY_DEVICE = 1 << 0,
+ MLX5_USER_CMDS_SUPP_UHW_CREATE_AH = 1 << 1,
};
struct mlx5_resource {
@@ -470,6 +471,7 @@ struct mlx5_av {
struct mlx5_ah {
struct ibv_ah ibv_ah;
struct mlx5_av av;
+ bool kern_ah;
};
struct mlx5_rwq {
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index e288ebf..7107a5b 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1636,11 +1636,21 @@ struct ibv_ah *mlx5_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
}
if (is_eth) {
- uint16_t vid;
+ if (ctx->cmds_supp_uhw & MLX5_USER_CMDS_SUPP_UHW_CREATE_AH) {
+ struct mlx5_create_ah_resp resp = {};
- if (ibv_resolve_eth_l2_from_gid(pd->context, attr, ah->av.rmac,
- &vid))
- goto err;
+ if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr, &resp.ibv_resp, sizeof(resp)))
+ goto err;
+
+ ah->kern_ah = true;
+ memcpy(ah->av.rmac, resp.dmac, ETHERNET_LL_SIZE);
+ } else {
+ uint16_t vid;
+
+ if (ibv_resolve_eth_l2_from_gid(pd->context, attr,
+ ah->av.rmac, &vid))
+ goto err;
+ }
}
return &ah->ibv_ah;
@@ -1651,8 +1661,16 @@ err:
int mlx5_destroy_ah(struct ibv_ah *ah)
{
- free(to_mah(ah));
+ struct mlx5_ah *mah = to_mah(ah);
+ int err;
+
+ if (mah->kern_ah) {
+ err = ibv_cmd_destroy_ah(ah);
+ if (err)
+ return err;
+ }
+ free(mah);
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V1 rdma-core 1/2] ibverbs: Allow vendor data response in create_ah command
From: Yishai Hadas @ 2016-12-04 15:53 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
In-Reply-To: <1480866806-5052-1-git-send-email-yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Let caller pass response buffer and response size to ibv_cmd_create_ah
to enable kernel driver to return some private vendor data.
Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
libibverbs/cmd.c | 11 ++++++-----
libibverbs/driver.h | 4 +++-
libibverbs/libibverbs.map | 6 +++++-
providers/hfi1verbs/verbs.c | 4 +++-
providers/ipathverbs/verbs.c | 4 +++-
providers/ocrdma/ocrdma_verbs.c | 4 +++-
providers/rxe/rxe.c | 4 +++-
7 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/libibverbs/cmd.c b/libibverbs/cmd.c
index 06a017b..eaf7164 100644
--- a/libibverbs/cmd.c
+++ b/libibverbs/cmd.c
@@ -1492,12 +1492,13 @@ int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
}
int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
- struct ibv_ah_attr *attr)
+ struct ibv_ah_attr *attr,
+ struct ibv_create_ah_resp *resp,
+ size_t resp_size)
{
struct ibv_create_ah cmd;
- struct ibv_create_ah_resp resp;
- IBV_INIT_CMD_RESP(&cmd, sizeof cmd, CREATE_AH, &resp, sizeof resp);
+ IBV_INIT_CMD_RESP(&cmd, sizeof cmd, CREATE_AH, resp, resp_size);
cmd.user_handle = (uintptr_t) ah;
cmd.pd_handle = pd->handle;
cmd.attr.dlid = attr->dlid;
@@ -1515,9 +1516,9 @@ int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
if (write(pd->context->cmd_fd, &cmd, sizeof cmd) != sizeof cmd)
return errno;
- (void) VALGRIND_MAKE_MEM_DEFINED(&resp, sizeof resp);
+ (void) VALGRIND_MAKE_MEM_DEFINED(resp, resp_size);
- ah->handle = resp.handle;
+ ah->handle = resp->handle;
ah->context = pd->context;
return 0;
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index ea3dade..c170169 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -233,7 +233,9 @@ int ibv_cmd_post_recv(struct ibv_qp *ibqp, struct ibv_recv_wr *wr,
int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
struct ibv_recv_wr **bad_wr);
int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
- struct ibv_ah_attr *attr);
+ struct ibv_ah_attr *attr,
+ struct ibv_create_ah_resp *resp,
+ size_t resp_size);
int ibv_cmd_destroy_ah(struct ibv_ah *ah);
int ibv_cmd_attach_mcast(struct ibv_qp *qp, const union ibv_gid *gid, uint16_t lid);
int ibv_cmd_detach_mcast(struct ibv_qp *qp, const union ibv_gid *gid, uint16_t lid);
diff --git a/libibverbs/libibverbs.map b/libibverbs/libibverbs.map
index 33cd6b6..7858e19 100644
--- a/libibverbs/libibverbs.map
+++ b/libibverbs/libibverbs.map
@@ -64,7 +64,6 @@ IBVERBS_1.0 {
ibv_cmd_post_send;
ibv_cmd_post_recv;
ibv_cmd_post_srq_recv;
- ibv_cmd_create_ah;
ibv_cmd_destroy_ah;
ibv_cmd_attach_mcast;
ibv_cmd_detach_mcast;
@@ -131,3 +130,8 @@ IBVERBS_1.3 {
ibv_cmd_destroy_rwq_ind_table;
ibv_query_gid_type;
} IBVERBS_1.1;
+
+IBVERBS_1.4 {
+ global:
+ ibv_cmd_create_ah;
+} IBVERBS_1.3;
diff --git a/providers/hfi1verbs/verbs.c b/providers/hfi1verbs/verbs.c
index 06ddbb7..d39a4d0 100644
--- a/providers/hfi1verbs/verbs.c
+++ b/providers/hfi1verbs/verbs.c
@@ -678,12 +678,14 @@ int hfi1_post_srq_recv(struct ibv_srq *ibsrq, struct ibv_recv_wr *wr,
struct ibv_ah *hfi1_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
{
struct ibv_ah *ah;
+ struct ibv_create_ah_resp resp;
ah = malloc(sizeof *ah);
if (ah == NULL)
return NULL;
- if (ibv_cmd_create_ah(pd, ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
diff --git a/providers/ipathverbs/verbs.c b/providers/ipathverbs/verbs.c
index 35b2162..2145b15 100644
--- a/providers/ipathverbs/verbs.c
+++ b/providers/ipathverbs/verbs.c
@@ -653,12 +653,14 @@ int ipath_post_srq_recv(struct ibv_srq *ibsrq, struct ibv_recv_wr *wr,
struct ibv_ah *ipath_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
{
struct ibv_ah *ah;
+ struct ibv_create_ah_resp resp;
ah = malloc(sizeof *ah);
if (ah == NULL)
return NULL;
- if (ibv_cmd_create_ah(pd, ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
diff --git a/providers/ocrdma/ocrdma_verbs.c b/providers/ocrdma/ocrdma_verbs.c
index 7e066dc..dce833b 100644
--- a/providers/ocrdma/ocrdma_verbs.c
+++ b/providers/ocrdma/ocrdma_verbs.c
@@ -2099,6 +2099,7 @@ struct ibv_ah *ocrdma_create_ah(struct ibv_pd *ibpd, struct ibv_ah_attr *attr)
int ahtbl_idx;
struct ocrdma_pd *pd;
struct ocrdma_ah *ah;
+ struct ibv_create_ah_resp resp;
pd = get_ocrdma_pd(ibpd);
ah = malloc(sizeof *ah);
@@ -2111,7 +2112,8 @@ struct ibv_ah *ocrdma_create_ah(struct ibv_pd *ibpd, struct ibv_ah_attr *attr)
if (ahtbl_idx < 0)
goto tbl_err;
attr->dlid = ahtbl_idx;
- status = ibv_cmd_create_ah(ibpd, &ah->ibv_ah, attr);
+ memset(&resp, 0, sizeof(resp));
+ status = ibv_cmd_create_ah(ibpd, &ah->ibv_ah, attr, &resp, sizeof(resp));
if (status)
goto cmd_err;
diff --git a/providers/rxe/rxe.c b/providers/rxe/rxe.c
index d23ef3d..1dd30ea 100644
--- a/providers/rxe/rxe.c
+++ b/providers/rxe/rxe.c
@@ -781,6 +781,7 @@ static struct ibv_ah *rxe_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
struct rxe_ah *ah;
struct rxe_av *av;
union ibv_gid sgid;
+ struct ibv_create_ah_resp resp;
err = ibv_query_gid(pd->context, attr->port_num, attr->grh.sgid_index,
&sgid);
@@ -803,7 +804,8 @@ static struct ibv_ah *rxe_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
rdma_gid2ip(&av->sgid_addr._sockaddr, &sgid);
rdma_gid2ip(&av->dgid_addr._sockaddr, &attr->grh.dgid);
- if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V1 rdma-core 0/2] Optimize RoCE address handle creation for userspace
From: Yishai Hadas @ 2016-12-04 15:53 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Sending V1 to address a note coming from Jason re symbol versioning,
details below.
This patch set from Moni is the supplementary part of the kernel series that
was lastly sent upstream.
Creating a UD address handler when link layer is Ethernet requires resolving
the remote L3 address (GID) to a L2 address (MAC/VLAN).
Until now the way to resolve GID (which is the remote IP or a function of it)
to a MAC was with an interface supplied by libnl. The implementation of this
interface is heavy and fails on large load of requests to create an address
handle.
This series of patches enables user drivers that care for it to optimize the
resolution of L3 to L2 addresses with uverbs interface.
The series was tested successfully with CX4 in both kernel which doesn't have
this support and with a kernel which includes the above support.
Pull request was sent:
https://github.com/linux-rdma/rdma-core/pull/42
Yishai
Changes from v0:
ibv_cmd_create_ah symbol version was changed to a newer version to prevent
legacy providers from being loaded when they are working with new libibverbs.
This behavior is better than getting some random error upon calling to
ibv_cmd_create_ah from a legacy provider which is out of the consolidate rdma
tree.
Test results:
------------------------------------------------------------------------------
Upon testing the above use case the provider couldn't be loaded as expected,
"libibverbs: Warning: couldn't load driver 'libmlx5-rdmav2.so':
libmlx5-rdmav2.so: cannot open shared object file: No such file or directory"
Run with strace, can see that as part of the dynamic linking loader flow (i.e.
dlopen) libmlx5-rdmav2.so was opened successfully from its default location
(i.e. /usr/lib64/libibverbs/), however, it was just later closed, apparently as
of the missing symbol, as expected. Later on the linker looked for other
locations for same library (e.g. /lib64/tls/x86_64, /lib64/tls) but didn't
find, so the flow ended up with the above error message from libibverbs.
>From strace:
open("/usr/lib64/libibverbs/libmlx5-rdmav2.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20(\0\0\0\0\0\0"., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=555006, ...}) = 0
mmap(NULL, 2192400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f910ba21000
mprotect(0x7f910ba38000, 2093056, PROT_NONE) = 0
mmap(0x7f910bc37000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x16000) = 0x7f910bc37000
close(3) = 0
munmap(0x7f910ba21000, 2192400) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=143158, ...}) = 0
mmap(NULL, 143158, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f910e5d0000
close(3) = 0
open("/lib64/tls/x86_64/libmlx5-rdmav2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
...
-------------------------------------------------------------------------------
Moni Shoua (2):
ibverbs: Allow vendor data response in create_ah command
mlx5: Create and destroy address handle with kernel assistance
libibverbs/cmd.c | 11 ++++++-----
libibverbs/driver.h | 4 +++-
libibverbs/libibverbs.map | 6 +++++-
providers/hfi1verbs/verbs.c | 4 +++-
providers/ipathverbs/verbs.c | 4 +++-
providers/mlx5/mlx5-abi.h | 7 +++++++
providers/mlx5/mlx5.h | 2 ++
providers/mlx5/verbs.c | 28 +++++++++++++++++++++++-----
providers/ocrdma/ocrdma_verbs.c | 4 +++-
providers/rxe/rxe.c | 4 +++-
10 files changed, 58 insertions(+), 16 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Stephen Bates @ 2016-12-04 13:23 UTC (permalink / raw)
To: Haggai Eran
Cc: John.Bridgman-5C7GfCeVMHo@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
Felix.Kuehling-5C7GfCeVMHo@public.gmane.org,
serguei.sagalovitch-5C7GfCeVMHo@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Paul.Blinzer-5C7GfCeVMHo@public.gmane.org, Jason Gunthorpe,
ben.sander-5C7GfCeVMHo@public.gmane.org,
Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org, Max Gurtovoy,
christian.koenig-5C7GfCeVMHo@public.gmane.org,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <c1ead8a0-6850-fc84-2793-b986f5c1f726-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Hi All
This has been a great thread (thanks to Alex for kicking it off) and I
wanted to jump in and maybe try and put some summary around the
discussion. I also wanted to propose we include this as a topic for LFS/MM
because I think we need more discussion on the best way to add this
functionality to the kernel.
As far as I can tell the people looking for P2P support in the kernel fall
into two main camps:
1. Those who simply want to expose static BARs on PCIe devices that can be
used as the source/destination for DMAs from another PCIe device. This
group has no need for memory invalidation and are happy to use
physical/bus addresses and not virtual addresses.
2. Those who want to support devices that suffer from occasional memory
pressure and need to invalidate memory regions from time to time. This
camp also would like to use virtual addresses rather than physical ones to
allow for things like migration.
I am wondering if people agree with this assessment?
I think something like the iopmem patches Logan and I submitted recently
come close to addressing use case 1. There are some issues around
routability but based on feedback to date that does not seem to be a
show-stopper for an initial inclusion.
For use-case 2 it looks like there are several options and some of them
(like HMM) have been around for quite some time without gaining
acceptance. I think there needs to be more discussion on this usecase and
it could be some time before we get something upstreamable.
I for one, would really like to see use case 1 get addressed soon because
we have consumers for it coming soon in the form of CMBs for NVMe devices.
Long term I think Jason summed it up really well. CPU vendors will put
high-speed, open, switchable, coherent buses on their processors and all
these problems will vanish. But I ain't holding my breathe for that to
happen ;-).
Cheers
Stephen
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Stephen Bates @ 2016-12-04 13:06 UTC (permalink / raw)
To: Haggai Eran
Cc: John.Bridgman-5C7GfCeVMHo@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
Felix.Kuehling-5C7GfCeVMHo@public.gmane.org,
serguei.sagalovitch-5C7GfCeVMHo@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Paul.Blinzer-5C7GfCeVMHo@public.gmane.org, Jason Gunthorpe,
ben.sander-5C7GfCeVMHo@public.gmane.org,
Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org, Max Gurtovoy,
christian.koenig-5C7GfCeVMHo@public.gmane.org,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <c1ead8a0-6850-fc84-2793-b986f5c1f726-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>
>> The NVMe fabrics stuff could probably make use of this. It's an
>> in-kernel system to allow remote access to an NVMe device over RDMA. So
>> they ought to be able to optimize their transfers by DMAing directly to
>> the NVMe's CMB -- no userspace interface would be required but there
>> would need some kernel infrastructure.
>
> Yes, that's what I was thinking. The NVMe/f driver needs to map the CMB
> for RDMA. I guess if it used ZONE_DEVICE like in the iopmem patches it
> would be relatively easy to do.
>
Haggai, yes that was one of the use cases we considered when we put
together the patchset.
^ permalink raw reply
* RE: [PATCH rdma-next V1 2/4] IB/core: Support rate limit for packet pacing
From: Liran Liss @ 2016-12-04 11:53 UTC (permalink / raw)
To: Leon Romanovsky, Hefty, Sean
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bodong Wang,
Rony Efraim
In-Reply-To: <20161202143957.GF4497-2ukJVAZIZ/Y@public.gmane.org>
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Leon Romanovsky
>
> On Thu, Dec 01, 2016 at 07:40:44PM +0000, Hefty, Sean wrote:
> > > enum ib_qp_state {
> > > @@ -1151,6 +1152,7 @@ struct ib_qp_attr {
> > > u8 rnr_retry;
> > > u8 alt_port_num;
> > > u8 alt_timeout;
> > > + u32 rate_limit;
> > > };
> >
> > And I still disagree with this approach, as there is already an existing field in the
> API that limits rate.
>
> Hi Sean,
>
> We would like to elaborate more on the subject, and we need your help here.
> Our cover letter [1] has description why the existing field is not enough. Can you
> write a little bit more why you didn't like the proposed approach to an existing
> and real problem?
>
Clearly, we need a new field that is greater than 8 bits that uses different encoding (actual rate rather than a predefined enumeration of values).
However, this is not only a new field - this rate is also conceptually different than AH static rate:
1) It is not related to the fabric path.
2) It is determined by the application rather than the fabric.
3) It needs to apply to QPs that don't use AH (raw Ethernet QPs)
Of course, we might require raw Ethernet QPs to use an AH just for the sake of rate-limiting.
But 1) + 2) indicate that this should be a concept orthogonal to network paths. In fact, it could apply to RC and UD QPs as well.
In addition, if we implement full connection establishment in the kernel (i.e., the static_rate field is filled in the kernel), we would still like to allow applications to further restrict their rate using a different component mask.
--Liran
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Haggai Eran @ 2016-12-04 7:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John.Bridgman-5C7GfCeVMHo@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
Felix.Kuehling-5C7GfCeVMHo@public.gmane.org,
serguei.sagalovitch-5C7GfCeVMHo@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Paul.Blinzer-5C7GfCeVMHo@public.gmane.org,
ben.sander-5C7GfCeVMHo@public.gmane.org,
Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org, Max Gurtovoy,
christian.koenig-5C7GfCeVMHo@public.gmane.org,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161130162353.GA24639-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 11/30/2016 6:23 PM, Jason Gunthorpe wrote:
>> and O_DIRECT operations that access GPU memory.
> This goes through user space so there is still a VMA..
>
>> Also, HMM's migration between two GPUs could use peer to peer in the
>> kernel, although that is intended to be handled by the GPU driver if
>> I understand correctly.
> Hum, presumably these migrations are VMA backed as well...
I guess so.
>>> Presumably in-kernel could use a vmap or something and the same basic
>>> flow?
>> I think we can achieve the kernel's needs with ZONE_DEVICE and DMA-API support
>> for peer to peer. I'm not sure we need vmap. We need a way to have a scatterlist
>> of MMIO pfns, and ZONE_DEVICE allows that.
> Well, if there is no virtual map then we are back to how do you do
> migrations and other things people seem to want to do on these
> pages. Maybe the loose 'struct page' flow is not for those users.
I was thinking that kernel use cases would disallow migration, similar to how
non-ODP MRs would work. Either they are short-lived (like an O_DIRECT transfer)
or they can be longed lived but non-migratable (like perhaps a CMB staging buffer).
> But I think if you want kGPU or similar then you probably need vmaps
> or something similar to represent the GPU pages in kernel memory.
Right, although sometimes the GPU pages are simply inaccessible to the CPU.
In any case, I haven't thought about kGPU as a use-case.
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Haggai Eran @ 2016-12-04 7:42 UTC (permalink / raw)
To: Logan Gunthorpe, Jason Gunthorpe
Cc: John.Bridgman-5C7GfCeVMHo@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
Felix.Kuehling-5C7GfCeVMHo@public.gmane.org,
serguei.sagalovitch-5C7GfCeVMHo@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Paul.Blinzer-5C7GfCeVMHo@public.gmane.org,
ben.sander-5C7GfCeVMHo@public.gmane.org,
Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org, Max Gurtovoy,
christian.koenig-5C7GfCeVMHo@public.gmane.org,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5f5b7989-84f5-737e-47c8-831f752d6280-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On 11/30/2016 8:01 PM, Logan Gunthorpe wrote:
>
>
> On 30/11/16 09:23 AM, Jason Gunthorpe wrote:
>>> Two cases I can think of are RDMA access to an NVMe device's controller
>>> memory buffer,
>>
>> I'm not sure on the use model there..
>
> The NVMe fabrics stuff could probably make use of this. It's an
> in-kernel system to allow remote access to an NVMe device over RDMA. So
> they ought to be able to optimize their transfers by DMAing directly to
> the NVMe's CMB -- no userspace interface would be required but there
> would need some kernel infrastructure.
Yes, that's what I was thinking. The NVMe/f driver needs to map the CMB for
RDMA. I guess if it used ZONE_DEVICE like in the iopmem patches it would be
relatively easy to do.
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Haggai Eran @ 2016-12-04 7:33 UTC (permalink / raw)
To: Serguei Sagalovitch, Jason Gunthorpe
Cc: John.Bridgman-5C7GfCeVMHo@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
Felix.Kuehling-5C7GfCeVMHo@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Paul.Blinzer-5C7GfCeVMHo@public.gmane.org,
ben.sander-5C7GfCeVMHo@public.gmane.org,
Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org, Max Gurtovoy,
christian.koenig-5C7GfCeVMHo@public.gmane.org,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <2560aab2-426c-6e58-cb4f-77ec76e0c941-5C7GfCeVMHo@public.gmane.org>
On 11/30/2016 7:28 PM, Serguei Sagalovitch wrote:
> On 2016-11-30 11:23 AM, Jason Gunthorpe wrote:
>>> Yes, that sounds fine. Can we simply kill the process from the GPU driver?
>>> Or do we need to extend the OOM killer to manage GPU pages?
>> I don't know..
> We could use send_sig_info to send signal from kernel to user space. So theoretically GPU driver
> could issue KILL signal to some process.
>
>> On Wed, Nov 30, 2016 at 12:45:58PM +0200, Haggai Eran wrote:
>>> I think we can achieve the kernel's needs with ZONE_DEVICE and DMA-API support
>>> for peer to peer. I'm not sure we need vmap. We need a way to have a scatterlist
>>> of MMIO pfns, and ZONE_DEVICE allows that.
> I do not think that using DMA-API as it is is the best solution (at least in the current form):
>
> - It deals with handles/fd for the whole allocation but client could/will use sub-allocation as
> well as theoretically possible to "merge" several allocations in one from GPU perspective.
> - It require knowledge to export but because "sharing" is controlled from user space it
> means that we must "export" all allocation by default
> - It deals with 'fd'/handles but user application may work with addresses/pointers.
Aren't you confusing DMABUF and DMA-API? DMA-API is how you program the IOMMU (dma_map_page/dma_map_sg/etc.).
The comment above is just about the need to extend this API to allow mapping peer device pages to bus addresses.
In the past I sent an RFC for using DMABUF for peer to peer. I think it had some
advantages for legacy devices. I agree that working with addresses and pointers through
something like HMM/ODP is much more flexible and easier to program from user-space.
For legacy, DMABUF would have allowed you a way to pin the pages so the GPU knows not to
move them. However, that can probably also be achieved simply via the reference count
on ZONE_DEVICE pages. The other nice thing about DMABUF is that it migrate the buffer
itself during attachment according to the requirements of the device that is attaching,
so you can automatically decide in the exporter whether to use p2p or a staging buffer.
>
> Also current DMA-API force each time to do all DMA table programming unrelated if
> location was changed or not. With vma / mmu we are able to install notifier to intercept
> changes in location and update translation tables only as needed (we do not need to keep
> get_user_pages() lock).
I agree.
^ permalink raw reply
* Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Leon Romanovsky @ 2016-12-04 7:17 UTC (permalink / raw)
To: Pan Bian
Cc: Yishai Hadas, Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pan Bian
In-Reply-To: <1480833938-6284-1-git-send-email-bianpan201603-9Onoh4P/yGk@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Sun, Dec 04, 2016 at 02:45:38PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
>
> If uhw->inlen is non-zero, the value of variable err is 0 if the copy
> succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
> will return 0 to the callers. As a result, the callers cannot detect the
> errors. This patch fixes the bug, assign "-ENOMEM" to err before the
> NULL pointer checks, and remove the initialization of err at the
> beginning.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
> Signed-off-by: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Mitesh Ahuja from emulex maintainers
From: Leon Romanovsky @ 2016-12-04 6:47 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
selvin.xavier-1wcpHE2jlwO1Z/+hSey0Gg,
devesh.sharma-1wcpHE2jlwO1Z/+hSey0Gg
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Remove Mitesh Ahuja <mitesh.ahuja-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org> from
maintainers file. This email address seems not active
and causes to mail bounces during submissions.
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
The mail system
<mitesh.ahuja-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org>: host aspmx.l.google.com[74.125.199.27] said:
550-5.1.1 The email account that you tried to reach does not exist. Please
try 550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1
https://support.google.com/mail/?p=NoSuchUser f14si10627738plm.266 - gsmtp
(in reply to RCPT TO command)
Final-Recipient: rfc822; mitesh.ahuja-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org
Original-Recipient: rfc822;mitesh.ahuja-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; aspmx.l.google.com
Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to
reach does
not exist. Please try 550-5.1.1 double-checking the recipient's email
address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1
https://support.google.com/mail/?p=NoSuchUser f14si10627738plm.266 - gsmtp
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d414840..37121a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10919,7 +10919,6 @@ F: drivers/net/ethernet/emulex/benet/
EMULEX ONECONNECT ROCE DRIVER
M: Selvin Xavier <selvin.xavier-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org>
M: Devesh Sharma <devesh.sharma-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org>
-M: Mitesh Ahuja <mitesh.ahuja-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org>
L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
W: http://www.emulex.com
S: Supported
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Pan Bian @ 2016-12-04 6:45 UTC (permalink / raw)
To: Leon Romanovsky, Yishai Hadas, Doug Ledford, Sean Hefty,
Hal Rosenstock, linux-rdma
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
If uhw->inlen is non-zero, the value of variable err is 0 if the copy
succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
will return 0 to the callers. As a result, the callers cannot detect the
errors. This patch fixes the bug, assign "-ENOMEM" to err before the
NULL pointer checks, and remove the initialization of err at the
beginning.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index b597e82..a87c395 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -430,7 +430,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
struct mlx4_ib_dev *dev = to_mdev(ibdev);
struct ib_smp *in_mad = NULL;
struct ib_smp *out_mad = NULL;
- int err = -ENOMEM;
+ int err;
int have_ib_ports;
struct mlx4_uverbs_ex_query_device cmd;
struct mlx4_uverbs_ex_query_device_resp resp = {.comp_mask = 0};
@@ -455,6 +455,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
sizeof(resp.response_length);
in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL);
out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
+ err = -ENOMEM;
if (!in_mad || !out_mad)
goto out;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] infiniband: hw: ocrdma: fix bad initialization
From: Leon Romanovsky @ 2016-12-04 6:20 UTC (permalink / raw)
To: Pan Bian
Cc: Selvin Xavier, Devesh Sharma, Mitesh Ahuja, Doug Ledford,
Sean Hefty, Hal Rosenstock, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pan Bian
In-Reply-To: <1480770621-6249-1-git-send-email-bianpan201602-9Onoh4P/yGk@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
On Sat, Dec 03, 2016 at 09:10:21PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
>
> In function ocrdma_mbx_create_ah_tbl(), returns the value of status on
> errors. However, because status is initialized with 0, 0 will be
> returned even if on error paths. This patch initialize status with
> "-ENOMEM".
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188831
>
> Signed-off-by: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Leon Romanovsky @ 2016-12-04 6:15 UTC (permalink / raw)
To: Pan Bian
Cc: Yishai Hadas, Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pan Bian
In-Reply-To: <1480830544-5002-1-git-send-email-bianpan201603-9Onoh4P/yGk@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On Sun, Dec 04, 2016 at 01:49:04PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
>
> If uhw->inlen is non-zero, the value of variable err is 0 if the copy
> succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
> will return 0 to the callers. As a result, the callers cannot detect the
> errors. This patch fixes the bug, assigning "-ENOMEM" to err before
> the NULL pointer checks.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
>
> Signed-off-by: Pan Bian <bianpan2016-9Onoh4P/yGk@public.gmane.org>
> ---
> drivers/infiniband/hw/mlx4/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
> index b597e82..f6c5158 100644
> --- a/drivers/infiniband/hw/mlx4/main.c
> +++ b/drivers/infiniband/hw/mlx4/main.c
> @@ -455,6 +455,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
> sizeof(resp.response_length);
> in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL);
> out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
> + err = -ENOMEM;
> if (!in_mad || !out_mad)
> goto out;
In such case, the err initialization at the beginning of
mlx4_ib_query_device function is not necessary. Can you please remove it?
Besides that, look good.
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Pan Bian @ 2016-12-04 5:49 UTC (permalink / raw)
To: Yishai Hadas, Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
If uhw->inlen is non-zero, the value of variable err is 0 if the copy
succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
will return 0 to the callers. As a result, the callers cannot detect the
errors. This patch fixes the bug, assigning "-ENOMEM" to err before
the NULL pointer checks.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/infiniband/hw/mlx4/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index b597e82..f6c5158 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -455,6 +455,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
sizeof(resp.response_length);
in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL);
out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
+ err = -ENOMEM;
if (!in_mad || !out_mad)
goto out;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] i40iw: Remove workaround for pre-production errata
From: Doug Ledford @ 2016-12-03 20:59 UTC (permalink / raw)
To: Henry Orosco
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20161019203332.7972-1-henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]
On Wed, 2016-10-19 at 15:33 -0500, Henry Orosco wrote:
> Pre-production silicon incorrectly truncates 4 bytes of the MPA
> packet in UDP loopback case. Remove the workaround as it is no
> longer necessary.
>
> Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Thanks, applied. And, in order to save time, I also applied these
other patches:
[PATCH] i40iw: Set MAX IRD, MAX ORD size to max supported value
[PATCH] i40iw: Fix for LAN handler removal
[PATCH] i40iw: Optimize inline data copy
[PATCH] i40iw: Query device accounts for internal rsrc
[PATCH] i40iw: Remove checks for more than 48 bytes inline data
[PATCH] i40iw: Remove NULL check for cm_node->iwdev
[PATCH] i40iw: Use actual page size
[PATCH] i40iw: Use runtime check for IS_ENABLED(CONFIG_IPV6)
[PATCH] i40iw: Use vector when creating CQs
[PATCH] i40iw: Remove check on return from device_init_pestat()
This one had some patch issues I fixed up, you might want to
double check it
[PATCH] i40iw: Remove variable flush_code and check to set qp->sq_flush
[PATCH] i40iw: Correct values for max_recv_sge, max_send_sge
[PATCH V2] i40iw: Convert page_size to encoded value
[PATCH] i40iw: Fix incorrect assignment of SQ head
[PATCH] i40iw: Utilize physically mapped memory regions
[PATCH] i40iw: Add 2MB page support
[PATCH] i40iw: Add missing cleanup on device close
[PATCH] i40iw: Add IP addr handling on netdev events
[PATCH] i40iw: Replace list_for_each_entry macro with safe version
[PATCH] i40iw: Add NULL check for ibqp event handler
[PATCH] i40iw: Fill in IRD value when on connect request
[PATCH] i40iw: Correctly fail loopback connection if no listener
[PATCH] i40iw: Code cleanup, remove check of PBLE pages
[PATCH] i40iw: Add request for reset on CQP timeout
[PATCH] i40iw: Set TOS field in IP header
For future release, please batch your patches up and send them as a
series. Tracking down and dealing with singleton patches when you have
an entire truckload that needs processed greatly increases the
processing time required.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i40iw: Enable message packing
From: Doug Ledford @ 2016-12-03 20:52 UTC (permalink / raw)
To: Henry Orosco
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20161019203253.14316-1-henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Wed, 2016-10-19 at 15:32 -0500, Henry Orosco wrote:
> Remove the parameter to disable message packing and
> always enable it.
>
> Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V3] i40iw: Add Quality of Service support
From: Doug Ledford @ 2016-12-03 20:51 UTC (permalink / raw)
To: Henry Orosco
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20161011021210.21776-1-henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Mon, 2016-10-10 at 21:12 -0500, Henry Orosco wrote:
> Add support for QoS on QPs. Upon device initialization,
> a map is created from user priority to queue set
> handles. On QP creation, use ToS to look up the queue
> set handle for use with the QP.
>
> Signed-off-by: Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update Intel RDMA RNIC driver maintainers
From: Doug Ledford @ 2016-12-03 20:49 UTC (permalink / raw)
To: Faisal Latif, Leon Romanovsky
Cc: Henry Orosco, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
In-Reply-To: <20161006192544.GA14272@flatif-MOBL1>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
On Thu, 2016-10-06 at 14:25 -0500, Faisal Latif wrote:
> On Thu, Oct 06, 2016 at 10:10:23AM +0300, Leon Romanovsky wrote:
> >
> > On Wed, Oct 05, 2016 at 10:35:30AM -0500, Faisal Latif wrote:
> > >
> > > On Wed, Oct 05, 2016 at 07:30:54AM -0700, Henry Orosco wrote:
> > > Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > >
> > > > ---
> > > > MAINTAINERS | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > --
> > > > 2.8.3
> > >
> > > Acked-by: Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > Faisal,
> >
> > Do you really expect to see 9 people in TO and CC field for every
> > patch in i40iw area?
> > 3 comes from drivers/infiniband/
> > 6 comes from drivers/infiniband/hw/i40iw/
> >
> > IMHO, it is worth to shrink the list and limit it to the active
> > developers.
> >
> > Thanks
>
> Doug,
>
> Please drop this patch and we are going over the sugestion made by
> Leon to reduce
> the list. We will have another patch to reduce the list in the
> Maintainer's file.
Dropped as requested.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/hns: Move HNS RoCE user vendor structures
From: Doug Ledford @ 2016-12-03 19:24 UTC (permalink / raw)
To: oulijun, Leon Romanovsky, xavier.huwei-hv44wF8Li93QT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58097F0D.2040001-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3943 bytes --]
On Fri, 2016-10-21 at 10:35 +0800, oulijun wrote:
> 在 2016/10/20 1:13, Leon Romanovsky 写道:
> >
> > This patch moves HNS vendor's specific structures to
> > common UAPI folder which will be visible to all consumers.
> >
> > Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > drivers/infiniband/hw/hns/hns_roce_cq.c |
> > 2 +-
> > drivers/infiniband/hw/hns/hns_roce_main.c |
> > 2 +-
> > drivers/infiniband/hw/hns/hns_roce_qp.c |
> > 2 +-
> > include/uapi/rdma/Kbuild |
> > 1 +
> > .../hw/hns/hns_roce_user.h => include/uapi/rdma/hns-abi.h |
> > 9 +++++----
> > 5 files changed, 9 insertions(+), 7 deletions(-)
> > rename drivers/infiniband/hw/hns/hns_roce_user.h =>
> > include/uapi/rdma/hns-abi.h (94%)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_cq.c
> > b/drivers/infiniband/hw/hns/hns_roce_cq.c
> > index 0973659..d8a1764 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_cq.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_cq.c
> > @@ -35,7 +35,7 @@
> > #include "hns_roce_device.h"
> > #include "hns_roce_cmd.h"
> > #include "hns_roce_hem.h"
> > -#include "hns_roce_user.h"
> > +#include <rdma/hns-abi.h>
> > #include "hns_roce_common.h"
> >
> > static void hns_roce_ib_cq_comp(struct hns_roce_cq *hr_cq)
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> > b/drivers/infiniband/hw/hns/hns_roce_main.c
> > index 764e35a..354f100 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > @@ -37,7 +37,7 @@
> > #include <rdma/ib_user_verbs.h>
> > #include "hns_roce_common.h"
> > #include "hns_roce_device.h"
> > -#include "hns_roce_user.h"
> > +#include <rdma/hns-abi.h>
> > #include "hns_roce_hem.h"
> >
> > /**
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c
> > b/drivers/infiniband/hw/hns/hns_roce_qp.c
> > index e86dd8d..5d13b6b 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_qp.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
> > @@ -37,7 +37,7 @@
> > #include "hns_roce_common.h"
> > #include "hns_roce_device.h"
> > #include "hns_roce_hem.h"
> > -#include "hns_roce_user.h"
> > +#include <rdma/hns-abi.h>
> >
> > #define SQP_NUM (2 *
> > HNS_ROCE_MAX_PORTS)
> >
> > diff --git a/include/uapi/rdma/Kbuild b/include/uapi/rdma/Kbuild
> > index f14ab7f..b54f10d 100644
> > --- a/include/uapi/rdma/Kbuild
> > +++ b/include/uapi/rdma/Kbuild
> > @@ -14,3 +14,4 @@ header-y += mlx5-abi.h
> > header-y += mthca-abi.h
> > header-y += nes-abi.h
> > header-y += ocrdma-abi.h
> > +header-y += hns-abi.h
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_user.h
> > b/include/uapi/rdma/hns-abi.h
> > similarity index 94%
> > rename from drivers/infiniband/hw/hns/hns_roce_user.h
> > rename to include/uapi/rdma/hns-abi.h
> > index a28f761..5d74019 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_user.h
> > +++ b/include/uapi/rdma/hns-abi.h
> > @@ -30,8 +30,10 @@
> > * SOFTWARE.
> > */
> >
> > -#ifndef _HNS_ROCE_USER_H
> > -#define _HNS_ROCE_USER_H
> > +#ifndef HNS_ABI_USER_H
> > +#define HNS_ABI_USER_H
> > +
> > +#include <linux/types.h>
> >
> > struct hns_roce_ib_create_cq {
> > __u64 buf_addr;
> > @@ -49,5 +51,4 @@ struct hns_roce_ib_create_qp {
> > struct hns_roce_ib_alloc_ucontext_resp {
> > __u32 qp_tab_size;
> > };
> > -
> > -#endif /*_HNS_ROCE_USER_H */
> > +#endif /* HNS_ABI_USER_H */
> >
> ok, thanks!
>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next V1 06/17] IB/hfi1: Remove debug prints after allocation failure
From: Doug Ledford @ 2016-12-03 18:31 UTC (permalink / raw)
To: Dalessandro, Dennis, leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1478923438.2458.9.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
On Sat, 2016-11-12 at 04:04 +0000, Dalessandro, Dennis wrote:
> On Thu, 2016-11-03 at 16:44 +0200, Leon Romanovsky wrote:
> >
> > The prints after [k|v][m|z|c]alloc() functions are not needed,
> > because in case of failure, allocator will print their internal
> > error prints anyway.
> >
> > Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Acked-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hi Denny,
Your Ack was not recorded by patchworks. Something about the way it
was signed or something like that. All patchworks saw was what looked
like an encyrpted or signed block, with no legible text.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next V1 00/17] Remove debug prints after allocation failure
From: Doug Ledford @ 2016-12-03 18:30 UTC (permalink / raw)
To: Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sagi Grimberg, Ira Weiny,
Steve Wise, Bart Van Assche, Faisal Latif, Matan Barak,
Moni Shoua, Mike Marciniszyn, Dennis Dalessandro a, Dave Goodell
In-Reply-To: <1478184265-9620-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
On Thu, 2016-11-03 at 16:44 +0200, Leon Romanovsky wrote:
> Hi Doug and all,
>
> This is semantic cleanup of infiniband stack from printks immediately
> after allocation failure. It doesn't get rid from all printks, but
> only from
> the ones which were found by the following grep construction.
>
> ➜ linux-rdma git:(topic/clean-alloc-prints) grep -rI
> "[k|v][m|z|c]alloc(" drivers/infiniband/* -A5 | grep "n\""
>
> The patchset consists from the 16 almost identical patches and from
> one fix
> which was discovered during the cleanup work.
>
> The fix is presented in the patch "IB/core: Release allocated memory
> in cache setup failure"
>
> Available in the "topic/clean-alloc-prints" topic branch of this git
> repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git
> Or for browsing:
> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/
> ?h=topic/clean-alloc-prints
>
> CC: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
> CC: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> CC: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> CC: Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> CC: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> CC: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>a
> CC: Dave Goodell <dgoodell-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
>
> Changes v0 -> v1:
> * Patch 17: Return brackets removed by mistake.
Sorry, I replied to the v0 thread when in fact I applied the v1
patchset.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 00/17] Remove debug prints after allocation failure
From: Doug Ledford @ 2016-12-03 18:21 UTC (permalink / raw)
To: Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sagi Grimberg, Ira Weiny,
Steve Wise, Bart Van Assche, Faisal Latif, Matan Barak,
Moni Shoua, Mike Marciniszyn, Dennis Dalessandro a, Dave Goodell
In-Reply-To: <1478149353-12125-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]
On Thu, 2016-11-03 at 07:02 +0200, Leon Romanovsky wrote:
> Hi Doug and all,
>
> This is semantic cleanup of infiniband stack from printks immediately
> after allocation failure. It doesn't get rid from all printks, but
> only from
> the ones which were found by the following grep construction.
>
> ➜ linux-rdma git:(topic/clean-alloc-prints) grep -rI
> "[k|v][m|z|c]alloc(" drivers/infiniband/* -A5 | grep "n\""
>
> The patchset consists from the 16 almost identical patches and from
> one fix
> which was discovered during the cleanup work.
>
> The fix is presented in the patch "IB/core: Release allocated memory
> in cache setup failure"
>
> Available in the "topic/clean-alloc-prints" topic branch of this git
> repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git
> Or for browsing:
> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/
> ?h=topic/clean-alloc-prints
>
> CC: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
> CC: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> CC: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> CC: Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> CC: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> CC: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> CC: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>a
> CC: Dave Goodell <dgoodell-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
>
> Leon Romanovsky (17):
> IB/mad: Remove debug prints after allocation failure
> IB/core: Remove debug prints after allocation failure
> IB/core: Release allocated memory in cache setup failure
> IB/mlx4: Remove debug prints after allocation failure
> IB/mlx5: Remove debug prints after allocation failure
> IB/hfi1: Remove debug prints after allocation failure
> IB/cxgb3: Remove debug prints after allocation failure
> IB/cxgb4: Remove debug prints after allocation failure
> IB/i40iw: Remove debug prints after allocation failure
> IB/qib: Remove debug prints after allocation failure
> IB/nes: Remove debug prints after allocation failure
> IB/mthca: Remove debug prints after allocation failure
> IB/usninc: Remove and fix debug prints after allocation failure
> IB/ocrdma: Remove and fix debug prints after allocation failure
> IB/rxe: Remove and fix debug prints after allocation failure
> IB/isert: Remove and fix debug prints after allocation failure
> IB/ipoib: Remove and fix debug prints after allocation failure
>
Thanks, series applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox