* [PATCH 2/5] mlx5: Remove a set-but-not-used variable
From: Bart Van Assche @ 2016-12-06 1:18 UTC (permalink / raw)
To: Doug Ledford
Cc: Eli Cohen, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9ff07804-492c-c67a-e729-b31e0f863027-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
This has been detected by building the mlx5 driver with W=1.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx5/qp.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index d1e921816bfe..b2c6c13d44ac 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -2577,7 +2577,6 @@ static int __mlx5_ib_modify_qp(struct ib_qp *ibqp,
struct mlx5_ib_port *mibport = NULL;
enum mlx5_qp_state mlx5_cur, mlx5_new;
enum mlx5_qp_optpar optpar;
- int sqd_event;
int mlx5_st;
int err;
u16 op;
@@ -2724,12 +2723,6 @@ static int __mlx5_ib_modify_qp(struct ib_qp *ibqp,
if (qp->rq.wqe_cnt && cur_state == IB_QPS_RESET && new_state == IB_QPS_INIT)
context->db_rec_addr = cpu_to_be64(qp->db.dma);
- if (cur_state == IB_QPS_RTS && new_state == IB_QPS_SQD &&
- attr_mask & IB_QP_EN_SQD_ASYNC_NOTIFY && attr->en_sqd_async_notify)
- sqd_event = 1;
- else
- sqd_event = 0;
-
if (cur_state == IB_QPS_RESET && new_state == IB_QPS_INIT) {
u8 port_num = (attr_mask & IB_QP_PORT ? attr->port_num :
qp->port) - 1;
--
2.11.0
--
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 3/5] mlx5: Avoid that sparse complains about dubious !x & y expressions
From: Bart Van Assche @ 2016-12-06 1:19 UTC (permalink / raw)
To: Doug Ledford
Cc: Eli Cohen, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9ff07804-492c-c67a-e729-b31e0f863027-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
This patch does not change any functionality.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx5/mr.c | 20 ++++++++++----------
drivers/net/ethernet/mellanox/mlx5/core/srq.c | 8 ++++----
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 4e9012463c37..3a5707e0d82a 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -687,10 +687,10 @@ struct ib_mr *mlx5_ib_get_dma_mr(struct ib_pd *pd, int acc)
mkc = MLX5_ADDR_OF(create_mkey_in, in, memory_key_mkey_entry);
MLX5_SET(mkc, mkc, access_mode, MLX5_MKC_ACCESS_MODE_PA);
- MLX5_SET(mkc, mkc, a, !!(acc & IB_ACCESS_REMOTE_ATOMIC));
- MLX5_SET(mkc, mkc, rw, !!(acc & IB_ACCESS_REMOTE_WRITE));
- MLX5_SET(mkc, mkc, rr, !!(acc & IB_ACCESS_REMOTE_READ));
- MLX5_SET(mkc, mkc, lw, !!(acc & IB_ACCESS_LOCAL_WRITE));
+ MLX5_SET(mkc, mkc, a, (acc & IB_ACCESS_REMOTE_ATOMIC) != 0);
+ MLX5_SET(mkc, mkc, rw, (acc & IB_ACCESS_REMOTE_WRITE) != 0);
+ MLX5_SET(mkc, mkc, rr, (acc & IB_ACCESS_REMOTE_READ) != 0);
+ MLX5_SET(mkc, mkc, lw, (acc & IB_ACCESS_LOCAL_WRITE) != 0);
MLX5_SET(mkc, mkc, lr, 1);
MLX5_SET(mkc, mkc, length64, 1);
@@ -1093,14 +1093,14 @@ static struct mlx5_ib_mr *reg_create(struct ib_mr *ibmr, struct ib_pd *pd,
/* The pg_access bit allows setting the access flags
* in the page list submitted with the command. */
- MLX5_SET(create_mkey_in, in, pg_access, !!(pg_cap));
+ MLX5_SET(create_mkey_in, in, pg_access, pg_cap != 0);
mkc = MLX5_ADDR_OF(create_mkey_in, in, memory_key_mkey_entry);
MLX5_SET(mkc, mkc, access_mode, MLX5_MKC_ACCESS_MODE_MTT);
- MLX5_SET(mkc, mkc, a, !!(access_flags & IB_ACCESS_REMOTE_ATOMIC));
- MLX5_SET(mkc, mkc, rw, !!(access_flags & IB_ACCESS_REMOTE_WRITE));
- MLX5_SET(mkc, mkc, rr, !!(access_flags & IB_ACCESS_REMOTE_READ));
- MLX5_SET(mkc, mkc, lw, !!(access_flags & IB_ACCESS_LOCAL_WRITE));
+ MLX5_SET(mkc, mkc, a, (access_flags & IB_ACCESS_REMOTE_ATOMIC) != 0);
+ MLX5_SET(mkc, mkc, rw, (access_flags & IB_ACCESS_REMOTE_WRITE) != 0);
+ MLX5_SET(mkc, mkc, rr, (access_flags & IB_ACCESS_REMOTE_READ) != 0);
+ MLX5_SET(mkc, mkc, lw, (access_flags & IB_ACCESS_LOCAL_WRITE) != 0);
MLX5_SET(mkc, mkc, lr, 1);
MLX5_SET64(mkc, mkc, start_addr, virt_addr);
@@ -1696,7 +1696,7 @@ struct ib_mw *mlx5_ib_alloc_mw(struct ib_pd *pd, enum ib_mw_type type,
MLX5_SET(mkc, mkc, umr_en, 1);
MLX5_SET(mkc, mkc, lr, 1);
MLX5_SET(mkc, mkc, access_mode, MLX5_MKC_ACCESS_MODE_KLMS);
- MLX5_SET(mkc, mkc, en_rinval, !!((type == IB_MW_TYPE_2)));
+ MLX5_SET(mkc, mkc, en_rinval, type == IB_MW_TYPE_2);
MLX5_SET(mkc, mkc, qpn, 0xffffff);
err = mlx5_core_create_mkey(dev->mdev, &mw->mmkey, in, inlen);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/srq.c b/drivers/net/ethernet/mellanox/mlx5/core/srq.c
index 3099630015d7..2dee3129f1cd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/srq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/srq.c
@@ -80,8 +80,8 @@ static int get_pas_size(struct mlx5_srq_attr *in)
static void set_wq(void *wq, struct mlx5_srq_attr *in)
{
- MLX5_SET(wq, wq, wq_signature, !!(in->flags
- & MLX5_SRQ_FLAG_WQ_SIG));
+ MLX5_SET(wq, wq, wq_signature,
+ (in->flags & MLX5_SRQ_FLAG_WQ_SIG) != 0);
MLX5_SET(wq, wq, log_wq_pg_sz, in->log_page_size);
MLX5_SET(wq, wq, log_wq_stride, in->wqe_shift + 4);
MLX5_SET(wq, wq, log_wq_sz, in->log_size);
@@ -93,8 +93,8 @@ static void set_wq(void *wq, struct mlx5_srq_attr *in)
static void set_srqc(void *srqc, struct mlx5_srq_attr *in)
{
- MLX5_SET(srqc, srqc, wq_signature, !!(in->flags
- & MLX5_SRQ_FLAG_WQ_SIG));
+ MLX5_SET(srqc, srqc, wq_signature,
+ (in->flags & MLX5_SRQ_FLAG_WQ_SIG) != 0);
MLX5_SET(srqc, srqc, log_page_size, in->log_page_size);
MLX5_SET(srqc, srqc, log_rq_stride, in->wqe_shift);
MLX5_SET(srqc, srqc, log_srq_size, in->log_size);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 525f17af108e..ea9076f61b6b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -539,7 +539,7 @@ int mlx5_modify_nic_vport_node_guid(struct mlx5_core_dev *mdev,
MLX5_SET(modify_nic_vport_context_in, in,
field_select.node_guid, 1);
MLX5_SET(modify_nic_vport_context_in, in, vport_number, vport);
- MLX5_SET(modify_nic_vport_context_in, in, other_vport, !!vport);
+ MLX5_SET(modify_nic_vport_context_in, in, other_vport, vport != 0);
nic_vport_context = MLX5_ADDR_OF(modify_nic_vport_context_in,
in, nic_vport_context);
--
2.11.0
--
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 4/5] mlx5: Fix mlx5_srq_attr.pas endianness annotation
From: Bart Van Assche @ 2016-12-06 1:19 UTC (permalink / raw)
To: Doug Ledford
Cc: Eli Cohen, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9ff07804-492c-c67a-e729-b31e0f863027-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Detected by sparse.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
include/linux/mlx5/srq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mlx5/srq.h b/include/linux/mlx5/srq.h
index 33c97dc900f8..1cde0fd53f90 100644
--- a/include/linux/mlx5/srq.h
+++ b/include/linux/mlx5/srq.h
@@ -55,7 +55,7 @@ struct mlx5_srq_attr {
u32 lwm;
u32 user_index;
u64 db_record;
- u64 *pas;
+ __be64 *pas;
};
struct mlx5_core_dev;
--
2.11.0
--
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 5/5] mlx5, calc_sq_size(): Make a debug message more informative
From: Bart Van Assche @ 2016-12-06 1:19 UTC (permalink / raw)
To: Doug Ledford
Cc: Eli Cohen, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9ff07804-492c-c67a-e729-b31e0f863027-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Make it clear that qp->sq.wqe_cnt is not the number of WQEs.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx5/qp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index b2c6c13d44ac..735b8aadb84c 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -381,7 +381,8 @@ static int calc_sq_size(struct mlx5_ib_dev *dev, struct ib_qp_init_attr *attr,
wq_size = roundup_pow_of_two(attr->cap.max_send_wr * wqe_size);
qp->sq.wqe_cnt = wq_size / MLX5_SEND_WQE_BB;
if (qp->sq.wqe_cnt > (1 << MLX5_CAP_GEN(dev->mdev, log_max_qp_sz))) {
- mlx5_ib_dbg(dev, "wqe count(%d) exceeds limits(%d)\n",
+ mlx5_ib_dbg(dev, "send queue size (%d * %d / %d -> %d) exceeds limits(%d)\n",
+ attr->cap.max_send_wr, wqe_size, MLX5_SEND_WQE_BB,
qp->sq.wqe_cnt,
1 << MLX5_CAP_GEN(dev->mdev, log_max_qp_sz));
return -ENOMEM;
--
2.11.0
--
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
* Re: [PATCHv13 0/3] rdmacg: IB/core: rdma controller support
From: Parav Pandit @ 2016-12-06 2:05 UTC (permalink / raw)
To: Tejun Heo
Cc: cgroups, linux-doc, Linux Kernel Mailing List, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
Jonathan Corbet, james.l.morris, serge, Or Gerlitz, Matan Barak,
Andrew Morton, linux-security-module
In-Reply-To: <20161205193528.GC30331@mtj.duckdns.org>
ok. Thanks Tejun.
Parav
On Tue, Dec 6, 2016 at 1:05 AM, Tejun Heo <tj@kernel.org> wrote:
> Parav, it's a bit too late for this cycle. Let's target v4.11. I'll
> review the patches after the merge window. Please ping me if I don't.
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH 00/28] Broadcom RoCE Driver (bnxt_re)
From: Selvin Xavier @ 2016-12-06 5:38 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Michael Chan
In-Reply-To: <ee2b9e6f-de43-ab80-d2a7-d431e33c45ba-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Mon, Dec 5, 2016 at 8:47 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Please be clear about what you are expecting done with those four
> patches. If Dave is currently reviewing them, then I need to know
> if/when he takes them so I can rebase the bnxt_en branch on his net-next
> and pick them up that way.
These patches are pulled to net-next already. Now, since David
insisted on splitting this patch series to two,
Michael will push the bnxt_en patch series to net-next. I will push
the bnxt_re v2 patch set on top of these changes.
You can rebase bnxt_re branch before applying v2 changes. Let me know
if you think otherwise.
Thanks,
Selvin
--
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: I/O error on dd commands
From: Tomita.Haruo-IGagC74glE2s6Rmoc/2Z03gSJqDPrsil @ 2016-12-06 5:55 UTC (permalink / raw)
To: maxg-VPRAkNaXOzVWk0Htik3J/w, monis-VPRAkNaXOzVWk0Htik3J/w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Tomita.Haruo-IGagC74glE2s6Rmoc/2Z03gSJqDPrsil
Hi Max,
Thank you for your reply.
This issue reproduced vanilla 4.9-rc8.
> can you try to repro it with iSER ?
I'm sorry. I can't try iSER.
> what is your backing store device ?
I do now using TOSHIBA Enterprise SSD PX04PMB160.
https://toshiba.semicon-storage.com/ap-en/product/storage-products/enterprise-ssd.html
> is this happens in 1k bs only or in different bs as well ?
This issue is confirming the reproduction in 512k/1024k/2048k/4096k/8192k bs.
It occurs by more than one machine, so it isn't a failed of a NIC.
LAN is a connection directly (It isn't a failed of a hub.)
> rxe_req.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
> --- linux-4.9-rc7/drivers/infiniband/sw/rxe/rxe_req.c.orig 2016-12-05 10:11:38.000000000 +0900
> +++ linux-4.9-rc7/drivers/infiniband/sw/rxe/rxe_req.c 2016-12-05 10:15:43.000000000 +0900
> @@ -705,12 +705,12 @@ next_wqe:
> skb = init_req_packet(qp, wqe, opcode, payload, &pkt);
> if (unlikely(!skb)) {
> pr_err("qp#%d Failed allocating skb\n", qp_num(qp));
> - goto err;
> + goto err1;
> }
>
> if (fill_packet(qp, wqe, &pkt, skb, payload)) {
> pr_debug("qp#%d Error during fill packet\n", qp_num(qp));
> - goto err;
> + goto err2;
> }
>
> /*
> @@ -734,15 +734,16 @@ next_wqe:
> goto exit;
> }
>
> - goto err;
> + goto err1;
> }
>
> update_state(qp, wqe, &pkt, payload);
>
> goto next_wqe;
>
> -err:
> +err2:
> kfree_skb(skb);
> +err1:
> wqe->status = IB_WC_LOC_PROT_ERR;
> wqe->state = wqe_state_error;
>
It's unrelated to this issue, please apply this patch.
thanks,
Haruo.
--
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: [PATCH 08/28] bnxt_re: Add bnxt_re RoCE driver files
From: Selvin Xavier @ 2016-12-06 5:56 UTC (permalink / raw)
To: Doug Ledford
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Eddie Wai, Devesh Sharma,
Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <09068db2-1a14-9fbb-074b-4cf000fbddfb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Doug,
Please find my response inline.
On Mon, Dec 5, 2016 at 8:46 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/5/2016 1:38 AM, Selvin Xavier wrote:
>
...
>> +++ b/drivers/infiniband/hw/bnxtre/Makefile
>> @@ -0,0 +1,5 @@
>> +
>> +obj-$(CONFIG_INFINIBAND_BNXTRE) += bnxt_re.o
>> +bnxt_re-y := bnxt_re_main.o bnxt_re_ib_verbs.o \
>> + bnxt_qplib_res.o bnxt_qplib_rcfw.o \
>> + bnxt_qplib_sp.o bnxt_qplib_fp.o
>
> A lot of times I prefer these files to be the final patch in the series.
> It's completely not possible to break bisectability if these are last.
> Then again, if I squash this down to one commit it doesn't really matter....
>
[Selvin Xavier] While splitting the patch series, we made sure that
the compilation works after applying each patch.
But i am ok to push these changes to last patch. This can be included
in v2 patch set.
....
>
> This copyright, repeated many times in the various skeleton files...
>
>> diff --git a/drivers/infiniband/hw/bnxtre/bnxt_re_main.c b/drivers/infiniband/hw/bnxtre/bnxt_re_main.c
>> new file mode 100644
>> index 0000000..4c377dc
>> --- /dev/null
>> +++ b/drivers/infiniband/hw/bnxtre/bnxt_re_main.c
>> @@ -0,0 +1,96 @@
>> +/* Broadcom NetXtreme-C/E RoCE driver.
>> + *
>> + * Copyright (c) 2016 Broadcom Corporation
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation.
>> + */
>> +
>> +/*
>> + * Description: Main component of the bnxt_re driver
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/mutex.h>
>> +#include <linux/list.h>
>> +#include <linux/rculist.h>
>> +#include "bnxt_re.h"
>> +static char version[] =
>> + BNXT_RE_DESC " v" ROCE_DRV_MODULE_VERSION "\n";
>> +
>> +
>> +MODULE_AUTHOR("Eddie Wai <eddie.wai-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>");
>> +MODULE_DESCRIPTION(BNXT_RE_DESC " Driver");
>> +MODULE_LICENSE("Dual BSD/GPL");
>
> and this module license description do not agree. Please make
> everything consistent. I don't care if it's GPLv2 or Dual licensed, it
> simply needs to be consistent.
>
[Selvin Xavier] i will post v2 with this change. We need Dual license.
Will edit the license text
accordingly.
>
>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG Key ID: 0E572FDD
>
Thanks,
Selvin
--
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: [PATCH 00/28] Broadcom RoCE Driver (bnxt_re)
From: Selvin Xavier @ 2016-12-06 6:01 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161205165144.GB24852-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Hi Jason,
On Mon, Dec 5, 2016 at 10:21 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> On Sun, Dec 04, 2016 at 10:38:04PM -0800, Selvin Xavier wrote:
>> drivers/infiniband/hw/bnxtre/bnxt_re_uverbs_abi.h | 60 +
>
> This file probably needs to be in include/uapi/rdma like the others
>
Sure.. i will this include as a part of V2.
> Do you have a git tree someplace for this?
>
I assume you are referring to our uverbs library. We have the
component ready but is not uploaded to external git yet. We will
publish it soon and let you know the pointers.
> Do you have the user space component ready for rdma-core as well?
>
This is not ready yet. Currently working on it.
> Jason
Thanks,
Selvin Xavier
--
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] net: return value of skb_linearize should be handled in Linux kernel
From: Zhouyi Zhou @ 2016-12-06 7:10 UTC (permalink / raw)
To: faisal.latif, dledford, sean.hefty, hal.rosenstock,
jeffrey.t.kirsher, QLogic-Storage-Upstream, jejb, martin.petersen,
jth, jon.maloy, ying.xue, davem, linux-rdma, linux-kernel,
intel-wired-lan, netdev, linux-scsi, fcoe-devel, tipc-discussion
Cc: Zhouyi Zhou
kmalloc_reserve may fail to allocate memory inside skb_linearize,
which means skb_linearize's return value should not be ignored.
Following patch correct the uses of skb_linearize.
Compiled in x86_64
Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
---
drivers/infiniband/hw/nes/nes_nic.c | 5 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 6 +++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 7 +++++--
drivers/scsi/fcoe/fcoe.c | 5 ++++-
net/tipc/link.c | 3 ++-
net/tipc/name_distr.c | 5 ++++-
7 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes_nic.c b/drivers/infiniband/hw/nes/nes_nic.c
index 2b27d13..69372ea 100644
--- a/drivers/infiniband/hw/nes/nes_nic.c
+++ b/drivers/infiniband/hw/nes/nes_nic.c
@@ -662,10 +662,11 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, struct net_device *netdev)
nesnic->sq_head &= nesnic->sq_size-1;
}
} else {
- nesvnic->linearized_skbs++;
hoffset = skb_transport_header(skb) - skb->data;
nhoffset = skb_network_header(skb) - skb->data;
- skb_linearize(skb);
+ if (skb_linearize(skb))
+ return NETDEV_TX_BUSY;
+ nesvnic->linearized_skbs++;
skb_set_transport_header(skb, hoffset);
skb_set_network_header(skb, nhoffset);
if (!nes_nic_send(skb, netdev))
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index 2a653ec..ab787cb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -490,7 +490,11 @@ int ixgbe_fcoe_ddp(struct ixgbe_adapter *adapter,
*/
if ((fh->fh_r_ctl == FC_RCTL_DD_SOL_DATA) &&
(fctl & FC_FC_END_SEQ)) {
- skb_linearize(skb);
+ int err = 0;
+
+ err = skb_linearize(skb);
+ if (err)
+ return err;
crc = (struct fcoe_crc_eof *)skb_put(skb, sizeof(*crc));
crc->fcoe_eof = FC_EOF_T;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..4926d48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2173,8 +2173,7 @@ static int ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
total_rx_bytes += ddp_bytes;
total_rx_packets += DIV_ROUND_UP(ddp_bytes,
mss);
- }
- if (!ddp_bytes) {
+ } else {
dev_kfree_skb_any(skb);
continue;
}
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index f9ddb61..197d02e 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -542,8 +542,11 @@ static void bnx2fc_recv_frame(struct sk_buff *skb)
return;
}
- if (skb_is_nonlinear(skb))
- skb_linearize(skb);
+ if (skb_linearize(skb)) {
+ kfree_skb(skb);
+ return;
+ }
+
mac = eth_hdr(skb)->h_source;
dest_mac = eth_hdr(skb)->h_dest;
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 9bd41a3..f691b97 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1685,7 +1685,10 @@ static void fcoe_recv_frame(struct sk_buff *skb)
skb->dev ? skb->dev->name : "<NULL>");
port = lport_priv(lport);
- skb_linearize(skb); /* check for skb_is_nonlinear is within skb_linearize */
+ if (skb_linearize(skb)) {
+ kfree_skb(skb);
+ return;
+ }
/*
* Frame length checks and setting up the header pointers
diff --git a/net/tipc/link.c b/net/tipc/link.c
index bda89bf..077c570 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1446,7 +1446,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l, struct sk_buff *skb,
if (tipc_own_addr(l->net) > msg_prevnode(hdr))
l->net_plane = msg_net_plane(hdr);
- skb_linearize(skb);
+ if (skb_linearize(skb))
+ goto exit;
hdr = buf_msg(skb);
data = msg_data(hdr);
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index c1cfd92..4e05d2a 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -356,7 +356,10 @@ void tipc_named_rcv(struct net *net, struct sk_buff_head *inputq)
spin_lock_bh(&tn->nametbl_lock);
for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
- skb_linearize(skb);
+ if (skb_linearize(skb)) {
+ kfree_skb(skb);
+ continue;
+ }
msg = buf_msg(skb);
mtype = msg_type(msg);
item = (struct distr_item *)msg_data(msg);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 12/16] IB/pvrdma: Add Queue Pair support
From: Yuval Shaia @ 2016-12-06 8:00 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <76188e1e-9b9b-07d6-febd-41827a049837-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
On Mon, Dec 05, 2016 at 01:21:07PM -0800, Adit Ranadive wrote:
> On Mon, Dec 05, 2016 at 7:25:34PM +0200, Yuval Shaia wrote:
> > > > +
> > > > + /* Skip header page. */
> > > > + qp->sq.offset = PAGE_SIZE;
> > > > +
> > > > + /* Recv queue pages are after send pages. */
> > > > + qp->rq.offset = qp->npages_send * PAGE_SIZE;
> > >
> > > Unless i'm missing something here, per comment it should be:
> > > qp->rq.offset = qp->sq.offset + qp->npages_send * PAGE_SIZE;
> >
> > Hi,
> > Any comments about this question?
>
> My comment [1] for the npages_send applies here as well. Since
> we account for the extra page within the npages_send attribute, the
> rq.offset calculated here is correct.
Ok, i see that now.
It is kind of confusing that this logic of one extra page for header is
implemented in two places, i.e. in pvrdma_set_sq_size and in
pvrdma_set_sq_size's caller.
Still suggesting to move this logic to one place for better modularization.
(Just imagine one day that you will need to expand this header to two
pages).
If you accept it then caller is my vote to place it :)
>
> [1] http://marc.info/?l=linux-rdma&m=148069497625433&w=2
> --
> 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
--
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-06 8:06 UTC (permalink / raw)
To: Dan Williams
Cc: Haggai Eran, 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
In-Reply-To: <CAPcyv4iVHhOSxPrLMZ53Xw3CK+9cOWn9zEG8smMtqF_LAcKKpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>> I've already recommended that iopmem not be a block device and
>>> instead be a device-dax instance. I also don't think it should claim
>>> the PCI ID, rather the driver that wants to map one of its bars this
>>> way can register the memory region with the device-dax core.
>>>
>>> I'm not sure there are enough device drivers that want to do this to
>>> have it be a generic /sys/.../resource_dmableX capability. It still
>>> seems to be an exotic one-off type of configuration.
>>
>>
>> Yes, this is essentially my thinking. Except I think the userspace
>> interface should really depend on the device itself. Device dax is a
>> good choice for many and I agree the block device approach wouldn't be
>> ideal.
I tend to agree here. The block device interface has seen quite a bit of
resistance and /dev/dax looks like a better approach for most. We can look
at doing it that way in v2.
>>
>> Specifically for NVME CMB: I think it would make a lot of sense to just
>> hand out these mappings with an mmap call on /dev/nvmeX. I expect CMB
>> buffers would be volatile and thus you wouldn't need to keep track of
>> where in the BAR the region came from. Thus, the mmap call would just be
>> an allocator from BAR memory. If device-dax were used, userspace would
>> need to lookup which device-dax instance corresponds to which nvme
>> drive.
>>
>
> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> device-dax instance under the nvme device, or if you already have the nvme
> sysfs path the dax instance(s) will appear under the "dax" sub-directory.
>
Personally I think mapping the dax resource in the sysfs tree is a nice
way to do this and a bit more intuitive than mapping a /dev/nvmeX.
^ permalink raw reply
* Re: Use ib_drain_qp instead of ib_drain_rq in ib_srp
From: Max Gurtovoy @ 2016-12-06 10:01 UTC (permalink / raw)
To: Bart Van Assche, sagig, Christoph Hellwig,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <b2a1ed73-fb4c-07a5-c343-389bdc29501c-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
thanks Bart.
I understand why the beacon/drain is needed but I'm wondering if it's
enough draining only the recv_q/send_q of the qp.
These are 2 seperate queues in the qp so receiving the beacon on the
recv_q, In theory doesn't ensure the all the send_q elements flushed.
Moreover if the cq is different for recv/send queues.
I can't prove it currently but I think I saw these happens when
developing iSER over FreeBSD (It was long time ago so it might have
happend because we posted stuff after posting the beacon).
In the current implementation we can't drain with IB_POLL_DIRECT ctx
(like srp send_cq) but we might think of implementation that can enable
it if needed.
On 12/5/2016 7:05 PM, Bart Van Assche wrote:
> On 12/05/2016 06:43 AM, Max Gurtovoy wrote:
>> hi guys,
>> I've noticed that we use ib_drain_rq in teardown flow in ib_srp driver.
>> Trying to figure out why is this better than ib_drain_qp ?
>> BTW, the recv_cq != send_cq in srp so it's even better to use
>> ib_drain_qp, isn't it ?
>>
>> I haven't encountered a bug in this area yet, but just trying to
>> understand if it's there.
>
> Hello Max,
>
> The description of a patch that was accepted upstream about two years
> ago explains the purpose of the ib_drain_rq() call:
>
> commit 7dad6b2e440d810273946b0e7092a8fe043c3b8a
> Author: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
> Date: Tue Oct 21 18:00:35 2014 +0200
>
> IB/srp: Fix a race condition triggered by destroying a queue pair
>
> At least LID reassignment can trigger a race condition in the SRP
> initiator driver, namely the receive completion handler trying to
> post a request on a QP during or after QP destruction and before
> the CQ's have been destroyed. Avoid this race by modifying a QP
> into the error state and by waiting until all receive completions
> have been processed before destroying a QP.
>
> Reported-by: Max Gurtuvoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
> Reviewed-by: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
>
> There is no risk that any send work will be posted while the ib_srp
> driver destroys a QP.
>
> Bart.
--
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] cma: resolve to first active IB port
From: Jinpu Wang @ 2016-12-06 11:16 UTC (permalink / raw)
To: Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Michael Wang
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
Hi Doug, Sean and Hal,
We have problem when connect connection from second port with AF_IB,
when first port is down.
We will fail when resovle route.
It turned out when resolve addr, in cma_resolve_ib_dev, we will choose
the first port if subnet_prefix is the same, in our case we use
default well known prefix.
I proposal fix below to resolve to first acrive IB port:
Note: I will attach another one for easily apply if the format mangled by gmail.
Patch created based on Linux 4.9-rc7.
>From b42e51deb8da3c1b596cb4332b6815e5ac8658a7 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
Date: Tue, 6 Dec 2016 09:01:04 +0100
Subject: [PATCH] cma: resolve to first active ib_port
When resolve addr if we don't give src addr, cma core will try to resolve to
ib device on itself, current logic is only check if it has same
subnet_prefix, which is not enough if we use default well known gid,
we should also check if port is active.
Signed-off-by: Jack Wang <jinpu.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
---
drivers/infiniband/core/cma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 2a6fc47..9e46b42 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -684,6 +684,8 @@ static int cma_resolve_ib_dev(struct
rdma_id_private *id_priv)
for (i = 0; !ib_get_cached_gid(cur_dev->device, p, i,
&gid, NULL);
i++) {
+ struct ib_port_attr attr;
+
if (!memcmp(&gid, dgid, sizeof(gid))) {
cma_dev = cur_dev;
sgid = gid;
@@ -692,7 +694,9 @@ static int cma_resolve_ib_dev(struct
rdma_id_private *id_priv)
}
if (!cma_dev && (gid.global.subnet_prefix ==
- dgid->global.subnet_prefix)) {
+ dgid->global.subnet_prefix) &&
+ (!ib_query_port(cur_dev->device, p, &attr) &&
+ attr.state == IB_PORT_ACTIVE)) {
cma_dev = cur_dev;
sgid = gid;
id_priv->id.port_num = p;
--
2.7.4
--
Jinpu Wang
Linux Kernel Developer
ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Tel: +49 30 577 008 042
Fax: +49 30 577 008 299
Email: jinpu.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
URL: https://www.profitbricks.de
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss
[-- Attachment #2: 0001-cma-resolve-to-first-active-ib_port.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]
From b42e51deb8da3c1b596cb4332b6815e5ac8658a7 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@profitbricks.com>
Date: Tue, 6 Dec 2016 09:01:04 +0100
Subject: [PATCH] cma: resolve to first active ib_port
When resolve addr if we don't give src addr, cma core will try to resolve to
ib device on itself, current logic is only check if it has same
subnet_prefix, which is not enough if we use default well known gid,
we should also check if port is active.
Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
---
drivers/infiniband/core/cma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 2a6fc47..9e46b42 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -684,6 +684,8 @@ static int cma_resolve_ib_dev(struct rdma_id_private *id_priv)
for (i = 0; !ib_get_cached_gid(cur_dev->device, p, i,
&gid, NULL);
i++) {
+ struct ib_port_attr attr;
+
if (!memcmp(&gid, dgid, sizeof(gid))) {
cma_dev = cur_dev;
sgid = gid;
@@ -692,7 +694,9 @@ static int cma_resolve_ib_dev(struct rdma_id_private *id_priv)
}
if (!cma_dev && (gid.global.subnet_prefix ==
- dgid->global.subnet_prefix)) {
+ dgid->global.subnet_prefix) &&
+ (!ib_query_port(cur_dev->device, p, &attr) &&
+ attr.state == IB_PORT_ACTIVE)) {
cma_dev = cur_dev;
sgid = gid;
id_priv->id.port_num = p;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4/5] mlx5: Fix mlx5_srq_attr.pas endianness annotation
From: Leon Romanovsky @ 2016-12-06 13:55 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <3d4f5ffa-e9bf-cd28-d200-74c5dd3d68ce-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 05, 2016 at 05:19:29PM -0800, Bart Van Assche wrote:
> Detected by sparse.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks Bart,
It is fixed in Dave's tree.
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/include/linux/mlx5/srq.h?id=dd257efb1e0f8875ed7e42b88837a8dada0d0e41
> ---
> include/linux/mlx5/srq.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mlx5/srq.h b/include/linux/mlx5/srq.h
> index 33c97dc900f8..1cde0fd53f90 100644
> --- a/include/linux/mlx5/srq.h
> +++ b/include/linux/mlx5/srq.h
> @@ -55,7 +55,7 @@ struct mlx5_srq_attr {
> u32 lwm;
> u32 user_index;
> u64 db_record;
> - u64 *pas;
> + __be64 *pas;
> };
>
> struct mlx5_core_dev;
> --
> 2.11.0
>
> --
> 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
--
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: [PATCH 1/5] mlx5: Use NULL instead of 0 to represent a pointer
From: Leon Romanovsky @ 2016-12-06 13:59 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <16dc2a07-86f7-ce47-7b0c-1da03e58d99f-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 05, 2016 at 05:18:08PM -0800, Bart Van Assche wrote:
> Detected by sparse.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/infiniband/hw/mlx5/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> index 32b09f059c84..abd200e3e299 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -127,7 +127,7 @@ static int mlx5_netdev_event(struct notifier_block *this,
>
> if ((upper == ndev || (!upper && ndev == ibdev->roce.netdev))
> && ibdev->ib_active) {
> - struct ib_event ibev = {0};
> + struct ib_event ibev = { NULL };
I afraid that it is sparse anomality and because NULL==0, the ibev.event
will be initialized to zero, but it is a matter of time when the sparse
will complain about wrong initialization again.
>
> ibev.device = &ibdev->ib_dev;
> ibev.event = (event == NETDEV_UP) ?
> --
> 2.11.0
>
> --
> 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
--
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: [PATCH 2/5] mlx5: Remove a set-but-not-used variable
From: Leon Romanovsky @ 2016-12-06 14:24 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <f1351e2c-915d-9883-838b-d3c50f27da17-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 05, 2016 at 05:18:27PM -0800, Bart Van Assche wrote:
> This has been detected by building the mlx5 driver with W=1.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks,
Fixes: 1a412fb1caa2 ('net/mlx5: Fixes: 1a412fb1caa2 (IB/mlx5: Modify QP commands via mlx5 ifc')
Acked-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/infiniband/hw/mlx5/qp.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
> index d1e921816bfe..b2c6c13d44ac 100644
> --- a/drivers/infiniband/hw/mlx5/qp.c
> +++ b/drivers/infiniband/hw/mlx5/qp.c
> @@ -2577,7 +2577,6 @@ static int __mlx5_ib_modify_qp(struct ib_qp *ibqp,
> struct mlx5_ib_port *mibport = NULL;
> enum mlx5_qp_state mlx5_cur, mlx5_new;
> enum mlx5_qp_optpar optpar;
> - int sqd_event;
> int mlx5_st;
> int err;
> u16 op;
> @@ -2724,12 +2723,6 @@ static int __mlx5_ib_modify_qp(struct ib_qp *ibqp,
> if (qp->rq.wqe_cnt && cur_state == IB_QPS_RESET && new_state == IB_QPS_INIT)
> context->db_rec_addr = cpu_to_be64(qp->db.dma);
>
> - if (cur_state == IB_QPS_RTS && new_state == IB_QPS_SQD &&
> - attr_mask & IB_QP_EN_SQD_ASYNC_NOTIFY && attr->en_sqd_async_notify)
> - sqd_event = 1;
> - else
> - sqd_event = 0;
> -
> if (cur_state == IB_QPS_RESET && new_state == IB_QPS_INIT) {
> u8 port_num = (attr_mask & IB_QP_PORT ? attr->port_num :
> qp->port) - 1;
> --
> 2.11.0
>
> --
> 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
--
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: [PATCH 5/5] mlx5, calc_sq_size(): Make a debug message more informative
From: Leon Romanovsky @ 2016-12-06 14:31 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4387aa0f-5097-d456-eee2-b480dfa5af87-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 05, 2016 at 05:19:52PM -0800, Bart Van Assche wrote:
> Make it clear that qp->sq.wqe_cnt is not the number of WQEs.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks,
Acked-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/infiniband/hw/mlx5/qp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
> index b2c6c13d44ac..735b8aadb84c 100644
> --- a/drivers/infiniband/hw/mlx5/qp.c
> +++ b/drivers/infiniband/hw/mlx5/qp.c
> @@ -381,7 +381,8 @@ static int calc_sq_size(struct mlx5_ib_dev *dev, struct ib_qp_init_attr *attr,
> wq_size = roundup_pow_of_two(attr->cap.max_send_wr * wqe_size);
> qp->sq.wqe_cnt = wq_size / MLX5_SEND_WQE_BB;
> if (qp->sq.wqe_cnt > (1 << MLX5_CAP_GEN(dev->mdev, log_max_qp_sz))) {
> - mlx5_ib_dbg(dev, "wqe count(%d) exceeds limits(%d)\n",
> + mlx5_ib_dbg(dev, "send queue size (%d * %d / %d -> %d) exceeds limits(%d)\n",
> + attr->cap.max_send_wr, wqe_size, MLX5_SEND_WQE_BB,
> qp->sq.wqe_cnt,
> 1 << MLX5_CAP_GEN(dev->mdev, log_max_qp_sz));
> return -ENOMEM;
> --
> 2.11.0
>
> --
> 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
--
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
* Potential double-lock BUG in drivers/infiniband/core/umem_odp.c (Linux 4.9-rc7)
From: Iago Abal @ 2016-12-06 15:59 UTC (permalink / raw)
To: Doug Ledford
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock, Stephen Rothwell,
Guy Shapiro, Haggai Eran, Jesper Dangaard Brouer,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi,
With the help of a static bug finder (EBA -
http://www.iagoabal.eu/eba) I have found a potential double-lock in
drivers/infiniband/core/umem_odp.c: there seems to be a recursive lock
on `umem->odp_data->umem_mutex' in function
`ib_umem_odp_map_dma_pages'.
This problem may have been introduced by commit c1d383b5785b
("IB/core: dma map/unmap locking optimizations").
If this is indeed a bug, I could try to help with a patch... although
it doesn't look trivial to fix at first sight.
The trace is as follows:
1. Function `ib_umem_odp_map_dma_pages' takes the lock for the first
time in line 589:
// see https://github.com/torvalds/linux/blob/v4.9-rc7/drivers/infiniband/core/umem_odp.c#L589
mutex_lock(&umem->odp_data->umem_mutex);
2. Call to function `ib_umem_odp_map_dma_single_page' in line 591;
3. Call to function `invalidate_page_trampoline' in line 486;
4. Call to function `ib_umem_notifier_start_account' in line 160;
5. Lock is taken for the second time in line 46:
// see https://github.com/torvalds/linux/blob/v4.9-rc7/drivers/infiniband/core/umem_odp.c#L46
mutex_lock(&item->odp_data->umem_mutex);
Hope it helps!
-- iago
--
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: [PATCH 1/5] mlx5: Use NULL instead of 0 to represent a pointer
From: Jason Gunthorpe @ 2016-12-06 16:28 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Bart Van Assche, Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161206135917.GC2437-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Tue, Dec 06, 2016 at 03:59:17PM +0200, Leon Romanovsky wrote:
> On Mon, Dec 05, 2016 at 05:18:08PM -0800, Bart Van Assche wrote:
> > Detected by sparse.
> >
> > Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> > Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > drivers/infiniband/hw/mlx5/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> > index 32b09f059c84..abd200e3e299 100644
> > +++ b/drivers/infiniband/hw/mlx5/main.c
> > @@ -127,7 +127,7 @@ static int mlx5_netdev_event(struct notifier_block *this,
> >
> > if ((upper == ndev || (!upper && ndev == ibdev->roce.netdev))
> > && ibdev->ib_active) {
> > - struct ib_event ibev = {0};
> > + struct ib_event ibev = { NULL };
>
> I afraid that it is sparse anomality and because NULL==0, the ibev.event
> will be initialized to zero, but it is a matter of time when the sparse
> will complain about wrong initialization again.
Use '= {}' for zeroing structs.
Jason
--
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: [PATCH 1/5] mlx5: Use NULL instead of 0 to represent a pointer
From: Bart Van Assche @ 2016-12-06 16:29 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161206135917.GC2437-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On 12/06/2016 05:59 AM, Leon Romanovsky wrote:
> On Mon, Dec 05, 2016 at 05:18:08PM -0800, Bart Van Assche wrote:
>> Detected by sparse.
>>
>> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
>> Cc: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>> ---
>> drivers/infiniband/hw/mlx5/main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
>> index 32b09f059c84..abd200e3e299 100644
>> --- a/drivers/infiniband/hw/mlx5/main.c
>> +++ b/drivers/infiniband/hw/mlx5/main.c
>> @@ -127,7 +127,7 @@ static int mlx5_netdev_event(struct notifier_block *this,
>>
>> if ((upper == ndev || (!upper && ndev == ibdev->roce.netdev))
>> && ibdev->ib_active) {
>> - struct ib_event ibev = {0};
>> + struct ib_event ibev = { NULL };
>
> I afraid that it is sparse anomality and because NULL==0, the ibev.event
> will be initialized to zero, but it is a matter of time when the sparse
> will complain about wrong initialization again.
Hello Leon,
The first member of struct ib_event is a pointer so I think the sparse
complaint is correct. Anyway, how about one of the following two
alternatives:
* Change {0} into { }.
* Use memset() instead of an initializer.
Bart.
--
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: [PATCH 00/28] Broadcom RoCE Driver (bnxt_re)
From: Jason Gunthorpe @ 2016-12-06 16:34 UTC (permalink / raw)
To: Selvin Xavier; +Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+sbYW1sUrv8CBHScMjU7ozBm709-tiVWaynDQK_Dq3AqAfggA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 06, 2016 at 11:31:14AM +0530, Selvin Xavier wrote:
> > Do you have a git tree someplace for this?
> I assume you are referring to our uverbs library.
No, I mean this series for linux. It is very hard to read these
patches when they touch the same file again and again and have
dependencies on net trees and things. I encourage people to include a
git tree for such large works..
> > Do you have the user space component ready for rdma-core as well?
> >
> This is not ready yet. Currently working on it.
I'm also encouraging people to have their user space ready so the
kernel driver can be properly reviewed.
Jason
--
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: Jason Gunthorpe @ 2016-12-06 16:38 UTC (permalink / raw)
To: Stephen Bates
Cc: Haggai Eran, 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: <ac07a73f2601f6ca35cecc83c553feb0.squirrel-2RFepEojUI2m/tTznewQxVaTQe2KTcn/@public.gmane.org>
> > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> > device-dax instance under the nvme device, or if you already have the nvme
> > sysfs path the dax instance(s) will appear under the "dax" sub-directory.
>
> Personally I think mapping the dax resource in the sysfs tree is a nice
> way to do this and a bit more intuitive than mapping a /dev/nvmeX.
It is still not at all clear to me what userpsace is supposed to do
with this on nvme.. How is the CMB usable from userspace?
Jason
^ permalink raw reply
* Re: Enabling peer to peer device transactions for PCIe devices
From: Logan Gunthorpe @ 2016-12-06 16:51 UTC (permalink / raw)
To: Jason Gunthorpe, Stephen Bates
Cc: Haggai Eran, 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: <20161206163850.GC28066-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Hey,
On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
>>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
>>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
>>> device-dax instance under the nvme device, or if you already have the nvme
>>> sysfs path the dax instance(s) will appear under the "dax" sub-directory.
>>
>> Personally I think mapping the dax resource in the sysfs tree is a nice
>> way to do this and a bit more intuitive than mapping a /dev/nvmeX.
>
> It is still not at all clear to me what userpsace is supposed to do
> with this on nvme.. How is the CMB usable from userspace?
The flow is pretty simple. For example to write to NVMe from an RDMA device:
1) Obtain a chunk of the CMB to use as a buffer(either by mmaping
/dev/nvmx, the device dax char device or through a block layer interface
(which sounds like a good suggestion from Christoph, but I'm not really
sure how it would look).
2) Create an MR with the buffer and use an RDMA function to fill it with
data from a remote host. This will cause the RDMA hardware to write
directly to the memory in the NVMe card.
3) Using O_DIRECT, write the buffer to a file on the NVMe filesystem.
When the address reaches hardware the NVMe will recognize it as local
memory and copy it directly there.
Thus we are able to transfer data to any file on an NVMe device without
going through system memory. This has benefits on systems with lots of
activity in system memory but step 3 is likely to be slowish due to the
need to pin/unpin the memory for every transaction.
Logan
^ permalink raw reply
* Re: [PATCH] net: return value of skb_linearize should be handled in Linux kernel
From: Yuval Shaia @ 2016-12-06 16:57 UTC (permalink / raw)
To: Zhouyi Zhou
Cc: faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
QLogic-Storage-Upstream-h88ZbnxC6KDQT0dZR+AlfA,
jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
martin.petersen-QHcLZuEGTsvQT0dZR+AlfA,
jth-DgEjT+Ai2ygdnm+yROfE0A, jon.maloy-IzeFyvvaP7pWk0Htik3J/w,
ying.xue-CWA4WttNNZF54TAoqtyWWQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
intel-wired-lan-qjLDD68F18P21nG7glBr7A,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
tipc-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1481008233-16777-1-git-send-email-zhouzhouyi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 06, 2016 at 03:10:33PM +0800, Zhouyi Zhou wrote:
> kmalloc_reserve may fail to allocate memory inside skb_linearize,
> which means skb_linearize's return value should not be ignored.
> Following patch correct the uses of skb_linearize.
>
> Compiled in x86_64
FWIW compiled also on SPARC
Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Zhouyi Zhou <zhouzhouyi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/infiniband/hw/nes/nes_nic.c | 5 +++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 6 +++++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 7 +++++--
> drivers/scsi/fcoe/fcoe.c | 5 ++++-
> net/tipc/link.c | 3 ++-
> net/tipc/name_distr.c | 5 ++++-
> 7 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/hw/nes/nes_nic.c b/drivers/infiniband/hw/nes/nes_nic.c
> index 2b27d13..69372ea 100644
> --- a/drivers/infiniband/hw/nes/nes_nic.c
> +++ b/drivers/infiniband/hw/nes/nes_nic.c
> @@ -662,10 +662,11 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, struct net_device *netdev)
> nesnic->sq_head &= nesnic->sq_size-1;
> }
> } else {
> - nesvnic->linearized_skbs++;
> hoffset = skb_transport_header(skb) - skb->data;
> nhoffset = skb_network_header(skb) - skb->data;
> - skb_linearize(skb);
> + if (skb_linearize(skb))
> + return NETDEV_TX_BUSY;
> + nesvnic->linearized_skbs++;
> skb_set_transport_header(skb, hoffset);
> skb_set_network_header(skb, nhoffset);
> if (!nes_nic_send(skb, netdev))
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index 2a653ec..ab787cb 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> @@ -490,7 +490,11 @@ int ixgbe_fcoe_ddp(struct ixgbe_adapter *adapter,
> */
> if ((fh->fh_r_ctl == FC_RCTL_DD_SOL_DATA) &&
> (fctl & FC_FC_END_SEQ)) {
> - skb_linearize(skb);
> + int err = 0;
> +
> + err = skb_linearize(skb);
> + if (err)
> + return err;
> crc = (struct fcoe_crc_eof *)skb_put(skb, sizeof(*crc));
> crc->fcoe_eof = FC_EOF_T;
> }
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index fee1f29..4926d48 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -2173,8 +2173,7 @@ static int ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
> total_rx_bytes += ddp_bytes;
> total_rx_packets += DIV_ROUND_UP(ddp_bytes,
> mss);
> - }
> - if (!ddp_bytes) {
> + } else {
> dev_kfree_skb_any(skb);
> continue;
> }
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> index f9ddb61..197d02e 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> @@ -542,8 +542,11 @@ static void bnx2fc_recv_frame(struct sk_buff *skb)
> return;
> }
>
> - if (skb_is_nonlinear(skb))
> - skb_linearize(skb);
> + if (skb_linearize(skb)) {
> + kfree_skb(skb);
> + return;
> + }
> +
> mac = eth_hdr(skb)->h_source;
> dest_mac = eth_hdr(skb)->h_dest;
>
> diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
> index 9bd41a3..f691b97 100644
> --- a/drivers/scsi/fcoe/fcoe.c
> +++ b/drivers/scsi/fcoe/fcoe.c
> @@ -1685,7 +1685,10 @@ static void fcoe_recv_frame(struct sk_buff *skb)
> skb->dev ? skb->dev->name : "<NULL>");
>
> port = lport_priv(lport);
> - skb_linearize(skb); /* check for skb_is_nonlinear is within skb_linearize */
> + if (skb_linearize(skb)) {
> + kfree_skb(skb);
> + return;
> + }
>
> /*
> * Frame length checks and setting up the header pointers
> diff --git a/net/tipc/link.c b/net/tipc/link.c
> index bda89bf..077c570 100644
> --- a/net/tipc/link.c
> +++ b/net/tipc/link.c
> @@ -1446,7 +1446,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l, struct sk_buff *skb,
> if (tipc_own_addr(l->net) > msg_prevnode(hdr))
> l->net_plane = msg_net_plane(hdr);
>
> - skb_linearize(skb);
> + if (skb_linearize(skb))
> + goto exit;
> hdr = buf_msg(skb);
> data = msg_data(hdr);
>
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> index c1cfd92..4e05d2a 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -356,7 +356,10 @@ void tipc_named_rcv(struct net *net, struct sk_buff_head *inputq)
>
> spin_lock_bh(&tn->nametbl_lock);
> for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
> - skb_linearize(skb);
> + if (skb_linearize(skb)) {
> + kfree_skb(skb);
> + continue;
> + }
> msg = buf_msg(skb);
> mtype = msg_type(msg);
> item = (struct distr_item *)msg_data(msg);
> --
> 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
--
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
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