Please pull rdma.git

Hi Linus,

This has been a slow -rc cycle for the RDMA subsystem.  We really haven't had a lot of rc fixes come in.  This pull request is the first of this entire rc cycle and it has all of the suitable fixes so far and it's still only about 20 patches.  The fix for the minor breakage cause by the dma mapping patchset is in here, as well as a couple other potential oops fixes, but the rest is more minor.

Here's the boilerplate:

The following changes since commit
97da3854c526d3a6ee05c849c96e48d21527606c:

  Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
tags/for-linus

for you to fetch changes up to
f6aafac184a3e46e919769dd4faa8bf0dc436534:

  IB/qib: fix false-postive maybe-uninitialized warning (2017-03-24 22:44:29 -0400)

----------------------------------------------------------------
Fixups for -rc4 kernel

- Fix for dma_ops change in this kernel, resolving the s390, powerpc, and IOMMU operation
- A few other oops fixes
- The rest are all minor fixes

----------------------------------------------------------------
Adit Ranadive (2):
      RDMA/vmw_pvrdma: Cleanup unused variables RDMA/vmw_pvrdma: Dont hardcode QP header page

Aditya Sarwade (1):
      RDMA/vmw_pvrdma: Activate device on ethernet link up

Arnd Bergmann (1):
      IB/qib: fix false-postive maybe-uninitialized warning

Bart Van Assche (1):
      IB/core: Restore I/O MMU, s390 and powerpc support

Dan Carpenter (2):
      IB/rxe: double free on error
      RDMA/ocrdma: fix a type issue in ocrdma_put_pd_num()

David Marchand (1):
      IB/rxe: increment msn only when completing a request

Dmitry V. Levin (1):
      uapi: fix rdma/mlx5-abi.h userspace compilation errors

Jason Gunthorpe (1):
      infiniband: Fix alignment of mmap cookies to support VIPT caching

Leon Romanovsky (1):
      IB/rxe: Update documentation link

Sagi Grimberg (4):
      IB/core: Protect against self-requeue of a cq work item IB/cq: Don't process more than the given budget IB/device: Convert ib-comp-wq to be CPU-bound RDMA/iser: Fix possible mr leak on device removal event

Shiraz Saleem (1):
      i40iw: Receive netdev events post INET_NOTIFIER state

 drivers/infiniband/core/cq.c                      | 10 ++++-- drivers/infiniband/core/device.c                  | 29 +++++++++++--
---
 drivers/infiniband/hw/i40iw/i40iw_utils.c         |  8 +++++ drivers/infiniband/hw/ocrdma/ocrdma_verbs.c       |  2 +- drivers/infiniband/hw/qib/qib_iba7322.c           |  2 +- drivers/infiniband/hw/vmw_pvrdma/pvrdma.h         |  3 ++ drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h |  2 +- drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c    | 17 ++++++--- drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c      | 42 ++++++++++-----
--------
 drivers/infiniband/sw/rdmavt/mmap.c               |  4 +-- drivers/infiniband/sw/rxe/Kconfig                 |  2 +- drivers/infiniband/sw/rxe/rxe_mmap.c              |  4 +-- drivers/infiniband/sw/rxe/rxe_req.c               |  2 +- drivers/infiniband/sw/rxe/rxe_resp.c              |  9 +++-- drivers/infiniband/ulp/iser/iscsi_iser.h          |  2 ++ drivers/infiniband/ulp/iser/iser_verbs.c          |  8 +++-- include/rdma/ib_verbs.h                           | 30 +++++++++----
---
 include/uapi/rdma/mlx5-abi.h                      |  3 +-

 18 files changed, 110 insertions(+), 69 deletions(-)

Doug Ledford <[email protected]>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I am getting *very* irritated with the rdma pull requests.

I'm looking at your commits, and they have all been done on a Friday evening between 4pm and 11pm (with the bulk being after 9pm).

So what the hell happened in the rdma subsystem the rest of the week? That's just *odd*. Why am I getting a pull request on a Saturday with stuff that was done late Friday night?

Can you understand why it feels very hurried to me, and why I get a feeling that you're timing your work and your pull requests for the rc releases on a Sunday?

What testing did this branch get during the week? Several patches have dates from a month ago, but regardless they all show this pattern of looking like they were hurriedly committed the night before being sent off..

It just fails the smell test. What's going on here?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I checked out these machines in our RDMA cluster:

rdma-dev-17.lab.bos.redhat.com - Intel KnightsLanding F with OPA
dledford HTTP 2017-03-22 10:34:04 -04:00 Distro
Tree Provision Fedora-26-20170320.n.0 Everything
x86_64

rdma-dev-19.lab.bos.redhat.com - ConnectX-4 IB/RoCE (using LACP LAG)
dledford HTTP 2017-03-22 10:34:28 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-dev-20.lab.bos.redhat.com - ConnectX-4 IB/RoCE (using LACP LAG)
dledford HTTP 2017-03-22 10:34:45 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-dev-22.lab.bos.redhat.com - ConnectX-4 IB/RoCE (100Gig on both)
dledford HTTP 2017-03-22 10:35:07 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-perf-01.lab.bos.redhat.com - ConnectX-3 IB/RoCE (56Gig on both)
dledford HTTP 2017-03-22 10:35:23 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-virt-00.lab.bos.redhat.com - ConnectX-3 Pro (IB/RoCE) (56Gig)
dledford HTTP 2017-03-22 10:35:45 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-dev-12.lab.bos.redhat.com - cxgb4 (iWARP) (40Gig)
dledford HTTP 2017-03-22 10:45:19 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-dev-06.lab.bos.redhat.com - qib (IB) (40Gig)
dledford HTTP 2017-03-22 10:44:35 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

rdma-dev-04.lab.bos.redhat.com - mthca (IB) (20Gig)
dledford HTTP 2017-03-22 10:36:42 -04:00 Distro
Tree Provision Fedora-Rawhide-20170321.n.0
Everything x86_64

This gave me direct testing of OPA/hfi1, iWARP/cxgb4, IB/mthca;mlx4;mlx5;qib, and RoCE/mlx5;mlx4.  The ocrdma and bnxt_re RoCE machines were checked out by other people, so I skipped those.  I then did my work on the cluster itself.  I brought in all the patches I sent you, plus an additional 15 patches that I needed to test so I could give an Acked-by/Tested-by to them.  I then spent my time testing them in the cluster.  When I was satisfied, I pulled them again, one at a time, from patchworks, applied them to my normal work tree on my workstation, emailed the mailing list, then marked the patch approved in patchworks.  I do those four things in sequence every time now (get from patchworks, apply, email reply, marked approved in patchworks). It's how I keep patchworks and my mailing list email in sync and if I don't follow this pattern, I have lost a patch or two in the past.  For the for-next area, where I'm going to commit the code and if it's wrong do a revert, the dates will be more representative of when I'm doing the work.  When I'm building and testing a bunch of -rc fixes like this, I'm more likely to do an initial pull in the cluster, test it and make sure I'm happy with all of the patches, then basically do it all over again with a list of known good patches when I'm satisfied with my testing.

Because I leave for an RDMA conference on Monday morning, so I needed to get it in.  It wasn't rushed in the sense you are thinking, but I am running out of time before I leave and I did want to get it in.

I absolutely *was* trying to beat your sunday -rc tag, because I want groups that aren't going to be at this conference (such as the Mellanox QE team that tests upstream kernels) to have something to test against while the rest of us are there.  They tend to pull -rc tags and go from there.

I pulled and tested them in the Red Hat cluster this week, and when I was satisfied with the overall set of patches, pulled those that were actually mine to submit and not part of the PCI pool changes and built a branch and submitted that branch to you.

Doug Ledford <[email protected]>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

FWIW, it normally wouldn't take me that long to do my testing, but this was the first time that I had configured these machines to use dual port LACP LAG and then run RoCE over the top of the bonded interface. There was a lot of time spent getting the settings in the switches and the configuration files for NetworkManager all tweaked properly.

Doug Ledford <[email protected]>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html