* Re: [PATCH 0/3] Address three Coverity complaints about RDMA code
From: Doug Ledford @ 2016-12-14 18:27 UTC (permalink / raw)
To: Bart Van Assche; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <94eb11fc-b558-b994-c933-da784caefc53-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 365 bytes --]
On 11/21/2016 1:20 PM, Bart Van Assche wrote:
> Hello Doug,
>
> The three patches in this series address warnings reported by Coverity
> on the RDMA code. Please consider these patches for kernel version v4.10.
>
> Thanks,
>
> Bart.
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2] infiniband: remove WARN that is not kernel bug
From: Leon Romanovsky @ 2016-12-14 18:27 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, Dmitry Vyukov, syzkaller, Valdis.Kletnieks,
sean.hefty, Hal Rosenstock, linux-rdma, LKML
In-Reply-To: <b5343f5e-68a8-5a01-5fa9-04e9181e4082@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Wed, Dec 14, 2016 at 01:16:45PM -0500, Doug Ledford wrote:
> On 11/21/2016 12:38 PM, Leon Romanovsky wrote:
> > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
> >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
> >>>>
> >>>> In ib_ucm_write function there is a wrong prefix:
> >>>>
> >>>> + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
> >>>
> >>> I did it intentionally to have the same errors for all flows.
> >>
> >> Lets actually use a good message too please?
> >>
> >> pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
> >>
> >> Jason
>
> I applied Leon's reworked version of this patch, thanks.
Thanks Doug,
I already forgot about it :)
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG Key ID: 0E572FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] infiniband: remove WARN that is not kernel bug
From: Doug Ledford @ 2016-12-14 18:16 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Dmitry Vyukov, syzkaller, Valdis.Kletnieks-PjAqaU27lzQ,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, LKML
In-Reply-To: <20161121173820.GC23083-2ukJVAZIZ/Y@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]
On 11/21/2016 12:38 PM, Leon Romanovsky wrote:
> On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
>> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
>>>>
>>>> In ib_ucm_write function there is a wrong prefix:
>>>>
>>>> + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
>>>
>>> I did it intentionally to have the same errors for all flows.
>>
>> Lets actually use a good message too please?
>>
>> pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
>>
>> Jason
I applied Leon's reworked version of this patch, thanks.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 0/6] Add support for Vxlan protocol for the steering rules
From: Doug Ledford @ 2016-12-14 18:03 UTC (permalink / raw)
To: Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Maor Gottlieb
In-Reply-To: <1479143092-11723-1-git-send-email-leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3439 bytes --]
On 11/14/2016 12:04 PM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Virtual Extensible LAN - Vxlan is a proposed encapsulation protocol for
> running an overlay network on existing Layer 3 infrastructure. An
> overlay network is a virtual network that is built on top of existing
> network Layer 2 and Layer 3 technologies to support elastic COMPUTE
> architectures. Vxlan will make it easier for network engineers to scale
> out a cloud computing environment while logically isolating cloud apps
> and tenants.
>
> This patchset introduces support Vxlan steering rules to IB/core and
> mlx5 devices implementation. The application will be able to send
> packet with Vxlan tunneling, and configure a steering rule to receive
> the stream from the rule to the QP.
>
> The rule will contain inner and outer parts for the inner and outer
> protocol header respectively. The matching is based on the rule
> specification and it includes the Vxlan header itself, so application
> will be able to send several Vxlan streams with a new vni for each stream.
>
> In order to steer traffic according to a Vxlan tunnel ID, there is a need to
> use the ibv_cmd_create_flow call. At the end of the struct, the application
> should append several specs for each feature.
>
> The number of specifications to add is 4. Use the first as the Vxlan
> spec (tunnel), which is described below. The following specifications to
> add are the L2, L3, and L4 specs.
>
> There is an option to mask a range of tunnel IDs to be steered by using
> the filler mask, This following example provides the ibv_flow_tunnel_filter
> struct definition:
>
> struct ibv_flow_tunnel_filter {
> uint32_t tunnel_id;
> };
>
> This following example specifies the Vxlan tunnel definition:
>
> struct ibv_flow_spec_tunnel {
> enum ibv_flow_spec_type type;
> uint16_t size;
> struct ibv_flow_tunnel_filter val;
> struct ibv_flow_tunnel_filter mask;
> };
>
> Where:
>
> * type - Specifies that there is a need to use IBV_FLOW_SPEC_VXLAN_TUNNEL
> to define the spec as an Vxlan spec.
> * size - Identifies the size of the ibv_kern_spec_tunnel.
> * tunnel_id: Indicates that the tunnel ID as in the Vxlan header.
>
>
> Thanks,
> Mosses and Leon.
>
> Available in the "topic/vxlan" 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/vxlan
>
> CC: Maor Gottlieb <maorg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Moses Reuben (6):
> IB/core: Add flow spec tunneling support
> IB/core: Align structure ib_flow_spec_type
> IB/uverbs: Add support for Vxlan protocol
> IB/mlx5: Support Vxlan tunneling specification
> IB/core: Introduce inner flow steering
> IB/mlx5: Add support to match inner packet fields
>
> drivers/infiniband/core/uverbs_cmd.c | 19 ++++-
> drivers/infiniband/hw/mlx5/main.c | 142 ++++++++++++++++++++++-------------
> include/rdma/ib_verbs.h | 44 +++++++----
> include/uapi/rdma/ib_user_verbs.h | 17 +++++
> 4 files changed, 155 insertions(+), 67 deletions(-)
Series applied, thanks.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/mlx4: Rework special QP creation error path
From: Doug Ledford @ 2016-12-14 18:01 UTC (permalink / raw)
To: Bart Van Assche
Cc: Yishai Hadas, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <3a41daa7-cfb8-7374-5dab-dfa3b1bf83ff-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]
On 11/14/2016 11:44 AM, Bart Van Assche wrote:
> The special QP creation error path relies on offset_of(struct mlx4_ib_sqp,
> qp) == 0. Remove this assumption because that makes the QP creation
> code easier to understand.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH, RESEND] IB/srpt: Report login failures only once
From: Doug Ledford @ 2016-12-14 17:59 UTC (permalink / raw)
To: Bart Van Assche
Cc: Nicholas A. Bellinger, Christoph Hellwig, Sagi Grimberg,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <7737d8fc-d41d-0755-d7d2-a3a2b9b6a76e-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]
On 11/11/2016 7:36 PM, Bart Van Assche wrote:
> Report the following message only once if no ACL has been configured
> yet for an initiator port:
>
> "Rejected login because no ACL has been configured yet for initiator %s.\n"
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Nicholas Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
> Cc: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> Cc: Sagi Grimberg <sagig-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR
From: Doug Ledford @ 2016-12-14 17:58 UTC (permalink / raw)
To: Julia Lawall, Christian Benvenuti
Cc: kernel-janitors, Dave Goodell, Sean Hefty, Hal Rosenstock,
linux-rdma, linux-kernel, Christophe JAILLET
In-Reply-To: <1478891066-16093-1-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1.1: Type: text/plain, Size: 931 bytes --]
On 11/11/2016 2:04 PM, Julia Lawall wrote:
> The function usnic_ib_qp_grp_get_chunk only returns an ERR_PTR value or a
> valid pointer, never NULL. The same is true of get_qp_res_chunk, which
> just returns the result of calling usnic_ib_qp_grp_get_chunk. Simplify
> IS_ERR_OR_NULL to IS_ERR in both cases.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression t,e;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> - IS_ERR_OR_NULL(t)
> + IS_ERR(t)
>
> @@
> expression t,e,e1;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> ?- t ? PTR_ERR(t) : e1
> + PTR_ERR(t)
> ... when any
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, applied.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IBcore/CM: Issue DREQ when receiving REQ/REP for stale QP
From: Doug Ledford @ 2016-12-14 17:55 UTC (permalink / raw)
To: Hans Westgaard Ry, Sean Hefty, Hal Rosenstock, Matan Barak,
Erez Shitrit, Bart Van Assche, Ira Weiny, Or Gerlitz, Hakon Bugge,
Yuval Shaia, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477653269-27359-1-git-send-email-hans.westgaard.ry-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]
On 10/28/2016 7:14 AM, Hans Westgaard Ry wrote:
> from "InfiBand Architecture Specifications Volume 1":
>
> A QP is said to have a stale connection when only one side has
> connection information. A stale connection may result if the remote CM
> had dropped the connection and sent a DREQ but the DREQ was never
> received by the local CM. Alternatively the remote CM may have lost
> all record of past connections because its node crashed and rebooted,
> while the local CM did not become aware of the remote node's reboot
> and therefore did not clean up stale connections.
>
> and:
>
> A local CM may receive a REQ/REP for a stale connection. It shall
> abort the connection issuing REJ to the REQ/REP. It shall then issue
> DREQ with "DREQ:remote QPN” set to the remote QPN from the REQ/REP.
>
> This patch solves a problem with reuse of QPN. Current codebase, that
> is IPoIB, relies on a REAP-mechanism to do cleanup of the structures
> in CM. A problem with this is the timeconstants governing this
> mechanism; they are up to 768 seconds and the interface may look
> inresponsive in that period. Issuing a DREQ (and receiving a DREP)
> does the necessary cleanup and the interface comes up.
>
> Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Håkon Bugge <haakon.bugge-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] infiniband: nes: nes_nic: use new api ethtool_{get|set}_link_ksettings
From: Doug Ledford @ 2016-12-14 17:52 UTC (permalink / raw)
To: Philippe Reynes, faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477409387-25056-1-git-send-email-tremyfr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 369 bytes --]
On 10/25/2016 11:29 AM, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/isert: do not ignore errors in dma_map_single()
From: Doug Ledford @ 2016-12-14 17:51 UTC (permalink / raw)
To: Alexey Khoroshilov, Sagi Grimberg
Cc: Sean Hefty, Hal Rosenstock, linux-rdma, target-devel,
linux-kernel, ldv-project
In-Reply-To: <1477087281-26275-1-git-send-email-khoroshilov@ispras.ru>
[-- Attachment #1.1: Type: text/plain, Size: 376 bytes --]
On 10/21/2016 6:01 PM, Alexey Khoroshilov wrote:
> There are several places, where errors in dma_map_single() are
> ignored. The patch fixes them.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Thanks, applied.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] IB/rdmavt: cq ktrhead worker fix and API update
From: Doug Ledford @ 2016-12-14 17:17 UTC (permalink / raw)
To: Dalessandro, Dennis, pmladek@suse.com, Hefty, Sean
Cc: hal.rosenstock@gmail.com, tj@kernel.org,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1476968182.23693.14.camel@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1063 bytes --]
On 10/20/2016 8:56 AM, Dalessandro, Dennis wrote:
> On Wed, 2016-10-19 at 14:07 +0200, Petr Mladek wrote:
>> The kthread worker API has been improved in 4.9-rc1. The 2nd
>> patch uses the new functions and simplifies the kthread worker
>> creation and destroying.
>>
>> I have found a possible race when working on the API conversion.
>> A proposed fix is in the 1st patch.
>>
>> Both changes are compile tested only. I did not find an easy way
>> how to test them at runtime.
>>
>> Petr Mladek (2):
>> IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker
>> IB/rdmavt: Handle the kthread worker using the new API
>>
>> drivers/infiniband/sw/rdmavt/cq.c | 64 +++++++++++++++++----------
>> ------------
>> 1 file changed, 27 insertions(+), 37 deletions(-)
>
> Thanks for the patches. I'm going to take a closer look, I just now
> seen these.
>
> -Denny
>
These looked good to me, and you haven't objected, so I'm taking this
series. Thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/mlx4: avoid a -Wmaybe-uninitialize warning
From: Doug Ledford @ 2016-12-14 17:13 UTC (permalink / raw)
To: Arnd Bergmann, Yishai Hadas
Cc: David S. Miller, Jack Morgenstein, Or Gerlitz, Eran Ben Elisha,
Moshe Shemesh, Christophe Jaillet, Moni Shoua,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161025161632.411899-1-arnd-r2nGTMty4D4@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 712 bytes --]
On 10/25/2016 12:16 PM, Arnd Bergmann wrote:
> There is an old warning about mlx4_SW2HW_EQ_wrapper on x86:
>
> ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_SW2HW_EQ_wrapper’:
> ethernet/mellanox/mlx4/resource_tracker.c:3071:10: error: ‘eq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The problem here is that gcc won't track the state of the variable
> across a spin_unlock. Moving the assignment out of the lock is
> safe here and avoids the warning.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2] IB/mlx5: avoid bogus -Wmaybe-uninitialized warning
From: Doug Ledford @ 2016-12-14 17:13 UTC (permalink / raw)
To: Arnd Bergmann, Sean Hefty, Hal Rosenstock
Cc: Matan Barak, Leon Romanovsky, Sagi Grimberg, Bart Van Assche,
Noa Osherovich, Saeed Mahameed, linux-rdma, linux-kernel
In-Reply-To: <20161024204830.620592-1-arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 1717 bytes --]
On 10/24/2016 4:48 PM, Arnd Bergmann wrote:
> We get a false-positive warning in linux-next for the mlx5 driver:
>
> infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’:
> infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> infiniband/hw/mlx5/mr.c:1161:6: note: ‘order’ was declared here
> infiniband/hw/mlx5/mr.c:1173:6: error: ‘ncont’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> infiniband/hw/mlx5/mr.c:1160:6: note: ‘ncont’ was declared here
> infiniband/hw/mlx5/mr.c:1173:6: error: ‘page_shift’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> infiniband/hw/mlx5/mr.c:1158:6: note: ‘page_shift’ was declared here
> infiniband/hw/mlx5/mr.c:1143:13: error: ‘npages’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> infiniband/hw/mlx5/mr.c:1159:6: note: ‘npages’ was declared here
>
> I had a trivial workaround for gcc-5 or higher, but that didn't work
> on gcc-4.9 unfortunately.
>
> The only way I found to avoid the warnings for gcc-4.9, short of
> initializing each of the arguments first was to change the calling
> conventions to separate the error code from the umem pointer. This
> avoids casting the error codes from one pointer to another incompatible
> pointer, and lets gcc figure out when that the data is actually valid
> whenever we return successfully.
>
> Acked-by: Leon Romanovsky <leonro@mellanox.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, applied (with fixups due to conflicts).
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH V2 08/10] i40iw: Control debug error prints using env variable
From: Leon Romanovsky @ 2016-12-14 17:11 UTC (permalink / raw)
To: Nikolova, Tatyana E
Cc: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
In-Reply-To: <13AA599688F47243B14FCFCCC2C803BB10AC7081-96pTJSsuoYQ64kNsxIetb7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 16254 bytes --]
On Tue, Dec 13, 2016 at 08:02:09PM +0000, Nikolova, Tatyana E wrote:
> Hi Leon,
>
> Please see inline.
>
> > -----Original Message-----
> > From: Leon Romanovsky [mailto:leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org]
> > Sent: Saturday, December 10, 2016 8:34 AM
> > To: Nikolova, Tatyana E <tatyana.e.nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Cc: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org; dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; linux-
> > rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > Subject: Re: [PATCH V2 08/10] i40iw: Control debug error prints using env
> > variable
> >
> > On Fri, Dec 09, 2016 at 11:55:02AM -0600, Tatyana Nikolova wrote:
> > > From: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > >
> > > Debug prints for error paths are off by default. User has the option
> > > to turn them on by setting environment variable I40IW_DEBUG in
> > command
> > > line.
> > >
> > > Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > Hi Tatyana,
> >
> > This patch duplicates already existing code in most of providers and libraries
> > in rdma-core, while two of our main goals for creating this consolidated
> > library were simplification for users and reduce code duplication.
> >
> > It will be very beneficial if you:
> > 1. Use and promote general pr_debug(..), srp_tools has nice piece of code,
> > to be general code.
>
> [Tatyana Nikolova] The debug/error printing macros available in rdma-core use different mechanisms to report information, for instance, they set/check one or more variables, or they use a bit mask to enable debug level. They also print to different outputs: stderr/stdout, debug files or syslog.
At the end, all these prints are for debug. It is hard to see any
objections to see output from them in one place.
>
> By promoting general code, do you mean that we need to implement common functions and replace all of the currently used debug macros in rdma-core with the common ones?
Yes.
>
> Which one of the different debug mechanisms should be used?
The most common, all providers copy/paste the same code.
>
> Please, provide details on what you are asking for.
>
> > 2. Create one and general place for all rdma-core's environment variables.
>
> [Tatyana Nikolova] Are you suggesting a new common header file with defines for all environmental variables in rdma-core?
>
> For example:
> # cat rdma-core/util/env_vars.h
>
> #define MLX5_CQE_SIZE "MLX5_CQE_SIZE"
> #define MLX5_SCATTER_TO_CQE "MLX5_SCATTER_TO_CQE"
> #define MLX5_SRQ_SIGNATURE "MLX5_SRQ_SIGNATURE"
> #define MLX5_QP_SIGNATURE "MLX5_QP_SIGNATURE"
> #define MLX5_LOCAL_CPUS "MLX5_LOCAL_CPUS"
> #define MLX5_STALL_CQ_POLL "MLX5_STALL_CQ_POLL"
> #define MLX5_STALL_NUM_LOOP "MLX5_STALL_NUM_LOOP"
>
> Please explain and provide an example if possible.
I had something different in mind.
The lib is interested in ENV facilities will have something like that in
their init function.
...
struct i40w_env *i40w_env;
i40w_env = get_env_vars(I40W_ENV);
...
in rdma-core/util/env.h|c
#define SET_VAR(type, var, field) \
(struct ##name*)env->field = get_env_var(...)
void *get_env_vars(enum typ)
{
void *env;
switch(type) {
case I40W_ENV:
env = malloc(sizeof(struct i40w_env));
....
SET_VAR(i40w_env, "I40W_DEBUG", debug);
...
}
>
> Thank you,
> Tatyana
>
> >
> > This infrastructure will allow us in the future create better manual of all
> > variables supported and ensure easy change if neeeded.
> >
> > Thanks
> >
> > > ---
> > > providers/i40iw/i40iw_umain.c | 11 ++++++---
> > > providers/i40iw/i40iw_umain.h | 7 ++++++
> > > providers/i40iw/i40iw_uverbs.c | 52
> > > +++++++++++++++++++++++-------------------
> > > 3 files changed, 44 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/providers/i40iw/i40iw_umain.c
> > > b/providers/i40iw/i40iw_umain.c index 1756e65..a204859 100644
> > > --- a/providers/i40iw/i40iw_umain.c
> > > +++ b/providers/i40iw/i40iw_umain.c
> > > @@ -46,7 +46,7 @@
> > > #include "i40iw_umain.h"
> > > #include "i40iw-abi.h"
> > >
> > > -unsigned int i40iw_debug_level;
> > > +unsigned int i40iw_dbg;
> > >
> > > #include <sys/types.h>
> > > #include <sys/stat.h>
> > > @@ -184,7 +184,7 @@ static struct ibv_context
> > *i40iw_ualloc_context(struct ibv_device *ibdev, int cm
> > > return &iwvctx->ibv_ctx;
> > >
> > > err_free:
> > > - fprintf(stderr, PFX "%s: failed to allocate context for device.\n",
> > __func__);
> > > + i40iw_debug("failed to allocate context for device.\n");
> > > free(iwvctx);
> > >
> > > return NULL;
> > > @@ -216,6 +216,7 @@ static struct ibv_device_ops i40iw_udev_ops = {
> > > struct ibv_device *i40iw_driver_init(const char *uverbs_sys_path, int
> > > abi_version) {
> > > char value[16];
> > > + char *env_val;
> > > struct i40iw_udevice *dev;
> > > unsigned int vendor, device;
> > > int i;
> > > @@ -236,9 +237,13 @@ struct ibv_device *i40iw_driver_init(const char
> > > *uverbs_sys_path, int abi_versio
> > >
> > > return NULL;
> > > found:
> > > + env_val = getenv("I40IW_DEBUG");
> > > + if (env_val)
> > > + i40iw_dbg = atoi(env_val);
> > > +
> > > dev = malloc(sizeof(*dev));
> > > if (!dev) {
> > > - fprintf(stderr, PFX "%s: failed to allocate memory for device
> > object\n", __func__);
> > > + i40iw_debug("failed to allocate memory for device
> > object\n");
> > > return NULL;
> > > }
> > >
> > > diff --git a/providers/i40iw/i40iw_umain.h
> > > b/providers/i40iw/i40iw_umain.h index 13d3da8..889c006 100644
> > > --- a/providers/i40iw/i40iw_umain.h
> > > +++ b/providers/i40iw/i40iw_umain.h
> > > @@ -72,6 +72,13 @@
> > > #define I40E_DB_SHADOW_AREA_SIZE 64
> > > #define I40E_DB_CQ_OFFSET 0x40
> > >
> > > +extern unsigned int i40iw_dbg;
> > > +#define i40iw_debug(fmt, args...) \
> > > +do { \
> > > + if (i40iw_dbg) \
> > > + fprintf(stderr, PFX "%s: " fmt, __FUNCTION__, ##args); \ }
> > while
> > > +(0)
> > > +
> > > enum i40iw_uhca_type {
> > > INTEL_i40iw
> > > };
> > > diff --git a/providers/i40iw/i40iw_uverbs.c
> > > b/providers/i40iw/i40iw_uverbs.c index f6d9196..464900b 100644
> > > --- a/providers/i40iw/i40iw_uverbs.c
> > > +++ b/providers/i40iw/i40iw_uverbs.c
> > > @@ -65,7 +65,7 @@ int i40iw_uquery_device(struct ibv_context *context,
> > > struct ibv_device_attr *att
> > >
> > > ret = ibv_cmd_query_device(context, attr, &i40iw_fw_ver, &cmd,
> > sizeof(cmd));
> > > if (ret) {
> > > - fprintf(stderr, PFX "%s: query device failed and returned
> > status code: %d\n", __func__, ret);
> > > + i40iw_debug("query device failed and returned status code:
> > %d\n",
> > > +ret);
> > > return ret;
> > > }
> > >
> > > @@ -165,7 +165,7 @@ struct ibv_mr *i40iw_ureg_mr(struct ibv_pd *pd,
> > void *addr, size_t length, int a
> > > if (ibv_cmd_reg_mr(pd, addr, length, (uintptr_t)addr,
> > > access, mr, &cmd.ibv_cmd, sizeof(cmd),
> > > &resp, sizeof(resp))) {
> > > - fprintf(stderr, PFX "%s: Failed to register memory\n",
> > __func__);
> > > + i40iw_debug("Failed to register memory\n");
> > > free(mr);
> > > return NULL;
> > > }
> > > @@ -264,7 +264,7 @@ struct ibv_cq *i40iw_ucreate_cq(struct ibv_context
> > *context, int cqe,
> > > &iwucq->mr, ®_mr_cmd.ibv_cmd,
> > sizeof(reg_mr_cmd), ®_mr_resp,
> > > sizeof(reg_mr_resp));
> > > if (ret) {
> > > - fprintf(stderr, PFX "%s: failed to pin memory for CQ\n",
> > __func__);
> > > + i40iw_debug("failed to pin memory for CQ\n");
> > > goto err;
> > > }
> > >
> > > @@ -274,7 +274,7 @@ struct ibv_cq *i40iw_ucreate_cq(struct ibv_context
> > *context, int cqe,
> > > &resp.ibv_resp, sizeof(resp));
> > > if (ret) {
> > > ibv_cmd_dereg_mr(&iwucq->mr);
> > > - fprintf(stderr, PFX "%s: failed to create CQ\n", __func__);
> > > + i40iw_debug("failed to create CQ\n");
> > > goto err;
> > > }
> > >
> > > @@ -286,7 +286,7 @@ struct ibv_cq *i40iw_ucreate_cq(struct ibv_context
> > *context, int cqe,
> > > if (!ret)
> > > return &iwucq->ibv_cq;
> > > else
> > > - fprintf(stderr, PFX "%s: failed to initialze CQ, status %d\n",
> > __func__, ret);
> > > + i40iw_debug("failed to initialze CQ, status %d\n", ret);
> > > err:
> > > if (info.cq_base)
> > > free(info.cq_base);
> > > @@ -307,11 +307,11 @@ int i40iw_udestroy_cq(struct ibv_cq *cq)
> > >
> > > ret = pthread_spin_destroy(&iwucq->lock);
> > > if (ret)
> > > - return ret;
> > > + goto err;
> > >
> > > ret = ibv_cmd_destroy_cq(cq);
> > > if (ret)
> > > - return ret;
> > > + goto err;
> > >
> > > ibv_cmd_dereg_mr(&iwucq->mr);
> > >
> > > @@ -319,6 +319,9 @@ int i40iw_udestroy_cq(struct ibv_cq *cq)
> > > free(iwucq);
> > >
> > > return 0;
> > > +err:
> > > + i40iw_debug("failed to destroy CQ, status %d\n", ret);
> > > + return ret;
> > > }
> > >
> > > /**
> > > @@ -344,7 +347,7 @@ int i40iw_upoll_cq(struct ibv_cq *cq, int
> > num_entries, struct ibv_wc *entry)
> > > if (ret == I40IW_ERR_QUEUE_EMPTY) {
> > > break;
> > > } else if (ret) {
> > > - fprintf(stderr, PFX "%s: Error polling CQ, status
> > %d\n", __func__, ret);
> > > + i40iw_debug("Error polling CQ, status %d\n", ret);
> > > if (!cqe_count)
> > > /* Indicate error */
> > > cqe_count = -1;
> > > @@ -519,7 +522,7 @@ static int i40iw_vmapped_qp(struct i40iw_uqp
> > *iwuqp, struct ibv_pd *pd,
> > > info->sq = memalign(I40IW_HW_PAGE_SIZE, totalqpsize);
> > >
> > > if (!info->sq) {
> > > - fprintf(stderr, PFX "%s: failed to allocate memory for SQ\n",
> > __func__);
> > > + i40iw_debug("failed to allocate memory for SQ\n");
> > > return 0;
> > > }
> > >
> > > @@ -535,7 +538,7 @@ static int i40iw_vmapped_qp(struct i40iw_uqp
> > *iwuqp, struct ibv_pd *pd,
> > > IBV_ACCESS_LOCAL_WRITE, &iwuqp->mr,
> > ®_mr_cmd.ibv_cmd,
> > > sizeof(reg_mr_cmd), ®_mr_resp,
> > sizeof(reg_mr_resp));
> > > if (ret) {
> > > - fprintf(stderr, PFX "%s: failed to pin memory for SQ\n",
> > __func__);
> > > + i40iw_debug("failed to pin memory for SQ\n");
> > > free(info->sq);
> > > return 0;
> > > }
> > > @@ -545,7 +548,7 @@ static int i40iw_vmapped_qp(struct i40iw_uqp
> > *iwuqp, struct ibv_pd *pd,
> > > ret = ibv_cmd_create_qp(pd, &iwuqp->ibv_qp, attr, &cmd.ibv_cmd,
> > sizeof(cmd),
> > > &resp->ibv_resp, sizeof(struct
> > i40iw_ucreate_qp_resp));
> > > if (ret) {
> > > - fprintf(stderr, PFX "%s: failed to create QP, status %d\n",
> > __func__, ret);
> > > + i40iw_debug("failed to create QP, status %d\n", ret);
> > > ibv_cmd_dereg_mr(&iwuqp->mr);
> > > free(info->sq);
> > > return 0;
> > > @@ -565,7 +568,7 @@ static int i40iw_vmapped_qp(struct i40iw_uqp
> > *iwuqp, struct ibv_pd *pd,
> > > map = mmap(NULL, I40IW_HW_PAGE_SIZE, PROT_WRITE |
> > PROT_READ, MAP_SHARED,
> > > pd->context->cmd_fd, offset);
> > > if (map == MAP_FAILED) {
> > > - fprintf(stderr, PFX "%s: failed to map push page,
> > errno %d\n", __func__, errno);
> > > + i40iw_debug("failed to map push page, errno %d\n",
> > errno);
> > > info->push_wqe = NULL;
> > > info->push_db = NULL;
> > > } else {
> > > @@ -575,7 +578,7 @@ static int i40iw_vmapped_qp(struct i40iw_uqp
> > *iwuqp, struct ibv_pd *pd,
> > > map = mmap(NULL, I40IW_HW_PAGE_SIZE,
> > PROT_WRITE | PROT_READ, MAP_SHARED,
> > > pd->context->cmd_fd, offset);
> > > if (map == MAP_FAILED) {
> > > - fprintf(stderr, PFX "%s: failed to map push
> > doorbell, errno %d\n", __func__, errno);
> > > + i40iw_debug("failed to map push doorbell,
> > errno %d\n", errno);
> > > munmap(info->push_wqe,
> > I40IW_HW_PAGE_SIZE);
> > > info->push_wqe = NULL;
> > > info->push_db = NULL;
> > > @@ -639,7 +642,7 @@ struct ibv_qp *i40iw_ucreate_qp(struct ibv_pd *pd,
> > struct ibv_qp_init_attr *attr
> > > int sq_attr, rq_attr;
> > >
> > > if (attr->qp_type != IBV_QPT_RC) {
> > > - fprintf(stderr, PFX "%s: failed to create QP, unsupported QP
> > type: 0x%x\n", __func__, attr->qp_type);
> > > + i40iw_debug("failed to create QP, unsupported QP type:
> > 0x%x\n",
> > > +attr->qp_type);
> > > return NULL;
> > > }
> > >
> > > @@ -658,8 +661,8 @@ struct ibv_qp *i40iw_ucreate_qp(struct ibv_pd *pd,
> > struct ibv_qp_init_attr *attr
> > > /* Sanity check QP size before proceeding */
> > > sqdepth = i40iw_qp_get_qdepth(sq_attr, attr->cap.max_send_sge,
> > attr->cap.max_inline_data);
> > > if (!sqdepth) {
> > > - fprintf(stderr, PFX "%s: invalid SQ attributes,
> > max_send_wr=%d max_send_sge=%d\n",
> > > - __func__, attr->cap.max_send_wr, attr-
> > >cap.max_send_sge);
> > > + i40iw_debug("invalid SQ attributes, max_send_wr=%d
> > max_send_sge=%d\n",
> > > + attr->cap.max_send_wr, attr->cap.max_send_sge);
> > > return NULL;
> > > }
> > >
> > > @@ -691,13 +694,13 @@ struct ibv_qp *i40iw_ucreate_qp(struct ibv_pd
> > *pd, struct ibv_qp_init_attr *attr
> > > info.sq_wrtrk_array = calloc(sqdepth, sizeof(*info.sq_wrtrk_array));
> > >
> > > if (!info.sq_wrtrk_array) {
> > > - fprintf(stderr, PFX "%s: failed to allocate memory for SQ work
> > array\n", __func__);
> > > + i40iw_debug("failed to allocate memory for SQ work
> > array\n");
> > > goto err_destroy_lock;
> > > }
> > >
> > > info.rq_wrid_array = calloc(rqdepth, sizeof(*info.rq_wrid_array));
> > > if (!info.rq_wrid_array) {
> > > - fprintf(stderr, PFX "%s: failed to allocate memory for RQ
> > work array\n", __func__);
> > > + i40iw_debug("failed to allocate memory for RQ work
> > array\n");
> > > goto err_free_sq_wrtrk;
> > > }
> > >
> > > @@ -706,7 +709,7 @@ struct ibv_qp *i40iw_ucreate_qp(struct ibv_pd *pd,
> > struct ibv_qp_init_attr *attr
> > > status = i40iw_vmapped_qp(iwuqp, pd, attr, &resp, sqdepth,
> > rqdepth,
> > > &info);
> > >
> > > if (!status) {
> > > - fprintf(stderr, PFX "%s: failed to map QP\n", __func__);
> > > + i40iw_debug("failed to map QP\n");
> > > goto err_free_rq_wrid;
> > > }
> > > info.qp_id = resp.qp_id;
> > > @@ -772,11 +775,11 @@ int i40iw_udestroy_qp(struct ibv_qp *qp)
> > >
> > > ret = pthread_spin_destroy(&iwuqp->lock);
> > > if (ret)
> > > - return ret;
> > > + goto err;
> > >
> > > ret = i40iw_destroy_vmapped_qp(iwuqp, iwuqp->qp.sq_base);
> > > if (ret)
> > > - return ret;
> > > + goto err;
> > >
> > > if (iwuqp->qp.sq_wrtrk_array)
> > > free(iwuqp->qp.sq_wrtrk_array);
> > > @@ -792,6 +795,9 @@ int i40iw_udestroy_qp(struct ibv_qp *qp)
> > > free(iwuqp);
> > >
> > > return 0;
> > > +err:
> > > + i40iw_debug("failed to destroy QP, status %d\n", ret);
> > > + return ret;
> > > }
> > >
> > > /**
> > > @@ -916,7 +922,7 @@ int i40iw_upost_send(struct ibv_qp *ib_qp, struct
> > ibv_send_wr *ib_wr, struct ibv
> > > default:
> > > /* error */
> > > err = -EINVAL;
> > > - fprintf(stderr, PFX "%s: post work request failed,
> > invalid opcode: 0x%x\n", __func__, ib_wr->opcode);
> > > + i40iw_debug("post work request failed, invalid
> > opcode: 0x%x\n",
> > > +ib_wr->opcode);
> > > break;
> > > }
> > >
> > > @@ -960,7 +966,7 @@ int i40iw_upost_recv(struct ibv_qp *ib_qp, struct
> > ibv_recv_wr *ib_wr, struct ibv
> > > post_recv.sg_list = sg_list;
> > > ret = iwuqp->qp.ops.iw_post_receive(&iwuqp->qp,
> > &post_recv);
> > > if (ret) {
> > > - fprintf(stderr, PFX "%s: failed to post receives, status
> > %d\n", __func__, ret);
> > > + i40iw_debug("failed to post receives, status %d\n",
> > ret);
> > > if (ret == I40IW_ERR_QP_TOOMANY_WRS_POSTED)
> > > err = -ENOMEM;
> > > else
> > > --
> > > 1.8.5.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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/rdmavt: Only put mmap_info ref if it exists
From: Doug Ledford @ 2016-12-14 16:51 UTC (permalink / raw)
To: Jim Foraker, linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: Dennis Dalessandro
In-Reply-To: <1478033052-147252-1-git-send-email-foraker1-i2BcT+NCU+M@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 620 bytes --]
On 11/1/2016 4:44 PM, Jim Foraker wrote:
> rvt_create_qp() creates qp->ip only when a qp creation request comes from
> userspace (udata is not NULL). If we exceed the number of available
> queue pairs however, the error path always attempts to put a kref to this
> structure. If the requestor is inside the kernel, this leads to a crash.
>
> We fix this by checking that qp->ip is not NULL before caling kref_put().
>
> Signed-off-by: Jim Foraker <foraker1-i2BcT+NCU+M@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] rdma UAPI: Use __kernel_sockaddr_storage
From: Doug Ledford @ 2016-12-14 16:43 UTC (permalink / raw)
To: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477587077-15410-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 447 bytes --]
On 10/27/2016 12:51 PM, Jason Gunthorpe wrote:
> The kernel side is #ifdef'd to this type, and the UAPI header
> should use it directly. It has slightly different alignment
> requirments from the usual user space version.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/8] connect reject event helpers
From: Doug Ledford @ 2016-12-14 16:38 UTC (permalink / raw)
To: Steve Wise, sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagi-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg,
santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA
In-Reply-To: <017401d24a62$bcedd7c0$36c98740$@opengridcomputing.com>
[-- Attachment #1.1: Type: text/plain, Size: 315 bytes --]
On 11/29/2016 12:05 PM, Steve Wise wrote:
> Hey Doug,
>
> Are you planning to merge this series for 4.10? They're still marked 'new' on
> patchworks.
>
> Thanks,
>
> Steve.
>
Yes, series applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] net/mlx5: Report multi packet WQE capabilities
From: Doug Ledford @ 2016-12-14 16:31 UTC (permalink / raw)
To: Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Bodong Wang
In-Reply-To: <1477908921-12222-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 587 bytes --]
On 10/31/2016 6:15 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Multi packet WQE enables sending multiple fix sized packets
> using a single WQE. The exposed field reports such HW support.
>
> Signed-off-by: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Both the WQE and CQE capabilities patch series applied, thanks.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH -next] qedr: Use list_move_tail instead of list_del/list_add_tail
From: Doug Ledford @ 2016-12-14 16:29 UTC (permalink / raw)
To: Wei Yongjun, Sean Hefty, Hal Rosenstock, Ram Amrani,
Rajesh Borundia
Cc: Wei Yongjun, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477757993-32186-1-git-send-email-weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 398 bytes --]
On 10/29/2016 12:19 PM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Using list_move_tail() instead of list_del() + list_add_tail().
>
> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] qedr: Fix possible memory leak in qedr_create_qp()
From: Doug Ledford @ 2016-12-14 16:29 UTC (permalink / raw)
To: Wei Yongjun, Sean Hefty, Hal Rosenstock, Ram Amrani,
Rajesh Borundia
Cc: Wei Yongjun, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477672427-31575-1-git-send-email-weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]
On 10/28/2016 12:33 PM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> 'qp' is malloced in qedr_create_qp() and should be freed before leaving
> from the error handling cases, otherwise it will cause memory leak.
>
> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2] qedr: remove pointless NULL check in qedr_post_send()
From: Doug Ledford @ 2016-12-14 16:28 UTC (permalink / raw)
To: Wei Yongjun, Sean Hefty, Hal Rosenstock, Ram Amrani,
Rajesh Borundia, Leon Romanovsky
Cc: Wei Yongjun, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478092292-17225-1-git-send-email-weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]
On 11/2/2016 9:11 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Remove pointless NULL check for 'wr' in qedr_post_send().
>
> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-core] qede: fix general protection fault may occur on probe
From: Doug Ledford @ 2016-12-14 16:26 UTC (permalink / raw)
To: Amrani, Ram
Cc: Elior, Ariel, Kalderon, Michal, Mintz, Yuval,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <SN1PR07MB2207D200A1EF95EBFAAEBCFFF8BD0-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1472 bytes --]
On 11/13/2016 11:42 AM, Amrani, Ram wrote:
>> The recent introduction of qedr driver support in qede causes a GPF when
>> probing the driver in a server without a RoCE enabled QLogic NIC. This fix avoids
>> using an uninitialized pointer in such a case. Caught by the kernel test robot.
>>
>> Signed-off-by: Ram Amrani <Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>> ---
>> drivers/net/ethernet/qlogic/qede/qede_roce.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/qlogic/qede/qede_roce.c
>> b/drivers/net/ethernet/qlogic/qede/qede_roce.c
>> index 9867f96..4927271 100644
>> --- a/drivers/net/ethernet/qlogic/qede/qede_roce.c
>> +++ b/drivers/net/ethernet/qlogic/qede/qede_roce.c
>> @@ -191,8 +191,8 @@ int qede_roce_register_driver(struct qedr_driver *drv)
>> }
>> mutex_unlock(&qedr_dev_list_lock);
>>
>> - DP_INFO(edev, "qedr: discovered and registered %d RoCE funcs\n",
>> - qedr_counter);
>> + pr_notice("qedr: discovered and registered %d RoCE funcs\n",
>> + qedr_counter);
>>
>> return 0;
>> }
>> --
>> 1.8.3.1
>
>
> Hi Doug,
> Can you update if this patch taken and if not, when do you expect it will be?
This patch no longer applies. But, more importantly, it's a patch to
the ethernet side of the driver and should go through Dave Miller anyway.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] qedr: return -EINVAL if pd is null and avoid null ptr dereference
From: Doug Ledford @ 2016-12-14 16:25 UTC (permalink / raw)
To: Colin King, Sean Hefty, Hal Rosenstock, Rajesh Borundia,
Ram Amrani, linux-rdma
Cc: linux-kernel
In-Reply-To: <20161018183928.8539-1-colin.king@canonical.com>
[-- Attachment #1.1: Type: text/plain, Size: 434 bytes --]
On 10/18/2016 2:39 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently, if pd is null then we hit a null pointer derference
> on accessing pd->pd_id. Instead of just printing an error message
> we should also return -EINVAL immediately.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/mad: Eliminate redundant SM class version defines for OPA
From: Doug Ledford @ 2016-12-14 16:02 UTC (permalink / raw)
To: Hal Rosenstock
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Weiny, Ira
In-Reply-To: <3995ed79-d933-1c93-1fa6-3f03b7e51d44-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 406 bytes --]
On 10/18/2016 1:20 PM, Hal Rosenstock wrote:
>
> and rename class version define to indicate SM rather than SMP or SMI
>
> Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: SR-IOV with mlx4 on ConnectX-2 fails with DMAR errors
From: Joshua McBeth @ 2016-12-14 15:06 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Leon Romanovsky, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161213190102.GA15119-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Tue, Dec 13, 2016 at 2:01 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
>
> On Tue, Dec 13, 2016 at 01:36:42PM -0500, Joshua McBeth wrote:
> > I bisected the kernel between v4.1 and v4.3.1 by booting each build on
> > the SR-IOV host and attempting to "ping x.x.x.x" with x.x.x.x being
> > the IP address assigned to the Infiniband interface of a remote host
> >
> > At 4be90bc's parent the SR-IOV host is able to ping the remote host,
> > but at 4be90bc the SR-IOV host is not able to ping the remote host
> > (destination host unreachable)
>
> Okay, that makes sense
>
> > The DMAR errors occur in both the kernel built at 4be90bc (not passing
> > ping test) and its parent (passing ping test)
>
> Continuing to bisect until you find the commit that introduces the
> DMAR errors would also be helpful, I think.
I will do this when I find some time and report back with the results.
>
>
>
> > Reverting only the commit 4be90bc from a later kernel (4.8.x) does not
> > enable the SR-IOV host to ping the remote host, which to me suggests
> > that another commit after 4be90bc is also causing my test to fail.
>
> Okay, that does not seem too surprising.
>
> Does this make your 4.8 kernel work? If yes, then I suspect mlx4 has
> broken IB_DEVICE_LOCAL_DMA_LKEY with SRIOV.. Leon? mlx5 has this
> broken, doesn't it?
>
With 4.8.1 and the below applied to the SR-IOV host and guest kernels,
SR-IOV functions in both the SR-IOV host and guests and there are no
DMAR errors emitted. The NFS/RDMA client in the guest does not work
on the SR-IOV virtual function with the NFS/RDMA server of the host on
the SR-IOV physical function, but this may be something else I need to
troubleshoot further, as both IPoIB and synthetic RDMA traffic passes
between the guest, host, and remote node just fine. The remote node's
NFS/RDMA client is additionally able to function with the host's
NFS/RDMA server on the SR-IOV physical function.
>
> It would also be very helpful to try and determine what memory the NIC is
> trying to read.. If it is the ipoib packet or some mlx4 internal
> thing.
How can I determine this?
> diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
> index 2be4ea0cda9c19..1346924d27691f 100644
> --- a/drivers/infiniband/core/verbs.c
> +++ b/drivers/infiniband/core/verbs.c
> @@ -243,6 +243,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device, unsigned int flags,
> atomic_set(&pd->usecnt, 0);
> pd->flags = flags;
>
> + device->attrs.device_cap_flags = 0;
> +
> if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
> pd->local_dma_lkey = device->local_dma_lkey;
> else
>
> Jason
Apologies for duplicates, I am resending with subject for threading.
On Tue, Dec 13, 2016 at 2:01 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> On Tue, Dec 13, 2016 at 01:36:42PM -0500, Joshua McBeth wrote:
>> I bisected the kernel between v4.1 and v4.3.1 by booting each build on
>> the SR-IOV host and attempting to "ping x.x.x.x" with x.x.x.x being
>> the IP address assigned to the Infiniband interface of a remote host
>>
>> At 4be90bc's parent the SR-IOV host is able to ping the remote host,
>> but at 4be90bc the SR-IOV host is not able to ping the remote host
>> (destination host unreachable)
>
> Okay, that makes sense
>
>> The DMAR errors occur in both the kernel built at 4be90bc (not passing
>> ping test) and its parent (passing ping test)
>
> Continuing to bisect until you find the commit that introduces the
> DMAR errors would also be helpful, I think.
>
>> Reverting only the commit 4be90bc from a later kernel (4.8.x) does not
>> enable the SR-IOV host to ping the remote host, which to me suggests
>> that another commit after 4be90bc is also causing my test to fail.
>
> Okay, that does not seem too surprising.
>
> Does this make your 4.8 kernel work? If yes, then I suspect mlx4 has
> broken IB_DEVICE_LOCAL_DMA_LKEY with SRIOV.. Leon? mlx5 has this
> broken, doesn't it?
>
> It would also be very helpful to try and determine what memory the NIC is
> trying to read.. If it is the ipoib packet or some mlx4 internal
> thing.
>
> diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
> index 2be4ea0cda9c19..1346924d27691f 100644
> --- a/drivers/infiniband/core/verbs.c
> +++ b/drivers/infiniband/core/verbs.c
> @@ -243,6 +243,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device, unsigned int flags,
> atomic_set(&pd->usecnt, 0);
> pd->flags = flags;
>
> + device->attrs.device_cap_flags = 0;
> +
> if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
> pd->local_dma_lkey = device->local_dma_lkey;
> else
>
> 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
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