Linux-RDMA Archive on lore.kernel.org
 help / color / Atom feed
* [PULL REQUEST] Please pull rdma.git
@ 2019-08-14 14:59 Doug Ledford
  2019-08-14 18:25 ` pr-tracker-bot
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2019-08-14 14:59 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3537 bytes --]

Hi Linus,

Fairly small pull request for -rc3.  I'm out of town the rest of this
week, so I made sure to clean out as much as possible from patchworks in
enough time for 0-day to chew through it (Yay! for 0-day being back
online! :-)).  Jason might send through any emergency stuff that could
pop up, otherwise I'm back next week.

The only real thing of note is the siw ABI change.  Since we just merged
siw *this* release, there are no prior kernel releases to maintain
kernel ABI with.  I told Bernard that if there is anything else about
the siw ABI he thinks he might want to change before it goes set in
stone, he should get it in ASAP.  The siw module was around for several
years outside the kernel tree, and it had to be revamped considerably
for inclusion upstream, so we are making no attempts to be backward
compatible with the out of tree version.  Once 5.3 is actually released,
we will have our baseline ABI to maintain.

Here's the boiler plate:

The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:

  Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 2c8ccb37b08fe364f02a9914daca474d43151453:

  RDMA/siw: Change CQ flags from 64->32 bits (2019-08-13 12:22:06 -0400)

----------------------------------------------------------------
Pull request for 5.3-rc3

- Fix a memory registration release flow issue that was causing a
  WARN_ON (mlx5)
- If the counters for a port aren't allocated, then we can't do
  operations on the non-existent counters (core)
- Check the right variable for error code result (mlx5)
- Fix a use after free issue (mlx5)
- Fix an off by one memory leak (siw)
- Actually return an error code on error (core)
- Allow siw to be built on 32bit arches (siw, ABI change, but OK since
  siw was just merged this merge window and there is no prior released
  kernel to maintain compatibility with and we also updated the
  rdma-core user space package to match)

Signed-off-by: Doug Ledford <dledford@redhat.com>

----------------------------------------------------------------
Bernard Metzler (1):
      RDMA/siw: Change CQ flags from 64->32 bits

Dan Carpenter (3):
      IB/mlx5: Check the correct variable in error handling code
      RDMA/siw: Fix a memory leak in siw_init_cpulist()
      RDMA/core: Fix error code in stat_get_doit_qp()

Mark Zhang (1):
      RDMA/counter: Prevent QP counter binding if counters unsupported

Yishai Hadas (2):
      IB/mlx5: Fix implicit MR release flow
      IB/mlx5: Fix use-after-free error while accessing ev_file pointer

 drivers/infiniband/core/counters.c    |  6 ++++++
 drivers/infiniband/core/nldev.c       |  8 ++++++--
 drivers/infiniband/core/umem_odp.c    |  4 ----
 drivers/infiniband/hw/mlx5/devx.c     | 11 ++++++-----
 drivers/infiniband/hw/mlx5/odp.c      | 24 +++++++++---------------
 drivers/infiniband/sw/siw/Kconfig     |  2 +-
 drivers/infiniband/sw/siw/siw.h       |  2 +-
 drivers/infiniband/sw/siw/siw_main.c  |  4 +---
 drivers/infiniband/sw/siw/siw_qp.c    | 14 ++++++++++----
 drivers/infiniband/sw/siw/siw_verbs.c | 16 +++++++++++-----
 include/uapi/rdma/siw-abi.h           |  3 ++-
 11 files changed, 53 insertions(+), 41 deletions(-)

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2019-08-14 14:59 [PULL REQUEST] Please pull rdma.git Doug Ledford
@ 2019-08-14 18:25 ` pr-tracker-bot
  0 siblings, 0 replies; 186+ messages in thread
From: pr-tracker-bot @ 2019-08-14 18:25 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, Gunthorpe, Jason, linux-rdma, linux-kernel

The pull request you sent on Wed, 14 Aug 2019 10:59:07 -0400:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a8dba0531bc0ba8b65e77a4a858da4b6eeaa1b92

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2019-08-02 14:39 Doug Ledford
@ 2019-08-02 22:10 ` pr-tracker-bot
  0 siblings, 0 replies; 186+ messages in thread
From: pr-tracker-bot @ 2019-08-02 22:10 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, Gunthorpe, Jason, linux-rdma, linux-kernel

The pull request you sent on Fri, 02 Aug 2019 10:39:04 -0400:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b07042ca32ffca69b4e3c3b938bb89ab8aa18035

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2019-08-02 14:39 Doug Ledford
  2019-08-02 22:10 ` pr-tracker-bot
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2019-08-02 14:39 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

Hi Linus,

Here's our second -rc pull request.  Nothing particularly special in
this one.  The client removal deadlock fix is kindy tricky, but we had
multiple eyes on it and no one could find a fault in it.  A couple
Spectre V1 fixes too.  Otherwise, all just normal -rc fodder.

Here's the boilerplate:

The following changes since commit b7165bd0d6cbb93732559be6ea8774653b204480:

  IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification (2019-07-25 11:45:48 -0300)

are available in the Git repository at:

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

for you to fetch changes up to 020fb3bebc224dfe9353a56ecbe2d5fac499dffc:

  RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp() (2019-08-01 12:53:53 -0400)

----------------------------------------------------------------
Pull request for 5.3-rc2

- A couple Spectre V1 fixes (umad, hfi1)
- Fix a tricky deadlock in the rdma core code with refcounting instead
  of locks (client removal patches)
- Build errors (hns)
- Fix a scheduling while atomic issue (mlx5)
- Use after free fix (mad)
- Fix error path return code (hns)
- Null deref fix (siw_crypto_hash)
- A few other misc. minor fixes

----------------------------------------------------------------
Bernard Metzler (1):
      Do not dereference 'siw_crypto_shash' before checking

Gal Pressman (1):
      RDMA/restrack: Track driver QP types in resource tracker

Gustavo A. R. Silva (1):
      IB/hfi1: Fix Spectre v1 vulnerability

Guy Levi (1):
      IB/mlx5: Fix MR registration flow to use UMR properly

Jack Morgenstein (1):
      IB/mad: Fix use-after-free in ib mad completion handling

Jason Gunthorpe (2):
      RDMA/devices: Do not deadlock during client removal
      RDMA/devices: Remove the lock around remove_client_context

Leon Romanovsky (1):
      RDMA/mlx5: Release locks during notifier unregister

Michal Kalderon (1):
      RDMA/qedr: Fix the hca_type and hca_rev returned in device attributes

Tony Luck (1):
      IB/core: Add mitigation for Spectre V1

Wei Yongjun (1):
      RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp()

YueHaibing (1):
      RDMA/hns: Fix build error

 drivers/infiniband/core/core_priv.h        |   5 +-
 drivers/infiniband/core/device.c           | 102 +++++++++++++++++++----------
 drivers/infiniband/core/mad.c              |  20 +++---
 drivers/infiniband/core/user_mad.c         |   6 +-
 drivers/infiniband/hw/hfi1/verbs.c         |   2 +
 drivers/infiniband/hw/hns/Kconfig          |   6 +-
 drivers/infiniband/hw/hns/Makefile         |   8 +--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c |   4 +-
 drivers/infiniband/hw/mlx5/main.c          |   7 +-
 drivers/infiniband/hw/mlx5/mr.c            |  27 +++-----
 drivers/infiniband/hw/qedr/main.c          |  10 ++-
 drivers/infiniband/sw/siw/siw_qp.c         |   6 +-
 include/rdma/ib_verbs.h                    |   4 +-
 13 files changed, 124 insertions(+), 83 deletions(-)

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2019-06-21 19:42 Doug Ledford
@ 2019-06-21 22:35 ` pr-tracker-bot
  0 siblings, 0 replies; 186+ messages in thread
From: pr-tracker-bot @ 2019-06-21 22:35 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, Gunthorpe, Jason, linux-rdma, linux-kernel

The pull request you sent on Fri, 21 Jun 2019 15:42:09 -0400:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/121bddf39a8e39baf0df9ef1d688392c179935cd

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2019-06-21 19:42 Doug Ledford
  2019-06-21 22:35 ` pr-tracker-bot
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2019-06-21 19:42 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

Hi Linus,

This is probably our last -rc pull request.  We don't have anything else
outstanding at the moment anyway, and with the summer months on us and
people taking trips, I expect the next weeks leading up to the merge
window to be pretty calm and sedate.

This has two simple, no brainer fixes for the EFA driver.

Then it has ten not quite so simple fixes for the hfi1 driver.  The
problem with them is that they aren't simply one liner typo fixes. 
They're still fixes, but they're more complex issues like livelock under
heavy load where the answer was to change work queue usage and spinlock
usage to resolve the problem, or issues with orphaned requests during
certain types of failures like link down which required some more
complex work to fix too.  They all look like legitimate fixes to me,
they just aren't small like I wish they were.

Here's the boilerplate:

The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:

  Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 7a5834e456f7fb3eca9b63af2a6bc7f460ae482f:

  RDMA/efa: Handle mmap insertions overflow (2019-06-18 16:27:24 -0400)

----------------------------------------------------------------
Pull request for 5.1-rc5

- 2 minor EFA fixes
- 10 hfi1 fixes related to scaling issues

----------------------------------------------------------------
Gal Pressman (2):
      RDMA/efa: Fix success return value in case of error
      RDMA/efa: Handle mmap insertions overflow

Kaike Wan (1):
      IB/hfi1: Validate fault injection opcode user input

Mike Marciniszyn (9):
      IB/hfi1: Close PSM sdma_progress sleep window
      IB/hfi1: Correct tid qp rcd to match verbs context
      IB/hfi1: Avoid hardlockup with flushlist_lock
      IB/hfi1: Silence txreq allocation warnings
      IB/hfi1: Create inline to get extended headers
      IB/hfi1: Use aborts to trigger RC throttling
      IB/hfi1: Wakeup QPs orphaned on wait list after flush
      IB/hfi1: Handle wakeup of orphaned QPs for pio
      IB/hfi1: Handle port down properly in pio

 drivers/infiniband/hw/efa/efa_com_cmd.c  | 24 +++++++++++----
 drivers/infiniband/hw/efa/efa_verbs.c    | 21 ++++++++++---
 drivers/infiniband/hw/hfi1/chip.c        | 13 ++++++++
 drivers/infiniband/hw/hfi1/chip.h        |  1 +
 drivers/infiniband/hw/hfi1/fault.c       |  5 +++
 drivers/infiniband/hw/hfi1/hfi.h         | 31 +++++++++++++++++++
 drivers/infiniband/hw/hfi1/pio.c         | 21 +++++++++++--
 drivers/infiniband/hw/hfi1/rc.c          | 53 +++++++++++++++++++-------------
 drivers/infiniband/hw/hfi1/sdma.c        | 26 ++++++++++++----
 drivers/infiniband/hw/hfi1/tid_rdma.c    |  4 +--
 drivers/infiniband/hw/hfi1/ud.c          |  4 +--
 drivers/infiniband/hw/hfi1/user_sdma.c   | 12 +++-----
 drivers/infiniband/hw/hfi1/user_sdma.h   |  1 -
 drivers/infiniband/hw/hfi1/verbs.c       | 14 +++++----
 drivers/infiniband/hw/hfi1/verbs.h       |  1 +
 drivers/infiniband/hw/hfi1/verbs_txreq.c |  2 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.h |  3 +-
 17 files changed, 174 insertions(+), 62 deletions(-)

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2018-12-13 16:56 Doug Ledford
@ 2018-12-13 21:15 ` pr-tracker-bot
  0 siblings, 0 replies; 186+ messages in thread
From: pr-tracker-bot @ 2018-12-13 21:15 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, Gunthorpe, Jason, linux-rdma, linux-kernel

The pull request you sent on Thu, 13 Dec 2018 11:56:10 -0500:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e10db791bf73c1973f24591897e839db2eb3c804

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2018-12-13 16:56 Doug Ledford
  2018-12-13 21:15 ` pr-tracker-bot
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2018-12-13 16:56 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

Hi Linus,

We have 5 small fixes for this pull request.  One is a performance
regression, so not necessarily strictly a fix, but it was small and
reasonable and claimed to avoid thrashing in the scheduler, so I took
it.  The remaining are all legitimate fixes that match the "we take
fixes any time" criteria.

Here's the boilerplate:

The following changes since commit 7bca603a69c0c239654a8f0bcb99e1a60b30040c:

  RDMA/mlx5: Initialize return variable in case pagefault was skipped (2018-11-29 15:16:45 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 37fbd834b4e492dc41743830cbe435f35120abd8:

  IB/core: Fix oops in netdev_next_upper_dev_rcu() (2018-12-12 12:14:49 -0500)

----------------------------------------------------------------
Pull request for 4.20-rc

- One performance regression for hfi1
- One kasan fix for hfi1
- A couple mlx5 fixes
- A core oops fix

----------------------------------------------------------------
Artemy Kovalyov (1):
      IB/mlx5: Fix implicit ODP interrupted page fault

Mark Zhang (1):
      IB/core: Fix oops in netdev_next_upper_dev_rcu()

Michael J. Ruhl (1):
      IB/hfi1: Fix a latency issue for small messages

Piotr Stankiewicz (1):
      IB/hfi1: Fix an out-of-bounds access in get_hw_stats

Yishai Hadas (1):
      IB/mlx5: Block DEVX umem from the non applicable cases

 drivers/infiniband/core/roce_gid_mgmt.c | 3 +++
 drivers/infiniband/hw/hfi1/chip.c       | 3 ++-
 drivers/infiniband/hw/hfi1/hfi.h        | 2 ++
 drivers/infiniband/hw/hfi1/qp.c         | 7 +++++++
 drivers/infiniband/hw/hfi1/verbs.c      | 2 +-
 drivers/infiniband/hw/mlx5/devx.c       | 4 +++-
 drivers/infiniband/hw/mlx5/odp.c        | 9 ++++-----
 7 files changed, 22 insertions(+), 8 deletions(-)



-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2018-02-06  0:31 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2018-02-06  0:31 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: David Miller, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 9018 bytes --]

Hi Linus (and Dave),

As mentioned before, we had about 30 patches that we were waiting on
resubmissions from people.  Those have all come in.  There was a group
of 13 or so for hfi1, a few for the RDMA core, a 6 patch series for soft
RoCE, a 4 patch series for hns RoCE, and a few other random items.

Items of note:

1) There was a two patch series that came out of a regression in the
4.15 kernel.  The 4.14 kernel worked fine with NVMe over Fabrics and
mlx5 adapters.  That broke in 4.15.  The fix is here.  There were two
patches, one came in first from Sagi so I took his, but Max Gurtovoy
from Mellanox had submitted the same fix as Sagi plus an addition fix
for mlx5 intended to harden it against future issues.  It's his second
patch that is the reason I Cc:ed Dave here, as it touched files in
drivers/net/ instead of drivers/infiniband.  It's just an update to a
single #define value to increase capacity, and was part of that fix, and
Max didn't send it to netdev@ so I assumed he intended me to send it,
but I wanted to make sure it was clear why that is in the diffstat.

2) One of the patches from Lijun looks like a lot of lines of change,
but it's mostly mechanical in nature.  The endian notation patch.  We
sent him back to make some minor changes and those were done today so it
got added to the pull request and amounts to the biggest chunk of change
in it (it's about 2/3rds of the overall pull request).

3) The boilerplate says the starting point is the 4.15 merge tag. 
That's the same merge of Jason's you pulled the first time, so we just
kept with the same branch for this pull request.

Here's the boilerplate:

The following changes since commit e7996a9a77fc669387da43ff4823b91cc4872bd0:

  Merge tag v4.15 of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (2018-01-30 09:30:00 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 03ecdd2dcf39834ff2b012a8b29168d7076da84a:

  net/mlx5: increase async EQ to avoid EQ overrun (2018-02-05 10:58:25 -0500)

----------------------------------------------------------------
Second pull request for 4.16 merge window

- Clean up some function signatures in rxe for clarity
- Tidy the RDMA netlink header to remove unimplemented constants
- bnxt_re driver fixes, one is a regression this window.
- Minor hns driver fixes
- Various fixes from Dan Carpenter and his tool
- Fix IRQ cleanup race in HFI1
- HF1 performance optimizations and a fix to report counters in the right units
- Fix for an IPoIB startup sequence race with the external manager
- Oops fix for the new kabi path
- Endian cleanups for hns
- Fix for mlx5 related to the new automatic affinity support

----------------------------------------------------------------
Alex Estrin (3):
      IB/hfi1: Fix for early release of sdma context
      IB/hfi1: Fix for potential refcount leak in hfi1_open_file()
      IB/ipoib: Fix for potential no-carrier state

Bartlomiej Dudek (1):
      IB/hfi1: Do not override given pcie_pset value

Dan Carpenter (2):
      RDMA/bnxt_re: Fix an error code in bnxt_qplib_create_srq()
      RDMA/nldev: missing error code in nldev_res_get_doit()

Don Hiatt (2):
      IB/core: Map iWarp AH type to undefined in rdma_ah_find_type
      IB/hfi1: Add 16B rcvhdr trace support

Doug Ledford (1):
      RDMA/bnxt_re: Fix static checker warning

Jason Gunthorpe (2):
      IB: Update references to libibverbs
      IB/uverbs: Use the standard kConfig format for experimental

Kamenee Arumugam (2):
      IB/hfi1: Convert PortXmitWait/PortVLXmitWait counters to flit times
      IB/hfi1: Convert kzalloc_node and kcalloc to use kcalloc_node

Leon Romanovsky (1):
      RDMA/netlink: Hide unimplemented NLDEV commands

Markus Elfring (2):
      RDMA/bnxt_re: Delete two error messages for a failed memory allocation in bnxt_qplib_alloc_dpi_tbl()
      RDMA/bnxt_re: Use common error handling code in bnxt_qplib_alloc_dpi_tbl()

Max Gurtovoy (1):
      net/mlx5: increase async EQ to avoid EQ overrun

Michael J. Ruhl (2):
      IB/hfi1: Re-order IRQ cleanup to address driver cleanup race
      IB/core: Avoid a potential OOPs for an unused optional parameter

Mike Marciniszyn (1):
      IB/hfi1: Remove blind constants from 16B update

Mitko Haralanov (2):
      IB/hfi1: Remove dependence on qp->s_hdrwords
      IB/hfi1: Show fault stats in both TX and RX directions

Sagi Grimberg (1):
      mlx5: fix mlx5_get_vector_affinity to start from completion vector 0

Sebastian Sanchez (5):
      IB/hfi1: Compute BTH only for RDMA_WRITE_LAST/SEND_LAST packet
      IB/hfi1: Optimize packet type comparison using 9B and bypass code paths
      IB/hfi1: Look up ibport using a pointer in receive path
      IB/hfi1: Remove unnecessary fecn and becn fields
      IB/hfi1: Optimize process_receive_ib()

Zhu Yanjun (6):
      IB/rxe: remove redudant parameter in function
      IB/rxe: change the function to void from int
      IB/rxe: remove unnecessary parameter in rxe_av_to_attr
      IB/rxe: change the function to void from int
      IB/rxe: change the function rxe_av_fill_ip_info to void
      IB/rxe: remove redudant parameter in rxe_av_fill_ip_info

oulijun (4):
      RDMA/hns: Remove unnecessary operator
      RDMA/hns: Add names to function arguments in function pointers
      RDMA/hns: Fix misplaced call to hns_roce_cleanup_hem_table
      RDMA/hns: Fix the endian problem for hns

 Documentation/infiniband/user_verbs.txt      |   2 +-
 MAINTAINERS                                  |   2 +-
 drivers/infiniband/Kconfig                   |   7 +-
 drivers/infiniband/core/nldev.c              |   4 +-
 drivers/infiniband/core/uverbs_std_types.c   |   2 +-
 drivers/infiniband/hw/bnxt_re/ib_verbs.c     |   7 +-
 drivers/infiniband/hw/bnxt_re/qplib_fp.c     |   4 +-
 drivers/infiniband/hw/bnxt_re/qplib_res.c    |  18 +-
 drivers/infiniband/hw/hfi1/chip.c            |  82 ++++++--
 drivers/infiniband/hw/hfi1/chip.h            |   4 +-
 drivers/infiniband/hw/hfi1/debugfs.c         |   9 +-
 drivers/infiniband/hw/hfi1/driver.c          |  51 +++--
 drivers/infiniband/hw/hfi1/file_ops.c        |   4 +-
 drivers/infiniband/hw/hfi1/hfi.h             |  26 +--
 drivers/infiniband/hw/hfi1/init.c            |  31 ++-
 drivers/infiniband/hw/hfi1/iowait.h          |   9 +
 drivers/infiniband/hw/hfi1/mad.c             | 127 +++++++++++-
 drivers/infiniband/hw/hfi1/mad.h             |  47 ++++-
 drivers/infiniband/hw/hfi1/pcie.c            |  23 +--
 drivers/infiniband/hw/hfi1/pio.c             |  15 +-
 drivers/infiniband/hw/hfi1/qp.c              |   4 +-
 drivers/infiniband/hw/hfi1/qp.h              |  13 ++
 drivers/infiniband/hw/hfi1/rc.c              |  51 +++--
 drivers/infiniband/hw/hfi1/ruc.c             |  47 ++---
 drivers/infiniband/hw/hfi1/sdma.c            |  16 +-
 drivers/infiniband/hw/hfi1/sdma.h            |   1 +
 drivers/infiniband/hw/hfi1/trace.c           |   8 +-
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h    |  16 +-
 drivers/infiniband/hw/hfi1/trace_rx.h        |  30 ++-
 drivers/infiniband/hw/hfi1/uc.c              |   9 +-
 drivers/infiniband/hw/hfi1/ud.c              |  39 ++--
 drivers/infiniband/hw/hfi1/verbs.c           |  10 +-
 drivers/infiniband/hw/hfi1/verbs.h           |  24 ++-
 drivers/infiniband/hw/hfi1/verbs_txreq.h     |   7 +
 drivers/infiniband/hw/hns/hns_roce_common.h  |   6 +-
 drivers/infiniband/hw/hns/hns_roce_device.h  |  10 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c   |  60 ++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h   | 258 ++++++++++++------------
 drivers/infiniband/hw/hns/hns_roce_hw_v2.c   |  58 ++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v2.h   | 283 ++++++++++++++-------------
 drivers/infiniband/hw/hns/hns_roce_main.c    |   3 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c      |  18 +-
 drivers/infiniband/hw/qib/qib_rc.c           |   3 +-
 drivers/infiniband/hw/qib/qib_uc.c           |   3 +-
 drivers/infiniband/hw/qib/qib_ud.c           |   3 +-
 drivers/infiniband/sw/rxe/rxe_av.c           |  14 +-
 drivers/infiniband/sw/rxe/rxe_loc.h          |  10 +-
 drivers/infiniband/sw/rxe/rxe_qp.c           |  15 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c        |  10 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c    |   3 +
 drivers/net/ethernet/mellanox/mlx5/core/eq.c |   2 +-
 include/linux/mlx5/driver.h                  |   2 +-
 include/rdma/ib_hdrs.h                       |  19 +-
 include/rdma/ib_verbs.h                      |  20 +-
 include/uapi/rdma/rdma_netlink.h             |  14 +-
 55 files changed, 919 insertions(+), 644 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1510868362.8751.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-11-17  0:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 186+ messages in thread
From: Jason Gunthorpe @ 2017-11-17  0:03 UTC (permalink / raw)
  To: Doug Ledford, linux-rdma

On Thu, Nov 16, 2017 at 04:39:22PM -0500, Doug Ledford wrote:

> Timing here is nice because in the US we are headed into a holiday
> period whereas Jason will be around to keep the patch flow progressing
> (I guess Canadians do their equivalent to Thanksgiving in October, so he
> doesn't have an excuse to ignore email for the next week ;-)).

Right, so linux-rdma list:

We don't have everything setup yet on k.o for a shared tree or
patchworks, expect announcements on that topic in the next days.

But I will put in some effort to prepare patches for the -rc pull
request that Doug will send when he comes back.

Please cc my on your patches that are for -rc

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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-11-16 21:39 Doug Ledford
       [not found] ` <1510868362.8751.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-11-16 21:39 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

Hi Linus,

This is a super small pull request.  One patch only, and only a few
lines.  But, it's a change that we've been waiting to get all finalized
and it *just* now became a legal "done deal", so to speak.  And it's
timing couldn't be better.

The change is simply to add Jason Gunthorpe to the MAINTAINERS file for
the RDMA stack (and update him in the .mailmap).  Jason and I have
talked offline, and Jason will be filing a ticket with the k.o helpdesk
to get an account on k.o, and then we will likely move the rdma tree to
an area where we can both access it and use a shared repo + individual
topic branches + merged up for-next branch as the staging basis for each
release.

Timing here is nice because in the US we are headed into a holiday
period whereas Jason will be around to keep the patch flow progressing
(I guess Canadians do their equivalent to Thanksgiving in October, so he
doesn't have an excuse to ignore email for the next week ;-)).

Here's the boilerplate:

The following changes since commit
4190b4e96954e2c3597021d29435c3f8db8d3129:

  RDMA/core: Rename kernel modify_cq to better describe its usage (2017-
11-13 16:59:22 -0500)

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 e6e58e7774148b0d20bcdf7bab097e51ddb758d1:

  RDMA: Add Jason Gunthorpe as a co-maintainer (2017-11-16 15:56:29
-0500)

----------------------------------------------------------------
Add Jason Gunthorpe as co-maintainer of the RDMA stack

----------------------------------------------------------------
Jason Gunthorpe (1):
      RDMA: Add Jason Gunthorpe as a co-maintainer

 .mailmap    | 2 ++
 MAINTAINERS | 1 +
 2 files changed, 3 insertions(+)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-11-15 16:01 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-11-15 16:01 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 40608 bytes --]

Hi Linus,

This is a fairly plain pull request.  Lots of driver updates across the
stack, a huge number of static analysis cleanups including a close to 50
patch series from Bart Van Assche, and a number of new features inside
the stack such as general CQ moderation support.

Nothing really stands out, but there might be a few conflicts as you
take things in.  In particular, the cleanups touched some of the same
lines as the new timer_setup changes.

Everything in this pull request has been through 0day and at least 2
days of linux-next (since Stephen doesn't necessarily flag new
errors/warnings until day2).  A few more items (about 30 patches) from
Intel and Mellanox showed up on the list on Tuesday.  I've excluded
those from this pull request, and I'm sure some of them qualify as fixes
suitable to send any time, but I still have to review them fully.  If
they contain mostly fixes and little or no new development, then I will
probably send them through by the end of the week just to get them out
of the way.

There was a break in my acceptance of patches which coincides with the
computer problems I had, and then when I got things mostly back under
control I had a backlog of patches to process, which I did mostly last
Friday and Monday.  So there is a larger number of patches processed in
that timeframe than I was striving for.

There is a section of this pull request that patches files in the
drivers/net directory.  These come from the shared pull request that
both Dave and I took from Mellanox this cycle.  If you pull Dave's tree
first, those will drop out, or vice versa if you take mine first.  I did
not pull Dave's net-next this cycle, so it should be OK to take my tree
first.

Here's the boilerplate:
The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:

  Linux 4.14-rc4 (2017-10-08 20:53:29 -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 4190b4e96954e2c3597021d29435c3f8db8d3129:

  RDMA/core: Rename kernel modify_cq to better describe its usage (2017-11-13 16:59:22 -0500)

----------------------------------------------------------------
Updates for 4.15 kernel merge window

- Add iWARP support to qedr driver
- Lots of misc fixes across subsystem
- Multiple update series to hns roce driver
- Multiple update series to hfi1 driver
- Updates to vnic driver
- Add kref to wait struct in cxgb4 driver
- Updates to i40iw driver
- Mellanox shared pull request
- timer_setup changes
- massive cleanup series from Bart Van Assche
- Two series of SRP/SRPT changes from Bart Van Assche
- Core updates from Mellanox
- i40iw updates
- IPoIB updates
- mlx5 updates
- mlx4 updates
- hns updates
- bnxt_re fixes
- PCI write padding support
- Sparse/Smatch/warning cleanups/fixes
- CQ moderation support
- SRQ support in vmw_pvrdma

----------------------------------------------------------------
Ajaykumar Hotchandani (1):
      IB/{ipoib, iser}: Consistent print format of vendor error

Alex Estrin (1):
      IB/rdmavt: Don't wait for resources in QP reset

Alex Vesker (10):
      net/mlx5e: IPoIB, Move underlay QP init/uninit to separate functions
      net/mlx5: Support for attaching multiple underlay QPs to root flow table
      IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
      IB/ipoib: Add ability to set PKEY index to lower device driver
      net/mlx5e: IPoIB, Support for setting PKEY index to underlay QP
      net/mlx5e: IPoIB, Use hash-table to map between QPN to child netdev
      net/mlx5e: IPoIB, Add PKEY child interface nic profile
      net/mlx5e: IPoIB, Add PKEY child interface ndos
      net/mlx5e: IPoIB, Add PKEY child interface ethtool ops
      net/mlx5e: IPoIB, Modify rdma netdev allocate and free to support PKEY

Arnd Bergmann (5):
      RDMA/qedr: fix build error without ipv6
      IB/uverbs: clean up INIT_UDATA_BUF_OR_NULL usage
      IB/uverbs: clean up INIT_UDATA() macro usage
      infiniband: add MMU dependency for user_mem
      RDMA/core: avoid uninitialized variable warning in create_udata

Arvind Yadav (2):
      IB/mlx5:: pr_err() and mlx5_ib_dbg() strings should end with newlines
      IB/ocrdma: pr_err() strings should end with newlines

Bart Van Assche (59):
      IB/core: Simplify sa_path_set_[sd]lid() calls
      IB/core: Fix endianness annotation in rdma_is_multicast_addr()
      IB/cm: Suppress gcc 7 fall-through complaints
      RDMA/cma: Avoid triggering undefined behavior
      RDMA/iwcm: Remove a set-but-not-used variable
      RDMA/isert: Suppress gcc 7 fall-through complaints
      RDMA/bnxt_re: Suppress gcc 7 fall-through complaints
      RDMA/bnxt_re: Remove set-but-not-used variables
      RDMA/cxgb3: Annotate locking assumptions
      RDMA/cxgb3: Annotate an RCU pointer
      RDMA/cxgb3: Remove a set-but-not-used variable
      RDMA/cxgb4: Fix indentation
      RDMA/cxgb4: Remove the obsolete kernel module option 'c4iw_debug'
      RDMA/cxgb4: Suppress gcc 7 fall-through complaints
      RDMA/cxgb4: Remove a set-but-not-used variable
      IB/hfi1: Suppress gcc 7 fall-through complaints
      IB/hfi1: Remove set-but-not-used variables
      IB/hfi1: Define hfi1_handle_cnp_tbl[] once
      IB/hns: Annotate iomem pointers correctly
      IB/hns: Declare local functions 'static'
      RDMA/i40iw: Fix a race condition
      RDMA/i40iw: Suppress gcc 7 fall-through complaints
      RDMA/i40iw: Remove a set-but-not-used variable
      IB/mthca: Fix indentation
      IB/mlx4: Suppress gcc 7 fall-through complaints
      IB/mlx5: Suppress gcc 7 fall-through complaints
      IB/mlx5: Remove a set-but-not-used variable
      IB/nes: Fix indentation
      IB/nes: Suppress gcc 7 fall-through complaints
      IB/nes: Remove set-but-not-used variables
      IB/nes: Fix a race condition in nes_inetaddr_event()
      RDMA/ocrdma: Use NULL instead of 0 to represent a pointer
      RDMA/ocrdma: Suppress gcc 7 fall-through complaints
      RDMA/ocrdma: Remove set-but-not-used variables
      RDMA/qedr: Use NULL instead of 0 to represent a pointer
      RDMA/qedr: Declare local functions static
      RDMA/qedr: Annotate iomem pointers correctly
      RDMA/qedr: Remove set-but-not-used variables
      IB/qib: Remove remaining code related to writing the EEPROM
      IB/qib: Suppress gcc 7 fall-through complaints
      IB/qib: Remove set-but-not-used variables
      RDMA/rdmavt: Suppress gcc 7 fall-through complaints
      RDMA/rxe: Suppress gcc 7 fall-through complaints
      RDMA/usnic: Make the compiler check declaration consistency during compilation
      RDMA/usnic: Remove a set-but-not-used variable
      RDMA/usnic: Instantiate data structures once
      RDMA/uverbs: Make the code in ib_uverbs_cmd_verbs() less confusing
      IB/srpt: Do not accept invalid initiator port names
      IB/srpt: Limit the send and receive queue sizes to what the HCA supports
      IB/srpt: Cache global L_Key
      IB/srpt: Change default behavior from using SRQ to using RC
      IB/srp: Avoid that a cable pull can trigger a kernel crash
      IB/srp: Remove second argument of srp_destroy_qp()
      IB/srp: Cache global rkey
      IB/srp: Make CM timeout dependent on subnet timeout
      IB/srpt: Introduce helper functions for SRQ allocation and freeing
      IB/srpt: Introduce srpt_disconnect_ch_sync()
      IB/srpt: Wait until channel release has finished during module unload
      IB/srpt: Ensure that modifying the use_srq configfs attribute works

Bharat Potnuri (3):
      iw_cxgb4: Remove __func__ parameter from pr_debug()
      iw_cxgb4: change pr_debug to appropriate log level
      iw_cxgb4: Fix possible circular dependency locking warning

Bob Sharp (1):
      i40iw: Move cqp_cmd_head init to CQP initialization

Bryan Tan (1):
      RDMA/vmw_pvrdma: Add shared receive queue support

Christopher Bednarz (1):
      i40iw: Clear CQP Head/Tail during initialization

Colin Ian King (8):
      IB/core: fix spelling mistake: "aceess" -> "access"
      RDMA/cxgb3: remove redundant first assignement of sqp
      RDMA/hns: make various function static, fixes warnings
      RDMA/hns: remove redundant assignment to variable j
      RDMA/hns: return 0 rather than return a garbage status value
      IB/rxe: check for allocation failure on elem
      IB/core: remove redundant check on prot_sg_cnt
      RDMA/hns: fix spelling mistake: "Reseved" -> "Reserved"

Dan Carpenter (2):
      RDMA/qedr: Missing error code in qedr_init_user_queue()
      i40iw: delete some stray tabs

Daniel Jurgens (1):
      IB/core: Only maintain real QPs in the security lists

Dennis Dalessandro (1):
      IB/hfi1: Handle initial value of 0 for CCTI setting

Devesh Sharma (1):
      RDMA/bnxt_re: report vlan_id and sl in qp1 recv completion

Don Hiatt (7):
      IB/core: Use __be32 for LIDs in opa_is_extended_lid
      IB/core: Do not warn on lid conversions for OPA
      IB/hfi1: Do not warn on lid conversions for OPA
      IB/hfi1: Mask out A bit from psn trace
      IB/hfi1: Eliminate allocation while atomic
      IB/core: Convert OPA AH to IB for Extended LIDs only
      IB/hfi1: Mask upper 16Bits of Extended LID prior to rvt_cq_entry

Doug Ledford (12):
      Merge tag 'v4.14-rc2' into k.o/for-next
      Merge branch 'qedr' into k.o/for-next
      Merge branches 'hns' and 'misc' into k.o/for-next
      Merge branch 'hfi1' into k.o/for-next
      Merge branch 'vnic' into k.o/for-next
      IB/rxe: put the pool on allocation failure
      Merge tag 'mlx5-updates-2017-10-06' of git://git.kernel.org/.../mellanox/linux into k.o/for-next
      Merge branch 'hfi1' into k.o/for-next
      Merge tag 'mlx5-updates-2017-10-11' of git://git.kernel.org/.../mellanox/linux into mlnx-shared
      Merge branch 'for-next-early' into for-next
      Merge branch 'timer_setup' into for-next
      Merge branch 'k.o/for-rc' into k.o/for-next

Erez Shitrit (3):
      IB/ipoib: Get rid of the tx_outstanding variable in all modes
      IB/ipoib: Use NAPI in UD/TX flows
      IB/ipoib: Change number of TX wqe to 64

Feras Daoud (2):
      net/mlx5: File renaming towards ptp core implementation
      net/mlx5: PTP code migration to driver core section

Grzegorz Morys (2):
      IB/hfi1: Correct unnecessary acquisition of HW mutex
      IB/hfi1: Prohibit invalid Init to Armed state transition

Gustavo A. R. Silva (1):
      IB/ocrdma_hw: remove unnecessary code in ocrdma_mbx_dealloc_lkey

Guy Levi (7):
      IB/mlx5: Add 128B CQE compression and padding HW bits
      IB/mlx5: Support 128B CQE compression feature
      IB/mlx5: Support padded 128B CQE feature
      IB/mlx4: Add report for RSS capabilities by vendor channel
      IB/mlx4: Fix RSS's QPC attributes assignments
      IB/mlx4: Use optimal numbers of MTT entries
      IB/mlx4: Add contig support for control objects

Harish Chegondi (2):
      IB/hfi1: Convert the macro AHG_HEADER_SET into an inline function
      IB/hfi1: Remove the debug trace message in pin_sdma_pages()

Himanshu Jha (1):
      IB/qib: Use setup_timer and mod_timer

Ira Weiny (2):
      IB/hfi1: Set default_desc1 just one time
      IB/hfi1: Remove unused link_default variable

Ivan Barrera (1):
      i40iw: Remove UDA QP from QoS list if creation fails

Jakub Byczkowski (4):
      IB/hfi1: Add new state complete decodes for LNI failures
      IB/hfi1: Add parsing for platform configuration format version 4
      IB/hfi1: Allow meta version 4 for platform configuration
      IB/hfi1: Reduce 8051 command timeout

Jan Sokolowski (6):
      IB/hfi1: Remove unnecessary error messages on alloc failures
      IB/hfi1: Remove unused hfi1_cpulist variables
      IB/hfi1: Fix serdes loopback set-up
      IB/hfi1: Allow MgmtAllowed on B2B setups
      IB/hfi1: Remove unnecessary if check
      IB/hfi1: Send 'reboot' as planned down remote reason

Jérémy Lefaure (1):
      IB/mlx5: Use ARRAY_SIZE

Kaike Wan (1):
      IB/hfi1: Set hdr_type when tx req is allocated

Kalderon, Michal (9):
      RDMA/qedr: Add additional maintainer to MAINTAINERS file
      RDMA/qedr: Rename the qedr_cm file as a preparation for iWARP support
      RDMA/qedr: Add support for registering an iWARP device
      RDMA/qedr: Add iWARP support in existing verbs
      RDMA/qedr: Add support for read with invalidate, supported in iWARP
      RDMA/qedr: Add iWARP connection management qp related callbacks
      RDMA/qedr: Add iWARP connection management functions
      RDMA/qedr: Add support for iWARP in user space
      RDMA/qedr: Fix rdma_type initialization

Kamenee Arumugam (2):
      IB/hfi1: Don't modify num_user_contexts module parameter
      IB/hfi1: Remove wrapper function in mmu_rb

Kees Cook (11):
      RDMA/nes: Convert timers to use timer_setup()
      IB/qib: Convert timers to use timer_setup()
      RDMA/i40iw: Convert timers to use timer_setup()
      IB/ipoib: Convert timers to use timer_setup()
      net/mlx4_core: Convert timers to use timer_setup()
      IB/rdmavt: Convert timers to use timer_setup()
      IB/hfi1: Convert timers to use timer_setup()
      RDMA/cxgb3: Convert timers to use timer_setup()
      RDMA/i40iw: Convert timers to use timer_setup() (part 2)
      RDMA/cxgb4: Convert timers to use timer_setup()
      IB/rxe: Convert timers to use timer_setup()

Leon Romanovsky (7):
      RDMA: Remove Sean's and Hal's emails from MAINTAINER file
      RDMA/cxgb4: Declare stag as __be32
      RDMA/umem: Avoid partial declaration of non-static function
      RDMA/cxgb4: Annotate r2 and stag as __be32
      RDMA/bnxt_re: Remove unused vlan_tag variable
      RDMA/cxgb4: Protect from possible dereference
      RDMA/core: Rename kernel modify_cq to better describe its usage

Lijun Ou (6):
      RDMA/hns: Modify the value with rd&dest_rd of qp_attr
      RDMA/hns: Refactor code for readability
      RDMA/hns: Only assign dest_qp if IB_QP_DEST_QPN bit is set
      RDMA/hns: Set rdma_ah_attr type for querying qp
      RDMA/hns: Don't unregister a callback we didn't register
      RDMA/hns: Fix calltrace for sleeping in atomic

Majd Dibbiny (2):
      IB/mlx5: Assign send CQ and recv CQ of UMR QP
      IB/mlx5: Fix RoCE Address Path fields

Maor Gottlieb (11):
      net/mlx5: Avoid NULL pointer dereference on steering cleanup
      net/mlx5: Move the entry index allocator to flow group
      net/mlx5: Export building of matched flow groups list
      net/mlx5: Refactor FTE and FG creation code
      net/mlx5: Replace fs_node mutex with reader/writer semaphore
      net/mlx5: Support multiple updates of steering rules in parallel
      net/mlx5: Allocate FTE object without lock
      net/mlx5: Add FGs and FTEs memory pool
      IB/mlx5: Update tunnel offloads bits
      IB/mlx5: Add tunneling offloads support
      IB/mlx5: Add support for RSS on the inner packet

Mark Bloch (1):
      IB/mlx4: Increase maximal message size under UD QP

Matan Barak (1):
      net/mlx5: Fix creating a new FTE when an existing but full FTE exists

Michael J. Ruhl (16):
      IB/qib: Update QIB to use the latest PCI API
      IB/hfi1: Update HFI to use the latest PCI API
      IB/hfi1: Inline common calculation
      IB/hfi1: Add a safe wrapper for _rcd_get_by_index
      IB/hfi1: Refactor assign_ctxt() IOCTL
      IB/hfi1: Refactor get_ctxt_info
      IB/hfi1: Fix parenthesis alignment issues
      IB/hfi1: Refactor get_base_info
      IB/hfi1: Refactor hfi_user_exp_rcv_setup() IOCTL
      IB/hfi1: Refactor hfi_user_exp_rcv_clear() IOCTLs
      IB/hfi1: Refactor hfi_user_exp_rcv_invalid() IOCTLs
      IB/hfi1: Refactor get_user() IOCTLs
      IB/hfi1: Refactor reset_ctxt() IOCTL
      IB/hfi1: Fix incorrect available receive user context count
      RDMA/netlink: OOPs in rdma_nl_rcv_msg() from misinterpreted flag
      IB/hfi1: Race condition between user notification and driver state

Mike Marciniszyn (7):
      IB/hfi1: Extend input hdr tracing for packet type
      IB/hfi1: Fix output trace issues from 16B change
      IB/hfi1: Add tx_opcode_stats like the opcode_stats
      IB/hfi1: Insure int mask for in-kernel receive contexts is clear
      IB/hfi1: Take advantage of kvzalloc_node in sdma initialization
      IB/srpt: Post receive work requests after qp transition to INIT state
      IB/hfi1: Fix a wrapping test to insure the correct timeout

Mustafa Ismail (6):
      i40iw: Do not generate CQE for RTR on QP flush
      i40iw: Cleanup AE processing
      i40iw: Ignore AE source field in AEQE for some AEs
      i40iw: Remove unused static_rsrc from i40iw_create_qp_info
      i40iw: Move exception_lan_queue to VSI structure
      i40iw: Remove unused structures

Niranjana Vishwanathapura (7):
      IB/opa_vnic: Mark unused Ethernet MTU fields as reserved
      IB/opa_vnic: Set POD value for Ethernet MTU
      IB/opa_vnic: Allow reset of MAC address
      IB/opa_vnic: Properly return the total MACs in UC MAC list
      IB/opa_vnic: Properly set vesw port status
      IB/opa_vnic: Add routing control information
      IB/hfi1: Do not allocate PIO send contexts for VNIC

Noa Osherovich (5):
      IB/mlx5: Expose multi-packet RQ capabilities
      IB/mlx5: Allow creation of a multi-packet RQ
      IB/core: Add PCI write end padding flags for WQ and QP
      IB/mlx5: Add PCI write end padding support
      IB/mlx5: Fix ABI alignment to 64 bit

Parav Pandit (8):
      IB/core: Introduce and use rdma_create_user_ah
      IB: Let ib_core resolve destination mac address
      IB/core: Fix unable to change lifespan entry for hw_counters
      IB/core: Fix use workqueue without WQ_MEM_RECLAIM
      IB/core: Fix calculation of maximum RoCE MTU
      IB/cm: Fix memory corruption in handling CM request
      IB/core: Avoid crash on pkey enforcement failed in received MADs
      IB/core: Avoid unnecessary return value check

Patel Jay P (1):
      Ib/hfi1: Return actual operational VLs in port info query

Scott Franco (1):
      IB/opa_vnic: Properly clear Mac Table Digest

Sebastian Sanchez (3):
      IB/hfi1: Prevent LNI out of sync by resetting host interface version
      IB/rdmavt: Correct issues with read-mostly and send size cache lines
      IB/hfi1: Validate PKEY for incoming GSI MAD packets

Selvin Xavier (3):
      RDMA/bnxt_re: Set QP state in case of response completion errors
      RDMA/bnxt_re: Flush CQ notification Work Queue before destroying QP
      RDMA/bnxt_re: synchronize poll_cq and req_notify_cq verbs

Shaobo Xu (3):
      RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08
      RDMA/hns: Update the interfaces for MTT/CQE multi hop addressing in hip08
      RDMA/hns: Split CQE from MTT in hip08

Shiraz Saleem (5):
      i40iw: Do not allow posting WR after QP is flushed
      i40iw: Account for IPv6 header when setting MSS
      i40iw: Move ceq_valid to i40iw_sc_dev structure
      i40iw: Reinitialize IEQ on MTU change
      i40iw: Refactor queue depth calculation

Somnath Kotur (4):
      bnxt_re: Fix incorrect usage of test_bit()
      bnxt_re: Make room for mapping beyond 32 entries
      bnxt_re: Implement the shutdown hook of the L2-RoCE driver interface
      RDMA/bnxt_re: Add memory barriers when processing CQ/EQ entries

Sriharsha Basavapatna (2):
      bnxt_re: fix a crash in qp error event processing
      bnxt_re: changing the ip address shouldn't affect new connections

Steve Wise (8):
      iw_cxgb4: allocate wait object for each memory object
      iw_cxgb4: allocate wait object for each cq object
      iw_cxgb4: allocate wait object for each qp object
      iw_cxgb4: allocate wait object for each ep object
      iw_cxgb4: add referencing to wait objects
      iw_cxgb4: remove BUG_ON() usage.
      iw_cxgb4: only call the cq comp_handler when the cq is armed
      iw_cxgb4: atomically flush the qp

Tatyana Nikolova (1):
      i40iw: Do not retransmit MPA request after it is ACKed

Thomas Bogendoerfer (2):
      IB/hfi1: Add MODULE_FIRMWARE statements
      IB/rxe: don't crash, if allocation of crc algorithm failed

Wei Hu(Xavier) (26):
      RDMA/hns: Split hw v1 driver from hns roce driver
      RDMA/hns: Move priv in order to add multiple hns_roce support
      RDMA/hns: Initialize the PCI device for hip08 RoCE
      RDMA/hns: Modify assignment device variable to support both PCI device and platform device
      RDMA/hns: Add command queue support for hip08 RoCE driver
      RDMA/hns: Add profile support for hip08 driver
      RDMA/hns: Add mailbox's implementation for hip08 RoCE driver
      RDMA/hns: Configure BT BA and BT attribute for the contexts in hip08
      RDMA/hns: Support multi hop addressing for PBL in hip08
      RDMA/hns: Configure mac&gid and user access region for hip08 RoCE driver
      RDMA/hns: Add CQ operations support for hip08 RoCE driver
      RDMA/hns: Add QP operations support for hip08 SoC
      RDMA/hns: Add support for processing send wr and receive wr
      RDMA/hns: Configure the MTPT in hip08
      RDMA/hns: Add releasing resource operation in error branch
      RDMA/hns: Replace condition statement using hardware version information
      RDMA/hns: Fix inconsistent warning
      RDMA/hns: Delete the unnecessary initializing enum to zero
      RDMA/hns: Check return value of kzalloc
      RDMA/hns: Avoid NULL pointer exception
      RDMA/hns: Support WQE/CQE/PBL page size configurable feature in hip08
      RDMA/hns: Update the IRRL table chunk size in hip08
      RDMA/hns: Update the PD&CQE&MTT specification in hip08
      RDMA/hns: Add rereg mr support for hip08
      RDMA/hns: Generate gid type of RoCEv2
      RDMA/hns: Configure sgid type for hip08 RoCE

Yonatan Cohen (6):
      IB/uverbs: Allow CQ moderation with modify CQ
      IB/mlx4: Exposing modify CQ callback to uverbs layer
      IB/mlx5: Exposing modify CQ callback to uverbs layer
      IB/uverbs: Add CQ moderation capability to query_device
      IB/mlx4: Add CQ moderation capability to query_device
      IB/mlx5: Add CQ moderation capability to query_device

Yuval Shaia (4):
      IB: Move PCI dependency from root KConfig to HW's KConfigs
      IB/{cxgb3,cxgb4}: Remove unneeded config dependencies
      IB/ipoib: Remove device when one port fails to init
      RDMA/core: Make function rdma_copy_addr return void

oulijun (12):
      RDMA/hns: Add modify CQ support for hip08
      RDMA/hns: Update calculation of irrl_ba field for hip08
      RDMA/hns: Configure TRRL field in hip08 RoCE device
      RDMA/hns: Configure fence attribute in hip08 RoCE
      RDMA/hns: Set se attribute of sqwqe in hip08
      RDMA/hns: Enable the cqe field of sqwqe of RC
      RDMA/hns: Set sq_cur_sge_blk_addr field in QPC in hip08
      RDMA/hns: Update the usage of ack timeout in hip08
      RDMA/hns: Add sq_invld_flg field in QP context
      RDMA/hns: Set the owner field of SQWQE in hip08 RoCE
      RDMA/hns: Unify the calculation for hem index in hip08
      RDMA/hns: Modify the usage of cmd_sn in hip08

 MAINTAINERS                                        |    3 +-
 drivers/infiniband/Kconfig                         |    2 +-
 drivers/infiniband/core/Makefile                   |    2 +-
 drivers/infiniband/core/addr.c                     |   29 +-
 drivers/infiniband/core/cm.c                       |   38 +-
 drivers/infiniband/core/cma.c                      |   19 +-
 drivers/infiniband/core/iwcm.c                     |    3 -
 drivers/infiniband/core/mad.c                      |    3 +-
 drivers/infiniband/core/netlink.c                  |   13 +-
 drivers/infiniband/core/rw.c                       |   24 +-
 drivers/infiniband/core/security.c                 |   66 +-
 drivers/infiniband/core/sysfs.c                    |   16 +-
 drivers/infiniband/core/umem_odp.c                 |   72 +
 drivers/infiniband/core/umem_rbtree.c              |  109 -
 drivers/infiniband/core/user_mad.c                 |   13 +-
 drivers/infiniband/core/uverbs.h                   |   36 +-
 drivers/infiniband/core/uverbs_cmd.c               |  189 +-
 drivers/infiniband/core/uverbs_ioctl.c             |   13 +-
 drivers/infiniband/core/uverbs_ioctl_merge.c       |    2 +-
 drivers/infiniband/core/uverbs_main.c              |   23 +-
 drivers/infiniband/core/uverbs_marshall.c          |   13 +-
 drivers/infiniband/core/uverbs_std_types.c         |   20 +-
 drivers/infiniband/core/verbs.c                    |   52 +-
 drivers/infiniband/hw/bnxt_re/ib_verbs.c           |   78 +-
 drivers/infiniband/hw/bnxt_re/main.c               |   19 +-
 drivers/infiniband/hw/bnxt_re/qplib_fp.c           |   39 +-
 drivers/infiniband/hw/bnxt_re/qplib_fp.h           |    1 +
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c         |   18 +-
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h         |    6 +-
 drivers/infiniband/hw/bnxt_re/qplib_res.h          |    2 +-
 drivers/infiniband/hw/bnxt_re/qplib_sp.c           |    5 +-
 drivers/infiniband/hw/bnxt_re/roce_hsi.h           |    2 +-
 drivers/infiniband/hw/cxgb3/Kconfig                |    2 +-
 drivers/infiniband/hw/cxgb3/cxio_hal.c             |    6 +-
 drivers/infiniband/hw/cxgb3/iwch_cm.c              |   18 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |    1 -
 drivers/infiniband/hw/cxgb3/iwch_provider.h        |    1 -
 drivers/infiniband/hw/cxgb3/iwch_qp.c              |    3 +
 drivers/infiniband/hw/cxgb4/Kconfig                |    2 +-
 drivers/infiniband/hw/cxgb4/cm.c                   |  330 +-
 drivers/infiniband/hw/cxgb4/cq.c                   |  127 +-
 drivers/infiniband/hw/cxgb4/device.c               |   69 +-
 drivers/infiniband/hw/cxgb4/ev.c                   |   10 +-
 drivers/infiniband/hw/cxgb4/id_table.c             |    1 -
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h             |   95 +-
 drivers/infiniband/hw/cxgb4/mem.c                  |  268 +-
 drivers/infiniband/hw/cxgb4/provider.c             |   66 +-
 drivers/infiniband/hw/cxgb4/qp.c                   |  186 +-
 drivers/infiniband/hw/cxgb4/resource.c             |   46 +-
 drivers/infiniband/hw/cxgb4/t4.h                   |   29 +-
 drivers/infiniband/hw/cxgb4/t4fw_ri_api.h          |    4 +-
 drivers/infiniband/hw/hfi1/aspm.h                  |    7 +-
 drivers/infiniband/hw/hfi1/chip.c                  |  385 +--
 drivers/infiniband/hw/hfi1/chip.h                  |    6 +-
 drivers/infiniband/hw/hfi1/common.h                |    1 +
 drivers/infiniband/hw/hfi1/debugfs.c               |   60 +-
 drivers/infiniband/hw/hfi1/driver.c                |   22 +-
 drivers/infiniband/hw/hfi1/file_ops.c              |  486 +--
 drivers/infiniband/hw/hfi1/firmware.c              |  113 +-
 drivers/infiniband/hw/hfi1/hfi.h                   |   35 +-
 drivers/infiniband/hw/hfi1/init.c                  |   53 +-
 drivers/infiniband/hw/hfi1/intr.c                  |   57 +-
 drivers/infiniband/hw/hfi1/mad.c                   |  144 +-
 drivers/infiniband/hw/hfi1/mad.h                   |    4 +-
 drivers/infiniband/hw/hfi1/mmu_rb.c                |   24 +-
 drivers/infiniband/hw/hfi1/pio.c                   |   17 -
 drivers/infiniband/hw/hfi1/pio.h                   |    6 -
 drivers/infiniband/hw/hfi1/rc.c                    |    7 +-
 drivers/infiniband/hw/hfi1/ruc.c                   |   11 +-
 drivers/infiniband/hw/hfi1/sdma.c                  |   36 +-
 drivers/infiniband/hw/hfi1/sysfs.c                 |    2 +-
 drivers/infiniband/hw/hfi1/trace.c                 |   27 +-
 drivers/infiniband/hw/hfi1/trace.h                 |   10 +
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h          |   49 +-
 drivers/infiniband/hw/hfi1/trace_rx.h              |   11 +-
 drivers/infiniband/hw/hfi1/uc.c                    |    3 +-
 drivers/infiniband/hw/hfi1/ud.c                    |    8 +-
 drivers/infiniband/hw/hfi1/user_exp_rcv.c          |    9 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |   92 +-
 drivers/infiniband/hw/hfi1/user_sdma.h             |   29 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |   65 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.h           |    2 +
 drivers/infiniband/hw/hfi1/vnic_main.c             |   44 +-
 drivers/infiniband/hw/hns/Kconfig                  |   25 +-
 drivers/infiniband/hw/hns/Makefile                 |    8 +-
 drivers/infiniband/hw/hns/hns_roce_ah.c            |   16 +-
 drivers/infiniband/hw/hns/hns_roce_alloc.c         |   35 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.c           |  107 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.h           |   54 +
 drivers/infiniband/hw/hns/hns_roce_common.h        |   23 +
 drivers/infiniband/hw/hns/hns_roce_cq.c            |   95 +-
 drivers/infiniband/hw/hns/hns_roce_device.h        |  134 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    6 +-
 drivers/infiniband/hw/hns/hns_roce_hem.c           |  719 ++++-
 drivers/infiniband/hw/hns/hns_roce_hem.h           |   33 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         |  609 +++-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h         |    7 +
 drivers/infiniband/hw/hns/hns_roce_hw_v2.c         | 3296 ++++++++++++++++++++
 drivers/infiniband/hw/hns/hns_roce_hw_v2.h         | 1177 +++++++
 drivers/infiniband/hw/hns/hns_roce_main.c          |  384 +--
 drivers/infiniband/hw/hns/hns_roce_mr.c            |  692 +++-
 drivers/infiniband/hw/hns/hns_roce_pd.c            |   20 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c            |  226 +-
 drivers/infiniband/hw/i40iw/Kconfig                |    1 +
 drivers/infiniband/hw/i40iw/i40iw.h                |    3 -
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |   30 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.h             |    1 +
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           |   76 +-
 drivers/infiniband/hw/i40iw/i40iw_d.h              |   30 +-
 drivers/infiniband/hw/i40iw/i40iw_hw.c             |    3 +-
 drivers/infiniband/hw/i40iw/i40iw_main.c           |   48 +-
 drivers/infiniband/hw/i40iw/i40iw_p.h              |    3 +-
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |   19 +-
 drivers/infiniband/hw/i40iw/i40iw_puda.h           |    2 -
 drivers/infiniband/hw/i40iw/i40iw_type.h           |   13 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   76 +-
 drivers/infiniband/hw/i40iw/i40iw_user.h           |   23 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |   30 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |   47 +-
 drivers/infiniband/hw/mlx4/ah.c                    |    8 +-
 drivers/infiniband/hw/mlx4/cq.c                    |   10 +-
 drivers/infiniband/hw/mlx4/main.c                  |   23 +
 drivers/infiniband/hw/mlx4/mcg.c                   |    1 +
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |   19 +-
 drivers/infiniband/hw/mlx4/mr.c                    |  284 +-
 drivers/infiniband/hw/mlx4/qp.c                    |   26 +-
 drivers/infiniband/hw/mlx5/ah.c                    |    4 -
 drivers/infiniband/hw/mlx5/cq.c                    |   38 +-
 drivers/infiniband/hw/mlx5/main.c                  |   57 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   18 +
 drivers/infiniband/hw/mlx5/mr.c                    |    4 +-
 drivers/infiniband/hw/mlx5/odp.c                   |    6 +-
 drivers/infiniband/hw/mlx5/qp.c                    |  149 +-
 drivers/infiniband/hw/mthca/mthca_main.c           |   10 +-
 drivers/infiniband/hw/nes/nes.c                    |   33 +-
 drivers/infiniband/hw/nes/nes.h                    |    6 +-
 drivers/infiniband/hw/nes/nes_cm.c                 |   14 +-
 drivers/infiniband/hw/nes/nes_hw.c                 |   27 +-
 drivers/infiniband/hw/nes/nes_hw.h                 |    1 +
 drivers/infiniband/hw/nes/nes_mgt.c                |    9 +-
 drivers/infiniband/hw/nes/nes_nic.c                |   12 +-
 drivers/infiniband/hw/nes/nes_utils.c              |   24 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |   22 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c           |   15 -
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c           |   14 +-
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c        |    2 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c        |    4 +-
 drivers/infiniband/hw/qedr/Kconfig                 |    1 +
 drivers/infiniband/hw/qedr/Makefile                |    2 +-
 drivers/infiniband/hw/qedr/main.c                  |  118 +-
 drivers/infiniband/hw/qedr/qedr.h                  |   31 +-
 drivers/infiniband/hw/qedr/qedr_hsi_rdma.h         |    6 +-
 drivers/infiniband/hw/qedr/qedr_iw_cm.c            |  749 +++++
 drivers/infiniband/hw/qedr/qedr_iw_cm.h            |   49 +
 .../hw/qedr/{qedr_cm.c => qedr_roce_cm.c}          |   31 +-
 .../hw/qedr/{qedr_cm.h => qedr_roce_cm.h}          |    0
 drivers/infiniband/hw/qedr/verbs.c                 |  359 ++-
 drivers/infiniband/hw/qedr/verbs.h                 |    2 +
 drivers/infiniband/hw/qib/Kconfig                  |    1 +
 drivers/infiniband/hw/qib/qib.h                    |   30 +-
 drivers/infiniband/hw/qib/qib_7220.h               |    2 +-
 drivers/infiniband/hw/qib/qib_diag.c               |    6 -
 drivers/infiniband/hw/qib/qib_driver.c             |    9 +-
 drivers/infiniband/hw/qib/qib_file_ops.c           |    9 -
 drivers/infiniband/hw/qib/qib_iba6120.c            |   81 +-
 drivers/infiniband/hw/qib/qib_iba7220.c            |   95 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |  196 +-
 drivers/infiniband/hw/qib/qib_init.c               |   29 +-
 drivers/infiniband/hw/qib/qib_intr.c               |    6 +-
 drivers/infiniband/hw/qib/qib_mad.c                |   16 +-
 drivers/infiniband/hw/qib/qib_pcie.c               |  128 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |    2 +-
 drivers/infiniband/hw/qib/qib_sd7220.c             |   12 +-
 drivers/infiniband/hw/qib/qib_sdma.c               |    2 +-
 drivers/infiniband/hw/qib/qib_tx.c                 |    8 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |    9 +-
 drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c      |    2 -
 drivers/infiniband/hw/usnic/usnic_ib_qp_grp.h      |   25 +-
 drivers/infiniband/hw/usnic/usnic_ib_sysfs.c       |    1 +
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c       |   25 +
 drivers/infiniband/hw/vmw_pvrdma/Makefile          |    2 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |   25 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h  |   54 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     |   59 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c       |   55 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_srq.c      |  319 ++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c    |    3 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h    |   18 +
 drivers/infiniband/sw/rdmavt/Kconfig               |    1 +
 drivers/infiniband/sw/rdmavt/mcast.c               |    2 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   13 +-
 drivers/infiniband/sw/rxe/rxe_comp.c               |    8 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |    4 +-
 drivers/infiniband/sw/rxe/rxe_pool.c               |   16 +-
 drivers/infiniband/sw/rxe/rxe_qp.c                 |    4 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |    4 +-
 drivers/infiniband/sw/rxe/rxe_task.c               |    2 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   11 +-
 drivers/infiniband/ulp/ipoib/ipoib.h               |   16 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |   56 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |    5 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |  150 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |   29 +-
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c         |   17 +-
 drivers/infiniband/ulp/iser/iser_verbs.c           |    2 +-
 drivers/infiniband/ulp/isert/ib_isert.c            |   14 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c   |   42 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.h   |   22 +-
 .../infiniband/ulp/opa_vnic/opa_vnic_internal.h    |    7 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c  |   44 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c    |    1 +
 .../infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c  |   22 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |   90 +-
 drivers/infiniband/ulp/srp/ib_srp.h                |    3 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |  331 +-
 drivers/infiniband/ulp/srpt/ib_srpt.h              |    9 +-
 drivers/net/ethernet/chelsio/cxgb3/t3cdev.h        |    2 +-
 drivers/net/ethernet/mellanox/mlx4/catas.c         |   10 +-
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig    |    2 +-
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |    6 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h       |   39 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c |  619 ----
 .../net/ethernet/mellanox/mlx5/core/en_common.c    |    1 +
 .../net/ethernet/mellanox/mlx5/core/en_ethtool.c   |    7 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   95 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c    |   37 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c    |    6 +-
 drivers/net/ethernet/mellanox/mlx5/core/eq.c       |    3 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c   |   13 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.h   |    4 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c  |  976 ++++--
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.h  |   18 +-
 .../ethernet/mellanox/mlx5/core/ipoib/ethtool.c    |    5 +
 .../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c  |  260 +-
 .../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.h  |   36 +
 .../ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c |  350 +++
 .../net/ethernet/mellanox/mlx5/core/lib/clock.c    |  525 ++++
 .../net/ethernet/mellanox/mlx5/core/lib/clock.h    |   51 +
 drivers/net/ethernet/mellanox/mlx5/core/main.c     |    4 +
 .../net/ethernet/mellanox/mlx5/core/mlx5_core.h    |    1 +
 drivers/staging/lustre/lnet/Kconfig                |    2 +-
 include/linux/mlx4/cq.h                            |    3 +
 include/linux/mlx5/cq.h                            |    9 +-
 include/linux/mlx5/driver.h                        |   24 +
 include/linux/mlx5/mlx5_ifc.h                      |    9 +-
 include/rdma/ib_addr.h                             |   16 +-
 include/rdma/ib_pack.h                             |   19 +-
 include/rdma/ib_sa.h                               |   12 +-
 include/rdma/ib_umem_odp.h                         |    4 -
 include/rdma/ib_verbs.h                            |   35 +-
 include/rdma/opa_addr.h                            |    6 +-
 include/rdma/rdmavt_qp.h                           |    6 +-
 include/uapi/rdma/ib_user_verbs.h                  |   22 +-
 include/uapi/rdma/mlx5-abi.h                       |   52 +-
 include/uapi/rdma/vmw_pvrdma-abi.h                 |    2 +
 255 files changed, 14874 insertions(+), 4849 deletions(-)
 delete mode 100644 drivers/infiniband/core/umem_rbtree.c
 create mode 100644 drivers/infiniband/hw/hns/hns_roce_hw_v2.c
 create mode 100644 drivers/infiniband/hw/hns/hns_roce_hw_v2.h
 create mode 100644 drivers/infiniband/hw/qedr/qedr_iw_cm.c
 create mode 100644 drivers/infiniband/hw/qedr/qedr_iw_cm.h
 rename drivers/infiniband/hw/qedr/{qedr_cm.c => qedr_roce_cm.c} (96%)
 rename drivers/infiniband/hw/qedr/{qedr_cm.h => qedr_roce_cm.h} (100%)
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_srq.c
 delete mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/clock.h

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-10-26 18:05 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-10-26 18:05 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

This is the fix for the oops that I alerted you to earlier this week
and it's the only thing in the pull request.  Here's the boilerplate:

The following changes since commit 789f903fd75036f937409a9a1616a5a5e5cc5bae:

  i40iw: Fix port number for query QP (2017-10-04 15:28:49 -0400)

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 b4d91aeb6e120b7e2f207021c31b914895c69bc4:

  RDMA/netlink: OOPs in rdma_nl_rcv_msg() from misinterpreted flag (2017-10-25 14:54:43 -0400)

----------------------------------------------------------------
Fourth -rc update for 4.14 kernel

- Fix an oops issue in the new RDMA netlink code

----------------------------------------------------------------
Michael J. Ruhl (1):
      RDMA/netlink: OOPs in rdma_nl_rcv_msg() from misinterpreted flag

 drivers/infiniband/core/netlink.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-10-06 17:25 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-10-06 17:25 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

This is a pretty small pull request.  Only 6 patches in total.  There
are no outstanding -rc patches on the mailing list after this pull
request, so only if some new issues are discovered in the remainder of
the rc cycles will you here from me again.  Here's the boilerplate:

The following changes since commit 828bcbdc975fbcfb27946c33d4b1d1bfab70789b:

  IB/hfi1: Unsuccessful PCIe caps tuning should not fail driver load (2017-09-27 11:10:36 -0400)

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 789f903fd75036f937409a9a1616a5a5e5cc5bae:

  i40iw: Fix port number for query QP (2017-10-04 15:28:49 -0400)

----------------------------------------------------------------
Third -rc update for 4.14 kernel

- a fix for iwpm netlink usage
- a fix for error unwinding in mlx5
- two fixes to vlan handling in qedr
- a couple small i40iw fixes

----------------------------------------------------------------
Amrani, Ram (2):
      RDMA/qedr: Parse VLAN ID correctly and ignore the value of zero
      RDMA/qedr: Parse vlan priority as sl

Mustafa Ismail (2):
      i40iw: Add missing memory barriers
      i40iw: Fix port number for query QP

Parav Pandit (1):
      IB/mlx5: Fix label order in error path handling

Shiraz Saleem (1):
      RDMA/iwpm: Properly mark end of NL messages

 drivers/infiniband/core/iwpm_msg.c        |  8 ++++++++
 drivers/infiniband/core/iwpm_util.c       |  5 +++++
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c  |  2 +-
 drivers/infiniband/hw/i40iw/i40iw_p.h     |  2 ++
 drivers/infiniband/hw/i40iw/i40iw_puda.c  | 11 ++++-------
 drivers/infiniband/hw/i40iw/i40iw_verbs.c |  2 ++
 drivers/infiniband/hw/mlx5/main.c         |  4 ++--
 drivers/infiniband/hw/qedr/qedr.h         |  2 +-
 drivers/infiniband/hw/qedr/qedr_cm.c      | 12 +++++++++---
 9 files changed, 34 insertions(+), 14 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-09-28 16:06 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-09-28 16:06 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

Both Mellanox and Intel had a series of -rc fixes that landed this
week.  The Mellanox bunch is spread throughout the stack and not just
in their driver, where as the Intel bunch was mostly in the hfi1
driver.  And, several of the fixes in the hfi1 driver were more than
just simple 5 line fixes.  As a result, the hfi1 driver fixes has a
sizable LOC count.  Everything else is as one would expect in an RC
cycle in terms of LOC count.  One item that might jump out and make you
think "That's not an rc item" is the fix that corrects a typo.  But,
that change fixes a typo in a user visible API that was just added in
this merge window, so if we fix it now, we can fix it.  If we don't,
the typo is in the API forever.  Another that might not appear to be a
fix at first glance is the Simplify mlx5_ib_cont_pages patch, but the
simplification allows them to fix a bug in the existing function
whenever the length of an SGE exceeded page size.  We also had to
revert one patch from the merge window that was wrong.  Anyway, here's
the boilerplate:

The following changes since commit e19b205be43d11bff638cad4487008c48d21c103:

  Linux 4.14-rc2 (2017-09-24 16:38:56 -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 828bcbdc975fbcfb27946c33d4b1d1bfab70789b:

  IB/hfi1: Unsuccessful PCIe caps tuning should not fail driver load (2017-09-27 11:10:36 -0400)

----------------------------------------------------------------
Second -rc update for 4.14 kernel

- a few core fixes
- a few ipoib fixes
- a few mlx5 fixes
- a 7 patch hfi1 related series

----------------------------------------------------------------
Alex Estrin (1):
      Revert "IB/ipoib: Update broadcast object if PKey value was changed in index 0"

Alex Vesker (1):
      IB/ipoib: Fix inconsistency with free_netdev and free_rdma_netdev

Harish Chegondi (1):
      IB/hfi1: Unsuccessful PCIe caps tuning should not fail driver load

Ilya Lesokhin (2):
      IB/mlx5: Simplify mlx5_ib_cont_pages
      IB/mlx5: Fix NULL deference on mlx5_ib_update_xlt failure

Jan Sokolowski (1):
      IB/hfi1: Check eeprom config partition validity

Kamenee Arumugam (1):
      IB/hfi1: Return correct value in general interrupt handler

Leon Romanovsky (1):
      IB/core: Fix typo in the name of the tag-matching cap struct

Michael J. Ruhl (1):
      IB/hfi1: On error, fix use after free during user context setup

Parav Pandit (2):
      IB/core: Fix qp_sec use after free access
      IB: Correct MR length field to be 64-bit

Sebastian Sanchez (2):
      IB/hfi1: Turn off AOC TX after offline substates
      IB/hfi1: Only reset QSFP after link up and turn off AOC TX

Shalom Lagziel (1):
      IB/ipoib: Fix sysfs Pkey create<->remove possible deadlock

 drivers/infiniband/core/security.c        |   4 +-
 drivers/infiniband/core/uverbs_cmd.c      |  14 ++---
 drivers/infiniband/hw/hfi1/chip.c         | 101 +++++++++++++++++++++++-------
 drivers/infiniband/hw/hfi1/chip.h         |   3 +-
 drivers/infiniband/hw/hfi1/eprom.c        |  20 ++++--
 drivers/infiniband/hw/hfi1/file_ops.c     |  41 ++++++------
 drivers/infiniband/hw/hfi1/pcie.c         |  50 +++++++--------
 drivers/infiniband/hw/hfi1/platform.c     |   4 +-
 drivers/infiniband/hw/mlx5/main.c         |  10 +--
 drivers/infiniband/hw/mlx5/mem.c          |  47 +++++---------
 drivers/infiniband/hw/mlx5/mr.c           |  27 +++++---
 drivers/infiniband/hw/nes/nes_verbs.c     |   4 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c   |  13 ----
 drivers/infiniband/ulp/ipoib/ipoib_main.c |  15 +++--
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c |  30 ++++++---
 drivers/infiniband/ulp/iser/iser_memory.c |   2 +-
 include/rdma/ib_verbs.h                   |   6 +-
 include/uapi/rdma/ib_user_verbs.h         |   2 +-
 net/sunrpc/xprtrdma/frwr_ops.c            |   2 +-
 19 files changed, 231 insertions(+), 164 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <1506176753.120853.65.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-09-23 15:50           ` Linus Torvalds
  0 siblings, 0 replies; 186+ messages in thread
From: Linus Torvalds @ 2017-09-23 15:50 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Sat, Sep 23, 2017 at 4:25 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> This looks very similar - fixes mixed in with what looks like
>> development and new features that have never worked before.
>
> I disagree...I just went through the list of patches I sent you, and if
> there's something there you don't think is a fix, I'm happy to hear
> about it.  But from my reading, they are all fixes.

Ok, pulled.

             Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFz2hYPEkweckHKpOU45bHQU7tFLKYoVWaMGduMSP4NCFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-09-23 14:25       ` Doug Ledford
       [not found]         ` <1506176753.120853.65.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-09-23 14:25 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Fri, 2017-09-22 at 17:23 -1000, Linus Torvalds wrote:
> On Fri, Sep 22, 2017 at 11:12 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > - Smattering of miscellanous fixes
> > - A five patch series for i40iw that had a patch (5/5) that was
> > larger
> >   than I would like, but I took it because it's needed for large
> > scale
> >   users
> > - An 8 patch series for bnxt_re that landed right as I was leaving
> > on
> >   PTO and so had to wait until now...they are all appropriate fixes
> > for
> >   -rc IMO
> 
> Honestly, I'm not sure if I'm going to pull this. I already got one
> "fix" pull request today that I didn't think was just fixes.
> 
> This looks very similar - fixes mixed in with what looks like
> development and new features that have never worked before.

I disagree...I just went through the list of patches I sent you, and if
there's something there you don't think is a fix, I'm happy to hear
about it.  But from my reading, they are all fixes.  The only one
that's possibly arguable is f16dc0aa5ea2 (i40iw: Add support for port
reuse on active side connections) and I specifically called that one
out and listed the reason I included it.

> I thought we agreed thar rdma wasn't going to continue to be "that
> subsystem"?

I don't think that's the case here.  Please let me know any patches in
this list that you disagree with being fixes.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1506114769.120853.7.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-09-23  3:23   ` Linus Torvalds
       [not found]     ` <CA+55aFz2hYPEkweckHKpOU45bHQU7tFLKYoVWaMGduMSP4NCFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-09-23  3:23 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Fri, Sep 22, 2017 at 11:12 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> - Smattering of miscellanous fixes
> - A five patch series for i40iw that had a patch (5/5) that was larger
>   than I would like, but I took it because it's needed for large scale
>   users
> - An 8 patch series for bnxt_re that landed right as I was leaving on
>   PTO and so had to wait until now...they are all appropriate fixes for
>   -rc IMO

Honestly, I'm not sure if I'm going to pull this. I already got one
"fix" pull request today that I didn't think was just fixes.

This looks very similar - fixes mixed in with what looks like
development and new features that have never worked before.

I thought we agreed thar rdma wasn't going to continue to be "that subsystem"?

               Linu
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-09-22 21:12 Doug Ledford
       [not found] ` <1506114769.120853.7.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-09-22 21:12 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

I'm back from PTO (if you can call it that, moves are more stress than
relaxation).  As I mentioned in my pull request prior to leaving there
was an outstanding 8 patch series and a couple misc items that I knew I
needed to look at when I got back.  In the intervening time, a few more
things also cropped up.  All in all, the 8 patch bnxt_re series looked
-rc appropriate to me.  The 5 patch i40iw series looked mostly
appropriate.  One of it's patches is larger than I would like to see,
but it solves a scale up issue in a reasonable way despite its size, to
I took it too.  Then there were a smattering of random patches, all
appropriate for an early -rc cycle.  For three weeks of buildup while I
was out, it's really not bad.  Here's the boilerplate:

 The following changes since commit 8eb19e8e7c8658226d8b7e75728e6dfa2ef32717:

  IB/core: Expose ioctl interface through experimental Kconfig (2017-08-31 08:35:14 -0400)

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 89aaca54ba60e91f02c1c168fbef5d71f71a6d43:

  bnxt_re: Don't issue cmd to delete GID for QP1 GID entry before the QP is destroyed (2017-09-22 13:57:33 -0400)

----------------------------------------------------------------
First -rc update for 4.14 kernel

- Smattering of miscellanous fixes
- A five patch series for i40iw that had a patch (5/5) that was larger
  than I would like, but I took it because it's needed for large scale
  users
- An 8 patch series for bnxt_re that landed right as I was leaving on
  PTO and so had to wait until now...they are all appropriate fixes for
  -rc IMO

----------------------------------------------------------------
Adit Ranadive (1):
      RDMA/vmw_pvrdma: Fix reporting correct opcodes for completion

Alex Estrin (1):
      IB/core: Fix for core panic

Colin Ian King (1):
      IB/ocrdma: fix incorrect fall-through on switch statement

Devesh Sharma (2):
      bnxt_re: Fix update of qplib_qp.mtu when modified
      bnxt_re: Fix compare and swap atomic operands

Leon Romanovsky (1):
      IB/bnxt_re: Fix frame stack compilation warning

Mustafa Ismail (1):
      i40iw: Add missing VLAN priority

Santosh Shilimkar (1):
      IB/ipoib: Suppress the retry related completion errors

Selvin Xavier (1):
      bnxt_re: Fix memory leak in FRMR path

Shiraz Saleem (4):
      i40iw: Fail open if there are no available MSI-X vectors
      i40iw: Prevent multiple netdev event notifier registrations
      i40iw: Call i40iw_cm_disconn on modify QP to disconnect
      i40iw: Add support for port reuse on active side connections

Somnath Kotur (5):
      bnxt_re: Stop issuing further cmds to FW once a cmd times out
      bnxt_re: Free up devices in module_exit path
      bnxt_re: Fix race between the netdev register and unregister events
      bnxt_re: Remove RTNL lock dependency in bnxt_re_query_port
      bnxt_re: Don't issue cmd to delete GID for QP1 GID entry before the QP is destroyed

Steve Wise (3):
      iw_cxgb4: put ep reference in pass_accept_req()
      iw_cxgb4: drop listen destroy replies if no ep found
      iw_cxgb4: remove the stid on listen create failure

Sudip Mukherjee (1):
      IB/mlx5: fix debugfs cleanup

 drivers/infiniband/core/verbs.c            |   4 +-
 drivers/infiniband/hw/bnxt_re/bnxt_re.h    |  14 ++-
 drivers/infiniband/hw/bnxt_re/ib_verbs.c   | 107 ++++++++++++--------
 drivers/infiniband/hw/bnxt_re/main.c       |  28 ++++++
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c |   4 +
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h |   3 +-
 drivers/infiniband/hw/cxgb4/cm.c           |   9 +-
 drivers/infiniband/hw/i40iw/i40iw.h        |   1 -
 drivers/infiniband/hw/i40iw/i40iw_cm.c     | 154 ++++++++++++++---------------
 drivers/infiniband/hw/i40iw/i40iw_cm.h     |   5 +
 drivers/infiniband/hw/i40iw/i40iw_main.c   |  39 +++++---
 drivers/infiniband/hw/i40iw/i40iw_utils.c  |   6 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c  |  12 +++
 drivers/infiniband/hw/mlx5/main.c          |   6 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c   |   3 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h  |  31 +++++-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c    |  16 ++-
 17 files changed, 281 insertions(+), 161 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-08-31 13:42 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-08-31 13:42 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

I'm already on PTO, and will be on PTO throughout the merge window
(I'll try to pop in here or there, but we close on our new house today
and will be moving over the next few weeks), so I'm sending this now to
make sure it is in your hands in plenty of time.

This is a big pull request.  There are a few things that trickled into
the list that I couldn't get to before going on PTO.  I will try and
have some of those sorted before -rc1 (right now there are 10 patches
that need to be handled, a series of 2 and a series of 8).

Of note is that I'm sending you the new ioctl API for the rdma
subsystem.  We put it up on linux-api@, but didn't get much response. 
The API is complex, but it solves two different problems in one go:

1) The bi-directional nature of the RDMA file write calls, which
created the security hole we had to handle (and for which the fix is
now causing problems for systems in production, we were a bit over
zealous in the fix and the ability to open a device, then fork, then
create new queue pairs on the device and use them is broken).

2) The bloat caused by different vendors implementing extensions to the
base verbs API.  Each vendor's hardware is slightly different, and the
hardware might be suitable for one extension but not another.  By the
time we add generic extensions for all the different ways that the
different hardware can offload things, the API becomes bloated.  Things
like our completion structs have started to exceed a cache line in size
because of all the elements needed to support this.  That in turn shows
up heavily in the performance graphs with a noticable drop in
performance on 100Gigabit links as our completion structs go from
occupying one cache line to 1+.  This API makes things like the
completion structs modular in a very similar way to netlink so that
your structs can only include the items needed for the
offloads/features you are actually using on a given queue pair.  In
that way we support everything, but only use what we need, and our
structs stay smaller.

The ioctl API is better explained by the posting on linux-api@ than I
can explain it here, so I'll just leave it at that.

The rest of the pull request is typical stuff.  This tree is *not*
based on net-next, and in general I won't be submitting trees based on
net-next any more.

Finally, I'm giving you two different pull request URLs here.  The only
difference between the two is one is the base pull request plus the
ioctl interface, and the other is just the base pull request (in case
you want to skip the ioctl interface).  The boilerplate I'm including
will be for the ioctl interface included pull request, and in addition
there are a number of patches that the boilerplate pulls up that will
drop out (I had split my for-next area off at v4.13-rc2, but during the
development window, I merged in my -rc pull requests so that we would
be developing/testing on the fixed code and not code that still had
bugs we eliminated in the -rc cycles, all of those -rc patches sent to
you post v4.13-rc2 will drop out of this pull request and not show up
in the final diffstat when you try to pull this).

With the ioctl interface:

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

*or* without the ioctl interface:

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

The boilerplate:

The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:

  Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)

are available in the git repository at:

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

for you to fetch changes up to 8eb19e8e7c8658226d8b7e75728e6dfa2ef32717:

  IB/core: Expose ioctl interface through experimental Kconfig (2017-08-31 08:35:14 -0400)

----------------------------------------------------------------
Updates for 4.14 kernel merge window

- Lots of hfi1 driver updates (mixed with a few qib and core updates as
  well)
- rxe updates
- various mlx updates
- Set default roce type to RoCEv2
- Several larger fixes for bnxt_re that were too big for -rc
- Several larger fixes for qedr that, likewise, were too big for -rc
- Misc core changes
- Make the hns_roce driver compilable on arches other than aarch64 so we
  can more easily debug build issues related to it
- Add rdma-netlink infrastructure updates
- Add automatic IRQ affinity infrastructure
- Add 32bit lid support
- Lots of misc fixes across the subsystem from random people
- Autoloading of RDMA netlink modules
- PCI pool cleanups from Romain Perier
- mlx5 driver feature additions and fixes
- Hardware tag matchine feature
- Fix sleeping in atomic when resolving roce ah
- Add experimental ioctl interface as posted to linux-api@

----------------------------------------------------------------
Adit Ranadive (2):
      RDMA/vmw_pvrdma: Update device query parameters and port caps
      RDMA/vmw_pvrdma: Fix a signedness

Aditya Sarwade (1):
      RDMA/vmw_pvrdma: Report network header type in WC

Alex Estrin (3):
      IB/hfi1: Verify port data VLs credits on transition to Armed
      IB/hfi1: Harden state transition to Armed and Active
      IB/hfi1: Revert egress pkey check enforcement

Alex Vesker (2):
      IB/ipoib: Prevent setting negative values to max_nonsrq_conn_qp
      IB/ipoib: Add multicast packets statistics

Amrani, Ram (3):
      RDMA/qedr: notify user application if DPM is supported
      RDMA/qedr: notify user application of supported WIDs
      IB/core: Fix input len in multiple user verbs

Andrew Boyer (11):
      IB/rxe: Move refcounting earlier in rxe_send()
      IB/rxe: Disable completion upcalls when a CQ is destroyed
      IB/rxe: Remove dangling prototype
      IB/rxe: Fix up the responder's find_resources() function
      IB/rxe: Fix destination cache for IPv6
      IB/rxe: Add dst_clone() in prepare_ipv6_hdr()
      IB/rxe: Fix up rxe_qp_cleanup()
      IB/rxe: Remove unneeded initialization in prepare6()
      IB/rxe: Another fix for broken receive queue draining
      IB/rxe: Avoid ICRC errors by copying into the skb first
      IB/rxe: Handle NETDEV_CHANGE events

Arnd Bergmann (2):
      IB/hns: include linux/interrupt.h
      infiniband: avoid overflow warning

Artemy Kovalyov (11):
      net/mlx5: Update HW layout definitions
      IB/core: Add XRQ capabilities
      IB/core: Separate CQ handle in SRQ context
      IB/core: Add new SRQ type IB_SRQT_TM
      IB/uverbs: Add XRQ creation parameter to UAPI
      IB/uverbs: Add new SRQ type IB_SRQT_TM
      IB/uverbs: Expose XRQ capabilities
      IB/mlx5: Fill XRQ capabilities
      net/mlx5: Add XRQ support
      IB/mlx5: Support IB_SRQT_TM
      Documentation: Hardware tag matching

Arvind Yadav (4):
      infiniband: mthca: constify pci_device_id.
      infiniband: nes: constify pci_device_id.
      infiniband: pvrdma: constify pci_device_id.
      IB/hfi1: constify vm_operations_struct

Bartlomiej Dudek (4):
      IB/hfi1: Fix DC 8051 host info flag array
      IB/hfi1: Check return values from PCI config API calls
      IB/hfi1: Move saving PCI values to a separate function
      IB/hfi1: Use host_link_state to read state when DC is shut down

Bharat Potnuri (2):
      RDMA/uverbs: Initialize cq_context appropriately
      RDMA/uverbs: Initialize cq_context appropriately

Bhumika Goyal (3):
      IB/qib: add const to bin_attribute structures
      IB/hfi1: add const to bin_attribute structures
      i40iw: make some structures const

Bodong Wang (3):
      IB/mlx5: Restore IB guid/policy for virtual functions
      IB/mlx5: Allow posting multi packet send WQEs if hardware supports
      IB/mlx5: Report mlx5 enhanced multi packet WQE capability

Bryan Tan (2):
      RDMA/vmw_pvrdma: Report CQ missed events
      RDMA/vmw_pvrdma: Add RoCEv2 support

Byczkowski, Jakub (3):
      IB/hfi1: Modify handling of physical link state by Host Driver
      IB/hfi1: Fix initialization failure for debug firmware
      IB/hfi1: Remove lstate from hfi1_pportdata

Chien Tin Tung (1):
      i40iw: Fix parsing of query/commit FPM buffers

Christophe Jaillet (2):
      cxgb4: Remove some dead code
      i40iw: Simplify code

Christopher N Bednarz (2):
      i40iw: Use correct alignment for CQ0 memory
      i40iw: Fix potential fcn_id_array out of bounds

Colin Ian King (8):
      net/mlx5: fix spelling mistake: "alloated" -> "allocated"
      IB/hns: fix memory leak on ah on error return path
      IB/qib: fix spelling mistake: "failng" -> "failing"
      IB/hfi1: fix spelling mistake in variable name continious
      RDMA/bnxt_re: fix spelling mistake: "Deallocte" -> "Deallocate"
      i40iw: fix spelling mistake: "allloc_buf" -> "alloc_buf"
      IB/hfi1: fix spelling mistake: "Maximim" -> "Maximum"
      RDMA/qedr: fix spelling mistake: "invlaid" -> "invalid"

Dan Carpenter (2):
      IB/hns: checking for IS_ERR() instead of NULL
      IB/usnic: check for allocation failure

Dasaratharaman Chandramouli (10):
      IB/core: Convert ah_attr from OPA to IB when copying to user
      IB/srpt: Increase lid and sm_lid to 32 bits
      IB/IPoIB: Increase local_lid to 32 bits
      IB/mad: Change slid in RMPP recv from 16 to 32 bits
      IB/core: Change port_attr.lid size from 16 to 32 bits
      IB/core: Change port_attr.sm_lid from 16 to 32 bits
      IB/CM: Create appropriate path records when handling CM request
      IB/CM: Set appropriate slid and dlid when handling CM request
      IB/rdmavt, hfi1, qib: Enhance rdmavt and hfi1 to use 32 bit lids
      IB/hfi1: Enable RDMA_CAP_OPA_AH in hfi driver to support extended LIDs

Dennis Dalessandro (7):
      IB/rdmavt: Remove duplicated functions
      IB/hfi1: Ensure dd->gi_mask can not be overflowed
      IB/hfi1: Fix spelling mistake in linkdown reason
      IB/hfi1: Use QPN mask to avoid overflow
      IB/hfi1: Remove subtraction of uninitialized value
      IB/hfi1,qib: Do not send QKey trap for UD qps
      IB/hfi1: Document phys port state bits not used in IB

Don Hiatt (12):
      IB/hfi1: Add functions to parse BTH/IB headers
      IB/hfi1: Separate input/output header tracing
      IB/hfi1: Setup common IB fields in hfi1_packet struct
      IB/rdmavt, hfi1, qib: Modify check_ah() to account for extended LIDs
      IB/hfi1: Add support to receive 16B bypass packets
      IB/hfi1: Add support to send 16B bypass packets
      IB/hfi1: Add support to process 16B header errors
      IB/hfi1: Determine 9B/16B L2 header type based on Address handle
      IB/hfi1: Add 16B UD support
      IB/hfi1: Add 16B trace support
      IB/hfi1: Add 16B RC/UC support
      IB/hfi1: Enhance PIO/SDMA send for 16B

Doug Ledford (15):
      Merge branch 'k.o/for-4.12-rc' into k.o/for-4.13-mlx-shared
      Merge branch 'hfi1' into k.o/for-4.14
      Merge branches 'rxe' and 'mlx' into k.o/for-next
      Merge branch 'misc' into k.o/for-next
      IB/cma: Fix default RoCE type setting
      RDMA/hns: fix build regression
      Merge tag 'rdma-rc-2017-07-26' of git://git.kernel.org/.../leon/linux-rdma into leon-ipoib
      Merge tag 'rdma-next-2017-08-10' of git://git.kernel.org/.../leon/linux-rdma into rdma-netlink
      Merge branches '32bit_lid' and 'irq_affinity' into k.o/merge-test
      Merge branch 'rdma-netlink' into k.o/merge-test
      Revert "RDMA/hns: fix build regression"
      Merge branch 'misc' into k.o/for-next
      Merge branch 'k.o/for-4.13-rc' into k.o/for-next
      Merge branch 'k.o/for-4.13-rc' into k.o/for-next
      Merge branch 'mellanox' into k.o/for-next

Erez Shitrit (4):
      IB/ipoib: Use cancel_delayed_work_sync when needed
      IB/ipoib: Make sure no in-flight joins while leaving that mcast
      IB/ipoib: Notify on modify QP failure only when relevant
      IB/ipoib: Sync between remove_one to sysfs calls that use rtnl_lock

Feras Daoud (4):
      IB/ipoib: Fix race between light events and interface restart
      IB/ipoib: Set IPOIB_NEIGH_TBL_FLUSH after flushed completion initialization
      IB/ipoib: Add get statistics support to SRIOV VF
      IB/ipoib: Enable ioctl for to IPoIB rdma netdevs

Greg Kroah-Hartman (1):
      PCI/IB: add support for pci driver attribute groups

Grzegorz Morys (2):
      IB/hfi1: Remove HFI1_VERBS_31BIT_PSN option
      IB/hfi1: Ratelimit prints from sdma_interrupt

Gustavo A. R. Silva (1):
      IB/qib: remove duplicate code

Guy Levi (8):
      IB/mlx4: Add support for WQ related verbs
      IB/mlx4: Add support for WQ indirection table related verbs
      IB/mlx4: Add support for RSS QP
      IB/mlx4: Expose RSS capabilities
      IB/mlx4: Fix RSS QP type in creation verb
      IB/mlx4: Fix struct mlx4_ib_create_wq alignment
      IB/mlx4: Remove redundant attribute in mlx4_ib_create_qp_rss struct
      IB/mlx4: Check that reserved fields in mlx4_ib_create_qp_rss are zero

Harish Chegondi (7):
      IB/hfi1: Clean up hfi1_user_exp_rcv_setup function
      IB/hfi1: Clean up user_sdma_send_pkts() function
      IB/hfi1: Clean up pin_vector_pages() function
      IB/hfi1: Fix the bail out code in pin_vector_pages() function
      IB/hfi1: Remove duplicate definitions of num_user_pages() function
      IB/hfi1: Move structure definitions from user_exp_rcv.c to user_exp_rcv.h
      IB/hfi1: Move structure and MACRO definitions in user_sdma.c to user_sdma.h

Hiatt, Don (3):
      IB/core: Change wc.slid from 16 to 32 bits
      IB/CM: Add OPA Path record support to CM
      Add OPA extended LID support

Himanshu Jha (1):
      RDMA/bnxt_re: remove unnecessary call to memset

Huy Nguyen (3):
      net/mlx5: Add raw ethernet local loopback firmware command
      IB/mlx5: Add raw ethernet local loopback support
      net/mlx5e: Enable local loopback in loopback selftest

Ilya Lesokhin (3):
      IB/mlx5: Enable UMR for MRs created with reg_create
      IB/mlx5: Decouple MR allocation and population flows
      IB/mlx5: Fix integer overflow when page_shift == 31

Ira Weiny (2):
      IB/hfi1: Remove unused mk_qpn function
      IB/hfi1: Fix up sdma_init function comment

Ismail, Mustafa (1):
      RDMA/core: Add wait/retry version of ibnl_unicast

Jakub Byczkowski (3):
      IB/hfi1: Add flag for platform config scratch register read
      IB/hfi1: Load fallback platform configuration per HFI device
      IB/hfi1: Remove pstate from hfi1_pportdata

Jan Sokolowski (7):
      IB/hfi1: Set proper logging levels on QSFP cable error events
      IB/hfi1: Remove reading platform configuration from EFI variable
      IB/hfi1: Handle missing magic values in config file
      IB/hfi1: Fix code consistency for if/else blocks in chip.c
      IB/hfi1: Do not enable disabled port on cable insert
      IB/hfi1: Disambiguate corruption and uninitialized error cases
      IB/hfi1: Acquire QSFP cable information on loopback

Jason Gunthorpe (2):
      rdma: Allow demand loading of NETLINK_RDMA
      rdma: Autoload netlink client modules

Kaike Wan (5):
      IB/hfi1: Add receiving queue info to qp_stats
      IB/hfi1: Serve the most starved iowait entry first
      IB/hfi1: Add kernel receive context info to debugfs
      IB/hfi1: Add received request info to qp_stats
      IB/hfi1: Use accessor to determine ring size

Kalesh AP (1):
      RDMA/bnxt_re: Add vlan tag for untagged RoCE traffic when PFC is configured

Kamal Heib (7):
      IB/rxe: Use "foo *bar" instead of "foo * bar"
      IB/rxe: Prefer 'unsigned int' to bare use of 'unsigned'
      IB/rxe: Use DEVICE_ATTR_RO macro to show parent field
      IB/rxe: Use __func__ to print function's name
      IB/rxe: Constify static rxe_vm_ops
      IB/rxe: Make rxe_counter_name static
      IB/mlx5: Fix memory leak in clean_mr error path

Kamenee Arumugam (4):
      IB/qib: Remove unnecessary memory allocation for boardname
      IB/qib: Stricter bounds checking for copy and array access
      IB/hfi1: Fix whitespace alignment issue for MAD
      IB/qib: Stricter bounds checking for copy to buffer

Kamenee Arumugame (1):
      IB/hfi1: Stricter bounds checking of MAD trap index

Leon Romanovsky (52):
      IB/ipoib: Clean error paths in add port
      IB/ipoib: Remove double pointer assigning
      Revert "IB/core: Allow QP state transition from reset to error"
      RDMA/bnxt_re: Delete unsupported modify_port function
      RDMA: Remove useless MODULE_VERSION
      IB/mlx5: Fix existence check for extended address vector
      RDMA/uverbs: Prevent leak of reserved field
      RDMA/mlx5: Fix existence check for extended address vector
      RDMA/netlink: Remove netlink clients infrastructure
      RDMA/netlink: Remove redundant owner option for netlink callbacks
      RDMA/netlink: Avoid double pass for RDMA netlink messages
      RDMA/iwcm: Remove useless check of netlink client validity
      RDMA/iwcm: Remove extra EXPORT_SYMBOLS
      RDMA/netlink: Add flag to consolidate common handling
      RDMA/netlink: Simplify the put_msg and put_attr
      RDMA/netlink: Rename and remove redundant parameter from ibnl_unicast*
      RDMA/netlink: Rename and remove redundant parameter from ibnl_multicast
      RDMA/netlink: Simplify and rename ibnl_chk_listeners
      RDMA/netlink: Rename netlink callback struct
      RDMA/core: Add iterator over ib_devices
      RDMA/core: Add and expose static device index
      RDMA/netlink: Add and implement doit netlink callback
      RDMA/netlink: Reduce indirection access to cb_table
      RDMA/netlink: Convert LS to doit callback
      RDMA/netlink: Update copyright
      RDMA/netlink: Add netlink device definitions to UAPI
      RDMA/netlink: Add nldev initialization flows
      RDMA/netlink: Implement nldev device dumpit calback
      RDMA/netlink: Add nldev device doit implementation
      RDMA/netlink: Add nldev port dumpit implementation
      RDMA/netlink: Implement nldev port doit callback
      RDMA/netlink: Expose device and port capability masks
      RDMA: Simplify get firmware interface
      RDMA/netlink: Export FW version
      RDMA/netlink: Export node_guid and sys_image_guid
      RDMA/netlink: Advertise IB subnet prefix
      RDMA/netink: Export lids and sm_lids
      RDMA/netlink: Export LID mask control (LMC)
      RDMA/netlink: Provide port state and physical link state
      RDMA/netlink: Export node_type
      IB/cma: Fix erroneous validation of supported default GID type
      RDMA/mlx4: Don't use uninitialized variable
      RDMA/(core, ulp): Convert register/unregister event handler to be void
      RDMA/core: Cleanup device capability enum
      RDMA/core: Delete BUG() from unreachable flow
      RDMA/core: Refactor get link layer wrapper
      RDMA/mlx4: Remove gfp_mask argument from acquire_group call
      RDMA/usnic: Fix remove address space warning
      RDMA/mthca: Make explicit conversion to 64bit value
      RDMA/mlx5: Limit scope of get vector affinity local function
      RDMA/mlx4: Properly annotate link layer variable
      RDMA/nes: Remove zeroed parameter from port query callback

Li Dongyang (2):
      IB/mlx5: use kvmalloc_array for mlx5_ib_wq
      IB/mlx4: use kvmalloc_array to allocate wrid

Majd Dibbiny (3):
      IB/mlx5: Fix cached MR allocation flow
      IB/mlx5: Fix Raw Packet QP event handler assignment
      IB/mlx5: Always return success for RoCE modify port

Maor Gottlieb (9):
      IB/core: Introduce delay drop for a WQ
      net/mlx5: Introduce set delay drop command
      net/mlx5: Introduce general notification event
      IB/mlx5: Add support to dropless RQ
      IB/mlx5: Add delay drop configuration and statistics
      IB/mlx4: Add inline-receive support
      IB/uverbs: Fix NULL pointer dereference during device removal
      RDMA/mlx4: Fix create qp command alignment
      IB/mlx5: Add necessary delay drop assignment

Matan Barak (15):
      IB/hns: Support compile test for hns RoCE driver
      IB/hns: Avoid compile test under non 64bit environments
      IB/core: Add a generic way to execute an operation on a uobject
      IB/core: Add support to finalize objects in one transaction
      IB/core: Add new ioctl interface
      IB/core: Declare an object instead of declaring only type attributes
      IB/core: Add DEVICE object and root tree structure
      IB/core: Add uverbs merge trees functionality
      IB/core: Add macros for declaring methods and attributes
      IB/core: Explicitly destroy an object while keeping uobject
      IB/core: Export ioctl enum types to user-space
      IB/core: Add legacy driver's user-data
      IB/core: Add completion queue (cq) object actions
      IB/core: Assign root to all drivers
      IB/core: Expose ioctl interface through experimental Kconfig

Michael J. Ruhl (17):
      IB/hfi1: Name function prototype parameters for affinity module
      IB/hfi1: Replace deprecated pci functions with new API
      IB/qib: Replace deprecated pci functions with new API
      IB/hfi1: Initialize TID lists to avoid crash on cleanup
      IB/hfi1: Resolve kernel panics by reference counting receive contexts
      IB/hfi1: Assign context does not clean up file descriptor correctly on error
      IB/hfi1: Remove unused user context data members
      IB/hfi1: Size rcd array index correctly and consistently
      IB/hfi1: Use context pointer rather than context index
      IB/hfi1: Pass the context pointer rather than the index
      IB/hfi1: Send MAD traps until repressed
      IB/hfi1: Split copy_to_user data copy for better security
      IB/hfi1: Only set fd pointer when base context is completely initialized
      IB/hfi1: Protect context array set/clear with spinlock
      IB/hf1: User context locking is inconsistent
      IB/hfi1: Improve local kmem_cache_alloc performance
      IB/hif1: Remove static tracing from SDMA hot path

Mike Marciniszyn (14):
      IB/rdmavt: Compress adjacent SGEs in rvt_lkey_ok()
      IB/hfi1: Create common expected receive verbs/PSM code
      IB/hfi1: Use a template for tid reg/unreg
      IB/hfi1: Add traces for TID operations
      IB/hfi1: Fix bar0 mapping to use write combining
      IB/{rdmavt, hfi1, qib}: Fix panic with post receive and SGE compression
      IB/rdmavt: Use rvt_put_swqe() in rvt_clear_mr_ref()
      IB/{qib, hfi1}: Avoid flow control testing for RDMA write operation
      IB/hfi1: Add opcode states to qp_stats
      IB/rdmavt: Add QP iterator API for QPs
      IB/hfi1: Convert hfi1_error_port_qps() to use new QP iterator
      IB/hfi1: Convert qp_stats debugfs interface to use new iterator API
      IB/qib: Convert qp_stats debugfs interface to use new iterator API
      IB/rdmavt: Handle dereg of inuse MRs properly

Moni Shoua (2):
      IB/cma: Set default gid type to RoCEv2
      IB/mlx5: Change logic for dispatching IB events for port state

Moshe Shemesh (1):
      (IB, net)/mlx4: Add resource utilization support

Mustafa Ismail (2):
      i40iw: Correct variable names
      i40iw: Fix typecast of tcp_seq_num

Neel Desai (1):
      IB/hfi1: Add error checking for buffer overrun in OPA aggregate

Noa Osherovich (5):
      IB/core: Fix the validations of a multicast LID in attach or detach operations
      IB/core: Set RoCEv2 MGID according to spec
      IB/core: Add support for RoCEv2 multicast
      IB/core: Avoid accessing non-allocated memory when inferring port type
      IB/mlx5: Expose software parsing for Raw Ethernet QP

Parav Pandit (4):
      IB/mlx5: Add debug control parameters for congestion control
      IB/mlx5: Expose extended error counters
      IB/core: Fix race condition in resolving IP to MAC
      IB/uverbs: Introduce and use helper functions to copy ah attributes

Roland Dreier (2):
      IB/cm: Fix sleeping in atomic when RoCE is used
      IB/core: Add might_sleep() annotation to ib_init_ah_from_wc()

Romain Perier (3):
      IB/mthca: Replace PCI pool old API
      mlx4: Replace PCI pool old API
      mlx5: Replace PCI pool old API

Sagi Grimberg (12):
      mlx5: convert to generic pci_alloc_irq_vectors
      mlx5e: don't assume anything on the irq affinity mappings of the device
      mlx5: move affinity hints assignments to generic code
      RDMA/core: expose affinity mappings per completion vector
      mlx5: support ->get_vector_affinity
      block: Add rdma affinity based queue mapping helper
      nvme-rdma: use intelligent affinity based queue mappings
      RDMA/core: make ib_device.add method optional
      nvme-rdma: remove redundant empty device add callout
      nvmet-rdma: remove redundant empty device add callout
      cm: Don't allocate ib_cm workqueue with WQ_MEM_RECLAIM
      iwcm: Don't allocate iwcm workqueue with WQ_MEM_RECLAIM

Sebastian Sanchez (11):
      IB/hfi1: Remove unnecessary initialization from tx request
      IB/hfi1: Don't remove RB entry when not needed.
      IB/hfi1: Optimize cachelines for user SDMA request structure
      IB/hfi1: Remove atomic SDMA_REQ_SEND_DONE bit operation
      IB/hfi1: Remove atomic SDMA_REQ_HAS_ERROR bit operation
      IB/hfi1: Reclassify type of messages printed for platform config logic
      IB/hfi1: Create workqueue for link events
      IB/hfi1: Prevent link down request double queuing
      IB/hfi1: Always perform offline transition
      IB/hfi1: Remove pmtu from the QP structure
      IB/hfi1: Check xchg returned value for queuing link down entry

Selvin Xavier (4):
      RDMA/bnxt_re: Allow posting when QPs are in error
      RDMA/bnxt_re: Allocate multiple notification queues
      RDMA: Fix return value check for ib_get_eth_speed()
      IB: Avoid ib_modify_port() failure for RoCE devices

Shiraz Saleem (3):
      IB/core: Protect sysfs entry on ib_unregister_device
      i40iw: Fixes for static checker warnings
      i40iw: Improve CQP timeout logic

Somnath Kotur (1):
      RDMA/bnxt_re: Implement the alloc/get_hw_stats callback

Steve Wise (1):
      iw_cxgb4: fix misuse of integer variable

Tadeusz Struk (1):
      IB/core: Allow QP state transition from reset to error

Talat Batheesh (2):
      IB/mlx4: Fix some spelling mistakes
      IB/mlx5: Fix some spelling mistakes

Vishwanathapura, Niranjana (1):
      IB/core,rdmavt,hfi1,opa-vnic: Send OPA cap_mask3 in trap

Yishai Hadas (8):
      IB/core: Enable QP creation with a given source QP number
      IB/uverbs: Enable QP creation with a given source QP number
      IB/mlx5: Add support for QP with a given source QPN
      IB/mlx5: Add multicast flow steering support for underlay QP
      net/mlx5: Report enhanced capabilities for IPoIB
      IB/mlx5: Report RX checksum capabilities for IPoIB
      IB/uverbs: Fix device cleanup
      IB/mlx5: Add support for multi underlay QP

Yuval Shaia (6):
      IB/usnic: Implement get_netdev hook
      IB/core: Add generic function to extract IB speed from netdev
      IB/rxe: Convert pr_info to pr_warn
      IB/rxe: Remove unneeded check
      IB/pvrdma: Remove unused function
      RDMA/i40iw: Remove unused argument

kbuild test robot (3):
      IB/hns: fix boolreturn.cocci warnings
      IB/hns: fix returnvar.cocci warnings
      IB/hns: fix semicolon.cocci warnings

 Documentation/infiniband/tag_matching.txt          |   64 ++
 block/Kconfig                                      |    5 +
 block/Makefile                                     |    1 +
 block/blk-mq-rdma.c                                |   52 +
 drivers/infiniband/Kconfig                         |    9 +
 drivers/infiniband/core/Makefile                   |    6 +-
 drivers/infiniband/core/addr.c                     |   74 +-
 drivers/infiniband/core/cache.c                    |   23 +-
 drivers/infiniband/core/cm.c                       |  224 ++++-
 drivers/infiniband/core/cma.c                      |   35 +-
 drivers/infiniband/core/core_priv.h                |   27 +-
 drivers/infiniband/core/device.c                   |  149 ++-
 drivers/infiniband/core/iwcm.c                     |   16 +-
 drivers/infiniband/core/iwpm_msg.c                 |   20 +-
 drivers/infiniband/core/iwpm_util.c                |   15 +-
 drivers/infiniband/core/mad_rmpp.c                 |    2 +-
 drivers/infiniband/core/netlink.c                  |  321 +++---
 drivers/infiniband/core/nldev.c                    |  325 ++++++
 drivers/infiniband/core/rdma_core.c                |  179 ++++
 drivers/infiniband/core/rdma_core.h                |   42 +
 drivers/infiniband/core/roce_gid_mgmt.c            |    2 +
 drivers/infiniband/core/sa_query.c                 |   42 +-
 drivers/infiniband/core/sysfs.c                    |    4 +-
 drivers/infiniband/core/ucm.c                      |    2 +-
 drivers/infiniband/core/ucma.c                     |   10 +-
 drivers/infiniband/core/user_mad.c                 |    2 +-
 drivers/infiniband/core/uverbs.h                   |    3 +
 drivers/infiniband/core/uverbs_cmd.c               |  283 +++---
 drivers/infiniband/core/uverbs_ioctl.c             |  364 +++++++
 drivers/infiniband/core/uverbs_ioctl_merge.c       |  665 ++++++++++++
 drivers/infiniband/core/uverbs_main.c              |   42 +-
 drivers/infiniband/core/uverbs_marshall.c          |   48 +-
 drivers/infiniband/core/uverbs_std_types.c         |  281 +++++-
 drivers/infiniband/core/verbs.c                    |  177 +++-
 drivers/infiniband/hw/bnxt_re/Makefile             |    2 +-
 drivers/infiniband/hw/bnxt_re/bnxt_re.h            |    5 +-
 drivers/infiniband/hw/bnxt_re/hw_counters.c        |  114 +++
 drivers/infiniband/hw/bnxt_re/hw_counters.h        |   62 ++
 drivers/infiniband/hw/bnxt_re/ib_verbs.c           |  107 +-
 drivers/infiniband/hw/bnxt_re/ib_verbs.h           |    3 -
 drivers/infiniband/hw/bnxt_re/main.c               |  168 +++-
 drivers/infiniband/hw/bnxt_re/qplib_fp.c           |  486 +++++++--
 drivers/infiniband/hw/bnxt_re/qplib_fp.h           |   29 +-
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c         |   26 +-
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h         |   10 +-
 drivers/infiniband/hw/bnxt_re/qplib_res.c          |   10 +
 drivers/infiniband/hw/bnxt_re/qplib_res.h          |    2 +
 drivers/infiniband/hw/bnxt_re/qplib_sp.c           |   77 +-
 drivers/infiniband/hw/bnxt_re/qplib_sp.h           |    2 +
 drivers/infiniband/hw/bnxt_re/roce_hsi.h           |    4 +-
 drivers/infiniband/hw/cxgb3/iwch.c                 |    1 -
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |    5 +-
 drivers/infiniband/hw/cxgb4/cm.c                   |    1 -
 drivers/infiniband/hw/cxgb4/device.c               |    1 -
 drivers/infiniband/hw/cxgb4/mem.c                  |    2 +-
 drivers/infiniband/hw/cxgb4/provider.c             |    5 +-
 drivers/infiniband/hw/hfi1/Kconfig                 |    7 -
 drivers/infiniband/hw/hfi1/Makefile                |    2 +-
 drivers/infiniband/hw/hfi1/affinity.c              |   18 +-
 drivers/infiniband/hw/hfi1/affinity.h              |   14 +-
 drivers/infiniband/hw/hfi1/aspm.h                  |   41 +-
 drivers/infiniband/hw/hfi1/chip.c                  |  808 ++++++++-------
 drivers/infiniband/hw/hfi1/chip.h                  |   29 +-
 drivers/infiniband/hw/hfi1/common.h                |   11 +-
 drivers/infiniband/hw/hfi1/debugfs.c               |   94 +-
 drivers/infiniband/hw/hfi1/driver.c                |  513 +++++++---
 drivers/infiniband/hw/hfi1/eprom.c                 |   11 +-
 drivers/infiniband/hw/hfi1/exp_rcv.c               |  114 +++
 drivers/infiniband/hw/hfi1/exp_rcv.h               |  190 ++++
 drivers/infiniband/hw/hfi1/file_ops.c              |  437 ++++----
 drivers/infiniband/hw/hfi1/firmware.c              |   73 +-
 drivers/infiniband/hw/hfi1/hfi.h                   |  554 +++++++---
 drivers/infiniband/hw/hfi1/init.c                  |  393 ++++++--
 drivers/infiniband/hw/hfi1/intr.c                  |    3 +-
 drivers/infiniband/hw/hfi1/iowait.h                |   70 +-
 drivers/infiniband/hw/hfi1/mad.c                   |  805 ++++++++++-----
 drivers/infiniband/hw/hfi1/mad.h                   |    5 +-
 drivers/infiniband/hw/hfi1/mmu_rb.c                |   27 +-
 drivers/infiniband/hw/hfi1/mmu_rb.h                |    5 +-
 drivers/infiniband/hw/hfi1/opa_compat.h            |   21 +-
 drivers/infiniband/hw/hfi1/pcie.c                  |  384 ++++---
 drivers/infiniband/hw/hfi1/pio.c                   |   15 +-
 drivers/infiniband/hw/hfi1/platform.c              |  102 +-
 drivers/infiniband/hw/hfi1/qp.c                    |  222 ++---
 drivers/infiniband/hw/hfi1/qp.h                    |   23 +-
 drivers/infiniband/hw/hfi1/rc.c                    |  426 +++++---
 drivers/infiniband/hw/hfi1/ruc.c                   |  321 ++++--
 drivers/infiniband/hw/hfi1/sdma.c                  |   42 +-
 drivers/infiniband/hw/hfi1/sdma.h                  |    3 +-
 drivers/infiniband/hw/hfi1/sysfs.c                 |    4 +-
 drivers/infiniband/hw/hfi1/trace.c                 |  191 +++-
 drivers/infiniband/hw/hfi1/trace.h                 |    3 +-
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h          |  456 ++++++---
 drivers/infiniband/hw/hfi1/trace_misc.h            |   20 +
 drivers/infiniband/hw/hfi1/trace_mmu.h             |   95 ++
 drivers/infiniband/hw/hfi1/trace_rx.h              |  102 +-
 drivers/infiniband/hw/hfi1/trace_tx.h              |  136 ++-
 drivers/infiniband/hw/hfi1/uc.c                    |   60 +-
 drivers/infiniband/hw/hfi1/ud.c                    |  487 ++++++---
 drivers/infiniband/hw/hfi1/user_exp_rcv.c          |  371 +++----
 drivers/infiniband/hw/hfi1/user_exp_rcv.h          |   58 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |  626 +++++-------
 drivers/infiniband/hw/hfi1/user_sdma.h             |  169 +++-
 drivers/infiniband/hw/hfi1/verbs.c                 |  384 ++++---
 drivers/infiniband/hw/hfi1/verbs.h                 |   59 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.c           |   11 +-
 drivers/infiniband/hw/hfi1/vnic.h                  |   16 +-
 drivers/infiniband/hw/hfi1/vnic_main.c             |   39 +-
 drivers/infiniband/hw/hfi1/vnic_sdma.c             |   27 +-
 drivers/infiniband/hw/hns/Kconfig                  |    2 +-
 drivers/infiniband/hw/hns/hns_roce_ah.c            |    4 +-
 drivers/infiniband/hw/hns/hns_roce_alloc.c         |    1 +
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    3 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         |    5 +-
 drivers/infiniband/hw/hns/hns_roce_mr.c            |    1 +
 drivers/infiniband/hw/hns/hns_roce_qp.c            |    2 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |   27 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           |  134 ++-
 drivers/infiniband/hw/i40iw/i40iw_d.h              |    4 +-
 drivers/infiniband/hw/i40iw/i40iw_main.c           |    1 -
 drivers/infiniband/hw/i40iw/i40iw_p.h              |   14 +-
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |    9 +-
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |    8 +-
 drivers/infiniband/hw/i40iw/i40iw_status.h         |    2 +-
 drivers/infiniband/hw/i40iw/i40iw_type.h           |    5 +
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   14 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |   22 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |    7 +-
 drivers/infiniband/hw/mlx4/alias_GUID.c            |    4 +-
 drivers/infiniband/hw/mlx4/cq.c                    |    4 +-
 drivers/infiniband/hw/mlx4/mad.c                   |    8 +-
 drivers/infiniband/hw/mlx4/main.c                  |   54 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |    9 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |   42 +-
 drivers/infiniband/hw/mlx4/qp.c                    | 1054 ++++++++++++++++++--
 drivers/infiniband/hw/mlx4/srq.c                   |   17 +-
 drivers/infiniband/hw/mlx5/Makefile                |    2 +-
 drivers/infiniband/hw/mlx5/cmd.c                   |   20 +
 drivers/infiniband/hw/mlx5/cmd.h                   |    4 +
 drivers/infiniband/hw/mlx5/cong.c                  |  421 ++++++++
 drivers/infiniband/hw/mlx5/cq.c                    |    8 +-
 drivers/infiniband/hw/mlx5/ib_virt.c               |    9 +
 drivers/infiniband/hw/mlx5/mad.c                   |    4 +-
 drivers/infiniband/hw/mlx5/main.c                  |  464 ++++++++-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   86 +-
 drivers/infiniband/hw/mlx5/mr.c                    |  121 ++-
 drivers/infiniband/hw/mlx5/odp.c                   |    2 +-
 drivers/infiniband/hw/mlx5/qp.c                    |  172 +++-
 drivers/infiniband/hw/mlx5/srq.c                   |   33 +-
 drivers/infiniband/hw/mthca/mthca_av.c             |   10 +-
 drivers/infiniband/hw/mthca/mthca_cmd.c            |   14 +-
 drivers/infiniband/hw/mthca/mthca_dev.h            |    4 +-
 drivers/infiniband/hw/mthca/mthca_mad.c            |    4 +-
 drivers/infiniband/hw/mthca/mthca_main.c           |    3 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |    7 +-
 drivers/infiniband/hw/nes/nes.c                    |   70 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |   10 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c         |    6 +-
 drivers/infiniband/hw/qedr/main.c                  |    7 +-
 drivers/infiniband/hw/qedr/qedr.h                  |    3 +-
 drivers/infiniband/hw/qedr/verbs.c                 |    5 +-
 drivers/infiniband/hw/qib/qib.h                    |    8 +-
 drivers/infiniband/hw/qib/qib_debugfs.c            |   18 +-
 drivers/infiniband/hw/qib/qib_driver.c             |    1 -
 drivers/infiniband/hw/qib/qib_iba6120.c            |   26 +-
 drivers/infiniband/hw/qib/qib_iba7220.c            |   29 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |   92 +-
 drivers/infiniband/hw/qib/qib_init.c               |    3 +-
 drivers/infiniband/hw/qib/qib_mad.c                |   23 +-
 drivers/infiniband/hw/qib/qib_pcie.c               |  149 ++-
 drivers/infiniband/hw/qib/qib_qp.c                 |   51 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |    4 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   32 +-
 drivers/infiniband/hw/qib/qib_sysfs.c              |    4 +-
 drivers/infiniband/hw/qib/qib_ud.c                 |   43 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |    9 +
 drivers/infiniband/hw/qib/qib_verbs.h              |   14 +-
 drivers/infiniband/hw/usnic/usnic_fwd.c            |   12 +-
 drivers/infiniband/hw/usnic/usnic_fwd.h            |    2 +-
 drivers/infiniband/hw/usnic/usnic_ib_main.c        |   18 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c       |   43 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h       |    1 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |    2 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c       |   20 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h  |   37 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     |   44 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c     |    7 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h     |   17 -
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c    |    9 +
 drivers/infiniband/sw/rdmavt/ah.c                  |   10 -
 drivers/infiniband/sw/rdmavt/cq.c                  |    2 +-
 drivers/infiniband/sw/rdmavt/mr.c                  |  170 +++-
 drivers/infiniband/sw/rdmavt/qp.c                  |  348 ++++++-
 drivers/infiniband/sw/rdmavt/trace_mr.h            |   62 ++
 drivers/infiniband/sw/rdmavt/trace_tx.h            |   11 +-
 drivers/infiniband/sw/rdmavt/vt.c                  |    9 +-
 drivers/infiniband/sw/rxe/rxe.c                    |    1 -
 drivers/infiniband/sw/rxe/rxe.h                    |    2 +-
 drivers/infiniband/sw/rxe/rxe_av.c                 |    7 +-
 drivers/infiniband/sw/rxe/rxe_cq.c                 |   19 +
 drivers/infiniband/sw/rxe/rxe_hw_counters.c        |    2 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |    6 +-
 drivers/infiniband/sw/rxe/rxe_mmap.c               |    2 +-
 drivers/infiniband/sw/rxe/rxe_mr.c                 |   12 +-
 drivers/infiniband/sw/rxe/rxe_net.c                |   26 +-
 drivers/infiniband/sw/rxe/rxe_pool.c               |    2 +-
 drivers/infiniband/sw/rxe/rxe_qp.c                 |    9 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |    6 +-
 drivers/infiniband/sw/rxe/rxe_resp.c               |    2 +-
 drivers/infiniband/sw/rxe/rxe_task.c               |    4 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   67 +-
 drivers/infiniband/sw/rxe/rxe_verbs.h              |    2 +
 drivers/infiniband/ulp/ipoib/ipoib.h               |    4 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |    9 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |    6 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |   25 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |   50 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |   33 +-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c          |   22 +-
 drivers/infiniband/ulp/iser/iscsi_iser.c           |    1 -
 drivers/infiniband/ulp/iser/iser_verbs.c           |    6 +-
 drivers/infiniband/ulp/isert/ib_isert.c            |    1 -
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c    |   35 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |    1 -
 drivers/infiniband/ulp/srpt/ib_srpt.c              |    5 +-
 drivers/infiniband/ulp/srpt/ib_srpt.h              |    4 +-
 drivers/net/ethernet/mellanox/mlx4/cmd.c           |   10 +-
 drivers/net/ethernet/mellanox/mlx4/cq.c            |    7 +-
 drivers/net/ethernet/mellanox/mlx4/en_cq.c         |    1 +
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c     |    3 +-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c         |    6 +-
 drivers/net/ethernet/mellanox/mlx4/en_tx.c         |    3 +-
 drivers/net/ethernet/mellanox/mlx4/main.c          |    7 +-
 drivers/net/ethernet/mellanox/mlx4/mlx4.h          |    2 +-
 drivers/net/ethernet/mellanox/mlx4/qp.c            |    5 +-
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c      |   11 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h       |    1 -
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   57 +-
 .../net/ethernet/mellanox/mlx5/core/en_selftest.c  |   13 +
 drivers/net/ethernet/mellanox/mlx5/core/eq.c       |   32 +-
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c  |    2 +-
 drivers/net/ethernet/mellanox/mlx5/core/fw.c       |    6 +
 drivers/net/ethernet/mellanox/mlx5/core/health.c   |    2 +-
 drivers/net/ethernet/mellanox/mlx5/core/main.c     |  123 +--
 .../net/ethernet/mellanox/mlx5/core/mlx5_core.h    |    1 -
 drivers/net/ethernet/mellanox/mlx5/core/qp.c       |   14 +
 drivers/net/ethernet/mellanox/mlx5/core/sriov.c    |   42 +
 drivers/net/ethernet/mellanox/mlx5/core/srq.c      |  150 ++-
 drivers/net/ethernet/mellanox/mlx5/core/vport.c    |   62 ++
 drivers/nvme/host/rdma.c                           |   34 +-
 drivers/nvme/target/rdma.c                         |    5 -
 drivers/pci/pci-driver.c                           |    1 +
 include/linux/blk-mq-rdma.h                        |   10 +
 include/linux/mlx4/device.h                        |   12 +-
 include/linux/mlx5/device.h                        |   11 +-
 include/linux/mlx5/driver.h                        |   31 +-
 include/linux/mlx5/mlx5_ifc.h                      |  109 +-
 include/linux/mlx5/qp.h                            |    4 +-
 include/linux/mlx5/srq.h                           |    5 +
 include/linux/mlx5/vport.h                         |    3 +-
 include/linux/pci.h                                |    1 +
 include/rdma/ib_addr.h                             |   11 +-
 include/rdma/ib_hdrs.h                             |   84 ++
 include/rdma/ib_marshall.h                         |    6 +-
 include/rdma/ib_verbs.h                            |  163 ++-
 include/rdma/opa_addr.h                            |   42 +-
 include/rdma/opa_vnic.h                            |    3 -
 include/rdma/rdma_netlink.h                        |   58 +-
 include/rdma/rdma_vt.h                             |   23 +-
 include/rdma/rdmavt_mr.h                           |    3 +
 include/rdma/rdmavt_qp.h                           |   33 +-
 include/rdma/uverbs_ioctl.h                        |  438 ++++++++
 include/rdma/uverbs_std_types.h                    |   58 +-
 include/rdma/uverbs_types.h                        |   39 +-
 include/uapi/rdma/ib_user_ioctl_verbs.h            |   84 ++
 include/uapi/rdma/ib_user_verbs.h                  |   19 +-
 include/uapi/rdma/mlx4-abi.h                       |   52 +-
 include/uapi/rdma/mlx5-abi.h                       |   23 +
 include/uapi/rdma/qedr-abi.h                       |    3 +
 include/uapi/rdma/rdma_netlink.h                   |   84 +-
 include/uapi/rdma/rdma_user_ioctl.h                |   33 +
 include/uapi/rdma/vmw_pvrdma-abi.h                 |    6 +-
 282 files changed, 15100 insertions(+), 5331 deletions(-)
 create mode 100644 Documentation/infiniband/tag_matching.txt
 create mode 100644 block/blk-mq-rdma.c
 create mode 100644 drivers/infiniband/core/nldev.c
 create mode 100644 drivers/infiniband/core/uverbs_ioctl.c
 create mode 100644 drivers/infiniband/core/uverbs_ioctl_merge.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/hw_counters.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/hw_counters.h
 create mode 100644 drivers/infiniband/hw/hfi1/exp_rcv.c
 create mode 100644 drivers/infiniband/hw/hfi1/exp_rcv.h
 create mode 100644 drivers/infiniband/hw/hfi1/trace_mmu.h
 create mode 100644 drivers/infiniband/hw/mlx5/cong.c
 create mode 100644 include/linux/blk-mq-rdma.h
 create mode 100644 include/rdma/uverbs_ioctl.h
 create mode 100644 include/uapi/rdma/ib_user_ioctl_verbs.h

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-08-24 21:21 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-08-24 21:21 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Well, I thought we were going to be done for this -rc cycle.  I should
have known better than to say so though.

We have 4 additional items that trickled in.

One was a simple mistake on my part.  I took a patch into my for-next
thinking that the issue was less severe than it was.  I was then
notified that it needed to be in my -rc area instead.  So, since I had
already pushed my for-next to k.o and there wasn't going to be a
rebase, I cherry-picked it to my rc area.  I kept the cherry-pick tag,
I don't know if that's how you prefer this be done.  In any case, when
I send you my pull request for the merge window, this one patch will
end up falling out.

The other three were just found late in testing.

Here's the boiler plate:

The following changes since commit
870201f95fcbd19538aef630393fe9d583eff82e:

  IB/uverbs: Fix NULL pointer dereference during device removal (2017-
08-16 12:53:15 -0400)

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
ec2558796d25e6024071b6bcb8e11392538d57bf:

  IB/mlx5: Always return success for RoCE modify port (2017-08-24
15:33:33 -0400)

----------------------------------------------------------------
Fifth set of -rc fixes for 4.13 cycle

- One core fix accidentally applied first to for-next and then cherry
  picked back because it needed to be in the -rc cycles instead
- Another core fix
- Two mlx5 fixes

----------------------------------------------------------------
Bharat Potnuri (1):
      RDMA/uverbs: Initialize cq_context appropriately

Majd Dibbiny (2):
      IB/mlx5: Fix Raw Packet QP event handler assignment
      IB/mlx5: Always return success for RoCE modify port

Noa Osherovich (1):
      IB/core: Avoid accessing non-allocated memory when inferring port
type

 drivers/infiniband/core/uverbs_cmd.c | 13 ++++++++-----
 drivers/infiniband/core/verbs.c      |  7 ++++++-
 drivers/infiniband/hw/mlx5/main.c    |  6 ++++++
 drivers/infiniband/hw/mlx5/qp.c      |  1 +
 include/rdma/ib_verbs.h              |  1 +
 5 files changed, 22 insertions(+), 6 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-08-18 18:21 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-08-18 18:21 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

This is all of the -rc fixes that we know of.  I suspect this will be
the last rc pull request, but you never know, I could be wrong.

Nothing major here.  There are the i40iw patches I mentioned in my last
pull request minus one that I pulled out because it wasn't a fix and
not appropriate for the rc cycle.  Then a few other items trickled in
and were added to the pull request.  It's fairly small aside from those
5 i40iw patches.  Here's the boilerplate:
The following changes since commit
48107c4e596c8523d46c7b04f92cf29e7569a01e:

  Merge tag 'rdma-rc-2017-07-26' of
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma into
leon-ipoib (2017-08-07 13:30:40 -0400)

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
870201f95fcbd19538aef630393fe9d583eff82e:

  IB/uverbs: Fix NULL pointer dereference during device removal (2017-
08-16 12:53:15 -0400)

----------------------------------------------------------------
Fourth set of -rc fixes for 4.13 cycle

- Set of 5 i40iw fixes (the first of these is rather large by line
  count consideration, but I decided to send it because if fixes a
  legitimate issue and the line count is because it does so by creating
  a new function and using it where needed instead of just patching up
a
  few lines...a smaller fix could probably be done, but the larger fix
  is the better code solution)
- One vmw_pvrdma fix
- One hns_roce fix (this silences a checker warning, but can't actually
  happen, I expect a patch to remove this from all drivers that share
  this same check in for-next)
- One iw_cxgb4 fix
- Two IB core fixes

----------------------------------------------------------------
Bryan Tan (1):
      RDMA/vmw_pvrdma: Report CQ missed events

Chien Tin Tung (1):
      i40iw: Fix parsing of query/commit FPM buffers

Christopher N Bednarz (2):
      i40iw: Use correct alignment for CQ0 memory
      i40iw: Fix potential fcn_id_array out of bounds

Colin Ian King (1):
      IB/hns: fix memory leak on ah on error return path

Maor Gottlieb (1):
      IB/uverbs: Fix NULL pointer dereference during device removal

Mustafa Ismail (2):
      i40iw: Correct variable names
      i40iw: Fix typecast of tcp_seq_num

Shiraz Saleem (1):
      IB/core: Protect sysfs entry on ib_unregister_device

Steve Wise (1):
      iw_cxgb4: fix misuse of integer variable

 drivers/infiniband/core/device.c             |   5 +-
 drivers/infiniband/core/uverbs_main.c        |   2 +-
 drivers/infiniband/hw/cxgb4/mem.c            |   2 +-
 drivers/infiniband/hw/hns/hns_roce_ah.c      |   4 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c     | 123 ++++++++++++++++++-
--------
 drivers/infiniband/hw/i40iw/i40iw_d.h        |   4 +-
 drivers/infiniband/hw/i40iw/i40iw_puda.c     |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_status.h   |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c       |   8 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c |  17 +++-
 10 files changed, 114 insertions(+), 55 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-08-08 17:27 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-08-08 17:27 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

We had a small set of misc. fixes trickle in, and then we had a larger
set of IPoIB specific fixes that, I believe, were due to an audit come
through.  All totalled, it's not really a large pull request, just the
fixes we have so far.  However, there is an i40iw pull request in the
offing, but it isn't ready yet.  That's another 6 patches when it has
passed muster.

Here's the boilerplate:

The following changes since commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62:

  RDMA/core: Initialize port_num in qp_attr (2017-07-20 11:24:13 -0400)

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 48107c4e596c8523d46c7b04f92cf29e7569a01e:

  Merge tag 'rdma-rc-2017-07-26' of git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma into leon-ipoib (2017-08-07 13:30:40 -0400)

----------------------------------------------------------------
Third set of -rc fixes for 4.13 cycle

- small set of miscellanous fixes
- a reasonably sizable set of IPoIB fixes that deal with multiple long
  standing issues

----------------------------------------------------------------
Alex Vesker (2):
      IB/ipoib: Prevent setting negative values to max_nonsrq_conn_qp
      IB/ipoib: Add multicast packets statistics

Dan Carpenter (1):
      IB/hns: checking for IS_ERR() instead of NULL

Doug Ledford (1):
      Merge tag 'rdma-rc-2017-07-26' of git://git.kernel.org/.../leon/linux-rdma into leon-ipoib

Erez Shitrit (3):
      IB/ipoib: Use cancel_delayed_work_sync when needed
      IB/ipoib: Make sure no in-flight joins while leaving that mcast
      IB/ipoib: Notify on modify QP failure only when relevant

Feras Daoud (3):
      IB/ipoib: Fix race between light events and interface restart
      IB/ipoib: Set IPOIB_NEIGH_TBL_FLUSH after flushed completion initialization
      IB/ipoib: Add get statistics support to SRIOV VF

Leon Romanovsky (5):
      IB/ipoib: Clean error paths in add port
      IB/ipoib: Remove double pointer assigning
      Revert "IB/core: Allow QP state transition from reset to error"
      RDMA/uverbs: Prevent leak of reserved field
      RDMA/mlx5: Fix existence check for extended address vector

Parav Pandit (1):
      IB/core: Fix race condition in resolving IP to MAC

Yishai Hadas (1):
      IB/uverbs: Fix device cleanup

 drivers/infiniband/core/addr.c                 | 62 ++++++++++++++++++++------
 drivers/infiniband/core/uverbs_cmd.c           |  2 +-
 drivers/infiniband/core/uverbs_main.c          |  3 +-
 drivers/infiniband/core/verbs.c                |  1 -
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c     |  2 +-
 drivers/infiniband/hw/mlx5/odp.c               |  2 +-
 drivers/infiniband/ulp/ipoib/ipoib.h           |  1 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c        |  1 -
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c   |  3 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c        | 25 ++++++++++-
 drivers/infiniband/ulp/ipoib/ipoib_main.c      | 19 +++++---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 33 +++++---------
 include/linux/mlx5/qp.h                        |  1 -
 13 files changed, 102 insertions(+), 53 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <1500486883.23761.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  2017-07-19 20:40                       ` Bart Van Assche
@ 2017-07-21 22:27                       ` Robert LeBlanc
  1 sibling, 0 replies; 186+ messages in thread
From: Robert LeBlanc @ 2017-07-21 22:27 UTC (permalink / raw)
  To: Doug Ledford, Bart Van Assche; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Wed, Jul 19, 2017 at 11:54 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2017-07-18 at 21:42 -0600, Robert LeBlanc wrote:
>> On Tue, Jul 18, 2017 at 1:26 PM, Linus Torvalds
>> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>> > On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
>> > > wrote:
>> > >
>> > >
>> I'm trying to understand why merges are being done instead of
>> rebases.
>> Since we don't want to include other people's work, it seems that it
>> is cleaner to do a rebase. This is more for my education with using
>> Git with such a large project rather than me suggesting something
>> useful. (I dropped Linus from this part of the thread so as not to
>> bother him with an off-topic conversation).
>
> Rebases change the history of a patch.  If I commit a patch on July
> 7th, and then rebase on July 20th, the patch gets rewritten with the
> new date.  In addition, they get new commit hashes.  So if someone
> pulls my tree on the 9th, sees the commit hash for their patch, and
> then references it in an email or a bug report, then I rebase on the
> 20th, the old commit hash is gone and will be replaced with a new one.
> Finally, if someone pulls my tree on the 8th, and then again on the
> 22nd, and they don't know I've rebased it, the pull will attempt to put
> all of the new hashes on top of the old hashes for the same commits.
> It creates a ton of merge work that is error prone.  Sometimes chunks
> get added twice, stuff like that.
>
> There are a few things you can do to get around this, and I sometimes
> use those tricks.  I've declared on-list that my github repo is subject
> to being rebased at any time, so people know this.  I also have my
> github repo as the source for my 0day testing.  So, I can push to
> github, wait for 0day test results, and if there was a problem, I can
> fix it using a rebase of whatever patch was broken, repush to github,
> and repeat until 0day testing passes, and only then do I push to my
> kernel.org repo, which is taken to be involate and rebases are
> forbidden.  But even there, if I *really* have to, I can rebase by
> deleting the branch I originally created and creating a new branch with
> the rebase on it under a different name.  That prevents someone from
> accidentally pulling the rebase on top of a previous pull.  But I
> *really* try to avoid that.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>

Thank you Doug and Bart for taking the time to explain this to me.
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1500639364.23761.22.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-21 12:25   ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-07-21 12:25 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Fri, 2017-07-21 at 08:16 -0400, Doug Ledford wrote:
> Hi Linus,
> 
> As per my previous pull request, there were two drivers that each had
> a
> rather large number of legitimate fixes still to be sent.  As it
> turned
> out, I also missed a reasonably large set of fixes from one person
> across the stack that are all important fixes.  All in all, the
> bnxt_re, i40iw, and Dan Carpenter are 3/4 to 2/3rds of this pull
> request.  There were some other random fixes that I didn't send in
> the
> last pull request that I added to this one.  This catches the rdma
> stack up to the fixes from up to about the beginning of this
> week.  Any
> more fixes I'll wait and batch up later in the -rc cycle.  This will
> give us a good base to start with for basing a for-next branch on
> -rc2.
>  Thanks.

I didn't specifically mention it, because it goes without saying, but
this has passed 0day.  I don't send you anything that hasn't
specifically passed 0day unless 0day has failed to run the tests and
sent me an email saying I won't get any more emails.  This has not, as
you probably imagine, been through linux-next.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-07-21 12:16 Doug Ledford
       [not found] ` <1500639364.23761.22.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-21 12:16 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

As per my previous pull request, there were two drivers that each had a
rather large number of legitimate fixes still to be sent.  As it turned
out, I also missed a reasonably large set of fixes from one person
across the stack that are all important fixes.  All in all, the
bnxt_re, i40iw, and Dan Carpenter are 3/4 to 2/3rds of this pull
request.  There were some other random fixes that I didn't send in the
last pull request that I added to this one.  This catches the rdma
stack up to the fixes from up to about the beginning of this week.  Any
more fixes I'll wait and batch up later in the -rc cycle.  This will
give us a good base to start with for basing a for-next branch on -rc2.
 Thanks.

Here's the boilerplate:

The following changes since commit
ebc9ca43e1d52a85c72fc2d343f353386ed6c188:

  IB/core: Allow QP state transition from reset to error (2017-07-17
21:21:30 -0400)

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
a62ab66b13a0f9bcb17b7b761f6670941ed5cd62:

  RDMA/core: Initialize port_num in qp_attr (2017-07-20 11:24:13 -0400)

----------------------------------------------------------------
Second set of -rc fixes for 4.13 cycle

- i40iw fixes
- bnxt_re fixes
- Dan Carpenter bugfixes across stack
- 10 more random fixes, no more than 2 from any 1 person

----------------------------------------------------------------
Amrani, Ram (1):
      RDMA/qedr: Prevent memory overrun in verbs' user responses

Dan Carpenter (8):
      RDMA/bnxt_re: checking for NULL instead of IS_ERR()
      IB/IPoIB: Fix error code in ipoib_add_port()
      IB/i40iw: Fix error code in i40iw_create_cq()
      cxgb4: Fix error codes in c4iw_create_cq()
      IB/cxgb3: Fix error codes in iwch_alloc_mr()
      RDMA/ocrdma: Fix an error code in ocrdma_alloc_pd()
      RDMA/ocrdma: Fix error codes in ocrdma_create_srq()
      IB/mlx5: Fix a warning message

Devesh Sharma (3):
      RDMA/bnxt_re: Free doorbell page index (DPI) during dealloc
ucontext
      RDMA/bnxt_re: Enable atomics only if host bios supports
      RDMA/bnxt_re: Fix return value of poll routine

Eddie Wai (1):
      RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and
destination QP

Ganesh Goudar (1):
      iw_cxgb4: don't use WR keys/addrs for 0 byte reads

Henry Orosco (2):
      i40iw: Add missing memory barrier
      i40iw: Update list correctly

Håkon Bugge (1):
      IB/mlx4: Fix CM REQ retries in paravirt mode

Ismail, Mustafa (2):
      RDMA/uverbs: Fix the check for port number
      RDMA/core: Initialize port_num in qp_attr

Kaike Wan (1):
      IB/rdmavt: Setting of QP timeout can overflow jiffies computation

Kalderon, Michal (1):
      IB/cma: Fix reference count leak when no ipv4 addresses are set

Matan Barak (1):
      IB/core: Fix sparse warnings

Mustafa Ismail (2):
      i40iw: Fix order of cleanup in close
      i40iw: Do not poll CCQ after it is destroyed

Sagi Grimberg (1):
      RDMA/iser: don't send an rkey if all data is written as
immadiate-data

Selvin Xavier (4):
      RDMA/bnxt_re: Do not free the ctx_tbl entry if delete GID fails
      RDMA/bnxt_re: Report supported value to IB stack in query_device
      RDMA/bnxt_re: Report MISSED_EVENTS in req_notify_cq
      RDMA/bnxt_re: Fix the value reported for local ack delay

Shiraz Saleem (4):
      i40iw: Utilize iwdev->reset during PCI function reset
      i40iw: Release cm_id ref on PCI function reset
      i40iw: Free QP resources on CQP destroy QP failure
      i40iw: Avoid memory leak of CQP request objects

Somnath Kotur (2):
      RDMA/bnxt_re: Fix WQE Size posted to HW to prevent it from
throwing error
      RDMA/bnxt_re: Specify RDMA component when allocating stats
context

Tatyana Nikolova (1):
      i40iw: Free QP PBLEs when the QP is destroyed

Vijay Immanuel (1):
      rxe: fix broken receive queue draining

 drivers/infiniband/core/cma.c                |   2 +
 drivers/infiniband/core/uverbs_cmd.c         |  13 +--
 drivers/infiniband/hw/bnxt_re/bnxt_re.h      |   9 ++
 drivers/infiniband/hw/bnxt_re/ib_verbs.c     | 119 ++++++++++++++++---
--------
 drivers/infiniband/hw/bnxt_re/ib_verbs.h     |   3 +-
 drivers/infiniband/hw/bnxt_re/main.c         |   1 +
 drivers/infiniband/hw/bnxt_re/qplib_fp.c     |  29 +++++++
 drivers/infiniband/hw/bnxt_re/qplib_fp.h     |   1 +
 drivers/infiniband/hw/bnxt_re/qplib_sp.c     |  16 ++++
 drivers/infiniband/hw/bnxt_re/qplib_sp.h     |   3 +
 drivers/infiniband/hw/cxgb3/iwch_provider.c  |   9 +-
 drivers/infiniband/hw/cxgb4/cq.c             |   1 +
 drivers/infiniband/hw/cxgb4/qp.c             |   2 +-
 drivers/infiniband/hw/i40iw/i40iw.h          |   1 +
 drivers/infiniband/hw/i40iw/i40iw_cm.c       |   5 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c     |   2 +
 drivers/infiniband/hw/i40iw/i40iw_main.c     |  60 +++++++-------
 drivers/infiniband/hw/i40iw/i40iw_puda.c     |   5 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c    |  60 +++++++++++++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c    |  19 +++--
 drivers/infiniband/hw/i40iw/i40iw_verbs.h    |   2 +-
 drivers/infiniband/hw/mlx4/cm.c              |   4 +
 drivers/infiniband/hw/mlx5/mr.c              |   2 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c  |   4 +-
 drivers/infiniband/hw/qedr/verbs.c           |  16 +++-
 drivers/infiniband/sw/rdmavt/qp.c            |   4 +-
 drivers/infiniband/sw/rxe/rxe_resp.c         |   3 +
 drivers/infiniband/sw/rxe/rxe_verbs.c        |   3 +
 drivers/infiniband/ulp/ipoib/ipoib_main.c    |   1 +
 drivers/infiniband/ulp/iser/iser_initiator.c |   6 +-
 include/rdma/ib_addr.h                       |   6 +-
 include/rdma/rdmavt_qp.h                     |  14 ++++
 32 files changed, 306 insertions(+), 119 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                             ` <6b6d3dba-8eac-ef75-ef23-6e4e469670b6-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-19 22:56                               ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-07-19 22:56 UTC (permalink / raw)
  To: Bart Van Assche, robert-4JaGZRWAfWbajFs6igw21g,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1.1: Type: text/plain, Size: 679 bytes --]

On 7/19/2017 6:05 PM, Doug Ledford wrote:
> On 7/19/2017 4:40 PM, Bart Van Assche wrote:
>> On Wed, 2017-07-19 at 13:54 -0400, Doug Ledford wrote:
>>   that this branch is included in Steven Rostedt's linux-next tree and that

Credit where credit is due BTW, the linux-next tree is handled by
Stephen Rothwell.  Steven Rostedt is another kernel engineer of his own
separate acclaim, being maintainer of the ftrace subsystem and listed
reviewer for multiple other items (SRCU, RCU, etc.).

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                         ` <1500496830.2494.5.camel-Sjgp3cTcYWE@public.gmane.org>
@ 2017-07-19 22:05                           ` Doug Ledford
       [not found]                             ` <6b6d3dba-8eac-ef75-ef23-6e4e469670b6-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-19 22:05 UTC (permalink / raw)
  To: Bart Van Assche, robert-4JaGZRWAfWbajFs6igw21g,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1.1: Type: text/plain, Size: 6061 bytes --]

On 7/19/2017 4:40 PM, Bart Van Assche wrote:
> On Wed, 2017-07-19 at 13:54 -0400, Doug Ledford wrote:
>> On Tue, 2017-07-18 at 21:42 -0600, Robert LeBlanc wrote:
>>> On Tue, Jul 18, 2017 at 1:26 PM, Linus Torvalds
>>> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>>> On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
>>>>> wrote:
>>>>>
>>>>>
>>>
>>> I'm trying to understand why merges are being done instead of
>>> rebases.
>>> Since we don't want to include other people's work, it seems that it
>>> is cleaner to do a rebase. This is more for my education with using
>>> Git with such a large project rather than me suggesting something
>>> useful. (I dropped Linus from this part of the thread so as not to
>>> bother him with an off-topic conversation).
>>
>> Rebases change the history of a patch.  If I commit a patch on July
>> 7th, and then rebase on July 20th, the patch gets rewritten with the
>> new date.  In addition, they get new commit hashes.  So if someone
>> pulls my tree on the 9th, sees the commit hash for their patch, and
>> then references it in an email or a bug report, then I rebase on the
>> 20th, the old commit hash is gone and will be replaced with a new one. 
>> Finally, if someone pulls my tree on the 8th, and then again on the
>> 22nd, and they don't know I've rebased it, the pull will attempt to put
>> all of the new hashes on top of the old hashes for the same commits. 
>> It creates a ton of merge work that is error prone.  Sometimes chunks
>> get added twice, stuff like that.
>>
>> There are a few things you can do to get around this, and I sometimes
>> use those tricks.  I've declared on-list that my github repo is subject
>> to being rebased at any time, so people know this.  I also have my
>> github repo as the source for my 0day testing.  So, I can push to
>> github, wait for 0day test results, and if there was a problem, I can
>> fix it using a rebase of whatever patch was broken, repush to github,
>> and repeat until 0day testing passes, and only then do I push to my
>> kernel.org repo, which is taken to be involate and rebases are
>> forbidden.  But even there, if I *really* have to, I can rebase by
>> deleting the branch I originally created and creating a new branch with
>> the rebase on it under a different name.  That prevents someone from
>> accidentally pulling the rebase on top of a previous pull.  But I
>> *really* try to avoid that.
> 
> Hello Doug,
> 
> Rebases do not only change the commit ID of a patch but can also change the
> patch itself. If e.g. a patch (a) that was posted on the linux-rdma mailing
> list contains two changes and a patch (b) contains only one of two changes,
> if the rdma tree gets rebased on top of a tree that has patch (b) then the
> rebase will modify patch (a) such that only the changes that were not in
> patch (b) remain. git will neither complain about this nor report it.

This is no different than if you run git am on patch (b) and then patch
(a) on the same branch, except the change will be lost in the "conflicts
existed when applying the patch, please apply and resolve then commit
the result".  In this case patch (a) will loose the exact same data that
git dropped out during a rebase.

> Since
> a rebase can modify a patch it also invalidates any testing and reviews for
> that patch.

The same can be said of the situation I listed above.  It's up to my
discretion to determine if the change is significant enough to warrant
going back and getting new reviews.  If the issue is that there was a
typo in a patch that caused a build error, I'm not going to invalidate
reviews for that.

> This why Linus hates rebases and why nowadays Linus refuses to
> accept any pull requests of trees that have been rebased. I hope I
> misunderstood you but if you are routinely rebasing branches with patches
> that come from the linux-rdma mailing list please stop doing this.

Routinely?  No.  What I really use it for is when I'm taking a stack of
patches into either their own branch or directly onto my branch, if I
run into problems in the build test phase, then I'll rebase to fix the
build issues.  But that's limited to the stack I just took, so it all
happens as part of the "review, integrate, build, test" cycle for that
day's work.  By the time I leave for the day and push it to k.o (or at
worst come in the next morning and check 0day status and then either
fixup or push to k.o), it won't be rebased any more.  And if I split my
day's work up into different stacks, then once one stack is pushed to
k.o, that stack won't be rebased even if later stacks that same day need
rebasing to build/work properly.

> A model that some other kernel maintainers (e.g. Jens Axboe) follow is as
> follows:
> * Maintain one branch per pull request that will be sent to Linus, e.g.
>   for-4.13/block. Never rebase this branch, never rewrite its history and
>   only merge Linus' branch into this branch if absolutely necessary.
> * Every time a patch has to be applied, use "git am" to apply it to the
>   appropriate branch. Complain on the mailing list if "git am" complains.
>   Add the maintainer Signed-off-by and edit the patch if this is considered
>   necessary.
> * Maintain a for-next branch that is the result of merging all branches that
>   will be sent to Linus. Resolve any merge conflicts if necessary. Ensure
>   that this branch is included in Steven Rostedt's linux-next tree and that
>   it gets tested by the zero-day testing infrastructure.

This is fairly similar to what I do.  I really only use rebases as part
of my internal fixups for build issues in a given day's/stack's
integration, which, BTW, is in line with what Linus says in the email
you linked to.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <1500486883.23761.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-19 20:40                       ` Bart Van Assche
       [not found]                         ` <1500496830.2494.5.camel-Sjgp3cTcYWE@public.gmane.org>
  2017-07-21 22:27                       ` Robert LeBlanc
  1 sibling, 1 reply; 186+ messages in thread
From: Bart Van Assche @ 2017-07-19 20:40 UTC (permalink / raw)
  To: robert-4JaGZRWAfWbajFs6igw21g, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	dledford-H+wXaHxf7aLQT0dZR+AlfA

On Wed, 2017-07-19 at 13:54 -0400, Doug Ledford wrote:
> On Tue, 2017-07-18 at 21:42 -0600, Robert LeBlanc wrote:
> > On Tue, Jul 18, 2017 at 1:26 PM, Linus Torvalds
> > <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > > On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> > > > wrote:
> > > > 
> > > > 
> > 
> > I'm trying to understand why merges are being done instead of
> > rebases.
> > Since we don't want to include other people's work, it seems that it
> > is cleaner to do a rebase. This is more for my education with using
> > Git with such a large project rather than me suggesting something
> > useful. (I dropped Linus from this part of the thread so as not to
> > bother him with an off-topic conversation).
> 
> Rebases change the history of a patch.  If I commit a patch on July
> 7th, and then rebase on July 20th, the patch gets rewritten with the
> new date.  In addition, they get new commit hashes.  So if someone
> pulls my tree on the 9th, sees the commit hash for their patch, and
> then references it in an email or a bug report, then I rebase on the
> 20th, the old commit hash is gone and will be replaced with a new one. 
> Finally, if someone pulls my tree on the 8th, and then again on the
> 22nd, and they don't know I've rebased it, the pull will attempt to put
> all of the new hashes on top of the old hashes for the same commits. 
> It creates a ton of merge work that is error prone.  Sometimes chunks
> get added twice, stuff like that.
> 
> There are a few things you can do to get around this, and I sometimes
> use those tricks.  I've declared on-list that my github repo is subject
> to being rebased at any time, so people know this.  I also have my
> github repo as the source for my 0day testing.  So, I can push to
> github, wait for 0day test results, and if there was a problem, I can
> fix it using a rebase of whatever patch was broken, repush to github,
> and repeat until 0day testing passes, and only then do I push to my
> kernel.org repo, which is taken to be involate and rebases are
> forbidden.  But even there, if I *really* have to, I can rebase by
> deleting the branch I originally created and creating a new branch with
> the rebase on it under a different name.  That prevents someone from
> accidentally pulling the rebase on top of a previous pull.  But I
> *really* try to avoid that.

Hello Doug,

Rebases do not only change the commit ID of a patch but can also change the
patch itself. If e.g. a patch (a) that was posted on the linux-rdma mailing
list contains two changes and a patch (b) contains only one of two changes,
if the rdma tree gets rebased on top of a tree that has patch (b) then the
rebase will modify patch (a) such that only the changes that were not in
patch (b) remain. git will neither complain about this nor report it. Since
a rebase can modify a patch it also invalidates any testing and reviews for
that patch. This why Linus hates rebases and why nowadays Linus refuses to
accept any pull requests of trees that have been rebased. I hope I
misunderstood you but if you are routinely rebasing branches with patches
that come from the linux-rdma mailing list please stop doing this.

A model that some other kernel maintainers (e.g. Jens Axboe) follow is as
follows:
* Maintain one branch per pull request that will be sent to Linus, e.g.
  for-4.13/block. Never rebase this branch, never rewrite its history and
  only merge Linus' branch into this branch if absolutely necessary.
* Every time a patch has to be applied, use "git am" to apply it to the
  appropriate branch. Complain on the mailing list if "git am" complains.
  Add the maintainer Signed-off-by and edit the patch if this is considered
  necessary.
* Maintain a for-next branch that is the result of merging all branches that
  will be sent to Linus. Resolve any merge conflicts if necessary. Ensure
  that this branch is included in Steven Rostedt's linux-next tree and that
  it gets tested by the zero-day testing infrastructure.

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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <CAANLjFr9DxfoR_H5rp1ag_fC5AqxDJ5ZEj52wF-W2eGjof6iqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2017-07-19 17:52                   ` Bart Van Assche
@ 2017-07-19 17:54                   ` Doug Ledford
       [not found]                     ` <1500486883.23761.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  1 sibling, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-19 17:54 UTC (permalink / raw)
  To: Robert LeBlanc, linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Tue, 2017-07-18 at 21:42 -0600, Robert LeBlanc wrote:
> On Tue, Jul 18, 2017 at 1:26 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> > > wrote:
> > > 
> > > 
> I'm trying to understand why merges are being done instead of
> rebases.
> Since we don't want to include other people's work, it seems that it
> is cleaner to do a rebase. This is more for my education with using
> Git with such a large project rather than me suggesting something
> useful. (I dropped Linus from this part of the thread so as not to
> bother him with an off-topic conversation).

Rebases change the history of a patch.  If I commit a patch on July
7th, and then rebase on July 20th, the patch gets rewritten with the
new date.  In addition, they get new commit hashes.  So if someone
pulls my tree on the 9th, sees the commit hash for their patch, and
then references it in an email or a bug report, then I rebase on the
20th, the old commit hash is gone and will be replaced with a new one. 
Finally, if someone pulls my tree on the 8th, and then again on the
22nd, and they don't know I've rebased it, the pull will attempt to put
all of the new hashes on top of the old hashes for the same commits. 
It creates a ton of merge work that is error prone.  Sometimes chunks
get added twice, stuff like that.

There are a few things you can do to get around this, and I sometimes
use those tricks.  I've declared on-list that my github repo is subject
to being rebased at any time, so people know this.  I also have my
github repo as the source for my 0day testing.  So, I can push to
github, wait for 0day test results, and if there was a problem, I can
fix it using a rebase of whatever patch was broken, repush to github,
and repeat until 0day testing passes, and only then do I push to my
kernel.org repo, which is taken to be involate and rebases are
forbidden.  But even there, if I *really* have to, I can rebase by
deleting the branch I originally created and creating a new branch with
the rebase on it under a different name.  That prevents someone from
accidentally pulling the rebase on top of a previous pull.  But I
*really* try to avoid that.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <CAANLjFr9DxfoR_H5rp1ag_fC5AqxDJ5ZEj52wF-W2eGjof6iqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-07-19 17:52                   ` Bart Van Assche
  2017-07-19 17:54                   ` Doug Ledford
  1 sibling, 0 replies; 186+ messages in thread
From: Bart Van Assche @ 2017-07-19 17:52 UTC (permalink / raw)
  To: robert-4JaGZRWAfWbajFs6igw21g, linux-rdma-u79uwXL29TY76Z2rM5mHXA
  Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA

On Tue, 2017-07-18 at 21:42 -0600, Robert LeBlanc wrote:
> I'm trying to understand why merges are being done instead of rebases.

Hello Robert,

Linus has explained several times that it is completely unacceptable to
rebase patches from someone else. See e.g.
http://yarchive.net/comp/linux/git_rebase.html.

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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFxYrrWO0NFJLzMiSQxPKMcoLUD=xA0e-g01riFfX5-Vug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2017-07-19  3:42               ` Robert LeBlanc
@ 2017-07-19 17:46               ` Doug Ledford
  1 sibling, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-07-19 17:46 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Tue, 2017-07-18 at 12:26 -0700, Linus Torvalds wrote:
> On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > Fair enough.  My branch still had two unpulled commits and was
> > based on
> > v4.12-rc3.  But, you had already taken the SELinux/RDMA patches
> > through
> > the SELinux tree during this merge window, and two of the
> > fix  patches
> > in my pull request would have produced conflicts for you if I
> > didn't
> > merge up to a common ancestor that had the SELinux/RDMA patches
> > prior
> > to applying those patches to my tree (these two in particular):
> 
> Please don't worry about conflicts, unless they are something really
> really fundamentally hard to merge. And even then, for rdma, I
> probably want to see them, just to see what the hell went wrong *this
> time*.

There wasn't anything wrong.  Not every conflict is a failure of
development hygiene as you call it below.  It's just that the SELinux
patches touched a lot of entry points...*not* conflicting with them
would have been more of a magic trick.

> > > And if the only reason for that merge is "sync with upstream",
> > > then
> > > no, that is not a sufficient reason. It has to have an actual
> > > real
> > > reason, and it needs to be stated.
> > 
> > Does this apply to the for-next area as well?
> 
> Largely, yes. Because the further away "for-next" gets from what you
> then eventually send me, if your for-next branch has odd useless
> merges, then either what you send me will have them too, or what you
> send me will be something entirely different and rebased.

I asked this question because I was going to try doing one continuous
branch for ongoing future development.  In that case, at an absolute
minimum, one merge is required to get from one development window to
the next.  However, in addition to that one merge, I would argue that
one of these two things should also be done:

1) I *should* merge the prior release's for-rc area into my for-next
branch on an as-needed basis.  This is so that we are developing and
testing against a complete RDMA subsystem, not the RDMA subsystem as it
was at -rc1 or -rc2 when we branched with all its bugs still intact.

or, optionally

2) I could merge the prior release's rc tags.  It serves the same
purpose (getting any -rc fixes I've sent you into the development
branch), but also serves the purpose of getting other subsystem's fixes
in as well so we won't be fighting against other bugs in our
development and testing (this aspect is highly relevant with the net
subsystem because of how tightly tied our subsystems are).

So, anyway, I still either have to branch off a new branch when I open
my for-next area at each cycle, or I have to merge up to a current
kernel.  I'll stick with creating a new branch as it keeps the merge
count down by one.  I also still see value in option #2 above, even if
you don't.  I'll avoid it, but I do so noting my dissenting opinion.

> Finally, the merges have a fundamental problem that is from past
> problems with rdma - in particular the history of mixing stuff up and
> having teams within one single company not even being able to talk or
> synchronize with each other.

Yes, some bad submissions happened in the past.  There were two
egregiously bad examples.  Remember, though, that one of the things you
yelled at me for during that time was for being unaware of the issues. 
You made it clear that my job is to stay on top of these things and
make sure that they aren't happening again.  I can't do that if I'm not
pulling things together myself and making sure it's all good in the
end.

> If you need merges for conflict resolution, it indicates to me that
> rdma *still* has that issue where people fight over the direction and
> the drivers between different teams.

Conflicts happen, and they don't always indicate the issues that
happened in the past.  In fact, *most* of the time, they don't indicate
anything along those lines.  They're more an indicator of ongoing
development across the subsystem.  Major features, like SELinux support
and namespace support, and even less invasive series that went through
other trees like the RDMA cgroup support, are highly likely to conflict
with your average typical development or bug fixes.

> So while merges in general are something that should be avoided, when
> it comes to rdma in _particular_ I don't like seeing them, because I
> get the feeling that they are papering over the nasty development
> problems you guys have had, and are done as a way to handle the
> conflicts that were due to bad hygiene.

Aka, we're still on probation.  I'll merge things up on a test branch
and then throw it away.  If I don't do the merge ups and check things,
I'm not staying on top of the stack and doing my job.  But if I submit
the final product to you, then I'm preventing you from doing it
yourself.

> So the *one* kind of merge that is good is the "development of this
> topic branch is finished and done, let's merge it up". But that is
> never about time, that's about "I'm done with this series, it's good
> to go into my main branch". That's a "forward merge", where you
> really
> merge the new and finished development tree into the base.

It's only a forward merge if my "main branch" is ahead of, or at the
same base as, the development branch.  That hasn't been the case in the
last few cycles when I was merging a shared common Mellanox base that
was also in Dave's tree.  I've quit doing that effective now, so it
won't be an issue, but, when I was doing it, I did what you call a
back-merge because it cleaned up the subsequent merge from Dave and
made understanding what my tree contained possible.  Without it, it was
a nightmare concoction off in la la land.

> The back-merges, when you merge some unrelated development, is
> generally a bad sign. It inevitably happens for various reasons, but
> it should be seen as the exception, not the rule, and it should
> *always* have an explanation.

As I said above, pulling from Dave made it not so much an exception,
but a necessary pre-step to clean up the merge I got from him. 
Otherwise, it was impossible to sort out what was his, what was yours,
or where my tree now stood.

And in this particular case, remember that this was originally a branch
intended for 4.13-rc cycles, so it was based on 4.13-rc2 or rc3.  I
would argue that sending patches that are against 4.13-rc2 into a 4.14-
rc1 kernel, *as a maintainer*, is leaving too much to chance.  An
entire kernel of changes between your base and what you are submitting
too?  That seems irresponsible on my end.  That's the reason I didn't
document the back-merge on this pull request.  It seemed (and to be
honest, in spite of your comments, *still* seems) like the sane thing
to do prior to submitting a pull request into 4.14-rc1.  If I'm doing
*my* job, I should *know* how this code is going to interact with the
kernel I'm submitting it to.  Clearly, you would prefer I had done a
throw away branch instead of polluting my actual pull branch, but I
don't believe for a second that I should have left things to chance and
not verified how this code would interact with that kernel release
worth of changes.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFxYrrWO0NFJLzMiSQxPKMcoLUD=xA0e-g01riFfX5-Vug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-07-19  3:42               ` Robert LeBlanc
       [not found]                 ` <CAANLjFr9DxfoR_H5rp1ag_fC5AqxDJ5ZEj52wF-W2eGjof6iqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2017-07-19 17:46               ` Doug Ledford
  1 sibling, 1 reply; 186+ messages in thread
From: Robert LeBlanc @ 2017-07-19  3:42 UTC (permalink / raw)
  To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: Doug Ledford

On Tue, Jul 18, 2017 at 1:26 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Fair enough.  My branch still had two unpulled commits and was based on
>> v4.12-rc3.  But, you had already taken the SELinux/RDMA patches through
>> the SELinux tree during this merge window, and two of the fix  patches
>> in my pull request would have produced conflicts for you if I didn't
>> merge up to a common ancestor that had the SELinux/RDMA patches prior
>> to applying those patches to my tree (these two in particular):
>
> Please don't worry about conflicts, unless they are something really
> really fundamentally hard to merge. And even then, for rdma, I
> probably want to see them, just to see what the hell went wrong *this
> time*.
>
>>> And if the only reason for that merge is "sync with upstream", then
>>> no, that is not a sufficient reason. It has to have an actual real
>>> reason, and it needs to be stated.
>>
>> Does this apply to the for-next area as well?
>
> Largely, yes. Because the further away "for-next" gets from what you
> then eventually send me, if your for-next branch has odd useless
> merges, then either what you send me will have them too, or what you
> send me will be something entirely different and rebased.
>
> Basically, "automated merges" is wrong and bad. The ACPI people used
> to do them, and at some point their pull requests had more merge
> commits than they had actual changes.
>
> Merges should be generally *minimized*. They make it much harder to
> see what is actually your new independent work, and what is work that
> is on top of random other things.
>
> Regular automated merges is exactly the wrong thing to do, because it
> basically guarantees that you don't have a nice stand-alone
> development series (everything you do will be punctuated by those
> merges), _and_ that the merge commits are bad and have no good reason
> for them.
>
> Finally, the merges have a fundamental problem that is from past
> problems with rdma - in particular the history of mixing stuff up and
> having teams within one single company not even being able to talk or
> synchronize with each other.
>
> If you need merges for conflict resolution, it indicates to me that
> rdma *still* has that issue where people fight over the direction and
> the drivers between different teams.
>
> So while merges in general are something that should be avoided, when
> it comes to rdma in _particular_ I don't like seeing them, because I
> get the feeling that they are papering over the nasty development
> problems you guys have had, and are done as a way to handle the
> conflicts that were due to bad hygiene.
>
> So the *one* kind of merge that is good is the "development of this
> topic branch is finished and done, let's merge it up". But that is
> never about time, that's about "I'm done with this series, it's good
> to go into my main branch". That's a "forward merge", where you really
> merge the new and finished development tree into the base.
>
> The back-merges, when you merge some unrelated development, is
> generally a bad sign. It inevitably happens for various reasons, but
> it should be seen as the exception, not the rule, and it should
> *always* have an explanation.
>
>                       Linus
> --
> 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

I'm trying to understand why merges are being done instead of rebases.
Since we don't want to include other people's work, it seems that it
is cleaner to do a rebase. This is more for my education with using
Git with such a large project rather than me suggesting something
useful. (I dropped Linus from this part of the thread so as not to
bother him with an off-topic conversation).

Thanks,
Robert

----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <1500404869.23761.9.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 19:26           ` Linus Torvalds
       [not found]             ` <CA+55aFxYrrWO0NFJLzMiSQxPKMcoLUD=xA0e-g01riFfX5-Vug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-07-18 19:26 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Tue, Jul 18, 2017 at 12:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Fair enough.  My branch still had two unpulled commits and was based on
> v4.12-rc3.  But, you had already taken the SELinux/RDMA patches through
> the SELinux tree during this merge window, and two of the fix  patches
> in my pull request would have produced conflicts for you if I didn't
> merge up to a common ancestor that had the SELinux/RDMA patches prior
> to applying those patches to my tree (these two in particular):

Please don't worry about conflicts, unless they are something really
really fundamentally hard to merge. And even then, for rdma, I
probably want to see them, just to see what the hell went wrong *this
time*.

>> And if the only reason for that merge is "sync with upstream", then
>> no, that is not a sufficient reason. It has to have an actual real
>> reason, and it needs to be stated.
>
> Does this apply to the for-next area as well?

Largely, yes. Because the further away "for-next" gets from what you
then eventually send me, if your for-next branch has odd useless
merges, then either what you send me will have them too, or what you
send me will be something entirely different and rebased.

Basically, "automated merges" is wrong and bad. The ACPI people used
to do them, and at some point their pull requests had more merge
commits than they had actual changes.

Merges should be generally *minimized*. They make it much harder to
see what is actually your new independent work, and what is work that
is on top of random other things.

Regular automated merges is exactly the wrong thing to do, because it
basically guarantees that you don't have a nice stand-alone
development series (everything you do will be punctuated by those
merges), _and_ that the merge commits are bad and have no good reason
for them.

Finally, the merges have a fundamental problem that is from past
problems with rdma - in particular the history of mixing stuff up and
having teams within one single company not even being able to talk or
synchronize with each other.

If you need merges for conflict resolution, it indicates to me that
rdma *still* has that issue where people fight over the direction and
the drivers between different teams.

So while merges in general are something that should be avoided, when
it comes to rdma in _particular_ I don't like seeing them, because I
get the feeling that they are papering over the nasty development
problems you guys have had, and are done as a way to handle the
conflicts that were due to bad hygiene.

So the *one* kind of merge that is good is the "development of this
topic branch is finished and done, let's merge it up". But that is
never about time, that's about "I'm done with this series, it's good
to go into my main branch". That's a "forward merge", where you really
merge the new and finished development tree into the base.

The back-merges, when you merge some unrelated development, is
generally a bad sign. It inevitably happens for various reasons, but
it should be seen as the exception, not the rule, and it should
*always* have an explanation.

                      Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFyMw63bV+KOOiP9MbXF=BU8mHYEzBYsNH=xrVWxO=rzKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-07-18 19:07       ` Doug Ledford
       [not found]         ` <1500404869.23761.9.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-18 19:07 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Tue, 2017-07-18 at 11:24 -0700, Linus Torvalds wrote:
> On Tue, Jul 18, 2017 at 8:51 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > This is the first round of fixes for the -rc cycle.
> 
> Pulled. However, I want to complain (again!) about bad merge commits.
> 
> You're not the only one doing this, so this is not rdma-specific, but
> I complain when I notice.
> 
> There's a merge commit in there that has no explanation. This is the
> totality of the commit message:
> 
>     Merge tag 'v4.13-rc1' into k.o/for-4.13-rc
> 
>     Linux v4.13-rc1
> 
> and I want to point out that there is *nothing* there that explains
> why that merge exists.

Fair enough.  My branch still had two unpulled commits and was based on
v4.12-rc3.  But, you had already taken the SELinux/RDMA patches through
the SELinux tree during this merge window, and two of the fix  patches
in my pull request would have produced conflicts for you if I didn't
merge up to a common ancestor that had the SELinux/RDMA patches prior
to applying those patches to my tree (these two in particular):

f7c8f2e9ddc7 IB/uverbs: Make use of ib_modify_qp variant to avoid
resolving DMAC
a512c2fbef9c IB/core: Introduce modify QP operation with udata

So I didn't want to abandon the branch with those commits in them,
hence I did the forward merge and then proceeded with applying the
commits for you to pull.

> A merge? There *has* to be an explanation for why the merge exists.
> What problem did that merge fix? Why was it done in the first palce?
>
> And if the only reason for that merge is "sync with upstream", then
> no, that is not a sufficient reason. It has to have an actual real
> reason, and it needs to be stated.

Does this apply to the for-next area as well?  In particular, I was
planning on changing my process so that my for-next branch would
regularly sync with tagged rc releases (I believe this is what Dave
Miller does with his tree, or else he's getting updates to later -rcs
by pulling from other people, but I know I see merge commits for your
-rc releases in his history when I go scanning through it).  This is
how I intended to get the -rc fixes I send you into my for-next area so
that for-next development is against the RDMA subsystem as it exists
including the -rc fixes, and not as it existed when I branched off the
for-next branch.  I can merge my -rc branch instead if that is
preferred, and only merge the -rcs if I need one for a specific out-of-
RDMA area feature for building against.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1500393061.23761.1.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 18:24   ` Linus Torvalds
       [not found]     ` <CA+55aFyMw63bV+KOOiP9MbXF=BU8mHYEzBYsNH=xrVWxO=rzKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-07-18 18:24 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Tue, Jul 18, 2017 at 8:51 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> This is the first round of fixes for the -rc cycle.

Pulled. However, I want to complain (again!) about bad merge commits.

You're not the only one doing this, so this is not rdma-specific, but
I complain when I notice.

There's a merge commit in there that has no explanation. This is the
totality of the commit message:

    Merge tag 'v4.13-rc1' into k.o/for-4.13-rc

    Linux v4.13-rc1

and I want to point out that there is *nothing* there that explains
why that merge exists.

Dammit, if you cannot explain why a merge exists, you should not do
that merge! It's that simple.

There is absolutely no excuse for commits without explanations, and
that is *doubly* true of merge commits that don't even have any sane
patch associated with them.

A normal commit that does an obvious one-liner fix? It really may not
need more than a trivial commit message saying "Fix typo in xyz". The
rest of the commit explains it well enough.

A merge? There *has* to be an explanation for why the merge exists.
What problem did that merge fix? Why was it done in the first palce?

And if the only reason for that merge is "sync with upstream", then
no, that is not a sufficient reason. It has to have an actual real
reason, and it needs to be stated.

                     Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-07-18 15:51 Doug Ledford
       [not found] ` <1500393061.23761.1.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-18 15:51 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

This is the first round of fixes for the -rc cycle.  It isn't all
because a few of the drivers have lots of backlogged fixes so I'll do
those separately.  I've tried to pare this down to just important
things that qualify for -rc fixes and not new development.  The one
thing sitting in a grey area is the four patch series that fixes the
bad noio memalloc usage in the IPoIB ULP (I included it because using
the proper API instead of a poor hack around solution seems like a
"fix" to me), there is a two patch series that changes how ib_modify_qp
is called and seems like lots of lines, but it clearly makes the code
better and the second patch is the problem resolution, and I kept one
patch in that was not a fix only patch because it was part of a 5 patch
series and it was the only non-fix in the bunch (checkpatch.pl warnings
patch from Lijun Ou).  This specific branch/HEAD has not been through
linux-next, although all of the patches in this branch went through
linux-next previously as part of a larger branch, just since I pared it
down to fixes only it has not.  And it went to 0day, where it timed out
all but 13 configs, but in the 13 that passed was the 7.2-rhel-x86_64
config which I know will build the majority of the RDMA subsystem.

Here's the boilerplate:

The following changes since commit
5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -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
ebc9ca43e1d52a85c72fc2d343f353386ed6c188:

  IB/core: Allow QP state transition from reset to error (2017-07-17
21:21:30 -0400)

----------------------------------------------------------------
First set of -rc fixes for 4.13 cycle

- Misc. iSER fixes
- Namespace fixups
- Fix the fact that IPoIB didn't use the proper API for noio mem allocs
- rxe driver fixes
- hns_roce fixes
- Misc core fixes
- Misc IPoIB fixes

----------------------------------------------------------------
Amrani, Ram (1):
      RDMA/qedr: Add qedr to MAINTAINERS file

Bart Van Assche (1):
      mlx5: Avoid that mlx5_ib_sg_to_klms() overflows the klms[] array

Dennis Dalessandro (1):
      IB/hfi1: Ensure dd->gi_mask can not be overflowed

Doug Ledford (1):
      Merge tag 'v4.13-rc1' into k.o/for-4.13-rc

Erez Shitrit (2):
      IB/IPoIB: Forward MTU change to driver below
      IB/ipoib: Let lower driver handle get_stats64 call

Gustavo A. R. Silva (1):
      RDMA/core: Document confusing code

Leon Romanovsky (6):
      IB: Convert msleep below 20ms to usleep_range
      IB/IPoIB: Convert IPoIB to memalloc_noio_* calls
      IB/{rdmavt, qib, hfi1}: Remove gfp flags argument
      {net, IB}/mlx4: Remove gfp flags argument
      IB/core: Remove NOIO QP create flag
      IB/mlx5: Clean mr_cache debugfs in case of failure

Majd Dibbiny (1):
      IB/core: Add ordered workqueue for RoCE GID management

Mike Marciniszyn (1):
      IB/iser: Handle lack of memory management extentions correctly

Moni Shoua (2):
      IB/core: Namespace is mandatory input for address resolution
      IB/core: Don't resolve IP address to the loopback device

Parav Pandit (2):
      IB/core: Introduce modify QP operation with udata
      IB/uverbs: Make use of ib_modify_qp variant to avoid resolving
DMAC

Tadeusz Struk (1):
      IB/core: Allow QP state transition from reset to error

Vladimir Neyelov (1):
      IB/iser: Fix connection teardown race condition

Yonatan Cohen (1):
      IB/rxe: Fix kernel panic from skb destructor

oulijun (5):
      IB/hns: Fix the bug of polling cq failed for loopback Qps
      IB/hns: Fix the bug with wild pointer when destroy rc qp
      IB/hns: Fix the bug with rdma operation
      IB/hns: Fix the bug with modifying the MAC address without
removing the driver
      IB/hns: Fix for checkpatch.pl comment style warnings

yonatanc (1):
      IB/rxe: Set dma_mask and coherent_dma_mask

 MAINTAINERS                                        |  8 ++
 drivers/infiniband/core/addr.c                     | 46 +++++++++---
 drivers/infiniband/core/cma.c                      | 32 +-------
 drivers/infiniband/core/roce_gid_mgmt.c            | 11 ++-
 drivers/infiniband/core/uverbs_cmd.c               | 23 +-----
 drivers/infiniband/core/verbs.c                    | 51 +++++++++----
 drivers/infiniband/hw/hfi1/chip.c                  |  7 +-
 drivers/infiniband/hw/hfi1/qp.c                    |  7 +-
 drivers/infiniband/hw/hfi1/qp.h                    |  3 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         | 86 +++++++++++++-
--------
 drivers/infiniband/hw/hns/hns_roce_main.c          |  3 -
 drivers/infiniband/hw/mlx4/cq.c                    |  6 +-
 drivers/infiniband/hw/mlx4/main.c                  |  2 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |  2 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |  1 -
 drivers/infiniband/hw/mlx4/qp.c                    | 40 +++++-----
 drivers/infiniband/hw/mlx4/srq.c                   |  8 +-
 drivers/infiniband/hw/mlx5/mr.c                    | 36 +++++----
 drivers/infiniband/hw/nes/nes_hw.c                 |  4 +-
 drivers/infiniband/hw/qib/qib_qp.c                 | 15 ++--
 drivers/infiniband/hw/qib/qib_verbs.h              |  4 +-
 drivers/infiniband/sw/rdmavt/qp.c                  | 48 ++++--------
 drivers/infiniband/sw/rxe/rxe_net.c                |  3 +
 drivers/infiniband/sw/rxe/rxe_verbs.c              |  2 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            | 20 +++--
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |  2 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          | 31 +++++++-
 drivers/infiniband/ulp/iser/iscsi_iser.c           | 11 +++
 drivers/infiniband/ulp/iser/iser_verbs.c           | 10 ++-
 drivers/net/ethernet/mellanox/mlx4/alloc.c         | 29 ++++----
 drivers/net/ethernet/mellanox/mlx4/cq.c            |  4 +-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c         |  7 +-
 drivers/net/ethernet/mellanox/mlx4/en_tx.c         |  2 +-
 drivers/net/ethernet/mellanox/mlx4/icm.c           |  7 +-
 drivers/net/ethernet/mellanox/mlx4/icm.h           |  3 +-
 drivers/net/ethernet/mellanox/mlx4/mlx4.h          |  4 +-
 drivers/net/ethernet/mellanox/mlx4/mr.c            | 17 ++---
 drivers/net/ethernet/mellanox/mlx4/qp.c            | 20 ++---
 .../net/ethernet/mellanox/mlx4/resource_tracker.c  |  4 +-
 drivers/net/ethernet/mellanox/mlx4/srq.c           |  4 +-
 include/linux/mlx4/device.h                        | 10 +--
 include/rdma/ib_verbs.h                            | 18 ++++-
 include/rdma/rdma_vt.h                             |  5 +-
 43 files changed, 366 insertions(+), 290 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1499349377.2783.34.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  2017-07-06 14:20   ` Doug Ledford
@ 2017-07-06 16:49   ` Or Gerlitz
  1 sibling, 0 replies; 186+ messages in thread
From: Or Gerlitz @ 2017-07-06 16:49 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Thu, Jul 6, 2017 at 4:56 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Boris Pismenny (1):
>       RDMA/uverbs: Check port number supplied by user verbs cmds

Was this ever posted to the list?  when/where?

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1499349377.2783.34.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-06 14:20   ` Doug Ledford
  2017-07-06 16:49   ` Or Gerlitz
  1 sibling, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-07-06 14:20 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Thu, 2017-07-06 at 09:56 -0400, Doug Ledford wrote:
> Hi Linus,
> 
> This is my final pull request for the -rc cycle.  It includes two
> bugs

Oops, I didn't see you had skipped -rc8 this cycle, my bad.  Can we get
a kernel-announce-u79uwXL29TY76Z2rM5mHXA@public.gmane.org that we can subscribe to for
announcements without having to follow the entire kernel-u79uwXL29TaqPxH82wqD4g@public.gmane.org
g list?

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-07-06 13:56 Doug Ledford
       [not found] ` <1499349377.2783.34.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-07-06 13:56 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]

Hi Linus,

This is my final pull request for the -rc cycle.  It includes two bugs
against the newly added opa vnic that were found by turning on the
debug kernel options (one sleeping while holding a lock, so a one line
fix where they switched it from GFP_KERNEL allocation to a GFP_ATOMIC
allocation, the other a case where they had an isolated caller of their
code that could call them in an atomic context so they had to switch
their use of a mutex to a spinlock to be safe, so this was considerably
more lines of diff because all uses of that lock had to be switched),
one bug that was discussed with you already about an out of bounds
array access in ib_uverbs_modify_qp and ib_uverbs_create_ah and is only
7 lines of diff, and one fix to an earlier fix in the -rc cycle that
broke hfi1 and qib in regards to IPoIB (this one is, unfortunately,
larger than I would like for a -rc7 submission, but fixing the problem
required that we not treat all devices as though they had allocated a
netdev universally because it isn't true, and it took 70 lines of diff
to resolve the issue, but the final patch has been vetted by Intel and
Mellanox and they've both given their approval to the fix).

Here's the boilerplate:

The following changes since commit
d4702645838c8e04893383b50406249382b4e6bf:

  rdma/cxgb4: Fix memory leaks during module exit (2017-06-14 15:24:50
-0400)

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
8e959601996dc645f4ed7004482a1667c27deb39:

  IB/core, opa_vnic, hfi1, mlx5: Properly free rdma_netdev (2017-07-05
17:11:00 -0400)

----------------------------------------------------------------
Fixes #3 for 4.12-rc

- 2 Fixes for OPA found by debug kernel
- 1 Fix for user supplied input causing kernel problems
- 1 Fix for the IPoIB fixes submitted around -rc4

----------------------------------------------------------------
Boris Pismenny (1):
      RDMA/uverbs: Check port number supplied by user verbs cmds

Niranjana Vishwanathapura (1):
      IB/core, opa_vnic, hfi1, mlx5: Properly free rdma_netdev

Vishwanathapura, Niranjana (2):
      IB/opa_vnic: Use GFP_ATOMIC while sending trap
      IB/opa_vnic: Use spinlock instead of mutex for stats_lock

 drivers/infiniband/core/uverbs_cmd.c               |  8 +++++++
 drivers/infiniband/hw/hfi1/verbs.c                 |  1 -
 drivers/infiniband/hw/hfi1/vnic.h                  |  1 -
 drivers/infiniband/hw/hfi1/vnic_main.c             | 19 +++++++-------
-
 drivers/infiniband/hw/mlx5/main.c                  | 27
++++++++++++++--------
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |  8 +++----
 drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c |  4 ++--
 .../infiniband/ulp/opa_vnic/opa_vnic_internal.h    |  2 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c  | 16 ++++++-------
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c    |  2 +-
 .../infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c  |  8 +++----
 include/rdma/ib_verbs.h                            |  6 +++--
 12 files changed, 58 insertions(+), 44 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-06-16  2:09 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-06-16  2:09 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

I had thought at the time of the last pull request that there wouldn't
be much more to go, but several things just kept trickling in over the
last week.  Instead of just the 6 patches to bnxt_re that I had
anticipated, there are another 5 IPoIB patches, 2 qedr patches, and a
few other miscellaneous patches.  The bnxt_re patches are more lines of
diff than I like to submit this late in the game.  That's mostly
because of the first two patches in the series of 6.  I almost dropped
them just because of the lines of churn, but on a close review, a lot
of the churn came from removing duplicated code sections and
consolidating them into callable routines.  I felt like this made the
number of lines of change more acceptable, and they address problems,
so I left them.  The remainder of the patches are all small, well
contained, and well understood.  These have passed 0day testing, but
have not been submitted to linux-next (but a local merge test with your
current master was without any conflicts).

There are two patches I have not yet taken.  I won't have time to
process those until Tuesday due to PTO.  So there might be one more
pull request before the -rc cycle is over.

Here's the boilerplate:

The following changes since commit
d3957b86a40612826ef935f474b31359d66cbdca:

  RDMA/SA: Fix kernel panic in CMA request handler flow (2017-06-01
17:20:14 -0400)

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
d4702645838c8e04893383b50406249382b4e6bf:

  rdma/cxgb4: Fix memory leaks during module exit (2017-06-14 15:24:50
-0400)

----------------------------------------------------------------
Fixes #2 for 4.12-rc

- A fix for fix eea40b8f624 ("infiniband: call ipv6 route lookup via
the
  stub interface")
- 6 patches against bnxt_re...the first two are considerably larger
than
  I would like, but as they address real issues I went ahead and
  submitted them (it also helped that a good deal of the churn was
  removing code repeated in multiple places and consolidating it to one
  common function)
- 2 fixes against qedr that just came in
- 1 fix against rxe that took a few revisions to get right plus time to
  get the proper reviews
- 5 late breaking IPoIB fixes
- 1 late cxgb4 fix

----------------------------------------------------------------
Alex Vesker (4):
      IB/ipoib: Fix memory leaks for child interfaces priv
      IB/ipoib: Limit call to free rdma_netdev for capable devices
      IB/ipoib: Delete napi in device uninit default
      IB/ipoib: Fix access to un-initialized napi struct

Devesh Sharma (2):
      RDMA/bnxt_re: Fixing the Control path command and response
handling
      RDMA/bnxt_re: Fix RQE posting logic

Eddie Wai (1):
      RDMA/bnxt_re: HW workarounds for handling specific conditions

Feras Daoud (1):
      IB/ipoib: Fix memory leak in create child syscall

Jia-Ju Bai (1):
      rxe: Fix a sleep-in-atomic bug in post_one_send

Michal Kalderon (1):
      RDMA/qedr: Initialize byte_len in WC of READ and SEND commands

Raju Rangoju (1):
      rdma/cxgb4: Fix memory leaks during module exit

Ram Amrani (1):
      RDMA/qedr: Add 64KB PAGE_SIZE support to user-space queues

Roland Dreier (1):
      IB/addr: Fix setting source address in addr6_resolve()

Selvin Xavier (2):
      RDMA/bnxt_re: Dereg MR in FW before freeing the
fast_reg_page_list
      RDMA/bnxt_re: Remove FMR support

Somnath Kotur (1):
      RDMA/bnxt_re: Add HW workaround for avoiding stall for UD QPs

 drivers/infiniband/core/addr.c             |  10 +-
 drivers/infiniband/hw/bnxt_re/bnxt_re.h    |   4 +
 drivers/infiniband/hw/bnxt_re/ib_verbs.c   | 471
+++++++++++++++++++++--------
 drivers/infiniband/hw/bnxt_re/ib_verbs.h   |  22 +-
 drivers/infiniband/hw/bnxt_re/main.c       |   4 -
 drivers/infiniband/hw/bnxt_re/qplib_fp.c   | 384 ++++++++++++---------
--
 drivers/infiniband/hw/bnxt_re/qplib_fp.h   |  18 +-
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 314 ++++++++++---------
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h |  61 ++--
 drivers/infiniband/hw/bnxt_re/qplib_res.h  |   4 +
 drivers/infiniband/hw/bnxt_re/qplib_sp.c   | 333 +++++---------------
 drivers/infiniband/hw/bnxt_re/qplib_sp.h   |   2 +
 drivers/infiniband/hw/cxgb4/device.c       |  10 +-
 drivers/infiniband/hw/mlx5/main.c          |   6 +-
 drivers/infiniband/hw/qedr/qedr.h          |   5 +-
 drivers/infiniband/hw/qedr/verbs.c         |  68 +++--
 drivers/infiniband/sw/rxe/rxe_verbs.c      |   9 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c    |   1 -
 drivers/infiniband/ulp/ipoib/ipoib_main.c  |  15 +-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c  |  11 +-
 20 files changed, 935 insertions(+), 817 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-06-02 20:09 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-06-02 20:09 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

This is the majority of the -rc fixes for the rdma subsystem for this
cycle.  I will have one more pull request that I know of with 6
additional patches, all against bnxt_re.  They were mixed among a 14
patch series labeled as being for-next material, but on closer
inspection, some of them should be -rc, but I didn't have them in my
tree that I froze yesterday.

For the most part this is just a minor -rc cycle for the rdma
subsystem.  Even given that this is all of the -rc patches since the
merge window closed, it's still only about 25 patches.

Here's the git boilerplate:

The following changes since commit
5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -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
d3957b86a40612826ef935f474b31359d66cbdca:

  RDMA/SA: Fix kernel panic in CMA request handler flow (2017-06-01
17:20:14 -0400)

----------------------------------------------------------------
Fixes for 4.12-rc

- Multiple i40iw, nes, iw_cxgb4, hfi1, qib, mlx4, mlx5 fixes
- A few upper layer protocol fixes (IPoIB, iSER, SRP)
- A modest number of core fixes

----------------------------------------------------------------
Byczkowski, Jakub (1):
      RDMA/hfi1: Defer setting VL15 credits to link-up interrupt

Ganesh Goudar (1):
      RDMA/iw_cxgb4: calculate t4_eq_status_entries properly

Gustavo A. R. Silva (2):
      RDMA/i40iw: fix duplicated code for different branches
      RDMA/qedr: add null check before pointer dereference

Honggang Li (1):
      RDMA/IPoIB: Replace netdev_priv with ipoib_priv for
ipoib_get_link_ksettings

Israel Rukshin (1):
      RDMA/srp: Fix NULL deref at srp_destroy_qp()

Jack Morgenstein (1):
      RDMA/mlx4: Fix MAD tunneling when SRIOV is enabled

Leon Romanovsky (4):
      RDMA/IPoIB: Limit the ipoib_dev_uninit_default scope
      RDMA/netlink: Reduce exposure of RDMA netlink functions
      RDMA/uverbs: Declare local function static and add brackets to
sizeof
      RDMA/umem: Fix missing mmap_sem in get umem ODP call

Majd Dibbiny (1):
      RDMA/SA: Fix kernel panic in CMA request handler flow

Max Gurtovoy (2):
      net/mlx5: Define interface bits for fencing UMR wqe
      RDMA/mlx5: set UMR wqe fence according to HCA cap

Mike Marciniszyn (1):
      RDMA/qib,hfi1: Fix MR reference count leak on write with
immediate

Mustafa Ismail (1):
      RDMA/i40iw: Fix device initialization error path

Qing Huang (1):
      RDMA/core: not to set page dirty bit if it's already set.

Raju Rangoju (2):
      RDMA/iw_cxgb4: Avoid touch after free error in ARP failure
handlers
      RDMA/iw_cxgb4: fix the calculation of ipv6 header size

Shiraz Saleem (1):
      RDMA/i40iw: Remove MSS change support

Steven L. Roberts (2):
      RDMA/hfi1: fix array termination by appending NULL to attr array
      RDMA/hfi1: change PCI bar addr assignments to Linux API functions

Tatyana Nikolova (4):
      RDMA/i40iw: Don't set 0-length FULPDU RTR indication control flag
      RDMA/i40iw: ACK MPA Reject frame
      RDMA/nes: Don't set 0-length FULPDU RTR indication control flag
      RDMA/nes: ACK MPA Reply frame

 drivers/infiniband/core/cm.c                 |  4 +-
 drivers/infiniband/core/cma.c                | 13 +++---
 drivers/infiniband/core/core_priv.h          | 10 +++++
 drivers/infiniband/core/netlink.c            |  2 +-
 drivers/infiniband/core/sa_query.c           |  6 +--
 drivers/infiniband/core/umem.c               |  2 +-
 drivers/infiniband/core/umem_odp.c           |  6 ++-
 drivers/infiniband/core/uverbs_marshall.c    |  8 ++--
 drivers/infiniband/hw/cxgb4/cm.c             |  9 +++-
 drivers/infiniband/hw/cxgb4/device.c         |  2 +-
 drivers/infiniband/hw/hfi1/chip.c            | 67
+++++++++++++++++++++-------
 drivers/infiniband/hw/hfi1/chip_registers.h  |  2 +
 drivers/infiniband/hw/hfi1/hfi.h             | 11 ++++-
 drivers/infiniband/hw/hfi1/intr.c            |  3 +-
 drivers/infiniband/hw/hfi1/pcie.c            |  4 +-
 drivers/infiniband/hw/hfi1/rc.c              |  5 ++-
 drivers/infiniband/hw/hfi1/sysfs.c           |  3 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c       |  3 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c     | 12 +----
 drivers/infiniband/hw/i40iw/i40iw_main.c     | 20 ++++++---
 drivers/infiniband/hw/i40iw/i40iw_osdep.h    |  1 -
 drivers/infiniband/hw/i40iw/i40iw_type.h     |  2 -
 drivers/infiniband/hw/i40iw/i40iw_utils.c    | 17 -------
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c |  5 +--
 drivers/infiniband/hw/mlx4/mad.c             |  1 +
 drivers/infiniband/hw/mlx5/main.c            | 14 ++++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h         |  3 +-
 drivers/infiniband/hw/mlx5/qp.c              | 59 ++++++++++--------
------
 drivers/infiniband/hw/nes/nes_cm.c           |  3 +-
 drivers/infiniband/hw/qedr/qedr_cm.c         | 10 +++--
 drivers/infiniband/hw/qib/qib_rc.c           |  4 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c |  2 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c    |  2 +-
 drivers/infiniband/ulp/srp/ib_srp.c          |  4 +-
 include/linux/mlx5/mlx5_ifc.h                | 10 ++++-
 include/rdma/ib_sa.h                         | 25 ++---------
 include/rdma/rdma_netlink.h                  | 10 -----
 37 files changed, 194 insertions(+), 170 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFysG9EZ9hXAGq5WZ1pJXEV-nqG4uJ5vbuuq1b1G8d+eXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-05-09 14:23       ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-05-09 14:23 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Mon, 2017-05-08 at 20:15 -0700, Linus Torvalds wrote:
> On Mon, May 8, 2017 at 12:43 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > 
> > As mentioned in my first pull request, this is the subsequent pull
> > request(s) I had.
> 
> Btw, please send each pull request as one email each.
> 
> I did the first pull, and almost missed the other just because I
> didn't expect there to be a second one in the same email. The only
> reason I ended up looking down was that your explanations seemed
> incoherent and talked about "the first", without there being a second
> email.

Sorry, will make sure to get it right in the future.  Thanks for
catching it ;-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1494272587.3041.256.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-05-09  3:15   ` Linus Torvalds
       [not found]     ` <CA+55aFysG9EZ9hXAGq5WZ1pJXEV-nqG4uJ5vbuuq1b1G8d+eXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-05-09  3:15 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Mon, May 8, 2017 at 12:43 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> As mentioned in my first pull request, this is the subsequent pull
> request(s) I had.

Btw, please send each pull request as one email each.

I did the first pull, and almost missed the other just because I
didn't expect there to be a second one in the same email. The only
reason I ended up looking down was that your explanations seemed
incoherent and talked about "the first", without there being a second
email.

                 Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-05-08 19:43 Doug Ledford
       [not found] ` <1494272587.3041.256.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-05-08 19:43 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

As mentioned in my first pull request, this is the subsequent pull
request(s) I had.  This is all I have, and in fact this cleans out the
RDMA subsystem's entire patchworks queue of kernel changes that are
ready to go (well, it did for the weekend anyway, a few new patches are
in, but they'll be coming during the -rc cycle).

The first is the single patch that would have conflicted if taken from
my tree or DaveM's tree as it needed our trees merged to come cleanly.
 It's been in my tree since last week and has been through 0day, but
not linux-next.  It is using the for-linus tag, here's the boilerplate
for it:

The following changes since commit
4ac4d584886a4f47f8ff3bca0f32ff9a2987d3e5:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-
05-04 12:26:43 -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
693dfd5a3f19efc44acf3a57217c0480e414f8ee:

  IB/mlx5: Enable IPoIB acceleration (2017-05-04 16:22:08 -0400)

----------------------------------------------------------------
Updates #2 for 4.12 kernel merge window

- mlx5/IPoIB fixup patch

----------------------------------------------------------------
Erez Shitrit (1):
      IB/mlx5: Enable IPoIB acceleration

 drivers/infiniband/hw/mlx5/main.c               | 22 +++++++++++++
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/ipoib.c | 44 +++++++++++++++
----------
 drivers/net/ethernet/mellanox/mlx5/core/ipoib.h |  2 ++
 include/linux/mlx5/driver.h                     | 19 +++++++++++
 5 files changed, 70 insertions(+), 19 deletions(-)

The second pull request contains the patch series from Intel plus three
other stragllers that came in late last week.  I took them because it
allowed me to legitimately claim that the RDMA patchworks queue was,
for a short time, 100% cleared of all waiting kernel patches, woohoo!
:-).  I have it under my for-next tag, so it did get 0day and linux-
next over the end of last week, and linux-next did show one minor
conflict.  The Intel series does a patchworks cleanup of some function
declarations, while a different series coming to you via the PCI
subsystem removes in internal function and declaration that is in the
area of the cleanup.  The fixup is simple and obvious.  Here's the
boilerplate on this series:

The following changes since commit
24b43c99647bf9be4995e6a6c9c3a923c147770a:

  infiniband: avoid dereferencing uninitialized dst on error path
(2017-05-02 10:45:45 -0400)

are available in the git repository at:

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

for you to fetch changes up to
67cf3623e097706b0ca03bf79bf28d60c39591eb:

  rxe: expose num_possible_cpus() cnum_comp_vectors (2017-05-04
19:33:02 -0400)

----------------------------------------------------------------
Updates #3 for 4.12 kernel merge window

- The hfi1 15 patch set that landed late
- IPoIB get_link_ksettings which landed late because I asked for a
  respin
- One late rxe change
- One -rc worthy fix that's in early

----------------------------------------------------------------
Jakub Byczkowski (1):
      IB/hfi1: Fix checks for Offline transient state

Leon Romanovsky (1):
      IB/rxe: Update caller's CRC for RXE_MEM_TYPE_DMA memory type

Michael J. Ruhl (9):
      IB/hfi1: Return an error on memory allocation failure
      IB/hfi1: Fix a subcontext memory leak
      IB/hfi1: Name function prototype parameters
      IB/hfi1: Use filedata rather than filepointer
      IB/hfi1: Search shared contexts on the opened device, not all
devices
      IB/hfi1: Correctly clear the pkey
      IB/hfi1: Clean up context initialization
      IB/hfi1: Fix an assign/ordering issue with shared context IDs
      IB/hfi1: Clean up on context initialization failure

Mike Marciniszyn (2):
      IB/hfi1, IB/rdmavt: Move r_adefered to r_lock cache line
      IB/hfi1: Fix yield logic in send engine

Sagi Grimberg (1):
      rxe: expose num_possible_cpus() cnum_comp_vectors

Sebastian Sanchez (2):
      IB/hfi1: Get rid of divide when setting the tx request header
      IB/hfi1: Remove atomic operations for SDMA_REQ_HAVE_AHG bit

Tymoteusz Kielan (1):
      IB/hfi1: Adjust default eager_buffer_size to 8MB

Zhu Yanjun (1):
      IB/ipoib: add get_link_ksettings in ethtool

 drivers/infiniband/hw/hfi1/chip.c            |  47 ++-
 drivers/infiniband/hw/hfi1/chip.h            |  10 +-
 drivers/infiniband/hw/hfi1/driver.c          |  42 +--
 drivers/infiniband/hw/hfi1/file_ops.c        | 425 ++++++++++++++-----
--------
 drivers/infiniband/hw/hfi1/hfi.h             | 107 ++++---
 drivers/infiniband/hw/hfi1/init.c            |  33 +--
 drivers/infiniband/hw/hfi1/intr.c            |   3 +-
 drivers/infiniband/hw/hfi1/qp.c              |   4 +-
 drivers/infiniband/hw/hfi1/rc.c              |  13 +-
 drivers/infiniband/hw/hfi1/ruc.c             |  80 +++--
 drivers/infiniband/hw/hfi1/trace_ctxts.h     |  17 +-
 drivers/infiniband/hw/hfi1/trace_tx.h        |  34 +++
 drivers/infiniband/hw/hfi1/user_exp_rcv.c    | 180 ++++++------
 drivers/infiniband/hw/hfi1/user_exp_rcv.h    |  17 +-
 drivers/infiniband/hw/hfi1/user_sdma.c       | 191 ++++++------
 drivers/infiniband/hw/hfi1/user_sdma.h       |  18 +-
 drivers/infiniband/hw/hfi1/verbs.h           |   5 +-
 drivers/infiniband/hw/hfi1/vnic_main.c       |   8 +-
 drivers/infiniband/sw/rxe/rxe_mr.c           |   2 +-
 drivers/infiniband/sw/rxe/rxe_param.h        |   1 -
 drivers/infiniband/sw/rxe/rxe_verbs.c        |   2 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c |  59 ++++
 include/rdma/rdmavt_qp.h                     |   1 +
 include/uapi/linux/ethtool.h                 |   1 +
 24 files changed, 695 insertions(+), 605 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-05-03 15:17 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-05-03 15:17 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Linus,

As has been the case with several pull requests lately, I had to wait
until after the net-next pull request was pulled in as my tree is based
on a snapshot of net-next.  I've had people submit some late breaking
stuff this cycle.  I took a series last week that broke a followon
series that was on the list.  The fixed version didn't land until
Saturday, so I didn't get it until Monday.  Everything has passed 0day,
and everything should have been through linux-next (although since new
errors are ignored on the first day of new patches in linux-next, there
is one patch I took by itself yesterday that theoretically might
trigger new warnings, but once you see the patch, you'll agree it's not
an issue).

Primary updates in this release:

- Lots of driver fixes and misc fixes across the board.
- I had to base on a net-next tree because the IPoIB Accelorator
patches needed it.  Unfortunately, it was known to Mellanox that there
would need to be an IPoIB accelorator patch to the net tree (which left
some functions turned off by an #ifdef construct to avoid warnings
about defined but unused functions), then one to the RDMA tree, then a
fixup that went back and re-enabled the functions in the net tree and
enabled their use in the rdma tree.  But, a sparse fix was sent to the
net tree after I did my pull, and the fixup patch conflicts quite
directly with that sparse fix, so I'm going to submit the fixup patch
towards the end of the merge window by itself and based upon your
master branch at the time.
- Two separate rounds of hfi1 fixes, one that got dropped from last
release because it came in just a day or two before the end of the
merge window and then the one from this release cycle.  Of note is that
I now have a third series that just landed from Intel yesterday.  It is
not included in this pull request, but I may submit it by the end of
the week.  I'll talk to Intel about improving the timing of thier
submissions for my workflow.
- Changes to our idr usage in the RDMA subsystem that will tie into our
cgroup management and also into the upcoming changes for the RDMA
kernel<->userspace API.
- Addition of support for a netdev to be tied to an RDMA device at the
core level
- Addition of the VNIC driver from Intel.  While IPoIB provides IP over
InfiniBand (and *only* IP, no lower layer protocol headers are allowed
or supported), the VNIC driver presents a virtual Ethernet device with
support for things like varying Ethertypes, VLANs, priorities and other
features of Ethernet.  The virtual devices are centrally managed by the
OPA fabric manager, making this (for the time being) a strictly OPA
specific feature.
- Improvements to the On-Demand Paging support in the RDMA subsystem.
- Addition of three significant OPA changes.  While we added OPA
support some time ago (via the hfi1 driver), the RDMA subsystem has so
far glossed over the areas where OPA and InfiniBand differ.  With this
release we are starting to add support for the OPA extensions into the
RDMA core in the following area: Extended port information for OPA is
now supported, extended Address Handle attributes for OPA are now
supported, and extended SA Queries to get OPA specific subnet
information is now supported.

That pretty much covers things.  Here's the git produced boiler plate
for you:

The following changes since commit
70d40b366d2f7c2facaa3bc20f26e562e91ce94d:

  Merge branch 'mlx5-RDMA-netdevice' (2017-04-17 11:08:33 -0400)

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
24b43c99647bf9be4995e6a6c9c3a923c147770a:

  infiniband: avoid dereferencing uninitialized dst on error path
(2017-05-02 10:45:45 -0400)

----------------------------------------------------------------
Updates for 4.12 kernel merge window

- idr usage and locking changes
- build fix for hns
- ipoib debug path record file fix
- hfi1 updates
- core RDMA netdev addition
- Intel VNIC driver addition
- Enhanced accelerators for IPoIB addition
- Debug cleanups in cxgb3/4
- Trivial cleanups from SF Markus Elfring
- Misc rxe fixes from Mellanox
- Misc ipoib fixes from Mellanox
- Lots of mlx4/mlx5 changes from Mellanox
- Misc fixes across the RDMA subsystem
- ODP paging fixes and improvements
- qedr updates
- hfi1 updates
- OPA port info patches
- OPA AH patches
- OPA SA Query patches

----------------------------------------------------------------
Amrani, Ram (5):
      RDMA/qedr: reset access control when registering a MR
      RDMA/qedr: properly check atomic capabilities
      RDMA/qedr: enhance destroy flow for GSI QP
      RDMA/qedr: destroy CQ only after HW releases it
      RDMA/qedr: add support for send+invalidate in poll CQ

Ariel Levkovich (2):
      IB/mlx5: Add inner spec and IPv6 validation in user's flow
attribute list
      IB/mlx5: Use IP version matching to classify IP traffic

Arnd Bergmann (1):
      infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data

Artemy Kovalyov (10):
      IB: Replace ib_umem page_size by page_shift
      IB/mlx5: Fix function updating xlt emergency path
      IB/mlx5: Fix UMR size calculation
      IB/mlx5: Fix implicit MR GC
      IB/mlx5: Decrease verbosity level of ODP errors
      IB/umem: Add contiguous ODP support
      IB/mlx5: Add contiguous ODP support
      IB/umem: Add support to huge ODP
      IB/mlx5: Extract page fault code
      IB/mlx5: Add ODP support to MW

Bodong Wang (1):
      IB/mlx5: Fix wrong use of kfree at bad flow in create_cq_user

Colin Ian King (3):
      RDMA/bnxt_re: remove redundant initialization of rc to zero
      IB/iser: fix spelling mistake: "unexepected" -> "unexpected"
      IB/rxe: fix typo: "algorithmi" -> "algorithm"

Dan Carpenter (1):
      IB/rdmavt: restore IRQs on error path in rvt_create_ah()

Dasaratharaman Chandramouli (33):
      IB/hfi1: Rename hdr2sc to hfi1_9B_get_sc5
      IB/SA: Fix lines longer than 80 columns
      IB/SA: Add braces when using sizeof
      IB/SA: Remove unwanted braces
      IB/SA: Move functions update_sm_ah() and ib_sa_event()
      IB/SA: Modify SA to implicitly cache Class Port info
      IB/core: Add rdma_cap_opa_ah to expose opa address handles
      IB/core: Move opa_class_port_info definition to header file
      IB/SA: Add support to query opa classport info.
      IB/ocrdma: Add identifier names to function definitions
      IB/IPoIB: Remove 'else' when the 'if' has a return.
      IB/core: Add braces when using sizeof
      IB/core: Check for global flag when using ah_attr
      IB/rxe: Initialize ib_ah_attr during query_ah
      IB/core: Rename struct ib_ah_attr to rdma_ah_attr
      IB/core: Rename ib_create_ah to rdma_create_ah
      IB/core: Rename ib_modify_ah to rdma_modify_ah
      IB/core: Rename ib_query_ah to rdma_query_ah
      IB/core: Rename ib_destroy_ah to rdma_destroy_ah
      IB/mlx4: Rename to_ib_ah_attr to to_rdma_ah_attr
      IB/mlx5: Rename to_ib_ah_attr to to_rdma_ah_attr
      IB/mthca: Rename to_ib_ah_attr to to_rdma_ah_attr
      IB/PVRDMA: Rename ib_ah_attr related functions
      IB/core: Add accessor functions for rdma_ah_attr fields
      IB/core: Use rdma_ah_attr accessor functions
      IB/core: Define 'ib' and 'roce' rdma_ah_attr types
      IB/core: Define 'opa' rdma_ah_attr type
      IB/CM: Add braces when using sizeof
      IB/SA: Rename ib_sa_path_rec to sa_path_rec
      IB/SA: Introduce path record specific types
      IB/SA: Split struct sa_path_rec based on IB and ROCE specific
fields
      IB/SA: Add OPA path record type
      IB/SA: Add support to query OPA path records

Dean Luick (1):
      IB/hfi1: Force logical link down

Dennis Dalessandro (4):
      IB/hfi1: Fix misspelling in comment
      IB/hfi1: Convert %Lx to %llx
      IB/hfi1: Fix unbalanced braces around else
      IB/hfi1: Use bool in process_ecn

Don Hiatt (4):
      IB/hfi1: Add receive fault injection feature
      IB/hfi1: Add transmit fault injection feature
      IB/hfi1: Add functions to parse 9B headers
      IB/hfi1: Use defines from common headers

Doug Ledford (4):
      Merge branch 'k.o/for-4.12' into k.o/for-4.12-rdma-netdevice
      cxgb4: Convert PDBG to pr_debug the second
      RDMA/bnxt_re: Use IS_ERR_OR_NULL where appropriate
      IB/SA: Add OPA addr header

Easwar Hariharan (1):
      IB/hfi1: Check for QSFP presence before attempting reads

Erez Shitrit (5):
      IB/IPoIB: Separate control and data related initializations
      IB/IPoIB: Separate control from HW operation on ipoib_open/stop
ndo
      IB/IPoIB: Rename qpn to be dqpn in ipoib_send and post_send
functions
      IB/IPoIB: Use defined function for netdev_priv function
      IB/IPoIB: Support acceleration options callbacks

Feras Daoud (2):
      IB/ipoib: Update broadcast object if PKey value was changed in
index 0
      IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow

Ganesh Goudar (1):
      iw_cxgb4: Use dsgl by default

Geert Uytterhoeven (1):
      MAINTAINERS: Add file patterns for infiniband device tree
bindings

Geliang Tang (3):
      IB/i40iw: use setup_timer
      IB/nes: use setup_timer
      IB/qib: use setup_timer

Håkon Bugge (2):
      IB/mlx4: Change flush logic so it adheres to the variable name
      IB/mlx4: Fix incorrect order of formal and actual parameters

Ira Weiny (2):
      IB/hfi: Fix up comments in engine mapping
      IB/hfi: Protect against writable mmap

Jack Morgenstein (3):
      IB/core: Fix sysfs registration error flow
      IB/mlx4: Fix ib device initialization error flow
      IB/mlx4: Reduce SRIOV multicast cleanup warning message to debug
level

Jason Gunthorpe (1):
      IB/vmw_pvrdma: Spare annotate imm_data

Joe Perches (4):
      cxgb3: Use more common logging style
      cxgb3: Convert PDBG to pr_debug
      cxgb4: Use more common logging style
      cxgb4: Convert PDBG to pr_debug

Johannes Thumshirn (1):
      IB/rxe: Don't clamp residual length to mtu

Leon Romanovsky (5):
      IB/mthca: Check validity of output parameter pointer
      Ib/core: Mark local uverbs_std_types functions to be static
      Ib/usnic: Explicitly include usnic headers
      IB/usnic: Simplify the code to balance loc/unlock calls
      IB/nes: Fix incorrect type in assignment

Majd Dibbiny (1):
      IB/mlx4: Support RAW Ethernet when RoCE is disabled

Maor Gottlieb (6):
      IB/mlx4: Take write semaphore when changing the vma struct
      IB/mlx4: Change vma from shared to private
      IB/mlx5: Take write semaphore when changing the vma struct
      IB/mlx5: Change vma from shared to private
      IB/mlx5: Check supported flow table size
      IB/mlx5: Enlarge autogroup flow table

Mark Brown (1):
      IB/hns: Explicitly include linux/of.h

Markus Elfring (6):
      IB/hfi1: Use kcalloc() in hfi1_user_exp_rcv_init()
      IB/hfi1: Use kcalloc() in hfi1_user_sdma_alloc_queues()
      IB/hfi1: Remove intermediate var in hfi1_user_sdma_alloc_queues()
      IB/hfi1: Coding style improvement (make sizeof use safer)
      IB/hns: Use kmalloc_array() in hns_roce_cmd_use_events()
      IB/hns: Use kcalloc() in hns_roce_buddy_init()

Matan Barak (13):
      IB/core: Refactor idr to be per uverbs_file
      IB/core: Add support for idr types
      IB/core: Add idr based standard types
      IB/core: Change idr objects to use the new schema
      IB/core: Add lock to multicast handlers
      IB/core: Add support for fd objects
      IB/core: Change completion channel to use the reworked objects
schema
      IB/core: Rename write flag to exclusive in rdma_core
      IB/core: Don't pass the lock state to _rdma_remove_commit_uobject
      IB/core: Nullify ib_uobject during allocation
      IB/core: A small refactor in destroy WQ handler
      IB/core: Don't use is_async in event files to infer events size
      IB/core: Rename uverbs event file structure

Michael J. Ruhl (9):
      IB/hfi1: Race hazard avoidance in user SDMA driver
      IB/hfi1: Cache registers during state change
      IB/hfi1: Add a patch value to the firmware version string
      IB/hfi1: Ensure VL index is within bounds
      IB/core: If the MGID/MLID pair is not on the list return an error
      IB/hfi1: Correct MulticastMask/CollectiveMask info to SMA output
      IB/core: For multicast functions, verify that LIDs are multicast
LIDs
      IB/rdmavt/hfi1/qib: Use the MGID and MLID for multicast
addressing
      IB/hfi1: Validate the TID count before using it

Michael Mera (1):
      IB/ocrdma: fix out of bounds access to local buffer

Mike Marciniszyn (7):
      IB/rdmavt, IB/hfi1, IB/qib: Make wc opcode translation driver
dependent
      IB/rdmavt: Add additional fields to post send trace
      IB/rdmavt: Add tracing for cq entry and poll
      IB/rdmavt: Add swqe completion trace
      IB/rdmavt: Avoid reseting wqe send_flags in unreserve
      IB/hfi1: Eliminate synchronize_rcu() in mr delete
      IB/hfi1: Prevent kernel QP post send hard lockups

Moni Shoua (2):
      IB/cma: Send MRA for reply messages
      IB/mlx5: Set correct SL in completion for RoCE

Neel Desai (2):
      IB/hfi1: Adjust high temperature warning for QSFP cable
      IB/hfi1: Permanently enable P_Key checking in HFI

Niranjana Vishwanathapura (1):
      IB/IPoIB: Introduce RDMA netdev interface and IPoIB structs

Noa Osherovich (3):
      IB/core: Add HDR speed enum
      IB/mlx5: Set mlx5_query_roce_port's return value to void
      IB/mlx5: Add support for active_width and active_speed in RoCE

Pan Bian (1):
      iw_cxgb4: check return value of alloc_skb

Paolo Abeni (2):
      infiniband: call ipv6 route lookup via the stub interface
      infiniband: avoid dereferencing uninitialized dst on error path

Parav Pandit (4):
      IB/rxe: Avoid accessing timers for non RC QPs
      IB/rxe: Do not export module's private function
      IB/core: Fix kernel crash during fail to initialize device
      IB/mlx5: Support congestion related counters

Petr Mladek (1):
      IB/fmr_pool: Convert the cleanup thread into kthread worker API

Sagi Grimberg (1):
      mlx5: Fix mlx5_ib_map_mr_sg mr length

Sebastian Sanchez (3):
      IB/hfi1: NULL pointer dereference when freeing rhashtable
      IB/rdmavt, IB/hfi1: Fix timer migration regressions
      IB/hfi1: Return SC2VL mappings to FM with VL15 instead of
ILLEGAL_VL

Selvin Xavier (1):
      MAINTAINERS: Update ocrdma module status

Shamir Rabinovitch (1):
      IB/IPoIB: ibX: failed to create mcg debug file

Slava Shwartsman (2):
      IB/core: Introduce drop flow specification
      IB/mlx5: Add drop flow steering rule support

Stuart Summers (1):
      IB/hfi1: Cache neighbor secure data after link up

Tadeusz Struk (3):
      IB/hfi1: Check device id early during init
      IB/hfi1: Protect the global dev_cntr_names and port_cntr_names
      IB/hfi1: Fix softlockup issue

Tim Wright (1):
      IB/mlx5: Add port_xmit_wait to counter registers read

Vishwanathapura, Niranjana (12):
      IB/opa-vnic: Virtual Network Interface Controller (VNIC)
documentation
      IB/opa-vnic: RDMA NETDEV interface
      IB/opa-vnic: Virtual Network Interface Controller (VNIC)
interface
      IB/opa-vnic: Virtual Network Interface Controller (VNIC) netdev
      IB/opa-vnic: VNIC Ethernet Management (EM) structure definitions
      IB/opa-vnic: VNIC statistics support
      IB/opa-vnic: VNIC MAC table support
      IB/opa-vnic: VNIC Ethernet Management Agent (VEMA) interface
      IB/opa-vnic: VNIC Ethernet Management Agent (VEMA) function
      IB/hfi1: OPA_VNIC RDMA netdev support
      IB/hfi1: Virtual Network Interface Controller (VNIC) HW support
      IB/hfi1: VNIC SDMA support

Vlad Tsyrklevich (1):
      infiniband/uverbs: Fix integer overflows

Yonatan Cohen (1):
      IB/rxe: Add port protocol stats

Yuval Shaia (2):
      IB/usnic: Remove unused functions
      {net,IB}/{rxe,usnic}: Utilize generic mac to eui32 function

Zhu Yanjun (1):
      IB/core: change the return type to void

yonatanc (2):
      IB/rxe: Offload CRC calculation when possible
      IB/rxe: Cache dst in QP instead of getting it for each send

 Documentation/infiniband/opa_vnic.txt              |  153 ++
 MAINTAINERS                                        |   16 +-
 drivers/infiniband/Kconfig                         |    1 +
 drivers/infiniband/core/Makefile                   |    3 +-
 drivers/infiniband/core/addr.c                     |    6 +-
 drivers/infiniband/core/agent.c                    |    4 +-
 drivers/infiniband/core/cm.c                       |  119 +-
 drivers/infiniband/core/cma.c                      |  132 +-
 drivers/infiniband/core/device.c                   |   33 +-
 drivers/infiniband/core/fmr_pool.c                 |   49 +-
 drivers/infiniband/core/mad.c                      |   28 +-
 drivers/infiniband/core/mad_rmpp.c                 |   16 +-
 drivers/infiniband/core/multicast.c                |   27 +-
 drivers/infiniband/core/rdma_core.c                |  627 ++++++++
 drivers/infiniband/core/rdma_core.h                |   78 +
 drivers/infiniband/core/sa_query.c                 |  886 ++++++++---
 drivers/infiniband/core/sysfs.c                    |    6 +-
 drivers/infiniband/core/ucm.c                      |    6 +-
 drivers/infiniband/core/ucma.c                     |   24 +-
 drivers/infiniband/core/umem.c                     |   17 +-
 drivers/infiniband/core/umem_odp.c                 |   81 +-
 drivers/infiniband/core/user_mad.c                 |   44 +-
 drivers/infiniband/core/uverbs.h                   |   69 +-
 drivers/infiniband/core/uverbs_cmd.c               | 1582 ++++++----
----------
 drivers/infiniband/core/uverbs_main.c              |  508 +++----
 drivers/infiniband/core/uverbs_marshall.c          |   81 +-
 drivers/infiniband/core/uverbs_std_types.c         |  275 ++++
 drivers/infiniband/core/verbs.c                    |   86 +-
 drivers/infiniband/hw/bnxt_re/ib_verbs.c           |  118 +-
 drivers/infiniband/hw/bnxt_re/ib_verbs.h           |    6 +-
 drivers/infiniband/hw/cxgb3/cxio_dbg.c             |   35 +-
 drivers/infiniband/hw/cxgb3/cxio_hal.c             |  201 ++-
 drivers/infiniband/hw/cxgb3/cxio_hal.h             |    7 +-
 drivers/infiniband/hw/cxgb3/cxio_resource.c        |   25 +-
 drivers/infiniband/hw/cxgb3/iwch.c                 |   19 +-
 drivers/infiniband/hw/cxgb3/iwch_cm.c              |  269 ++--
 drivers/infiniband/hw/cxgb3/iwch_cm.h              |   18 +-
 drivers/infiniband/hw/cxgb3/iwch_cq.c              |   21 +-
 drivers/infiniband/hw/cxgb3/iwch_ev.c              |   26 +-
 drivers/infiniband/hw/cxgb3/iwch_mem.c             |    2 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |  118 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.h        |    9 +-
 drivers/infiniband/hw/cxgb3/iwch_qp.c              |   67 +-
 drivers/infiniband/hw/cxgb4/cm.c                   |  393 ++---
 drivers/infiniband/hw/cxgb4/cq.c                   |   79 +-
 drivers/infiniband/hw/cxgb4/device.c               |  141 +-
 drivers/infiniband/hw/cxgb4/ev.c                   |   39 +-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h             |   48 +-
 drivers/infiniband/hw/cxgb4/mem.c                  |   44 +-
 drivers/infiniband/hw/cxgb4/provider.c             |   44 +-
 drivers/infiniband/hw/cxgb4/qp.c                   |   96 +-
 drivers/infiniband/hw/cxgb4/resource.c             |   64 +-
 drivers/infiniband/hw/cxgb4/t4.h                   |   24 +-
 drivers/infiniband/hw/hfi1/Makefile                |    2 +-
 drivers/infiniband/hw/hfi1/aspm.h                  |   15 +-
 drivers/infiniband/hw/hfi1/chip.c                  |  590 ++++++--
 drivers/infiniband/hw/hfi1/chip.h                  |   20 +-
 drivers/infiniband/hw/hfi1/common.h                |   15 +-
 drivers/infiniband/hw/hfi1/debugfs.c               |  238 ++-
 drivers/infiniband/hw/hfi1/debugfs.h               |   62 +-
 drivers/infiniband/hw/hfi1/driver.c                |  128 +-
 drivers/infiniband/hw/hfi1/file_ops.c              |   31 +-
 drivers/infiniband/hw/hfi1/firmware.c              |   14 +-
 drivers/infiniband/hw/hfi1/hfi.h                   |   95 +-
 drivers/infiniband/hw/hfi1/init.c                  |   69 +-
 drivers/infiniband/hw/hfi1/intr.c                  |   27 +-
 drivers/infiniband/hw/hfi1/mad.c                   |   95 +-
 drivers/infiniband/hw/hfi1/pcie.c                  |    2 +-
 drivers/infiniband/hw/hfi1/pio.c                   |   19 +-
 drivers/infiniband/hw/hfi1/pio.h                   |   34 +-
 drivers/infiniband/hw/hfi1/qp.c                    |   12 +-
 drivers/infiniband/hw/hfi1/rc.c                    |   55 +-
 drivers/infiniband/hw/hfi1/ruc.c                   |  137 +-
 drivers/infiniband/hw/hfi1/sdma.c                  |   43 +-
 drivers/infiniband/hw/hfi1/sdma.h                  |   46 +-
 drivers/infiniband/hw/hfi1/sysfs.c                 |    4 +-
 drivers/infiniband/hw/hfi1/trace.c                 |    5 +-
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h          |    8 +-
 drivers/infiniband/hw/hfi1/trace_misc.h            |   48 +
 drivers/infiniband/hw/hfi1/trace_rc.h              |    7 +-
 drivers/infiniband/hw/hfi1/trace_tx.h              |   43 +
 drivers/infiniband/hw/hfi1/uc.c                    |   14 +-
 drivers/infiniband/hw/hfi1/ud.c                    |   73 +-
 drivers/infiniband/hw/hfi1/user_exp_rcv.c          |   16 +-
 drivers/infiniband/hw/hfi1/user_pages.c            |    5 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |   22 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |  153 +-
 drivers/infiniband/hw/hfi1/verbs.h                 |   15 +-
 drivers/infiniband/hw/hfi1/vnic.h                  |  184 +++
 drivers/infiniband/hw/hfi1/vnic_main.c             |  907 +++++++++++
 drivers/infiniband/hw/hfi1/vnic_sdma.c             |  323 ++++
 drivers/infiniband/hw/hns/hns_roce_ah.c            |   62 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.c           |    6 +-
 drivers/infiniband/hw/hns/hns_roce_cq.c            |    3 +-
 drivers/infiniband/hw/hns/hns_roce_device.h        |    5 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         |  119 +-
 drivers/infiniband/hw/hns/hns_roce_mr.c            |   20 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c            |    3 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |    5 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |   10 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |   12 +-
 drivers/infiniband/hw/mlx4/ah.c                    |  134 +-
 drivers/infiniband/hw/mlx4/cm.c                    |   10 +-
 drivers/infiniband/hw/mlx4/cq.c                    |    2 +-
 drivers/infiniband/hw/mlx4/mad.c                   |   87 +-
 drivers/infiniband/hw/mlx4/main.c                  |   33 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |   11 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |    6 +-
 drivers/infiniband/hw/mlx4/mr.c                    |    6 +-
 drivers/infiniband/hw/mlx4/qp.c                    |  112 +-
 drivers/infiniband/hw/mlx4/srq.c                   |    2 +-
 drivers/infiniband/hw/mlx5/ah.c                    |   74 +-
 drivers/infiniband/hw/mlx5/cmd.c                   |   11 +
 drivers/infiniband/hw/mlx5/cmd.h                   |    2 +
 drivers/infiniband/hw/mlx5/cq.c                    |   21 +-
 drivers/infiniband/hw/mlx5/mad.c                   |    2 +
 drivers/infiniband/hw/mlx5/main.c                  |  397 +++--
 drivers/infiniband/hw/mlx5/mem.c                   |   13 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   12 +-
 drivers/infiniband/hw/mlx5/mr.c                    |    8 +-
 drivers/infiniband/hw/mlx5/odp.c                   |  344 +++--
 drivers/infiniband/hw/mlx5/qp.c                    |  107 +-
 drivers/infiniband/hw/mthca/mthca_av.c             |   69 +-
 drivers/infiniband/hw/mthca/mthca_cmd.c            |   12 +-
 drivers/infiniband/hw/mthca/mthca_dev.h            |    4 +-
 drivers/infiniband/hw/mthca/mthca_mad.c            |   17 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |    7 +-
 drivers/infiniband/hw/mthca/mthca_qp.c             |   94 +-
 drivers/infiniband/hw/nes/nes_hw.c                 |    7 +-
 drivers/infiniband/hw/nes/nes_mgt.c                |    5 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |   12 +-
 drivers/infiniband/hw/ocrdma/ocrdma.h              |    6 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c           |   64 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.h           |   10 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c           |   23 +-
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c        |    2 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c        |   54 +-
 drivers/infiniband/hw/qedr/main.c                  |   88 +-
 drivers/infiniband/hw/qedr/qedr.h                  |   20 +-
 drivers/infiniband/hw/qedr/qedr_cm.c               |   19 +-
 drivers/infiniband/hw/qedr/qedr_cm.h               |    2 +-
 drivers/infiniband/hw/qedr/verbs.c                 |  240 ++-
 drivers/infiniband/hw/qedr/verbs.h                 |    2 +-
 drivers/infiniband/hw/qib/qib_iba6120.c            |   10 +-
 drivers/infiniband/hw/qib/qib_iba7220.c            |    5 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |   10 +-
 drivers/infiniband/hw/qib/qib_init.c               |   15 +-
 drivers/infiniband/hw/qib/qib_mad.c                |    7 +-
 drivers/infiniband/hw/qib/qib_qp.c                 |    2 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |   31 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   77 +-
 drivers/infiniband/hw/qib/qib_uc.c                 |    6 +-
 drivers/infiniband/hw/qib/qib_ud.c                 |   57 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |   37 +-
 drivers/infiniband/hw/qib/qib_verbs.h              |    4 +-
 drivers/infiniband/hw/usnic/usnic_common_util.h    |   38 +-
 drivers/infiniband/hw/usnic/usnic_ib_sysfs.c       |    1 +
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c       |   48 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h       |    2 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |    8 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c     |   43 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c       |    8 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c    |   30 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h    |    2 +-
 drivers/infiniband/sw/rdmavt/ah.c                  |   39 +-
 drivers/infiniband/sw/rdmavt/ah.h                  |    6 +-
 drivers/infiniband/sw/rdmavt/cq.c                  |    3 +
 drivers/infiniband/sw/rdmavt/mad.c                 |    2 +-
 drivers/infiniband/sw/rdmavt/mcast.c               |   61 +-
 drivers/infiniband/sw/rdmavt/mr.c                  |   57 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   44 +-
 drivers/infiniband/sw/rdmavt/trace.h               |    4 +-
 drivers/infiniband/sw/rdmavt/trace_cq.h            |  127 ++
 drivers/infiniband/sw/rdmavt/trace_rc.h            |  109 ++
 drivers/infiniband/sw/rdmavt/trace_tx.h            |   34 +-
 drivers/infiniband/sw/rxe/Kconfig                  |    1 +
 drivers/infiniband/sw/rxe/Makefile                 |    3 +-
 drivers/infiniband/sw/rxe/rxe.c                    |    6 +-
 drivers/infiniband/sw/rxe/rxe.h                    |   20 +
 drivers/infiniband/sw/rxe/rxe_av.c                 |   32 +-
 drivers/infiniband/sw/rxe/rxe_comp.c               |   14 +-
 drivers/infiniband/sw/rxe/rxe_hw_counters.c        |   78 +
 drivers/infiniband/sw/rxe/rxe_hw_counters.h        |   61 +
 drivers/infiniband/sw/rxe/rxe_icrc.c               |    6 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |   12 +-
 drivers/infiniband/sw/rxe/rxe_mr.c                 |   14 +-
 drivers/infiniband/sw/rxe/rxe_net.c                |   83 +-
 drivers/infiniband/sw/rxe/rxe_qp.c                 |   33 +-
 drivers/infiniband/sw/rxe/rxe_recv.c               |    7 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |    4 +-
 drivers/infiniband/sw/rxe/rxe_resp.c               |    7 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   33 +-
 drivers/infiniband/sw/rxe/rxe_verbs.h              |    9 +
 drivers/infiniband/ulp/Makefile                    |    1 +
 drivers/infiniband/ulp/ipoib/ipoib.h               |   44 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |   73 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |    6 +-
 drivers/infiniband/ulp/ipoib/ipoib_fs.c            |   13 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |  364 ++---
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |  456 ++++--
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |  120 +-
 drivers/infiniband/ulp/ipoib/ipoib_netlink.c       |   13 +-
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c         |   64 +-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c          |   12 +-
 drivers/infiniband/ulp/iser/iser_initiator.c       |    2 +-
 drivers/infiniband/ulp/opa_vnic/Kconfig            |    8 +
 drivers/infiniband/ulp/opa_vnic/Makefile           |    7 +
 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c   |  475 ++++++
 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.h   |  489 ++++++
 drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c |  187 +++
 .../infiniband/ulp/opa_vnic/opa_vnic_internal.h    |  329 ++++
 drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c  |  389 +++++
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c    | 1056
+++++++++++++
 .../infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c  |  390 +++++
 drivers/infiniband/ulp/srp/ib_srp.c                |   13 +-
 drivers/infiniband/ulp/srp/ib_srp.h                |    2 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |    4 +-
 include/linux/mlx4/device.h                        |    3 +-
 include/linux/mlx5/mlx5_ifc.h                      |   28 +-
 include/net/addrconf.h                             |   22 +-
 include/rdma/ib_cm.h                               |   14 +-
 include/rdma/ib_hdrs.h                             |   66 +
 include/rdma/ib_mad.h                              |   40 +-
 include/rdma/ib_marshall.h                         |    6 +-
 include/rdma/ib_pack.h                             |    2 +
 include/rdma/ib_sa.h                               |  304 +++-
 include/rdma/ib_umem.h                             |    8 +-
 include/rdma/ib_umem_odp.h                         |    6 +-
 include/rdma/ib_verbs.h                            |  325 +++-
 include/rdma/opa_addr.h                            |   79 +
 include/rdma/opa_port_info.h                       |    3 +-
 include/rdma/opa_vnic.h                            |  141 ++
 include/rdma/rdma_cm.h                             |    4 +-
 include/rdma/rdma_cm_ib.h                          |    2 +-
 include/rdma/rdma_vt.h                             |   11 +-
 include/rdma/rdmavt_qp.h                           |   18 +-
 include/rdma/uverbs_std_types.h                    |  114 ++
 include/rdma/uverbs_types.h                        |  172 +++
 include/uapi/linux/pci_regs.h                      |    1 +
 include/uapi/rdma/ib_user_verbs.h                  |   11 +
 include/uapi/rdma/vmw_pvrdma-abi.h                 |    4 +-
 net/smc/smc_ib.c                                   |   11 +-
 242 files changed, 14599 insertions(+), 5505 deletions(-)
 create mode 100644 Documentation/infiniband/opa_vnic.txt
 create mode 100644 drivers/infiniband/core/rdma_core.c
 create mode 100644 drivers/infiniband/core/rdma_core.h
 create mode 100644 drivers/infiniband/core/uverbs_std_types.c
 create mode 100644 drivers/infiniband/hw/hfi1/vnic.h
 create mode 100644 drivers/infiniband/hw/hfi1/vnic_main.c
 create mode 100644 drivers/infiniband/hw/hfi1/vnic_sdma.c
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_cq.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_rc.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_hw_counters.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_hw_counters.h
 create mode 100644 drivers/infiniband/ulp/opa_vnic/Kconfig
 create mode 100644 drivers/infiniband/ulp/opa_vnic/Makefile
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.h
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_internal.h
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c
 create mode 100644 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c
 create mode 100644
drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c
 create mode 100644 include/rdma/opa_addr.h
 create mode 100644 include/rdma/opa_vnic.h
 create mode 100644 include/rdma/uverbs_std_types.h
 create mode 100644 include/rdma/uverbs_types.h

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <1490536239.2404.80.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-03-26 14:45           ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-03-26 14:45 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Sun, 2017-03-26 at 09:50 -0400, Doug Ledford wrote:
> 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

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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFx+p+grY-vLzHOmj4VFKvni3eHUmO_hn+AzmHXw2MeUZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-03-26 13:50       ` Doug Ledford
       [not found]         ` <1490536239.2404.80.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-03-26 13:50 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Sat, 2017-03-25 at 15:45 -0700, Linus Torvalds wrote:
> On Sat, Mar 25, 2017 at 11:29 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > 
> > 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.
> 
> 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?

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.

> That's just *odd*. Why am I getting a pull request on a Saturday with
> stuff that was done late Friday night?

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.

> 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?

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.

> 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?

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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1490466578.2404.55.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-03-25 22:45   ` Linus Torvalds
       [not found]     ` <CA+55aFx+p+grY-vLzHOmj4VFKvni3eHUmO_hn+AzmHXw2MeUZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-03-25 22:45 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Sat, Mar 25, 2017 at 11:29 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> 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.

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-03-25 18:29 Doug Ledford
       [not found] ` <1490466578.2404.55.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-03-25 18:29 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-02-24 19:29 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-02-24 19:29 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 20155 bytes --]

Hi Linus,

As promised yesterday, the patch series done by Bart is now ready to
go.  I've prepared for you two options:

1) Take my merge branch.  I took your master from this morning and
merged in my original branch for this work, fixing up merge conflicts
in the merge commit and then adding one new commit because the bnxt_re
driver was not in mainline when Bart did his work and so it was missed.
 This code can be found at:

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

or

2) Take the original series as is and perform the fixups yourself (they
really aren't hard, and I detailed what they were in the log portion of
my merge commit in the above branch).  It can be found at:

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

I just completed the merge, so it hasn't been through 0day or linux-
next (it has passed local build tests though).  The original branch has
been through 0day, but I don't think it went through linux-next as I
don't think Stephen pulls my for-next-* tags, just the base for-next
tag (I've email him to see if we can change that, but haven't heard
back yet).

I'll include the boilerplate that git request-pull spits out from
option #1.  For option #2 it's identical minus my two commits.

The following changes since commit
f1ef09fde17f9b77ca1435a5b53a28b203afb81c:

  Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
(2017-02-23 20:33:51 -0800)

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
87a5da90d0c69de7102a3617115e0bb21e43ebfb:

  RDMA/bnxt_re: Switch from dma_device to dev.parent (2017-02-24
14:04:44 -0500)

----------------------------------------------------------------
Drop IB DMA mapping code and use core DMA code instead

Bart Van Assche noted that the IB DMA mapping code was significantly
similar enough to the core DMA mapping code that with a few changes
it was possible to remove the IB DMA mapping code entirely and
switch the RDMA stack to use the core DMA mapping code.  This resulted
in a nice set of cleanups, but touched the entire tree, and so is being
submitted on its own.

This has been merged up to current master, and fixups for merge
conflicts, as well as adding a patch for the bnxt_re driver which
wasn't
in mainline when Bart did his work, have been done.

----------------------------------------------------------------
Bart Van Assche (37):
      treewide: Constify most dma_map_ops structures
      treewide: Move dma_ops from struct dev_archdata into struct
device
      treewide: Consolidate set_dma_ops() implementations
      treewide: Consolidate get_dma_ops() implementations
      lib/dma-noop: Clarify a comment
      lib/dma-noop: Only build dma_noop_ops for s390 and m32r
      lib/dma-virt: Add dma_virt_ops
      IB/core: Remove ib_dma_*map_single_attrs()
      RDS: IB: Remove an unused structure member
      IB/core: Change the type of an ib_dma_alloc_coherent() argument
      IB/hf1: Remove DMA mapping code
      IB/qib: Remove DMA mapping code
      IB/core: Initialize ib_device.dev.parent earlier
      IB/core: Use dev.parent instead of dma_device
      IB/cxgb3: Set dev.parent instead of dma_device
      IB/cxgb4: Set dev.parent instead of dma_device
      IB/hfi1: Switch from dma_device to dev.parent
      IB/hns: Switch from dma_device to dev.parent
      IB/i40iw: Remove a superfluous assignment statement
      IB/mlx4: Switch from dma_device to dev.parent
      IB/mlx5: Switch from dma_device to dev.parent
      IB/mthca: Switch from dma_device to dev.parent
      IB/nes: Remove a superfluous assignment statement
      IB/ocrdma: Switch from dma_device to dev.parent
      IB/qedr: Switch from dma_device to dev.parent
      IB/qib: Switch from dma_device to dev.parent
      IB/usnic: Switch from dma_device to dev.parent
      IB/vmw_pvrdma: Switch from dma_device to dev.parent
      IB/rxe: Switch from dma_device to dev.parent
      IB/IPoIB: Switch from dma_device to dev.parent
      IB/iser: Switch from dma_device to dev.parent
      IB/srp: Switch from dma_device to dev.parent
      IB/srpt: Modify a debug statement
      RDS: net: Switch from dma_device to dev.parent
      nvme-rdma: Switch from dma_device to dev.parent
      IB/core: Remove ib_device.dma_device
      IB/rxe, IB/rdmavt: Use dma_virt_ops instead of duplicating it

Doug Ledford (2):
      Merge branch 'k.o/for-4.11-dma_ops'
      RDMA/bnxt_re: Switch from dma_device to dev.parent

 arch/alpha/include/asm/dma-mapping.h               |   4 +-
 arch/alpha/kernel/pci-noop.c                       |   4 +-
 arch/alpha/kernel/pci_iommu.c                      |   4 +-
 arch/arc/include/asm/dma-mapping.h                 |   4 +-
 arch/arc/mm/dma.c                                  |   2 +-
 arch/arm/common/dmabounce.c                        |   2 +-
 arch/arm/include/asm/device.h                      |   1 -
 arch/arm/include/asm/dma-mapping.h                 |  20 +--
 arch/arm/mm/dma-mapping.c                          |  22 +--
 arch/arm/xen/mm.c                                  |   4 +-
 arch/arm64/include/asm/device.h                    |   1 -
 arch/arm64/include/asm/dma-mapping.h               |  12 +-
 arch/arm64/mm/dma-mapping.c                        |  14 +-
 arch/avr32/include/asm/dma-mapping.h               |   4 +-
 arch/avr32/mm/dma-coherent.c                       |   2 +-
 arch/blackfin/include/asm/dma-mapping.h            |   4 +-
 arch/blackfin/kernel/dma-mapping.c                 |   2 +-
 arch/c6x/include/asm/dma-mapping.h                 |   4 +-
 arch/c6x/kernel/dma.c                              |   2 +-
 arch/cris/arch-v32/drivers/pci/dma.c               |   2 +-
 arch/cris/include/asm/dma-mapping.h                |   6 +-
 arch/frv/include/asm/dma-mapping.h                 |   4 +-
 arch/frv/mb93090-mb00/pci-dma-nommu.c              |   2 +-
 arch/frv/mb93090-mb00/pci-dma.c                    |   2 +-
 arch/h8300/include/asm/dma-mapping.h               |   4 +-
 arch/h8300/kernel/dma.c                            |   2 +-
 arch/hexagon/include/asm/dma-mapping.h             |   7 +-
 arch/hexagon/kernel/dma.c                          |   4 +-
 arch/ia64/hp/common/hwsw_iommu.c                   |   4 +-
 arch/ia64/hp/common/sba_iommu.c                    |   4 +-
 arch/ia64/include/asm/dma-mapping.h                |   7 +-
 arch/ia64/include/asm/machvec.h                    |   4 +-
 arch/ia64/kernel/dma-mapping.c                     |   4 +-
 arch/ia64/kernel/pci-dma.c                         |  10 +-
 arch/ia64/kernel/pci-swiotlb.c                     |   2 +-
 arch/m32r/Kconfig                                  |   1 +
 arch/m32r/include/asm/device.h                     |   1 -
 arch/m32r/include/asm/dma-mapping.h                |   4 +-
 arch/m68k/include/asm/dma-mapping.h                |   4 +-
 arch/m68k/kernel/dma.c                             |   2 +-
 arch/metag/include/asm/dma-mapping.h               |   4 +-
 arch/metag/kernel/dma.c                            |   2 +-
 arch/microblaze/include/asm/dma-mapping.h          |   4 +-
 arch/microblaze/kernel/dma.c                       |   2 +-
 arch/mips/cavium-octeon/dma-octeon.c               |   4 +-
 arch/mips/include/asm/device.h                     |   5 -
 arch/mips/include/asm/dma-mapping.h                |   9 +-
 .../include/asm/mach-cavium-octeon/dma-coherence.h |   2 +-
 arch/mips/include/asm/netlogic/common.h            |   2 +-
 arch/mips/loongson64/common/dma-swiotlb.c          |   2 +-
 arch/mips/mm/dma-default.c                         |   4 +-
 arch/mips/netlogic/common/nlm-dma.c                |   2 +-
 arch/mips/pci/pci-octeon.c                         |   2 +-
 arch/mn10300/include/asm/dma-mapping.h             |   4 +-
 arch/mn10300/mm/dma-alloc.c                        |   2 +-
 arch/nios2/include/asm/dma-mapping.h               |   4 +-
 arch/nios2/mm/dma-mapping.c                        |   2 +-
 arch/openrisc/include/asm/dma-mapping.h            |   4 +-
 arch/openrisc/kernel/dma.c                         |   2 +-
 arch/parisc/include/asm/dma-mapping.h              |   8 +-
 arch/parisc/kernel/drivers.c                       |   2 +-
 arch/parisc/kernel/pci-dma.c                       |   4 +-
 arch/powerpc/include/asm/device.h                  |   4 -
 arch/powerpc/include/asm/dma-mapping.h             |  14 +-
 arch/powerpc/include/asm/pci.h                     |   4 +-
 arch/powerpc/include/asm/ps3.h                     |   2 +-
 arch/powerpc/include/asm/swiotlb.h                 |   2 +-
 arch/powerpc/kernel/dma-swiotlb.c                  |   2 +-
 arch/powerpc/kernel/dma.c                          |   8 +-
 arch/powerpc/kernel/pci-common.c                   |   6 +-
 arch/powerpc/platforms/cell/iommu.c                |   6 +-
 arch/powerpc/platforms/pasemi/iommu.c              |   2 +-
 arch/powerpc/platforms/pasemi/setup.c              |   2 +-
 arch/powerpc/platforms/powernv/npu-dma.c           |   2 +-
 arch/powerpc/platforms/ps3/system-bus.c            |   8 +-
 arch/powerpc/platforms/pseries/ibmebus.c           |   4 +-
 arch/powerpc/platforms/pseries/vio.c               |   2 +-
 arch/s390/Kconfig                                  |   1 +
 arch/s390/include/asm/device.h                     |   1 -
 arch/s390/include/asm/dma-mapping.h                |   6 +-
 arch/s390/pci/pci.c                                |   2 +-
 arch/s390/pci/pci_dma.c                            |   2 +-
 arch/sh/include/asm/dma-mapping.h                  |   4 +-
 arch/sh/kernel/dma-nommu.c                         |   2 +-
 arch/sh/mm/consistent.c                            |   2 +-
 arch/sparc/include/asm/dma-mapping.h               |  10 +-
 arch/sparc/kernel/iommu.c                          |   4 +-
 arch/sparc/kernel/ioport.c                         |   8 +-
 arch/sparc/kernel/pci_sun4v.c                      |   2 +-
 arch/tile/include/asm/device.h                     |   3 -
 arch/tile/include/asm/dma-mapping.h                |  20 +--
 arch/tile/kernel/pci-dma.c                         |  24 +--
 arch/unicore32/include/asm/dma-mapping.h           |   4 +-
 arch/unicore32/mm/dma-swiotlb.c                    |   2 +-
 arch/x86/include/asm/device.h                      |   5 +-
 arch/x86/include/asm/dma-mapping.h                 |  11 +-
 arch/x86/include/asm/iommu.h                       |   2 +-
 arch/x86/kernel/amd_gart_64.c                      |   2 +-
 arch/x86/kernel/pci-calgary_64.c                   |   6 +-
 arch/x86/kernel/pci-dma.c                          |   4 +-
 arch/x86/kernel/pci-nommu.c                        |   2 +-
 arch/x86/kernel/pci-swiotlb.c                      |   2 +-
 arch/x86/pci/common.c                              |   2 +-
 arch/x86/pci/sta2x11-fixup.c                       |  10 +-
 arch/x86/xen/pci-swiotlb-xen.c                     |   2 +-
 arch/xtensa/include/asm/device.h                   |   4 -
 arch/xtensa/include/asm/dma-mapping.h              |   9 +-
 arch/xtensa/kernel/pci-dma.c                       |   2 +-
 drivers/infiniband/core/device.c                   |   9 +
 drivers/infiniband/core/sysfs.c                    |   2 +-
 drivers/infiniband/core/ucm.c                      |   2 +-
 drivers/infiniband/core/user_mad.c                 |   4 +-
 drivers/infiniband/core/uverbs_main.c              |   2 +-
 drivers/infiniband/hw/bnxt_re/main.c               |   2 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |   2 +-
 drivers/infiniband/hw/cxgb4/provider.c             |   2 +-
 drivers/infiniband/hw/hfi1/dma.c                   | 183 -----------
--------
 drivers/infiniband/hw/hfi1/mad.c                   |   2 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |   2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |   2 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c            |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |   1 -
 drivers/infiniband/hw/mlx4/main.c                  |   2 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |   2 +-
 drivers/infiniband/hw/mlx4/mr.c                    |   6 +-
 drivers/infiniband/hw/mlx5/main.c                  |   2 +-
 drivers/infiniband/hw/mlx5/mr.c                    |   8 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |   2 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |   1 -
 drivers/infiniband/hw/ocrdma/ocrdma_main.c         |   2 +-
 drivers/infiniband/hw/qedr/main.c                  |   2 +-
 drivers/infiniband/hw/qib/qib_dma.c                | 169 -----------
-------
 drivers/infiniband/hw/qib/qib_keys.c               |   5 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |   2 +-
 drivers/infiniband/hw/usnic/usnic_ib_main.c        |   2 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     |   2 +-
 drivers/infiniband/sw/rdmavt/Kconfig               |   1 +
 drivers/infiniband/sw/rdmavt/Makefile              |   2 +-
 drivers/infiniband/sw/rdmavt/dma.c                 | 198 -----------
----------
 drivers/infiniband/sw/rdmavt/dma.h                 |  53 ------
 drivers/infiniband/sw/rdmavt/mr.c                  |   8 +-
 drivers/infiniband/sw/rdmavt/vt.c                  |   4 +-
 drivers/infiniband/sw/rdmavt/vt.h                  |   1 -
 drivers/infiniband/sw/rxe/Kconfig                  |   1 +
 drivers/infiniband/sw/rxe/Makefile                 |   1 -
 drivers/infiniband/sw/rxe/rxe_dma.c                | 183 -----------
--------
 drivers/infiniband/sw/rxe/rxe_loc.h                |   2 -
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   9 +-
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |   2 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |   2 +-
 drivers/infiniband/ulp/iser/iscsi_iser.c           |   2 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |   4 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |   3 +-
 drivers/iommu/amd_iommu.c                          |  10 +-
 drivers/misc/mic/bus/mic_bus.c                     |   4 +-
 drivers/misc/mic/bus/scif_bus.c                    |   4 +-
 drivers/misc/mic/bus/scif_bus.h                    |   2 +-
 drivers/misc/mic/bus/vop_bus.c                     |   2 +-
 drivers/misc/mic/host/mic_boot.c                   |   4 +-
 drivers/nvme/host/rdma.c                           |   2 +-
 drivers/parisc/ccio-dma.c                          |   2 +-
 drivers/parisc/sba_iommu.c                         |   2 +-
 drivers/pci/host/vmd.c                             |   2 +-
 include/linux/device.h                             |   1 +
 include/linux/dma-mapping.h                        |  55 +++---
 include/linux/mic_bus.h                            |   2 +-
 include/rdma/ib_verbs.h                            | 143 ++-----------
--
 include/xen/arm/hypervisor.h                       |   2 +-
 lib/Kconfig                                        |  10 ++
 lib/Makefile                                       |   3 +-
 lib/dma-noop.c                                     |   4 +-
 lib/dma-virt.c                                     |  72 ++++++++
 net/rds/ib.h                                       |   8 +-
 net/rds/ib_mr.h                                    |   1 -
 174 files changed, 435 insertions(+), 1296 deletions(-)
 delete mode 100644 drivers/infiniband/hw/hfi1/dma.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_dma.c
 delete mode 100644 drivers/infiniband/sw/rdmavt/dma.c
 delete mode 100644 drivers/infiniband/sw/rdmavt/dma.h
 delete mode 100644 drivers/infiniband/sw/rxe/rxe_dma.c
 create mode 100644 lib/dma-virt.c

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <CA+55aFzzLKu2SVQ0NG0ixpVftbD_SaK0h9MTrAyHFiaERS524A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-02-23 17:57                   ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-02-23 17:57 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On Thu, 2017-02-23 at 09:53 -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2017 at 9:43 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > 
> > On Thu, 2017-02-23 at 08:39 -0800, Linus Torvalds wrote:
> > > 
> > > 
> > > Ok, I found them.
> > 
> > Not sure which you found, mailing list archive or other.  But they
> > are
> > also in my git repo on the k.o/for-4.11-dma_ops branch.
> 
> I found the latest 26-patch series on lkml from Bart. I'm assuming
> that's at least close to what you have.

That's close.  As a result of review comments, it was split even
further and what's in my tree is a total of 37 patches.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-02-23 17:54 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-02-23 17:54 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 7772 bytes --]

Hi Linus,

As per my previous email, this is the Mellanox specific pull request.
 I kept it separate from the main RDMA pull request because my for-next 
area was based on 4.10-rc3 and the shared Mellanox pull request that
DaveM and I both needed to take required an early snapshot of Dave's
net-next tree to apply properly, so my Mellanox branch was kept
separate so the rest of the code would have a clean starting point.

Here's the boilerplate:

The following changes since commit
bda65b4255ac983ce36a6c0ea6a7794f8e8fcc86:

  Merge tag 'mlx5-4kuar-for-4.11' of
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux (2017-01-
09 17:09:31 -0500)

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
cdbe33d0f82d68ff74f05502a4c26e65ec7e90bb:

  IB/mlx5: Fix configuration of port capabilities (2017-02-15 09:29:37
-0500)

----------------------------------------------------------------
Mellanox specific updates for 4.11 merge window

Because the Mellanox code required being based on a net-next tree,
I keept it separate from the remainder of the RDMA stack submission
that is based on 4.10-rc3.

This branch contains:

- Various mlx4 and mlx5 fixes and minor changes
- Support for adding a tag match rule to flow specs
- Support for cvlan offload operation for raw ethernet QPs
- A change to the core IB code to recognize raw eth capabilities and
  enumerate them (touches non-Mellanox code)
- Implicit On-Demand Paging memory registration support

----------------------------------------------------------------
Artemy Kovalyov (6):
      IB/core: Add implicit MR flag
      IB/umem: Update on demand page (ODP) support
      IB/umem: Indicate that process is being terminated
      IB/mlx5: Add null_mkey access
      IB/mlx5: Expose MR cache for mlx5_ib
      IB/mlx5: Add implicit MR support

Eli Cohen (2):
      IB/mlx5: Fix blue flame buffer size calculation
      IB/mlx5: Fix configuration of port capabilities

Kamal Heib (2):
      IB/mlx5: Verify that Q counters are supported
      IB/mlx5: Expose Q counters groups only if they are supported by
FW

Leon Romanovsky (5):
      IB/mlx5: Fix out-of-bound access
      IB/mlx5: Return error for unsupported signature type
      IB/mlx5: Remove deprecated module parameter
      IB/mlx5: Replace ENOTSUPP usage with EOPNOTSUPP
      IB/mlx4: Remove unused variable from function declaration

Majd Dibbiny (2):
      IB/mlx5: Assign DSCP for R-RoCE QPs Address Path
      IB/mlx5: Add port counter support for Receive WQs

Maor Gottlieb (3):
      IB/mlx5: Add additional checks before processing MADs
      IB/mlx5: Avoid SMP MADs from VFs
      net/mlx5: Consolidate flow rules regardless their flow tag

Moses Reuben (3):
      IB/core: Introduce flow tag specification
      IB/uverbs: Add support for flow tag
      IB/mlx5: Add flow tag support

Noa Osherovich (11):
      IB/core: Expose vlan offloads capabilities
      IB/core: Enable WQ creation and modification with cvlan offload
      IB/core: Enable QP creation with cvlan offload
      IB/core: Add scatter FCS flag to use in WQ creation
      IB/uverbs: Expose vlan offloads capabilities
      IB/uverbs: Enable WQ creation and modification with cvlan offload
      IB/uverbs: Enable QP creation with cvlan offload
      IB/mlx5: Expose vlan offloads capabilities
      IB/mlx5: Enable WQ creation and modification with cvlan offload
      IB/mlx5: Enable QP creation with cvlan offload
      IB/mlx5: Support creation of a WQ with scatter FCS offload

Or Gerlitz (5):
      IB/core: Add raw packet protocol
      IB/mlx5: Support raw packet protocol
      IB/mlx4: Support raw packet protocol
      IB: Add protocol for USNIC
      IB: Query ports via the core instead of direct into the driver

Talat Batheesh (1):
      IB/mlx4: Take source GID by index from HW GID table

 drivers/infiniband/core/umem.c                    |   3 -
 drivers/infiniband/core/umem_odp.c                |  92 +++-
 drivers/infiniband/core/umem_rbtree.c             |  21 +-
 drivers/infiniband/core/uverbs.h                  |   1 +
 drivers/infiniband/core/uverbs_cmd.c              |  53 ++-
 drivers/infiniband/hw/cxgb3/iwch_provider.c       |   7 +-
 drivers/infiniband/hw/cxgb4/provider.c            |   8 +-
 drivers/infiniband/hw/hfi1/verbs.c                |   1 +
 drivers/infiniband/hw/hns/hns_roce_main.c         |   7 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c         |   8 +-
 drivers/infiniband/hw/mlx4/alias_GUID.c           |   1 +
 drivers/infiniband/hw/mlx4/main.c                 |  27 +-
 drivers/infiniband/hw/mlx4/qp.c                   |  56 ++-
 drivers/infiniband/hw/mlx4/sysfs.c                |   1 +
 drivers/infiniband/hw/mlx5/Makefile               |   2 +-
 drivers/infiniband/hw/mlx5/cmd.c                  |  48 ++
 drivers/infiniband/hw/mlx5/cmd.h                  |  40 ++
 drivers/infiniband/hw/mlx5/mad.c                  |  14 +-
 drivers/infiniband/hw/mlx5/main.c                 | 337 ++++++++++++
---
 drivers/infiniband/hw/mlx5/mlx5_ib.h              |  46 +-
 drivers/infiniband/hw/mlx5/mr.c                   | 128 ++++--
 drivers/infiniband/hw/mlx5/odp.c                  | 505
++++++++++++++++++++--
 drivers/infiniband/hw/mlx5/qp.c                   |  91 +++-
 drivers/infiniband/hw/mlx5/srq.c                  |  11 +-
 drivers/infiniband/hw/mthca/mthca_provider.c      |   9 +-
 drivers/infiniband/hw/nes/nes_verbs.c             |   5 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c        |   9 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c       |   1 +
 drivers/infiniband/hw/qedr/verbs.c                |   9 +-
 drivers/infiniband/hw/qib/qib_verbs.c             |   1 +
 drivers/infiniband/hw/usnic/usnic_ib_main.c       |   4 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c      |   2 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c    |   5 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c   |   4 +-
 drivers/infiniband/sw/rdmavt/vt.c                 |   7 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c             |   6 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c |  12 +-
 include/linux/mlx5/driver.h                       |   6 +-
 include/linux/mlx5/mlx5_ifc.h                     |   2 +-
 include/rdma/ib_umem_odp.h                        |  21 +-
 include/rdma/ib_verbs.h                           |  57 ++-
 include/uapi/rdma/ib_user_verbs.h                 |  19 +-
 42 files changed, 1417 insertions(+), 270 deletions(-)
 create mode 100644 drivers/infiniband/hw/mlx5/cmd.c
 create mode 100644 drivers/infiniband/hw/mlx5/cmd.h

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <1487871809.86943.136.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-02-23 17:53               ` Linus Torvalds
       [not found]                 ` <CA+55aFzzLKu2SVQ0NG0ixpVftbD_SaK0h9MTrAyHFiaERS524A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-02-23 17:53 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Thu, Feb 23, 2017 at 9:43 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2017-02-23 at 08:39 -0800, Linus Torvalds wrote:
>>
>> Ok, I found them.
>
> Not sure which you found, mailing list archive or other.  But they are
> also in my git repo on the k.o/for-4.11-dma_ops branch.

I found the latest 26-patch series on lkml from Bart. I'm assuming
that's at least close to what you have.

              Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <CA+55aFyS3P70r4y53gYYr7OPf1rwaR0EJOpvMDZ3LQ=3XHCbqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-02-23 17:43           ` Doug Ledford
       [not found]             ` <1487871809.86943.136.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-02-23 17:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Thu, 2017-02-23 at 08:39 -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2017 at 8:33 AM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > 
> > 
> > Do you have pointers to the actual diff?
> 
> Ok, I found them.

Not sure which you found, mailing list archive or other.  But they are
also in my git repo on the k.o/for-4.11-dma_ops branch.

> > 
> > That doesn't sound very
> > tree-wide, it sounds limited to just rdma, and as such shouldn't
> > impact anybody else.
> 
> Ok, it's somewhat tree-wide, but doesn't look all that conflicting to
> me. I'd rather have those patches early than late.

I'll get those to you tomorrow then.  I pulled these patches on Jan 20,
and as a result of being in their own branch and not in my for-next
area (as per some guidance I received on how to handle these since they
are at least lightly tree-wide), they have developed some merge
conflicts.  It will be cleaner if I send the Mellanox pull request next
so you can process it while I fix up those 3 issues tonight (I have to
run to an appt soon).

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFz6mZUHonfz3qtq17MJNcO+m4m4qspuZzhBG8wPi8Azjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-02-23 16:39       ` Linus Torvalds
       [not found]         ` <CA+55aFyS3P70r4y53gYYr7OPf1rwaR0EJOpvMDZ3LQ=3XHCbqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-02-23 16:39 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Thu, Feb 23, 2017 at 8:33 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> Do you have pointers to the actual diff?

Ok, I found them.

> That doesn't sound very
> tree-wide, it sounds limited to just rdma, and as such shouldn't
> impact anybody else.

Ok, it's somewhat tree-wide, but doesn't look all that conflicting to
me. I'd rather have those patches early than late.

                         Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <1487796701.86943.126.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-02-23 16:33   ` Linus Torvalds
       [not found]     ` <CA+55aFz6mZUHonfz3qtq17MJNcO+m4m4qspuZzhBG8wPi8Azjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2017-02-23 16:33 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Wed, Feb 22, 2017 at 12:51 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> the third is a tree-wide change and per typical policy I was going to
> wait until the end of the merge window and submit it them...

Well, "typical policy" for tree-wide ones is definitely not that some
random crazy driver subsystem does them.

What are these tree-wide ones?

> it's the patch series posted by Bart Van Assche to remove the IB DMA
> ops structs and use the core DMA ops instead

Do you have pointers to the actual diff? That doesn't sound very
tree-wide, it sounds limited to just rdma, and as such shouldn't
impact anybody else.

                Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-02-22 20:51 Doug Ledford
       [not found] ` <1487796701.86943.126.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2017-02-22 20:51 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 21725 bytes --]

Hi Linus,

This is the first of three pull requests this merge window (they are
all ready to go, but they all also needed to wait before being
sent...two of them needed to wait on DaveM's pull request to land, and
the third is a tree-wide change and per typical policy I was going to
wait until the end of the merge window and submit it them...please let
me know if you want me to handle the tree-wide change any differently,
it's the patch series posted by Bart Van Assche to remove the IB DMA
ops structs and use the core DMA ops instead).  This particular pull
request is all of the non-Mellanox and non-tree-wide changes.  Nothing
overly exciting in this one.  There is another new RoCE driver, bnxt_re
(this was why we had to wait on Dave's pull request, we had a
dependency on changes to the bnxt driver in it).  We added a formal
ETH_P_IBOE definition in the core net headers so we would have to hard
code it all over the place.  And lots of miscellaneous updates and
fixes across the tree.

Here's the boilerplate:

> The following changes since
> commit 646ebd4166ca00bdf682a36bd2e1c9a74d848ac6:

  RDMA: Don't reference kernel private header from UAPI header (2017-
02-08 12:28:49 -0500)

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
db690328a7df0b507f7d59de0c7e1bbe8f4b9e6a:

  RDMA/bnxt_re: fix for "bnxt_en: Update to firmware interface spec
1.7.0." (2017-02-22 15:40:17 -0500)

----------------------------------------------------------------
First set of updates for 4.11 kernel merge window

- Add new Broadcom bnxt_re RoCE driver
- rxe driver updates
- ioctl cleanups
- ETH_P_IBOE declaration cleanup
- IPoIB changes
- Add port state cache
- Allow srpt driver to accept guids as port names in config
- Update to hfi1 driver
- Update to srp driver
- Lots of misc. minor changes all over

----------------------------------------------------------------
Amrani, Ram (1):
      RDMA/qedr: restructure functions that create/destroy QPs

Arnd Bergmann (3):
      IB/hfi1: use size_t for passing array length
      IB/hns: include linux/module.h
      RDMA/bnxt_re: add DCB dependency

Bart Van Assche (24):
      IB/rxe: Suppress sparse warnings
      IB/rxe: Constify the pool name
      IB/rxe: Remove an unused function
      IB/rxe: Remove an unused variable and an unused argument
      IB/rxe: Remove superfluous casts
      IB/rxe: Enable type checking on SKB_TO_PKT() and PKT_TO_SKB()
arguments
      IB/rxe: Let the compiler check the type of the cleanup functions
      IB/rxe: Issue warnings once
      IB/rxe: Add a runtime check in alloc_index()
      IB/rxe: Introduce functions for queue draining
      IB/rxe: Generate a completion for all failed work requests
      IB/rxe: Fix a MR reference leak in check_rkey()
      IB/rxe: Fix reference leaks in memory key invalidation code
      IB/rxe: Remove a pointless indirection layer
      IB/rxe: Fix an skb leak
      IB/srpt: Accept GUIDs as port names
      IB/SRP: Avoid using IB_MR_TYPE_SG_GAPS
      IB/srp: Avoid that duplicate responses trigger a kernel bug
      IB/srp: Fix race conditions related to task management
      IB/srp: Document locking conventions
      IB/srp: Make a diagnostic message more informative
      IB/srp: Improve an error path
      IB/core: Add support for draining IB_POLL_DIRECT completion
queues
      IB/srp: Drain the send queue before destroying a QP

Brian Welty (5):
      IB/hfi1, qib, rdmavt: Move two IB event functions into rdmavt
      IB/hfi1, qib, rdmavt: Move AETH credit functions into rdmavt
      IB/hfi1, rdmavt: Update copy_sge to use boolean arguments
      IB/hfi1, rdmavt: Move SGE state helper routines into rdmavt
      IB/qib: Updates to use rdmavt's SGE helper routines

Cao jin (2):
      RDMA/qib: drop qib_pci_link_reset()
      RDMA/hfi1: drop pci_link_reset()

Christoph Hellwig (2):
      IB/mthca: switch to pci_alloc_irq_vectors
      vmw_pvrdma: switch to pci_alloc_irq_vectors

Christophe Jaillet (2):
      IB/cma: Fix reversed test
      RDMA/qedr: Fix some error handling

Colin Ian King (1):
      IB/isert: fix spelling mistake: "teminating" -> "terminating"

Dan Carpenter (1):
      i40iw: fix some indenting in i40iw_sc_vsi_init()

Don Hiatt (2):
      IB/hfi1: Add rvt_rnr_tbl_to_usec function
      IB/hfi1, qib, rdmavt: Move AETH defines to rdma/ib_hdrs.h

Doug Ledford (1):
      Merge branch 'k.o/for-4.10-rc' into HEAD

Easwar Hariharan (1):
      IB/hfi1: Use static CTLE with Preset 6 for integrated HFIs

Erez Shitrit (1):
      IB/IPoIB: Add destination address when re-queue packet

Feras Daoud (9):
      IB/ipoib: When given an invalid UD MTU, give debug msg
      IB/ipoib: Set device connection mode only when needed
      IB/ipoib: Fix deadlock over vlan_mutex
      IB/ipoib: Fix deadlock between rmmod and set_mode
      IB/ipoib: rtnl_unlock can not come after free_netdev
      IB/ipoib: Add detailed error message to dev_queue_xmit call
      IB/ipoib: Use debug prints instead of warnings in RNR WC status
      IB/ipoib: Replace list_del of the neigh->list with list_del_init
      IB/ipoib: Change list_del to list_del_init in the tx object

Ganesh Goudar (2):
      iw_cxgb4: Guard against null cm_id in dump_ep/qp
      iw_cxgb4: clean up send_connect()

Geliang Tang (1):
      RDMA/qib: use rb_entry()

Jack Wang (5):
      RDMA/core: add port state cache
      RDMA/core: export ib_get_cached_port_state
      RDMA/cma: resolve to first active ib port
      RDMA/cma: use cached port state when bind loopback
      RDMA/core: create struct ib_port_cache

Jakub Byczkowski (1):
      IB/hfi1: Modify logging frequency of DCC errors

Jason Gunthorpe (1):
      RDMA/core: Fix incorrect structure packing for booleans

Kees Cook (2):
      RDMA/nes: use designated initializers
      RDMA/i40iw: use designated initializers

Leon Romanovsky (7):
      RDMA/core: Commonize RDMA IOCTL declarations location
      RDMA/core: Move legacy MAD IOCTL declarations to common file
      RDMA/hfi1: Avoid redeclaration error
      RDMA/core: Move HFI1 IOCTL declarations to common file
      RDMA/core: Rename RDMA magic number
      RDMA/core: Unify style of IOCTL commands
      IB/qib: Remove empty function

Majd Dibbiny (1):
      IB/cma: Add default RoCE TOS to CMA configfs

Max Gurtovoy (1):
      IB/iser: Protect completion context active_qps update

Michael J. Ruhl (2):
      IB/hfi1: Do not set physical link state if DC is in the shutdown
state
      IB/hfi1: Code reuse with memdup_copy

Mike Marciniszyn (6):
      IB/hfi1: Correct defered count after processing qp_wait_list
      IB/hfi1: Process qp wait list in IRQ thread periodically
      IB/hfi1: Ensure read of producer s_head is correct
      IB/hfi1: Correct error calldown locking
      IB/hfi1: Add additional fields to qp_stats
      IB/rdmavt, IB/hfi1, IB/qib: Correct ack count for passive (RTR)
QPs

Moni Shoua (3):
      IB/cma: Add debug messages to error flows
      IB/cma: Allow port reuse for rdma_id
      IB/cma: Destination and source addr families must match

Parav Pandit (1):
      IB/core: Remove pointer casting from void to net_device

Sebastian Sanchez (5):
      IB/hfi1: Access hfi1_ibport through rcd pointer
      IB/rdmavt: Use per-CPU reference count for MRs
      IB/hfi1: Allocate context data on memory node
      IB/hfi1: Reduce oversized fields in struct hfi1_packet
      IB/hfi1: Check upper-case EFI variables

Selvin Xavier (3):
      RDMA: Adding ethertype ETH_P_IBOE
      RDMA/bnxt_re: Add bnxt_re RoCE driver
      RDMA/bnxt_re: Add bnxt_re driver build support

Shiraz Saleem (1):
      i40iw: Set maj_err and min_err in i40iw_sc_cqp_create

Stephen Rothwell (1):
      RDMA/bnxt_re: fix for "bnxt_en: Update to firmware interface spec
1.7.0."

Steve Wise (1):
      rdma_cm: fail iwarp accepts w/o connection params

Venkata Sandeep Dhanalakota (3):
      IB/rdmavt: Adding timer logic to rdmavt
      IB/hfi1: Use new rdmavt timers
      IB/qib: Use new rdmavt timers

Wei Yongjun (1):
      IB/rxe: use setup_timer to simplify the code

Yuval Shaia (5):
      IB/core: Fix typo in comment
      IB/vmw_pvrdma: Remove unused qp_type
      IB/mad: Add port_num to error message
      IB/core: Add inline function to validate port
      IB/vmw_pvrdma: Expose vendor error to ULPs

Zhu Yanjun (5):
      IB/ipoib: Remove unnecessary returned value check
      IB/ipoib: function interface change
      IB/ipoib: Remove the unnecessary error check
      IB/ipoib: remove the unnecessary memory free
      IB/ipoib: Remove redudant label

ssh10 (2):
      RDMA/cxgb4: Use AF_INET for sin_family field
      RDMA/ocrdma: Replace BUG() with BUG_ON()

 Documentation/ABI/testing/configfs-rdma_cm         |    8 +
 MAINTAINERS                                        |   11 +
 drivers/infiniband/Kconfig                         |    2 +
 drivers/infiniband/core/cache.c                    |  162 +-
 drivers/infiniband/core/cm.c                       |    2 +
 drivers/infiniband/core/cma.c                      |  171 +-
 drivers/infiniband/core/cma_configfs.c             |   42 +
 drivers/infiniband/core/core_priv.h                |    3 +
 drivers/infiniband/core/cq.c                       |    6 +-
 drivers/infiniband/core/device.c                   |    4 +-
 drivers/infiniband/core/mad.c                      |    4 +-
 drivers/infiniband/core/roce_gid_mgmt.c            |   28 +-
 drivers/infiniband/core/verbs.c                    |   38 +-
 drivers/infiniband/hw/Makefile                     |    1 +
 drivers/infiniband/hw/bnxt_re/Kconfig              |    9 +
 drivers/infiniband/hw/bnxt_re/Makefile             |    6 +
 drivers/infiniband/hw/bnxt_re/bnxt_re.h            |  146 +
 drivers/infiniband/hw/bnxt_re/ib_verbs.c           | 3202
++++++++++++++++++++
 drivers/infiniband/hw/bnxt_re/ib_verbs.h           |  197 ++
 drivers/infiniband/hw/bnxt_re/main.c               | 1315 ++++++++
 drivers/infiniband/hw/bnxt_re/qplib_fp.c           | 2167
+++++++++++++
 drivers/infiniband/hw/bnxt_re/qplib_fp.h           |  439 +++
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c         |  694 +++++
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h         |  231 ++
 drivers/infiniband/hw/bnxt_re/qplib_res.c          |  825 +++++
 drivers/infiniband/hw/bnxt_re/qplib_res.h          |  223 ++
 drivers/infiniband/hw/bnxt_re/qplib_sp.c           |  838 +++++
 drivers/infiniband/hw/bnxt_re/qplib_sp.h           |  160 +
 drivers/infiniband/hw/bnxt_re/roce_hsi.h           | 2821
+++++++++++++++++
 drivers/infiniband/hw/cxgb4/cm.c                   |   62 +-
 drivers/infiniband/hw/cxgb4/device.c               |  133 +-
 drivers/infiniband/hw/hfi1/chip.c                  |   38 +-
 drivers/infiniband/hw/hfi1/common.h                |    4 -
 drivers/infiniband/hw/hfi1/debugfs.c               |   39 +-
 drivers/infiniband/hw/hfi1/driver.c                |  125 +-
 drivers/infiniband/hw/hfi1/efivar.c                |   26 +-
 drivers/infiniband/hw/hfi1/hfi.h                   |   18 +-
 drivers/infiniband/hw/hfi1/init.c                  |   17 +-
 drivers/infiniband/hw/hfi1/pcie.c                  |   14 +-
 drivers/infiniband/hw/hfi1/qp.c                    |  177 +-
 drivers/infiniband/hw/hfi1/qp.h                    |   22 -
 drivers/infiniband/hw/hfi1/rc.c                    |  296 +-
 drivers/infiniband/hw/hfi1/ruc.c                   |   55 +-
 drivers/infiniband/hw/hfi1/trace.c                 |    4 +-
 drivers/infiniband/hw/hfi1/uc.c                    |   16 +-
 drivers/infiniband/hw/hfi1/ud.c                    |   18 +-
 drivers/infiniband/hw/hfi1/user_exp_rcv.c          |   17 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |   17 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |  117 +-
 drivers/infiniband/hw/hfi1/verbs.h                 |   24 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |    1 +
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           |  137 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   34 +-
 drivers/infiniband/hw/mlx4/qp.c                    |    6 +-
 drivers/infiniband/hw/mthca/mthca_main.c           |   24 +-
 drivers/infiniband/hw/nes/nes_cm.c                 |   22 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c           |    4 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c           |    3 +-
 drivers/infiniband/hw/ocrdma/ocrdma_sli.h          |    5 -
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c        |   15 +-
 drivers/infiniband/hw/qedr/qedr_cm.c               |    2 +-
 drivers/infiniband/hw/qedr/qedr_cm.h               |    1 -
 drivers/infiniband/hw/qedr/verbs.c                 |  559 ++--
 drivers/infiniband/hw/qib/qib_common.h             |    4 -
 drivers/infiniband/hw/qib/qib_iba7322.c            |    1 -
 drivers/infiniband/hw/qib/qib_pcie.c               |    8 -
 drivers/infiniband/hw/qib/qib_qp.c                 |  135 -
 drivers/infiniband/hw/qib/qib_qsfp.c               |   10 -
 drivers/infiniband/hw/qib/qib_qsfp.h               |    1 -
 drivers/infiniband/hw/qib/qib_rc.c                 |  179 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   47 +-
 drivers/infiniband/hw/qib/qib_uc.c                 |   15 +-
 drivers/infiniband/hw/qib/qib_ud.c                 |    8 +-
 drivers/infiniband/hw/qib/qib_user_sdma.c          |    6 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |   96 +-
 drivers/infiniband/hw/qib/qib_verbs.h              |   10 +-
 drivers/infiniband/hw/usnic/usnic_common_pkt_hdr.h |    1 -
 drivers/infiniband/hw/usnic/usnic_fwd.h            |    3 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |    8 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c       |    2 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h  |    6 -
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     |  162 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c       |    5 +-
 drivers/infiniband/sw/rdmavt/Makefile              |    4 +-
 drivers/infiniband/sw/rdmavt/mr.c                  |   59 +-
 drivers/infiniband/sw/rdmavt/pd.c                  |    2 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |  233 +-
 drivers/infiniband/sw/rdmavt/rc.c                  |  189 ++
 drivers/infiniband/sw/rxe/rxe.c                    |    2 +-
 drivers/infiniband/sw/rxe/rxe_comp.c               |   91 +-
 drivers/infiniband/sw/rxe/rxe_cq.c                 |    4 +-
 drivers/infiniband/sw/rxe/rxe_hdr.h                |   12 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |   29 +-
 drivers/infiniband/sw/rxe/rxe_mcast.c              |    8 +-
 drivers/infiniband/sw/rxe/rxe_mr.c                 |   10 +-
 drivers/infiniband/sw/rxe/rxe_net.c                |   51 +-
 drivers/infiniband/sw/rxe/rxe_pool.c               |   14 +-
 drivers/infiniband/sw/rxe/rxe_pool.h               |    8 +-
 drivers/infiniband/sw/rxe/rxe_qp.c                 |   13 +-
 drivers/infiniband/sw/rxe/rxe_recv.c               |    2 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |   34 +-
 drivers/infiniband/sw/rxe/rxe_resp.c               |   64 +-
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   10 +-
 drivers/infiniband/sw/rxe/rxe_verbs.h              |   24 +-
 drivers/infiniband/ulp/ipoib/ipoib.h               |   10 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |   41 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |   14 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |   77 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |   10 +-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c          |   14 +-
 drivers/infiniband/ulp/iser/iser_verbs.c           |    2 +
 drivers/infiniband/ulp/isert/ib_isert.c            |    2 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |   93 +-
 drivers/infiniband/ulp/srp/ib_srp.h                |    1 +
 drivers/infiniband/ulp/srpt/ib_srpt.c              |  139 +-
 drivers/infiniband/ulp/srpt/ib_srpt.h              |   18 +-
 drivers/target/target_core_tpg.c                   |    1 +
 include/rdma/ib_cache.h                            |   13 +
 include/rdma/ib_hdrs.h                             |    6 +
 include/rdma/ib_sa.h                               |    6 +-
 include/rdma/ib_verbs.h                            |   18 +-
 include/rdma/rdma_vt.h                             |   21 +-
 include/rdma/rdmavt_mr.h                           |   60 +-
 include/rdma/rdmavt_qp.h                           |   46 +
 include/target/target_core_base.h                  |    1 +
 include/uapi/linux/if_ether.h                      |    1 +
 include/uapi/rdma/Kbuild                           |    1 +
 include/uapi/rdma/bnxt_re-abi.h                    |   89 +
 include/uapi/rdma/hfi/Kbuild                       |    1 +
 include/uapi/rdma/hfi/hfi1_ioctl.h                 |  173 ++
 include/uapi/rdma/hfi/hfi1_user.h                  |  175 +-
 include/uapi/rdma/ib_user_mad.h                    |   14 +-
 include/uapi/rdma/rdma_user_ioctl.h                |   87 +
 133 files changed, 15869 insertions(+), 2642 deletions(-)
 create mode 100644 drivers/infiniband/hw/bnxt_re/Kconfig
 create mode 100644 drivers/infiniband/hw/bnxt_re/Makefile
 create mode 100644 drivers/infiniband/hw/bnxt_re/bnxt_re.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/ib_verbs.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/ib_verbs.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/main.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_fp.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_fp.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_res.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_res.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_sp.c
 create mode 100644 drivers/infiniband/hw/bnxt_re/qplib_sp.h
 create mode 100644 drivers/infiniband/hw/bnxt_re/roce_hsi.h
 create mode 100644 drivers/infiniband/sw/rdmavt/rc.c
 create mode 100644 include/uapi/rdma/bnxt_re-abi.h
 create mode 100644 include/uapi/rdma/hfi/hfi1_ioctl.h
 create mode 100644 include/uapi/rdma/rdma_user_ioctl.h

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-02-10 19:42 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-02-10 19:42 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Hi Linus,

This is a very small pull request.  Two security related patches that
you know about, and a compile error problem.

The following changes since commit
b4cfe3971f6eab542dd7ecc398bfa1aeec889934:

  RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled (2017-
01-27 14:29:04 -0500)

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
646ebd4166ca00bdf682a36bd2e1c9a74d848ac6:

  RDMA: Don't reference kernel private header from UAPI header (2017-
02-08 12:28:49 -0500)

----------------------------------------------------------------
Third round of -rc fixes for 4.10 kernel

- Two security related issues in the rxe driver
- One compile issue in the RDMA uapi header

----------------------------------------------------------------
Eyal Itkin (2):
      IB/rxe: Fix resid update
      IB/rxe: Fix mem_check_range integer overflow

Leon Romanovsky (1):
      RDMA: Don't reference kernel private header from UAPI header

 drivers/infiniband/sw/rxe/rxe_mr.c   |  8 +++++---
 drivers/infiniband/sw/rxe/rxe_resp.c |  2 +-
 include/uapi/rdma/ib_user_verbs.h    | 11 ++++++++---
 3 files changed, 14 insertions(+), 7 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2017-01-27 19:52 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2017-01-27 19:52 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 5646 bytes --]

Hi Linus,

This -rc cycle has been slow for the rdma subsystem.  I had already
sent you the first batch before the Holiday break.  After that, we kept
only getting a few here or there.  Up until this week, when I got a
drop of 13 to one driver (qedr).  So, here's the -rc patches I have.  I
currently have none held in reserve, so unless something new comes in,
this is it until the next merge window opens.  Description of patch
breakdown from the tag:

Second round of -rc fixes for 4.10 kernel

- Series of iw_cxgb4 fixes to make it work with the drain cq API
- One or two patches each to: srp, iser, cxgb3, vmw_pvrdma, umem, rxe,
  and ipoib
- One big series (13 patches) for the new qedr driver

The full git request pull boilerplate:

The following changes since commit
a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

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
b4cfe3971f6eab542dd7ecc398bfa1aeec889934:

  RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled (2017-
01-27 14:29:04 -0500)

----------------------------------------------------------------
Second round of -rc fixes for 4.10 kernel

- Series of iw_cxgb4 fixes to make it work with the drain cq API
- One or two patches each to: srp, iser, cxgb3, vmw_pvrdma, umem, rxe,
  and ipoib
- One big series (13 patches) for the new qedr driver

----------------------------------------------------------------
Adit Ranadive (2):
      IB/vmw_pvrdma: Don't leak info from alloc_ucontext
      IB/vmw_pvrdma: Fix incorrect cleanup on pvrdma_pci_probe error
path

Amrani, Ram (3):
      RDMA/core: Add the function ib_mtu_int_to_enum
      RDMA/qedr: Fix MTU returned from QP query
      RDMA/qedr: Add uapi header qedr-abi.h

Israel Rukshin (2):
      IB/srp: fix mr allocation when the device supports sg gaps
      IB/srp: fix invalid indirect_sg_entries parameter value

Jack Morgenstein (1):
      RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled

Kenneth Lee (1):
      IB/umem: Release pid in error and ODP flow

Maor Gottlieb (1):
      IB/rxe: Fix rxe dev insertion to rxe_dev_list

Max Gurtovoy (2):
      IB/iser: Fix sg_tablesize calculation
      IB/iser: remove unused variable from iser_conn struct

Nicolas Iooss (1):
      IB/cxgb3: fix misspelling in header guard

Ram Amrani (10):
      RDMA/qedr: Return success when not changing QP state
      RDMA/qedr: Return max inline data in QP query result
      RDMA/qedr: Remove CQ spinlock from CM completion handlers
      RDMA/qedr: Don't spam dmesg if QP is in error state
      RDMA/qedr: Don't reset QP when queues aren't flushed
      RDMA/qedr: Mark three functions as static
      RDMA/qedr: Fix formatting
      RDMA/qedr: Fix RDMA CM loopback
      RDMA/qedr: Fix and simplify memory leak in PD alloc
      RDMA/qedr: Dispatch port active event from qedr_add

Steve Wise (3):
      iw_cxgb4: refactor sq/rq drain logic
      iw_cxgb4: free EQ queue memory on last deref
      iw_cxgb4: do not send RX_DATA_ACK CPLs after close/abort

Yonatan Cohen (1):
      IB/rxe: Prevent from completer to operate on non valid QP

 drivers/infiniband/core/cma.c                   |   3 +-
 drivers/infiniband/core/umem.c                  |   2 +
 drivers/infiniband/hw/cxgb3/iwch_provider.c     |  11 +-
 drivers/infiniband/hw/cxgb4/cm.c                |   7 +-
 drivers/infiniband/hw/cxgb4/cq.c                |  21 ++--
 drivers/infiniband/hw/cxgb4/device.c            |   9 ++
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h          |  24 +++-
 drivers/infiniband/hw/cxgb4/provider.c          |  33 +++---
 drivers/infiniband/hw/cxgb4/qp.c                | 147 +++++++++++++++-
--------
 drivers/infiniband/hw/cxgb4/t4.h                |   2 +
 drivers/infiniband/hw/i40iw/i40iw_verbs.c       |  11 +-
 drivers/infiniband/hw/nes/nes_verbs.c           |  12 +-
 drivers/infiniband/hw/qedr/main.c               |  23 ++--
 drivers/infiniband/hw/qedr/qedr.h               |   8 +-
 drivers/infiniband/hw/qedr/qedr_cm.c            |  14 +--
 drivers/infiniband/hw/qedr/verbs.c              |  62 ++++++----
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c  |   4 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c |   2 +-
 drivers/infiniband/sw/rxe/rxe_net.c             |   2 +-
 drivers/infiniband/sw/rxe/rxe_qp.c              |   3 +-
 drivers/infiniband/ulp/iser/iscsi_iser.c        |  11 +-
 drivers/infiniband/ulp/iser/iscsi_iser.h        |   2 -
 drivers/infiniband/ulp/iser/iser_verbs.c        |  13 +--
 drivers/infiniband/ulp/srp/ib_srp.c             |  15 ++-
 include/rdma/ib_verbs.h                         |  14 +++
 include/uapi/rdma/Kbuild                        |   1 +
 include/uapi/rdma/cxgb3-abi.h                   |   2 +-
 27 files changed, 269 insertions(+), 189 deletions(-)

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
@ 2017-01-04 13:36 Yuval Shaia
  0 siblings, 0 replies; 186+ messages in thread
From: Yuval Shaia @ 2017-01-04 13:36 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Doug,
My r-b for pvrdma driver is missing.

Yuval

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JuIV5ull1I07UlGfLnhgIGQ5NEA3RtTnx
Content-Type: multipart/mixed; boundary="aQmhCdlFM5GvV4npNCBtkiJ1orSdhujCS";
 protected-headers="v1"
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Torvalds, Linus" <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
 linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Message-ID: <ac96de9c-391b-70df-4c9d-d65d7dc28263-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: [PULL REQUEST] Please pull rdma.git

--aQmhCdlFM5GvV4npNCBtkiJ1orSdhujCS
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Linus,

This is the complete update for the rdma stack for this release cycle.
Most of it is typical driver and core updates, but there is the entirely
new VMWare pvrdma driver.  You may have noticed that there were changes
in DaveM's pull request to the bnxt Ethernet driver to support a RoCE
RDMA driver.  The bnxt_re driver was tentatively set to be pulled in
this release cycle, but it simply wasn't ready in time and was dropped
(a few review comments still to address, and some multi-arch build
issues like prefetch() not working across all arches).

There are two merge conflict issues to be aware of.  Since I have not
merged my -rc pull request from 4.9 into my for-4.10 branch (which I can
do if you would prefer, I didn't do it because of your instructions
before about not liking to see otherwise needless merges), there is a
patch in my 4.9-rc pull request that changed rxe_requestor() and added a
direct return in one location.  A patch in this series then adds ref
counting to the qp in that function.  If you don't know this, you can
miss putting a ref put prior to the direct return when fixing up the
merge conflict.  Other than that, it's a straight forward merge conflict
issue that's easy to resolve.

There was a second merge conflict related to the changes to iterating
netdevs, and on that you simply keep your head and drop anything else.

Here's the boilerplate:

The following changes since commit e37a79e5d4cac3831fac3d4afbf2461f56b4b7=
bd:

  net/mlx5e: Add tc support for FWD rule with counter (2016-10-30
15:43:18 +0200)

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 6f94ba20799b98c8badf047b184fb4cd7bc45e44:

  Merge branch 'vmw_pvrdma' into merge-test (2016-12-14 14:56:21 -0500)

----------------------------------------------------------------
Updates for 4.10 kernel merge window

- Shared mlx5 updates with net stack (will drop out on merge if Dave's
  tree has already been merged)
- Driver updates: cxgb4, hfi1, hns-roce, i40iw, mlx4, mlx5, qedr, rxe
- Debug cleanups
- New connection rejection helpers
- SRP updates
- Various misc fixes
- New paravirt driver from vmware

----------------------------------------------------------------
Adit Ranadive (2):
      vmxnet3: Move PCI Id to pci_ids.h
      IB: Add vmw_pvrdma driver

Alexey Khoroshilov (1):
      IB/isert: do not ignore errors in dma_map_single()

Amrani, Ram (1):
      qede: fix general protection fault may occur on probe

Andrew Boyer (10):
      IB/rxe: Remove buffer used for printing IP address
      IB/rxe: Advance the consumer pointer before posting the CQE
      IB/rxe: Don't update the response PSN unless it's going forwards
      IB/rxe: Unblock loopback by moving skb_out increment
      IB/rxe: Add support for zero-byte operations
      IB/rxe: Add support for IB_CQ_REPORT_MISSED_EVENTS
      IB/rxe: Fix ref leak in rxe_create_qp()
      IB/rxe: Fix ref leak in duplicate_request()
      IB/rxe: Wait for tasklets to finish before tearing down QP
      IB/rxe: Hold refs when running tasklets

Arnd Bergmann (3):
      IB/rxe: avoid putting a large struct rxe_qp on stack
      IB/mlx5: avoid bogus -Wmaybe-uninitialized warning
      IB/mlx4: avoid a -Wmaybe-uninitialize warning

Bart Van Assche (14):
      IB/hfi1: Define platform_config_table_limits once
      IB/srpt: Report login failures only once
      IB/mlx4: Rework special QP creation error path
      IB/mad: Fix an array index check
      IPoIB: Avoid reading an uninitialized member variable
      IB/multicast: Check ib_find_pkey() return value
      IB/srp: Fix CONFIG_DYNAMIC_DEBUG=3Dn build
      IB/srp: Introduce a local variable in srp_add_one()
      IB/srp: Make login failures easier to debug
      IB/srp: Make mapping failures easier to debug
      IB/srp: Make writing the add_target sysfs attr interruptible
      mlx5: Use { } instead of { 0 } to init struct
      mlx5: Remove a set-but-not-used variable
      mlx5, calc_sq_size(): Make a debug message more informative

Bhumika Goyal (1):
      IB/hfi1: constify mmu_notifier_ops structure

Bodong Wang (7):
      IB/mlx5: Report mlx5 multi packet WQE caps during query
      IB/mlx5: Report mlx5 CQE compression caps during query
      IB/mlx5: Add support for CQE compressing
      IB/mlx5: Report mlx5 packet pacing capabilities when querying devic=
e
      IB/core: Support rate limit for packet pacing
      IB/uverbs: Extend modify_qp and support packet pacing
      IB/mlx5: Properly adjust rate limit on QP state transitions

Colin Ian King (1):
      qedr: return -EINVAL if pd is null and avoid null ptr dereference

Dan Carpenter (1):
      IB/rxe: Remove unneeded cast in rxe_srq_from_attr()

Dean Luick (5):
      IB/hfi1: Read new EPROM format
      IB/hfi1: Fix dc8051 multiple qword memory reads
      IB/hfi1: Export 8051 memory and LCB registers via debugfs
      IB/hfi1: Add special setting for low power AOC
      IB/hfi1: Preserve external device completed bit

Dennis Dalessandro (1):
      IB/rdmavt: Fix trace hierarchy

Don Hiatt (1):
      IB/hfi1: Remove dependence on qp->s_cur_size

Doug Ledford (5):
      Merge branches 'chelsio', 'debug-cleanup', 'hns' and 'i40iw' into
merge-test
      Merge branch 'hfi1' into merge-test
      Merge branch 'mlx' into merge-test
      Merge branches 'misc', 'qedr', 'reject-helpers', 'rxe' and 'srp'
into merge-test
      Merge branch 'vmw_pvrdma' into merge-test

Easwar Hariharan (1):
      IB/hfi1: Add active channel and backplane support for integrated
devices

Eli Cohen (3):
      IB/mlx5: Wait for all async command completions to complete
      IB/mlx5: Fix reported max SGE calculation
      IB/mlx5: Avoid system crash when enabling many VFs

Eran Ben Elisha (2):
      IB/mlx4: When no DMFS for IPoIB, don't allow NET_IF QPs
      IB/mlx4: Check if GRH is available before using it

Hal Rosenstock (1):
      IB/mad: Eliminate redundant SM class version defines for OPA

Hans Westgaard Ry (1):
      IB/core: Issue DREQ when receiving REQ/REP for stale QP

Harish Chegondi (1):
      IB/hfi1: Avoid credit return allocation for cpu-less NUMA nodes

Henry Orosco (22):
      i40iw: Add Quality of Service support
      i40iw: Enable message packing
      i40iw: Remove workaround for pre-production errata
      i40iw: Set MAX IRD, MAX ORD size to max supported value
      i40iw: Convert page_size to encoded value
      i40iw: Use vector when creating CQs
      i40iw: Correct values for max_recv_sge, max_send_sge
      i40iw: Fix for LAN handler removal
      i40iw: Optimize inline data copy
      i40iw: Query device accounts for internal rsrc
      i40iw: Remove checks for more than 48 bytes inline data
      i40iw: Remove NULL check for cm_node->iwdev
      i40iw: Use actual page size
      i40iw: Use runtime check for IS_ENABLED(CONFIG_IPV6)
      i40iw: Remove check on return from device_init_pestat()
      i40iw: Remove variable flush_code and check to set qp->sq_flush
      i40iw: Fix incorrect assignment of SQ head
      i40iw: Utilize physically mapped memory regions
      i40iw: Add 2MB page support
      i40iw: Code cleanup, remove check of PBLE pages
      i40iw: Add request for reset on CQP timeout
      i40iw: Reorganize structures to align with HW capabilities

Jack Morgenstein (2):
      IB/mlx4: Handle well-known-gid in mad_demux processing
      IB/mlx4: Fix out-of-range array index in destroy qp flow

Jakub Pawlak (2):
      IB/hfi1: Unify access to GUID entries
      IB/hfi1: Disable header suppression for short packets

Jason Gunthorpe (1):
      rdma UAPI: Use __kernel_sockaddr_storage

Jianxin Xiong (1):
      IB/hfi1: Show statistics counters under IB stats interface

Jim Foraker (1):
      IB/rdmavt: Only put mmap_info ref if it exists

Julia Lawall (1):
      IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

Kamal Heib (1):
      IB/IPoIB: Remove can't use GFP_NOIO warning

Leon Romanovsky (21):
      IB/mad: Remove debug prints after allocation failure
      IB/core: Remove debug prints after allocation failure
      IB/core: Release allocated memory in cache setup failure
      IB/mlx4: Remove debug prints after allocation failure
      IB/mlx5: Remove debug prints after allocation failure
      IB/hfi1: Remove debug prints after allocation failure
      IB/cxgb3: Remove debug prints after allocation failure
      IB/cxgb4: Remove debug prints after allocation failure
      IB/i40iw: Remove debug prints after allocation failure
      IB/qib: Remove debug prints after allocation failure
      IB/nes: Remove debug prints after allocation failure
      IB/mthca: Remove debug prints after allocation failure
      IB/usninc: Remove and fix debug prints after allocation failure
      IB/ocrdma: Remove and fix debug prints after allocation failure
      IB/rxe: Remove and fix debug prints after allocation failure
      IB/isert: Remove and fix debug prints after allocation failure
      IB/ipoib: Remove and fix debug prints after allocation failure
      infiniband: remove WARN that is not kernel bug
      IB/hns: Move HNS RoCE user vendor structures
      net/mlx5: Report multi packet WQE capabilities
      MAINTAINERS: Remove Mitesh Ahuja from emulex maintainers

Lijun Ou (5):
      IB/hns: Add the interface for querying QP1
      IB/hns: add self loopback for CM
      IB/hns: Modify the condition of notifying hardware loopback
      IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()
      IB/hns: Fix the IB device name

Majd Dibbiny (1):
      IB/mlx5: Limit mkey page size to 2GB

Maor Gottlieb (6):
      IB/mlx5: Fix atomic cap in indirect UMR
      IB/mlx5: Put non zero value in max_ah
      IB/mlx4: Set traffic class in AH
      IB/mlx4: Put non zero value in max_ah device attribute
      IB/mlx5: Assign SRQ type earlier
      IB/mlx5: Use u64 for UMR length

Mark Bloch (1):
      IB/core: Save QP in ib_flow structure

Max Gurtovoy (1):
      IB/mlx5: Replace numerical constant with predefined MACRO

Mike Marciniszyn (11):
      IB/hfi1: Add unique txwait_lock for txreq events
      IB/hfi1: Inline sdma_txclean() for verbs pio
      IB/hfi1: Optimize lkey validation structures
      IB/rdmvat: Organize hot path calldowns into a single cacheline
      IB/hfi1: Optimize pio cachelines
      IB/rdmavt: Add trace of MR segs
      IB/rdmavt: Add a send completion helper
      IB/hfi1,IB/qib: Use new send completion helper
      IB/rdmavt: Add swqe mr deref helper
      IB/hfi1,IB/qib: use rvt swqe mr deref helper
      IB/rdmavt, IB/hfi1, IB/qib: Add inlines for mtu division

Mitko Haralanov (1):
      IB/hfi1: Remove usage of qp->s_cur_sge

Moni Shoua (6):
      IB/mlx4: Handle IPv4 header when demultiplexing MAD
      IB/core: Change ib_resolve_eth_dmac to use it in create AH
      IB/mlx5: Report that device has udata response in create_ah
      IB/core: Let create_ah return extended response to user
      IB/mlx5: Use kernel driver to help userspace create ah
      IB/mlx5: Make create/destroy_ah available to userspace

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

Mustafa Ismail (7):
      i40iw: Add missing cleanup on device close
      i40iw: Add IP addr handling on netdev events
      i40iw: Replace list_for_each_entry macro with safe version
      i40iw: Fix double free of QP
      i40iw: Fix memory leak in CQP destroy when in reset
      i40iw: Assign MSS only when it is a new MTU
      i40iw: Fix incorrect check for error

Or Gerlitz (3):
      IB/mlx5: Refactor registration to netdev notifier
      IB/mlx5: Rename RoCE related helpers to reflect being Eth ones
      IB/mlx5: Support RAW Ethernet when RoCE is disabled

Pan Bian (2):
      IB/ocrdma: fix bad initialization
      IB/mlx4: fix improper return value

Petr Mladek (2):
      IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker
      IB/rdmavt: Handle the kthread worker using the new API

Philippe Reynes (1):
      IB/nes: use new api ethtool_{get|set}_link_ksettings

Saeed Mahameed (1):
      IB/mlx4: Fix port query for 56Gb Ethernet links

Salil (1):
      IB/hns: Fix for Checkpatch.pl comment style errors

Sebastian Ott (1):
      IB/core: fix unmap_sg argument

Sebastian Sanchez (8):
      IB/hfi1: Optimize devdata cachelines
      IB/hfi1: Get rid of divide in pio buffer allocator
      IB/hfi1: Optimize pio_buf and send_context structs
      IB/hfi1: Use non-atomic __test_and_clear_bit in hot path
      IB/hfi1: Remove critical section gap in sc_buffer_alloc()
      IB/hfi1: Replace qp->refcount release code with standard driver
wrapper
      IB/hfi1: Use reference count wrapper for MRs
      IB/qib: Use standard refcount wrapper for QPs

Shaobo Xu (3):
      IB/hns: Implement the add_gid/del_gid and optimize the GIDs managem=
ent
      IB/hns: Fix the bug when free mr
      IB/hns: Fix the bug when free cq

Shiraz Saleem (8):
      i40iw: Add NULL check for ibqp event handler
      i40iw: Set TOS field in IP header
      i40iw: Fill in IRD value when on connect request
      i40iw: Correctly fail loopback connection if no listener
      i40iw: Use correct src address in memcpy to rdma stats counters
      i40iw: Fix QP flush to not hang on empty queues or failure
      i40iw: Fix race condition in terminate timer's handler
      MAINTAINERS: Update Intel RDMA RNIC driver maintainers

Souptick Joarder (1):
      IB/mthca: Replace pci_pool_alloc by pci_pool_zalloc

Steve Wise (8):
      rdma_cm: add rdma_reject_msg() helper function
      rdma_cm: add rdma_is_consumer_reject() helper function
      rdma_cm: add rdma_consumer_reject_data helper function
      nvme-rdma: use rdma connection reject helper functions
      ib_iser: log the connection reject message
      rds_rdma: log the connection reject message
      ib_isert: log the connection reject message
      nvmet_rdma: log the connection reject message

Tadeusz Struk (1):
      IB/hfi1: Remove definition of unused hfi1_affinity struct

Thomas Huth (1):
      i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and
I40IW_STAG_INDEX_FROM_STAG

Wei Hu (Xavier) (8):
      IB/hns: Add code for refreshing CQ CI using TPTR
      IB/hns: Optimize the logic of allocating memory using APIs
      IB/hns: Modify the macro for the timeout when cmd process
      IB/hns: Modify query info named port_num when querying RC QP
      IB/hns: Change qpn allocation to round-robin mode.
      IB/hns: Fix the bug when destroy qp
      IB/hns: Fix the bug of setting port mtu
      IB/hns: Delete the redundant memset operation

Wei Yongjun (5):
      iw_cxgb4: Fix error return code in c4iw_rdev_open()
      IB/rxe: Use DEFINE_SPINLOCK() for spinlock
      qedr: Fix possible memory leak in qedr_create_qp()
      qedr: Use list_move_tail instead of list_del/list_add_tail
      qedr: remove pointless NULL check in qedr_post_send()

Yonatan Cohen (1):
      IB/rxe: Increase max number of completions to 32k

Zhouyi Zhou (1):
      infiniband: nes: return value of skb_linearize should be handled

 MAINTAINERS                                        |   13 +-
 drivers/infiniband/Kconfig                         |    1 +
 drivers/infiniband/core/agent.c                    |    1 -
 drivers/infiniband/core/cache.c                    |   16 +-
 drivers/infiniband/core/cm.c                       |   72 +-
 drivers/infiniband/core/cma.c                      |   43 +
 drivers/infiniband/core/core_priv.h                |    3 -
 drivers/infiniband/core/device.c                   |    5 +-
 drivers/infiniband/core/fmr_pool.c                 |    1 -
 drivers/infiniband/core/iwcm.c                     |   21 +
 drivers/infiniband/core/iwpm_msg.c                 |    1 -
 drivers/infiniband/core/iwpm_util.c                |   12 +-
 drivers/infiniband/core/mad.c                      |   46 +-
 drivers/infiniband/core/multicast.c                |    7 +-
 drivers/infiniband/core/roce_gid_mgmt.c            |   21 +-
 drivers/infiniband/core/ucm.c                      |    5 +-
 drivers/infiniband/core/ucma.c                     |    5 +-
 drivers/infiniband/core/umem.c                     |    2 +-
 drivers/infiniband/core/uverbs.h                   |    1 +
 drivers/infiniband/core/uverbs_cmd.c               |  229 ++--
 drivers/infiniband/core/uverbs_main.c              |    6 +-
 drivers/infiniband/core/verbs.c                    |  108 +-
 drivers/infiniband/hw/Makefile                     |    1 +
 drivers/infiniband/hw/cxgb3/cxio_dbg.c             |   20 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |    3 +-
 drivers/infiniband/hw/cxgb4/device.c               |    8 +-
 drivers/infiniband/hw/cxgb4/provider.c             |    4 +-
 drivers/infiniband/hw/hfi1/affinity.c              |    3 +-
 drivers/infiniband/hw/hfi1/affinity.h              |    9 +-
 drivers/infiniband/hw/hfi1/chip.c                  |    9 +-
 drivers/infiniband/hw/hfi1/chip_registers.h        |    3 +
 drivers/infiniband/hw/hfi1/debugfs.c               |  110 ++
 drivers/infiniband/hw/hfi1/driver.c                |    3 +-
 drivers/infiniband/hw/hfi1/eprom.c                 |  211 +++-
 drivers/infiniband/hw/hfi1/firmware.c              |  156 ++-
 drivers/infiniband/hw/hfi1/hfi.h                   |  144 ++-
 drivers/infiniband/hw/hfi1/iowait.h                |    8 +
 drivers/infiniband/hw/hfi1/mad.c                   |   31 +-
 drivers/infiniband/hw/hfi1/mmu_rb.c                |    2 +-
 drivers/infiniband/hw/hfi1/pio.c                   |   40 +-
 drivers/infiniband/hw/hfi1/pio.h                   |   38 +-
 drivers/infiniband/hw/hfi1/pio_copy.c              |   22 +-
 drivers/infiniband/hw/hfi1/platform.c              |  193 +++-
 drivers/infiniband/hw/hfi1/platform.h              |  127 +-
 drivers/infiniband/hw/hfi1/qp.c                    |   11 +-
 drivers/infiniband/hw/hfi1/rc.c                    |   60 +-
 drivers/infiniband/hw/hfi1/ruc.c                   |   44 +-
 drivers/infiniband/hw/hfi1/sdma.c                  |   18 +-
 drivers/infiniband/hw/hfi1/sdma.h                  |   12 +-
 drivers/infiniband/hw/hfi1/uc.c                    |    4 +-
 drivers/infiniband/hw/hfi1/ud.c                    |    4 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |   60 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |  209 +++-
 drivers/infiniband/hw/hfi1/verbs.h                 |   16 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.c           |   13 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.h           |    1 +
 drivers/infiniband/hw/hns/hns_roce_ah.c            |    3 +-
 drivers/infiniband/hw/hns/hns_roce_alloc.c         |   11 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.c           |    8 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.h           |   12 +-
 drivers/infiniband/hw/hns/hns_roce_common.h        |   44 +-
 drivers/infiniband/hw/hns/hns_roce_cq.c            |   46 +-
 drivers/infiniband/hw/hns/hns_roce_device.h        |   66 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    6 +-
 drivers/infiniband/hw/hns/hns_roce_hem.c           |    6 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         | 1222
+++++++++++++++++---
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h         |   74 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |  329 ++----
 drivers/infiniband/hw/hns/hns_roce_mr.c            |   43 +-
 drivers/infiniband/hw/hns/hns_roce_pd.c            |    5 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c            |    4 +-
 drivers/infiniband/hw/i40iw/i40iw.h                |   37 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |  377 ++++--
 drivers/infiniband/hw/i40iw/i40iw_cm.h             |   11 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           |  646 +++++++----
 drivers/infiniband/hw/i40iw/i40iw_d.h              |   25 +-
 drivers/infiniband/hw/i40iw/i40iw_hw.c             |   61 +-
 drivers/infiniband/hw/i40iw/i40iw_main.c           |  166 ++-
 drivers/infiniband/hw/i40iw/i40iw_osdep.h          |    8 +-
 drivers/infiniband/hw/i40iw/i40iw_p.h              |   21 +-
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |    4 -
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |  271 +++--
 drivers/infiniband/hw/i40iw/i40iw_puda.h           |   20 +-
 drivers/infiniband/hw/i40iw/i40iw_type.h           |   98 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   40 +-
 drivers/infiniband/hw/i40iw/i40iw_user.h           |   14 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |  289 ++++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |  238 +++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.h          |    2 +
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c       |   33 +-
 drivers/infiniband/hw/mlx4/ah.c                    |   10 +-
 drivers/infiniband/hw/mlx4/alias_GUID.c            |    4 +-
 drivers/infiniband/hw/mlx4/cm.c                    |    4 +-
 drivers/infiniband/hw/mlx4/mad.c                   |   58 +-
 drivers/infiniband/hw/mlx4/main.c                  |   49 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |    5 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |    3 +-
 drivers/infiniband/hw/mlx4/qp.c                    |   13 +-
 drivers/infiniband/hw/mlx5/ah.c                    |   25 +-
 drivers/infiniband/hw/mlx5/cq.c                    |   34 +-
 drivers/infiniband/hw/mlx5/main.c                  |  268 +++--
 drivers/infiniband/hw/mlx5/mem.c                   |    7 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   12 +-
 drivers/infiniband/hw/mlx5/mr.c                    |   71 +-
 drivers/infiniband/hw/mlx5/qp.c                    |  131 ++-
 drivers/infiniband/hw/mlx5/srq.c                   |    6 +-
 drivers/infiniband/hw/mthca/mthca_av.c             |    6 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |    4 +-
 drivers/infiniband/hw/mthca/mthca_reset.c          |    4 -
 drivers/infiniband/hw/nes/nes.c                    |    1 -
 drivers/infiniband/hw/nes/nes_cm.c                 |    4 +-
 drivers/infiniband/hw/nes/nes_hw.c                 |    6 +-
 drivers/infiniband/hw/nes/nes_mgt.c                |   10 +-
 drivers/infiniband/hw/nes/nes_nic.c                |   84 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |    7 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c           |    3 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.h           |    4 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c           |    7 +-
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c        |    4 +-
 drivers/infiniband/hw/qedr/verbs.c                 |   27 +-
 drivers/infiniband/hw/qedr/verbs.h                 |    3 +-
 drivers/infiniband/hw/qib/qib_diag.c               |    6 +-
 drivers/infiniband/hw/qib/qib_driver.c             |    3 +-
 drivers/infiniband/hw/qib/qib_eeprom.c             |    6 +-
 drivers/infiniband/hw/qib/qib_file_ops.c           |    5 +-
 drivers/infiniband/hw/qib/qib_iba6120.c            |    8 +-
 drivers/infiniband/hw/qib/qib_iba7220.c            |    8 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |   22 +-
 drivers/infiniband/hw/qib/qib_init.c               |   47 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |   44 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   24 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |   33 +-
 drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c      |   22 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c       |   16 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h       |    4 +-
 drivers/infiniband/hw/usnic/usnic_vnic.c           |   22 +-
 drivers/infiniband/hw/vmw_pvrdma/Kconfig           |    7 +
 drivers/infiniband/hw/vmw_pvrdma/Makefile          |    3 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |  474 ++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cmd.c      |  119 ++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c       |  425 +++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h  |  586 ++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_doorbell.c |  127 ++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     | 1211
+++++++++++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c     |  304 +++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c       |  334 ++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c       |  972 ++++++++++++++=
++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h     |  131 +++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c    |  579 ++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h    |  436 +++++++
 drivers/infiniband/sw/rdmavt/cq.c                  |   64 +-
 drivers/infiniband/sw/rdmavt/mcast.c               |    5 +-
 drivers/infiniband/sw/rdmavt/mr.c                  |   22 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   20 +-
 drivers/infiniband/sw/rdmavt/trace.h               |  141 +--
 drivers/infiniband/sw/rdmavt/trace_mr.h            |  112 ++
 drivers/infiniband/sw/rdmavt/trace_qp.h            |   96 ++
 drivers/infiniband/sw/rdmavt/trace_rvt.h           |   81 ++
 drivers/infiniband/sw/rdmavt/trace_tx.h            |  132 +++
 drivers/infiniband/sw/rxe/rxe_comp.c               |    9 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |    2 -
 drivers/infiniband/sw/rxe/rxe_mr.c                 |    3 +
 drivers/infiniband/sw/rxe/rxe_net.c                |    8 +-
 drivers/infiniband/sw/rxe/rxe_param.h              |    2 +-
 drivers/infiniband/sw/rxe/rxe_pool.c               |    1 -
 drivers/infiniband/sw/rxe/rxe_recv.c               |   11 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |   19 +-
 drivers/infiniband/sw/rxe/rxe_resp.c               |   25 +-
 drivers/infiniband/sw/rxe/rxe_srq.c                |    2 +-
 drivers/infiniband/sw/rxe/rxe_task.c               |   19 +
 drivers/infiniband/sw/rxe/rxe_task.h               |    1 +
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   21 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |   10 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |    5 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |    5 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |    7 +-
 drivers/infiniband/ulp/iser/iser_verbs.c           |    5 +-
 drivers/infiniband/ulp/isert/ib_isert.c            |   31 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |   48 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |   22 +-
 .../net/ethernet/mellanox/mlx4/resource_tracker.c  |    5 +-
 drivers/net/ethernet/qlogic/qede/qede_roce.c       |    4 +-
 drivers/net/vmxnet3/vmxnet3_int.h                  |    3 +-
 drivers/nvme/host/rdma.c                           |   42 +-
 drivers/nvme/target/rdma.c                         |    3 +
 include/linux/mlx5/mlx5_ifc.h                      |    2 +-
 include/linux/pci_ids.h                            |    1 +
 include/rdma/ib_cm.h                               |    6 +
 include/rdma/ib_mad.h                              |    2 +-
 include/rdma/ib_verbs.h                            |   70 +-
 include/rdma/iw_cm.h                               |    6 +
 include/rdma/opa_smi.h                             |    2 -
 include/rdma/rdma_cm.h                             |   25 +
 include/rdma/rdma_vt.h                             |   46 +-
 include/rdma/rdmavt_mr.h                           |   10 +-
 include/rdma/rdmavt_qp.h                           |   77 ++
 include/uapi/rdma/Kbuild                           |    2 +
 include/uapi/rdma/hfi/hfi1_user.h                  |    2 +-
 .../hns_roce_user.h =3D> include/uapi/rdma/hns-abi.h |    9 +-
 include/uapi/rdma/ib_user_verbs.h                  |   38 +
 include/uapi/rdma/mlx5-abi.h                       |   38 +-
 include/uapi/rdma/rdma_user_cm.h                   |   12 +-
 include/uapi/rdma/vmw_pvrdma-abi.h                 |  289 +++++
 net/rds/rdma_transport.c                           |    5 +-
 204 files changed, 12279 insertions(+), 2657 deletions(-)
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/Kconfig
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/Makefile
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cmd.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_doorbell.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_mr.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_qp.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_rvt.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_tx.h
 rename drivers/infiniband/hw/hns/hns_roce_user.h =3D>
include/uapi/rdma/hns-abi.h (94%)
 create mode 100644 include/uapi/rdma/vmw_pvrdma-abi.h

--=20
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


--aQmhCdlFM5GvV4npNCBtkiJ1orSdhujCS--

--JuIV5ull1I07UlGfLnhgIGQ5NEA3RtTnx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYUsmGAAoJELgmozMOVy/dpV0P/0v2MOlez8U2G5gVE7tUkRIW
aVKGaulH5rzvi82EesDTNxHFsFhKAMEuNIh2JfdBVvbZGicH2DzMWy+/qqGZqoOc
5jNJmF5dPBKbCuKqIWV2cPBGNubOxHW1GFqndrIVl63zisdmQCooe7u1eKlMKrg5
2ALzV4V7rNH0B1wCYHwbizTA4s7kmQ+AvQowB6Nbq6e8WfgKMZzubfvfARqR85BT
PDW98tShP5b7r676xsIIr4HgYSA6IZSonEkTvGXyEHup1yjl2al6zyiv+J8YztPf
GFUptlV7gqwcPv40xXauA2To2pAenrcc9si0USa70knDOWqyAk4RF/7Fyz/iVFz7
ZaAWgmWH+6uU3fgIcU3LYTeukK7ISjDn1CuIQfWarSXxRvM6P5o1So5en9To4Su6
2tJOm4pXYnTlMx655RUMdsQe92YXLXaDAp6Osy2eBCVugmpRy4Gi0dzxu73s3Zv3
kU8hL1jUTt2crUEn3D+7Wroz/3P3vmEzbmTC9uQlLwPXMwHvo6vhuuey/vgf/D9O
yyuwvv0W9LeDLfyQCtlGd+jZbxf++XVZfrOsnFEBYJtvLi87HGz+EKCo5ly988Vu
+UiufZLhxH7iLrw3APIv1xqGVxMoYQeCr5gnlsP+a1eslw/T+ZBSW0iN9aMFMMQK
Iuam1hsXWGQ58gU2/GJy
=5OVt
-----END PGP SIGNATURE-----

--JuIV5ull1I07UlGfLnhgIGQ5NEA3RtTnx--
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-12-22 21:40 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-12-22 21:40 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 3107 bytes --]

Hi Linus,

This is the first 4.10 rc cycle pull request.  There are a smattering of
fixes I have queued up so far.  This can be pulled now or wait until
after the New Year, I just wanted to get this off my plate so I could
enjoy my down time next week ;-)

Here's the boilerplate:

The following changes since commit 6f94ba20799b98c8badf047b184fb4cd7bc45e44:

  Merge branch 'vmw_pvrdma' into merge-test (2016-12-14 14:56:21 -0500)

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 5cc8fabc5e4c588c75a5ec21423e7c3425f69f48:

  IB/rxe: Don't check for null ptr in send() (2016-12-22 11:36:12 -0500)

----------------------------------------------------------------
First round of -rc fixes for 4.10 kernel

- Series of qedr fixes
- Series of rxe fixes
- One isolated i40iw fix
- One isolated cma fix
- One isolated cxgb4 fix

----------------------------------------------------------------
Amrani, Ram (8):
      qedr: configure the number of CQEs on CQ creation
      qedr: return error if destroy CQ failed
      qedr: return correct value on modify qp
      qedr: modify QP state to error when destroying it
      qedr: ignore inline flag in read verbs
      qedr: post_send/recv according to QP state
      qedr: clear the vendor error field in the work completion
      qedr: Always notify the verb consumer of flushed CQEs

Andrew Boyer (3):
      IB/rxe: Use BTH_PSN_MASK when ACKing duplicate sends
      IB/rxe: Drop future atomic/read packets rather than retrying
      IB/rxe: Don't check for null ptr in send()

Bart Van Assche (2):
      IB/rxe: Fix a memory leak in rxe_qp_cleanup()
      IB/cma: Fix a race condition in iboe_addr_get_sgid()

Chien Tin Tung (1):
      i40iw: Set 128B as the only supported RQ WQE size

Steve Wise (1):
      iw_cxgb4: set correct FetchBurstMax for QPs

 drivers/infiniband/hw/cxgb4/qp.c             |  5 ++--
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c     | 25 ++++++++++++++++----
 drivers/infiniband/hw/i40iw/i40iw_puda.c     |  2 +-
 drivers/infiniband/hw/i40iw/i40iw_type.h     |  4 +++-
 drivers/infiniband/hw/i40iw/i40iw_ucontext.h |  4 ++--
 drivers/infiniband/hw/i40iw/i40iw_uk.c       | 17 ++++++++++----
 drivers/infiniband/hw/i40iw/i40iw_user.h     |  4 +++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c    | 21 +++++++++--------
 drivers/infiniband/hw/i40iw/i40iw_verbs.h    |  1 +
 drivers/infiniband/hw/qedr/verbs.c           | 35
++++++++++++++++++++--------
 drivers/infiniband/sw/rxe/rxe_comp.c         |  2 +-
 drivers/infiniband/sw/rxe/rxe_net.c          |  3 +--
 drivers/infiniband/sw/rxe/rxe_qp.c           |  1 +
 drivers/infiniband/sw/rxe/rxe_resp.c         |  3 ++-
 include/rdma/ib_addr.h                       |  6 +++--
 15 files changed, 90 insertions(+), 43 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <ac96de9c-391b-70df-4c9d-d65d7dc28263-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-12-15 20:18   ` Linus Torvalds
  0 siblings, 0 replies; 186+ messages in thread
From: Linus Torvalds @ 2016-12-15 20:18 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

On Thu, Dec 15, 2016 at 8:49 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> tags/for-linus

This adds a new compiler warning, and the compiler is obviously right:
rvt_cq_exit() is completely buggy and cannot possibly work.

I fixed it up in a separate commit, but I'm a bit annoyed.

                 Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-12-15 16:49 Doug Ledford
       [not found] ` <ac96de9c-391b-70df-4c9d-d65d7dc28263-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-12-15 16:49 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 30137 bytes --]

Hi Linus,

This is the complete update for the rdma stack for this release cycle.
Most of it is typical driver and core updates, but there is the entirely
new VMWare pvrdma driver.  You may have noticed that there were changes
in DaveM's pull request to the bnxt Ethernet driver to support a RoCE
RDMA driver.  The bnxt_re driver was tentatively set to be pulled in
this release cycle, but it simply wasn't ready in time and was dropped
(a few review comments still to address, and some multi-arch build
issues like prefetch() not working across all arches).

There are two merge conflict issues to be aware of.  Since I have not
merged my -rc pull request from 4.9 into my for-4.10 branch (which I can
do if you would prefer, I didn't do it because of your instructions
before about not liking to see otherwise needless merges), there is a
patch in my 4.9-rc pull request that changed rxe_requestor() and added a
direct return in one location.  A patch in this series then adds ref
counting to the qp in that function.  If you don't know this, you can
miss putting a ref put prior to the direct return when fixing up the
merge conflict.  Other than that, it's a straight forward merge conflict
issue that's easy to resolve.

There was a second merge conflict related to the changes to iterating
netdevs, and on that you simply keep your head and drop anything else.

Here's the boilerplate:

The following changes since commit e37a79e5d4cac3831fac3d4afbf2461f56b4b7bd:

  net/mlx5e: Add tc support for FWD rule with counter (2016-10-30
15:43:18 +0200)

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 6f94ba20799b98c8badf047b184fb4cd7bc45e44:

  Merge branch 'vmw_pvrdma' into merge-test (2016-12-14 14:56:21 -0500)

----------------------------------------------------------------
Updates for 4.10 kernel merge window

- Shared mlx5 updates with net stack (will drop out on merge if Dave's
  tree has already been merged)
- Driver updates: cxgb4, hfi1, hns-roce, i40iw, mlx4, mlx5, qedr, rxe
- Debug cleanups
- New connection rejection helpers
- SRP updates
- Various misc fixes
- New paravirt driver from vmware

----------------------------------------------------------------
Adit Ranadive (2):
      vmxnet3: Move PCI Id to pci_ids.h
      IB: Add vmw_pvrdma driver

Alexey Khoroshilov (1):
      IB/isert: do not ignore errors in dma_map_single()

Amrani, Ram (1):
      qede: fix general protection fault may occur on probe

Andrew Boyer (10):
      IB/rxe: Remove buffer used for printing IP address
      IB/rxe: Advance the consumer pointer before posting the CQE
      IB/rxe: Don't update the response PSN unless it's going forwards
      IB/rxe: Unblock loopback by moving skb_out increment
      IB/rxe: Add support for zero-byte operations
      IB/rxe: Add support for IB_CQ_REPORT_MISSED_EVENTS
      IB/rxe: Fix ref leak in rxe_create_qp()
      IB/rxe: Fix ref leak in duplicate_request()
      IB/rxe: Wait for tasklets to finish before tearing down QP
      IB/rxe: Hold refs when running tasklets

Arnd Bergmann (3):
      IB/rxe: avoid putting a large struct rxe_qp on stack
      IB/mlx5: avoid bogus -Wmaybe-uninitialized warning
      IB/mlx4: avoid a -Wmaybe-uninitialize warning

Bart Van Assche (14):
      IB/hfi1: Define platform_config_table_limits once
      IB/srpt: Report login failures only once
      IB/mlx4: Rework special QP creation error path
      IB/mad: Fix an array index check
      IPoIB: Avoid reading an uninitialized member variable
      IB/multicast: Check ib_find_pkey() return value
      IB/srp: Fix CONFIG_DYNAMIC_DEBUG=n build
      IB/srp: Introduce a local variable in srp_add_one()
      IB/srp: Make login failures easier to debug
      IB/srp: Make mapping failures easier to debug
      IB/srp: Make writing the add_target sysfs attr interruptible
      mlx5: Use { } instead of { 0 } to init struct
      mlx5: Remove a set-but-not-used variable
      mlx5, calc_sq_size(): Make a debug message more informative

Bhumika Goyal (1):
      IB/hfi1: constify mmu_notifier_ops structure

Bodong Wang (7):
      IB/mlx5: Report mlx5 multi packet WQE caps during query
      IB/mlx5: Report mlx5 CQE compression caps during query
      IB/mlx5: Add support for CQE compressing
      IB/mlx5: Report mlx5 packet pacing capabilities when querying device
      IB/core: Support rate limit for packet pacing
      IB/uverbs: Extend modify_qp and support packet pacing
      IB/mlx5: Properly adjust rate limit on QP state transitions

Colin Ian King (1):
      qedr: return -EINVAL if pd is null and avoid null ptr dereference

Dan Carpenter (1):
      IB/rxe: Remove unneeded cast in rxe_srq_from_attr()

Dean Luick (5):
      IB/hfi1: Read new EPROM format
      IB/hfi1: Fix dc8051 multiple qword memory reads
      IB/hfi1: Export 8051 memory and LCB registers via debugfs
      IB/hfi1: Add special setting for low power AOC
      IB/hfi1: Preserve external device completed bit

Dennis Dalessandro (1):
      IB/rdmavt: Fix trace hierarchy

Don Hiatt (1):
      IB/hfi1: Remove dependence on qp->s_cur_size

Doug Ledford (5):
      Merge branches 'chelsio', 'debug-cleanup', 'hns' and 'i40iw' into
merge-test
      Merge branch 'hfi1' into merge-test
      Merge branch 'mlx' into merge-test
      Merge branches 'misc', 'qedr', 'reject-helpers', 'rxe' and 'srp'
into merge-test
      Merge branch 'vmw_pvrdma' into merge-test

Easwar Hariharan (1):
      IB/hfi1: Add active channel and backplane support for integrated
devices

Eli Cohen (3):
      IB/mlx5: Wait for all async command completions to complete
      IB/mlx5: Fix reported max SGE calculation
      IB/mlx5: Avoid system crash when enabling many VFs

Eran Ben Elisha (2):
      IB/mlx4: When no DMFS for IPoIB, don't allow NET_IF QPs
      IB/mlx4: Check if GRH is available before using it

Hal Rosenstock (1):
      IB/mad: Eliminate redundant SM class version defines for OPA

Hans Westgaard Ry (1):
      IB/core: Issue DREQ when receiving REQ/REP for stale QP

Harish Chegondi (1):
      IB/hfi1: Avoid credit return allocation for cpu-less NUMA nodes

Henry Orosco (22):
      i40iw: Add Quality of Service support
      i40iw: Enable message packing
      i40iw: Remove workaround for pre-production errata
      i40iw: Set MAX IRD, MAX ORD size to max supported value
      i40iw: Convert page_size to encoded value
      i40iw: Use vector when creating CQs
      i40iw: Correct values for max_recv_sge, max_send_sge
      i40iw: Fix for LAN handler removal
      i40iw: Optimize inline data copy
      i40iw: Query device accounts for internal rsrc
      i40iw: Remove checks for more than 48 bytes inline data
      i40iw: Remove NULL check for cm_node->iwdev
      i40iw: Use actual page size
      i40iw: Use runtime check for IS_ENABLED(CONFIG_IPV6)
      i40iw: Remove check on return from device_init_pestat()
      i40iw: Remove variable flush_code and check to set qp->sq_flush
      i40iw: Fix incorrect assignment of SQ head
      i40iw: Utilize physically mapped memory regions
      i40iw: Add 2MB page support
      i40iw: Code cleanup, remove check of PBLE pages
      i40iw: Add request for reset on CQP timeout
      i40iw: Reorganize structures to align with HW capabilities

Jack Morgenstein (2):
      IB/mlx4: Handle well-known-gid in mad_demux processing
      IB/mlx4: Fix out-of-range array index in destroy qp flow

Jakub Pawlak (2):
      IB/hfi1: Unify access to GUID entries
      IB/hfi1: Disable header suppression for short packets

Jason Gunthorpe (1):
      rdma UAPI: Use __kernel_sockaddr_storage

Jianxin Xiong (1):
      IB/hfi1: Show statistics counters under IB stats interface

Jim Foraker (1):
      IB/rdmavt: Only put mmap_info ref if it exists

Julia Lawall (1):
      IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

Kamal Heib (1):
      IB/IPoIB: Remove can't use GFP_NOIO warning

Leon Romanovsky (21):
      IB/mad: Remove debug prints after allocation failure
      IB/core: Remove debug prints after allocation failure
      IB/core: Release allocated memory in cache setup failure
      IB/mlx4: Remove debug prints after allocation failure
      IB/mlx5: Remove debug prints after allocation failure
      IB/hfi1: Remove debug prints after allocation failure
      IB/cxgb3: Remove debug prints after allocation failure
      IB/cxgb4: Remove debug prints after allocation failure
      IB/i40iw: Remove debug prints after allocation failure
      IB/qib: Remove debug prints after allocation failure
      IB/nes: Remove debug prints after allocation failure
      IB/mthca: Remove debug prints after allocation failure
      IB/usninc: Remove and fix debug prints after allocation failure
      IB/ocrdma: Remove and fix debug prints after allocation failure
      IB/rxe: Remove and fix debug prints after allocation failure
      IB/isert: Remove and fix debug prints after allocation failure
      IB/ipoib: Remove and fix debug prints after allocation failure
      infiniband: remove WARN that is not kernel bug
      IB/hns: Move HNS RoCE user vendor structures
      net/mlx5: Report multi packet WQE capabilities
      MAINTAINERS: Remove Mitesh Ahuja from emulex maintainers

Lijun Ou (5):
      IB/hns: Add the interface for querying QP1
      IB/hns: add self loopback for CM
      IB/hns: Modify the condition of notifying hardware loopback
      IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()
      IB/hns: Fix the IB device name

Majd Dibbiny (1):
      IB/mlx5: Limit mkey page size to 2GB

Maor Gottlieb (6):
      IB/mlx5: Fix atomic cap in indirect UMR
      IB/mlx5: Put non zero value in max_ah
      IB/mlx4: Set traffic class in AH
      IB/mlx4: Put non zero value in max_ah device attribute
      IB/mlx5: Assign SRQ type earlier
      IB/mlx5: Use u64 for UMR length

Mark Bloch (1):
      IB/core: Save QP in ib_flow structure

Max Gurtovoy (1):
      IB/mlx5: Replace numerical constant with predefined MACRO

Mike Marciniszyn (11):
      IB/hfi1: Add unique txwait_lock for txreq events
      IB/hfi1: Inline sdma_txclean() for verbs pio
      IB/hfi1: Optimize lkey validation structures
      IB/rdmvat: Organize hot path calldowns into a single cacheline
      IB/hfi1: Optimize pio cachelines
      IB/rdmavt: Add trace of MR segs
      IB/rdmavt: Add a send completion helper
      IB/hfi1,IB/qib: Use new send completion helper
      IB/rdmavt: Add swqe mr deref helper
      IB/hfi1,IB/qib: use rvt swqe mr deref helper
      IB/rdmavt, IB/hfi1, IB/qib: Add inlines for mtu division

Mitko Haralanov (1):
      IB/hfi1: Remove usage of qp->s_cur_sge

Moni Shoua (6):
      IB/mlx4: Handle IPv4 header when demultiplexing MAD
      IB/core: Change ib_resolve_eth_dmac to use it in create AH
      IB/mlx5: Report that device has udata response in create_ah
      IB/core: Let create_ah return extended response to user
      IB/mlx5: Use kernel driver to help userspace create ah
      IB/mlx5: Make create/destroy_ah available to userspace

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

Mustafa Ismail (7):
      i40iw: Add missing cleanup on device close
      i40iw: Add IP addr handling on netdev events
      i40iw: Replace list_for_each_entry macro with safe version
      i40iw: Fix double free of QP
      i40iw: Fix memory leak in CQP destroy when in reset
      i40iw: Assign MSS only when it is a new MTU
      i40iw: Fix incorrect check for error

Or Gerlitz (3):
      IB/mlx5: Refactor registration to netdev notifier
      IB/mlx5: Rename RoCE related helpers to reflect being Eth ones
      IB/mlx5: Support RAW Ethernet when RoCE is disabled

Pan Bian (2):
      IB/ocrdma: fix bad initialization
      IB/mlx4: fix improper return value

Petr Mladek (2):
      IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker
      IB/rdmavt: Handle the kthread worker using the new API

Philippe Reynes (1):
      IB/nes: use new api ethtool_{get|set}_link_ksettings

Saeed Mahameed (1):
      IB/mlx4: Fix port query for 56Gb Ethernet links

Salil (1):
      IB/hns: Fix for Checkpatch.pl comment style errors

Sebastian Ott (1):
      IB/core: fix unmap_sg argument

Sebastian Sanchez (8):
      IB/hfi1: Optimize devdata cachelines
      IB/hfi1: Get rid of divide in pio buffer allocator
      IB/hfi1: Optimize pio_buf and send_context structs
      IB/hfi1: Use non-atomic __test_and_clear_bit in hot path
      IB/hfi1: Remove critical section gap in sc_buffer_alloc()
      IB/hfi1: Replace qp->refcount release code with standard driver
wrapper
      IB/hfi1: Use reference count wrapper for MRs
      IB/qib: Use standard refcount wrapper for QPs

Shaobo Xu (3):
      IB/hns: Implement the add_gid/del_gid and optimize the GIDs management
      IB/hns: Fix the bug when free mr
      IB/hns: Fix the bug when free cq

Shiraz Saleem (8):
      i40iw: Add NULL check for ibqp event handler
      i40iw: Set TOS field in IP header
      i40iw: Fill in IRD value when on connect request
      i40iw: Correctly fail loopback connection if no listener
      i40iw: Use correct src address in memcpy to rdma stats counters
      i40iw: Fix QP flush to not hang on empty queues or failure
      i40iw: Fix race condition in terminate timer's handler
      MAINTAINERS: Update Intel RDMA RNIC driver maintainers

Souptick Joarder (1):
      IB/mthca: Replace pci_pool_alloc by pci_pool_zalloc

Steve Wise (8):
      rdma_cm: add rdma_reject_msg() helper function
      rdma_cm: add rdma_is_consumer_reject() helper function
      rdma_cm: add rdma_consumer_reject_data helper function
      nvme-rdma: use rdma connection reject helper functions
      ib_iser: log the connection reject message
      rds_rdma: log the connection reject message
      ib_isert: log the connection reject message
      nvmet_rdma: log the connection reject message

Tadeusz Struk (1):
      IB/hfi1: Remove definition of unused hfi1_affinity struct

Thomas Huth (1):
      i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and
I40IW_STAG_INDEX_FROM_STAG

Wei Hu (Xavier) (8):
      IB/hns: Add code for refreshing CQ CI using TPTR
      IB/hns: Optimize the logic of allocating memory using APIs
      IB/hns: Modify the macro for the timeout when cmd process
      IB/hns: Modify query info named port_num when querying RC QP
      IB/hns: Change qpn allocation to round-robin mode.
      IB/hns: Fix the bug when destroy qp
      IB/hns: Fix the bug of setting port mtu
      IB/hns: Delete the redundant memset operation

Wei Yongjun (5):
      iw_cxgb4: Fix error return code in c4iw_rdev_open()
      IB/rxe: Use DEFINE_SPINLOCK() for spinlock
      qedr: Fix possible memory leak in qedr_create_qp()
      qedr: Use list_move_tail instead of list_del/list_add_tail
      qedr: remove pointless NULL check in qedr_post_send()

Yonatan Cohen (1):
      IB/rxe: Increase max number of completions to 32k

Zhouyi Zhou (1):
      infiniband: nes: return value of skb_linearize should be handled

 MAINTAINERS                                        |   13 +-
 drivers/infiniband/Kconfig                         |    1 +
 drivers/infiniband/core/agent.c                    |    1 -
 drivers/infiniband/core/cache.c                    |   16 +-
 drivers/infiniband/core/cm.c                       |   72 +-
 drivers/infiniband/core/cma.c                      |   43 +
 drivers/infiniband/core/core_priv.h                |    3 -
 drivers/infiniband/core/device.c                   |    5 +-
 drivers/infiniband/core/fmr_pool.c                 |    1 -
 drivers/infiniband/core/iwcm.c                     |   21 +
 drivers/infiniband/core/iwpm_msg.c                 |    1 -
 drivers/infiniband/core/iwpm_util.c                |   12 +-
 drivers/infiniband/core/mad.c                      |   46 +-
 drivers/infiniband/core/multicast.c                |    7 +-
 drivers/infiniband/core/roce_gid_mgmt.c            |   21 +-
 drivers/infiniband/core/ucm.c                      |    5 +-
 drivers/infiniband/core/ucma.c                     |    5 +-
 drivers/infiniband/core/umem.c                     |    2 +-
 drivers/infiniband/core/uverbs.h                   |    1 +
 drivers/infiniband/core/uverbs_cmd.c               |  229 ++--
 drivers/infiniband/core/uverbs_main.c              |    6 +-
 drivers/infiniband/core/verbs.c                    |  108 +-
 drivers/infiniband/hw/Makefile                     |    1 +
 drivers/infiniband/hw/cxgb3/cxio_dbg.c             |   20 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |    3 +-
 drivers/infiniband/hw/cxgb4/device.c               |    8 +-
 drivers/infiniband/hw/cxgb4/provider.c             |    4 +-
 drivers/infiniband/hw/hfi1/affinity.c              |    3 +-
 drivers/infiniband/hw/hfi1/affinity.h              |    9 +-
 drivers/infiniband/hw/hfi1/chip.c                  |    9 +-
 drivers/infiniband/hw/hfi1/chip_registers.h        |    3 +
 drivers/infiniband/hw/hfi1/debugfs.c               |  110 ++
 drivers/infiniband/hw/hfi1/driver.c                |    3 +-
 drivers/infiniband/hw/hfi1/eprom.c                 |  211 +++-
 drivers/infiniband/hw/hfi1/firmware.c              |  156 ++-
 drivers/infiniband/hw/hfi1/hfi.h                   |  144 ++-
 drivers/infiniband/hw/hfi1/iowait.h                |    8 +
 drivers/infiniband/hw/hfi1/mad.c                   |   31 +-
 drivers/infiniband/hw/hfi1/mmu_rb.c                |    2 +-
 drivers/infiniband/hw/hfi1/pio.c                   |   40 +-
 drivers/infiniband/hw/hfi1/pio.h                   |   38 +-
 drivers/infiniband/hw/hfi1/pio_copy.c              |   22 +-
 drivers/infiniband/hw/hfi1/platform.c              |  193 +++-
 drivers/infiniband/hw/hfi1/platform.h              |  127 +-
 drivers/infiniband/hw/hfi1/qp.c                    |   11 +-
 drivers/infiniband/hw/hfi1/rc.c                    |   60 +-
 drivers/infiniband/hw/hfi1/ruc.c                   |   44 +-
 drivers/infiniband/hw/hfi1/sdma.c                  |   18 +-
 drivers/infiniband/hw/hfi1/sdma.h                  |   12 +-
 drivers/infiniband/hw/hfi1/uc.c                    |    4 +-
 drivers/infiniband/hw/hfi1/ud.c                    |    4 +-
 drivers/infiniband/hw/hfi1/user_sdma.c             |   60 +-
 drivers/infiniband/hw/hfi1/verbs.c                 |  209 +++-
 drivers/infiniband/hw/hfi1/verbs.h                 |   16 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.c           |   13 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.h           |    1 +
 drivers/infiniband/hw/hns/hns_roce_ah.c            |    3 +-
 drivers/infiniband/hw/hns/hns_roce_alloc.c         |   11 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.c           |    8 +-
 drivers/infiniband/hw/hns/hns_roce_cmd.h           |   12 +-
 drivers/infiniband/hw/hns/hns_roce_common.h        |   44 +-
 drivers/infiniband/hw/hns/hns_roce_cq.c            |   46 +-
 drivers/infiniband/hw/hns/hns_roce_device.h        |   66 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    6 +-
 drivers/infiniband/hw/hns/hns_roce_hem.c           |    6 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         | 1222
+++++++++++++++++---
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h         |   74 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |  329 ++----
 drivers/infiniband/hw/hns/hns_roce_mr.c            |   43 +-
 drivers/infiniband/hw/hns/hns_roce_pd.c            |    5 +-
 drivers/infiniband/hw/hns/hns_roce_qp.c            |    4 +-
 drivers/infiniband/hw/i40iw/i40iw.h                |   37 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |  377 ++++--
 drivers/infiniband/hw/i40iw/i40iw_cm.h             |   11 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           |  646 +++++++----
 drivers/infiniband/hw/i40iw/i40iw_d.h              |   25 +-
 drivers/infiniband/hw/i40iw/i40iw_hw.c             |   61 +-
 drivers/infiniband/hw/i40iw/i40iw_main.c           |  166 ++-
 drivers/infiniband/hw/i40iw/i40iw_osdep.h          |    8 +-
 drivers/infiniband/hw/i40iw/i40iw_p.h              |   21 +-
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |    4 -
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |  271 +++--
 drivers/infiniband/hw/i40iw/i40iw_puda.h           |   20 +-
 drivers/infiniband/hw/i40iw/i40iw_type.h           |   98 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   40 +-
 drivers/infiniband/hw/i40iw/i40iw_user.h           |   14 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |  289 ++++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |  238 +++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.h          |    2 +
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c       |   33 +-
 drivers/infiniband/hw/mlx4/ah.c                    |   10 +-
 drivers/infiniband/hw/mlx4/alias_GUID.c            |    4 +-
 drivers/infiniband/hw/mlx4/cm.c                    |    4 +-
 drivers/infiniband/hw/mlx4/mad.c                   |   58 +-
 drivers/infiniband/hw/mlx4/main.c                  |   49 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |    5 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |    3 +-
 drivers/infiniband/hw/mlx4/qp.c                    |   13 +-
 drivers/infiniband/hw/mlx5/ah.c                    |   25 +-
 drivers/infiniband/hw/mlx5/cq.c                    |   34 +-
 drivers/infiniband/hw/mlx5/main.c                  |  268 +++--
 drivers/infiniband/hw/mlx5/mem.c                   |    7 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   12 +-
 drivers/infiniband/hw/mlx5/mr.c                    |   71 +-
 drivers/infiniband/hw/mlx5/qp.c                    |  131 ++-
 drivers/infiniband/hw/mlx5/srq.c                   |    6 +-
 drivers/infiniband/hw/mthca/mthca_av.c             |    6 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |    4 +-
 drivers/infiniband/hw/mthca/mthca_reset.c          |    4 -
 drivers/infiniband/hw/nes/nes.c                    |    1 -
 drivers/infiniband/hw/nes/nes_cm.c                 |    4 +-
 drivers/infiniband/hw/nes/nes_hw.c                 |    6 +-
 drivers/infiniband/hw/nes/nes_mgt.c                |   10 +-
 drivers/infiniband/hw/nes/nes_nic.c                |   84 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |    7 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c           |    3 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.h           |    4 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c           |    7 +-
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c        |    4 +-
 drivers/infiniband/hw/qedr/verbs.c                 |   27 +-
 drivers/infiniband/hw/qedr/verbs.h                 |    3 +-
 drivers/infiniband/hw/qib/qib_diag.c               |    6 +-
 drivers/infiniband/hw/qib/qib_driver.c             |    3 +-
 drivers/infiniband/hw/qib/qib_eeprom.c             |    6 +-
 drivers/infiniband/hw/qib/qib_file_ops.c           |    5 +-
 drivers/infiniband/hw/qib/qib_iba6120.c            |    8 +-
 drivers/infiniband/hw/qib/qib_iba7220.c            |    8 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |   22 +-
 drivers/infiniband/hw/qib/qib_init.c               |   47 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |   44 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   24 +-
 drivers/infiniband/hw/qib/qib_verbs.c              |   33 +-
 drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c      |   22 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c       |   16 +-
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h       |    4 +-
 drivers/infiniband/hw/usnic/usnic_vnic.c           |   22 +-
 drivers/infiniband/hw/vmw_pvrdma/Kconfig           |    7 +
 drivers/infiniband/hw/vmw_pvrdma/Makefile          |    3 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h          |  474 ++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cmd.c      |  119 ++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c       |  425 +++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h  |  586 ++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_doorbell.c |  127 ++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c     | 1211
+++++++++++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c     |  304 +++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c       |  334 ++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c       |  972 ++++++++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h     |  131 +++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c    |  579 ++++++++++
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h    |  436 +++++++
 drivers/infiniband/sw/rdmavt/cq.c                  |   64 +-
 drivers/infiniband/sw/rdmavt/mcast.c               |    5 +-
 drivers/infiniband/sw/rdmavt/mr.c                  |   22 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   20 +-
 drivers/infiniband/sw/rdmavt/trace.h               |  141 +--
 drivers/infiniband/sw/rdmavt/trace_mr.h            |  112 ++
 drivers/infiniband/sw/rdmavt/trace_qp.h            |   96 ++
 drivers/infiniband/sw/rdmavt/trace_rvt.h           |   81 ++
 drivers/infiniband/sw/rdmavt/trace_tx.h            |  132 +++
 drivers/infiniband/sw/rxe/rxe_comp.c               |    9 +-
 drivers/infiniband/sw/rxe/rxe_loc.h                |    2 -
 drivers/infiniband/sw/rxe/rxe_mr.c                 |    3 +
 drivers/infiniband/sw/rxe/rxe_net.c                |    8 +-
 drivers/infiniband/sw/rxe/rxe_param.h              |    2 +-
 drivers/infiniband/sw/rxe/rxe_pool.c               |    1 -
 drivers/infiniband/sw/rxe/rxe_recv.c               |   11 +-
 drivers/infiniband/sw/rxe/rxe_req.c                |   19 +-
 drivers/infiniband/sw/rxe/rxe_resp.c               |   25 +-
 drivers/infiniband/sw/rxe/rxe_srq.c                |    2 +-
 drivers/infiniband/sw/rxe/rxe_task.c               |   19 +
 drivers/infiniband/sw/rxe/rxe_task.h               |    1 +
 drivers/infiniband/sw/rxe/rxe_verbs.c              |   21 +-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c            |   10 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |    5 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |    5 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |    7 +-
 drivers/infiniband/ulp/iser/iser_verbs.c           |    5 +-
 drivers/infiniband/ulp/isert/ib_isert.c            |   31 +-
 drivers/infiniband/ulp/srp/ib_srp.c                |   48 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |   22 +-
 .../net/ethernet/mellanox/mlx4/resource_tracker.c  |    5 +-
 drivers/net/ethernet/qlogic/qede/qede_roce.c       |    4 +-
 drivers/net/vmxnet3/vmxnet3_int.h                  |    3 +-
 drivers/nvme/host/rdma.c                           |   42 +-
 drivers/nvme/target/rdma.c                         |    3 +
 include/linux/mlx5/mlx5_ifc.h                      |    2 +-
 include/linux/pci_ids.h                            |    1 +
 include/rdma/ib_cm.h                               |    6 +
 include/rdma/ib_mad.h                              |    2 +-
 include/rdma/ib_verbs.h                            |   70 +-
 include/rdma/iw_cm.h                               |    6 +
 include/rdma/opa_smi.h                             |    2 -
 include/rdma/rdma_cm.h                             |   25 +
 include/rdma/rdma_vt.h                             |   46 +-
 include/rdma/rdmavt_mr.h                           |   10 +-
 include/rdma/rdmavt_qp.h                           |   77 ++
 include/uapi/rdma/Kbuild                           |    2 +
 include/uapi/rdma/hfi/hfi1_user.h                  |    2 +-
 .../hns_roce_user.h => include/uapi/rdma/hns-abi.h |    9 +-
 include/uapi/rdma/ib_user_verbs.h                  |   38 +
 include/uapi/rdma/mlx5-abi.h                       |   38 +-
 include/uapi/rdma/rdma_user_cm.h                   |   12 +-
 include/uapi/rdma/vmw_pvrdma-abi.h                 |  289 +++++
 net/rds/rdma_transport.c                           |    5 +-
 204 files changed, 12279 insertions(+), 2657 deletions(-)
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/Kconfig
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/Makefile
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cmd.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_doorbell.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_misc.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
 create mode 100644 drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_mr.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_qp.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_rvt.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace_tx.h
 rename drivers/infiniband/hw/hns/hns_roce_user.h =>
include/uapi/rdma/hns-abi.h (94%)
 create mode 100644 include/uapi/rdma/vmw_pvrdma-abi.h

-- 
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                           ` <710f3e81-dd9c-8221-cf5e-7a96f4cad5b9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-20 12:53                             ` Leon Romanovsky
  0 siblings, 0 replies; 186+ messages in thread
From: Leon Romanovsky @ 2016-11-20 12:53 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Or Gerlitz, linux-rdma, Linux Kernel

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

On Sat, Nov 19, 2016 at 06:11:22PM -0500, Doug Ledford wrote:
> On 11/19/2016 2:46 PM, Or Gerlitz wrote:
> > On Fri, Nov 18, 2016 at 4:01 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >> On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> >
> > [...]
> > Are you going to comment on that to the submitter? if not, they are
> > going to continue with this practice.
>
> Comment on what to the submitter?  That the patch might not have been
> -rc material?  I would have been OK with it around rc1 or rc2, just not
> this late in the rc cycle.  In the end, I don't, nor can I, rely on
> submitters to determine what's RC material and what isn't, that's what
> I'm supposed to be doing.  I will always apply my own judgment on that
> issue and submitters will learn over time when their patches get skipped
> on any sort of a regular basis.

And I'm pretty fine with Doug's judgement regarding -rc vs. -next. Our
submission flow meets the expected by RDMA maintainer and we will
continue to work in the same mode as long it suits Doug's expectations
for acceptable/unacceptable submission.

>
> > How are we supposed to realize from patchworks + your github branches
> > that patches that were submitted for 4.9-rc are picked for 4.10? this
> > is very confusing and error prone too.
>
> I emailed the submitters off list about it and provided them a list of
> what patches went where and why.

Thank you, I compared the submitted list with found in your trees and
everything looks in place.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2016-11-19 19:46                       ` Or Gerlitz
@ 2016-11-19 23:11                         ` Doug Ledford
       [not found]                           ` <710f3e81-dd9c-8221-cf5e-7a96f4cad5b9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-11-19 23:11 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: linux-rdma, Linux Kernel

[-- Attachment #1.1: Type: text/plain, Size: 2753 bytes --]

On 11/19/2016 2:46 PM, Or Gerlitz wrote:
> On Fri, Nov 18, 2016 at 4:01 AM, Doug Ledford <dledford@redhat.com> wrote:
>> On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> 
> [...]
> 
>> I agree with you.  It doesn't fix your patch.  The commit message can
>> still be fixed up.
> 
>>> Please do not send it to Linus and wait for them to respond. I
>>> disagree that it fixes my commit b/c my commit was prior to when
>>> route-able RoCE  was introduced and on that time TOS had no relation.
> 
>> I agree.  A better fix tag would be the commit that added RoCEv2 support.
> 
> But this is the smaller part of the problem. The bigger part is that I
> have asked for clarifications on the patch and they didn't provide
> anything.

You asked for clarification on the commit message, I didn't hear any
objections to the content of the patch itself.

> So if you are picking patches where a reviewer comments are
> ignored, what lesson are you teaching the submitter, that he can just
> continue with this practice? why you letting this go that way?

Because I can fix up the log message at any time prior to pulling it
into my official -next branch.  Since that's all you objected to, I can
take the patch and wait for the final version of the comments.  It's not
a big deal Or.

>>> does a tiny enhancement for a 10y old commit of Roland, why you think
>>> we need it in 4.9-rc6 or 7??
> 
>> I don't, it's in the mlx-next branch which means I'll queue it up for
>> the 4.10 merge window.  I have no plan on sending that branch for 4.9-rc.
> 
> Are you going to comment on that to the submitter? if not, they are
> going to continue with this practice.

Comment on what to the submitter?  That the patch might not have been
-rc material?  I would have been OK with it around rc1 or rc2, just not
this late in the rc cycle.  In the end, I don't, nor can I, rely on
submitters to determine what's RC material and what isn't, that's what
I'm supposed to be doing.  I will always apply my own judgment on that
issue and submitters will learn over time when their patches get skipped
on any sort of a regular basis.

> How are we supposed to realize from patchworks + your github branches
> that patches that were submitted for 4.9-rc are picked for 4.10? this
> is very confusing and error prone too.

I emailed the submitters off list about it and provided them a list of
what patches went where and why.

> Please comment also on the bunch of patches I pointed you where the
> copy you have picked into your tree (pulled it from somewhere?) isn't
> what was submitted.

I'm sorry, but you'll have to refresh my memory on this issue.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <fea924a0-f399-8ecf-c039-5cb7c5e0acb8-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-19 19:46                       ` Or Gerlitz
  2016-11-19 23:11                         ` Doug Ledford
  0 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-11-19 19:46 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma, Linux Kernel

On Fri, Nov 18, 2016 at 4:01 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 11/17/2016 5:24 PM, Or Gerlitz wrote:

[...]

> I agree with you.  It doesn't fix your patch.  The commit message can
> still be fixed up.

>> Please do not send it to Linus and wait for them to respond. I
>> disagree that it fixes my commit b/c my commit was prior to when
>> route-able RoCE  was introduced and on that time TOS had no relation.

> I agree.  A better fix tag would be the commit that added RoCEv2 support.

But this is the smaller part of the problem. The bigger part is that I
have asked for clarifications on the patch and they didn't provide
anything. So if you are picking patches where a reviewer comments are
ignored, what lesson are you teaching the submitter, that he can just
continue with this practice? why you letting this go that way?

>> does a tiny enhancement for a 10y old commit of Roland, why you think
>> we need it in 4.9-rc6 or 7??

> I don't, it's in the mlx-next branch which means I'll queue it up for
> the 4.10 merge window.  I have no plan on sending that branch for 4.9-rc.

Are you going to comment on that to the submitter? if not, they are
going to continue with this practice.

How are we supposed to realize from patchworks + your github branches
that patches that were submitted for 4.9-rc are picked for 4.10? this
is very confusing and error prone too.

Please comment also on the bunch of patches I pointed you where the
copy you have picked into your tree (pulled it from somewhere?) isn't
what was submitted.

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <CAJ3xEMjXYYnhS6qUzM9F+yjtq8Aahn08MjsSU4OnLS66Cu7mgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-11-18  2:01                   ` Doug Ledford
       [not found]                     ` <fea924a0-f399-8ecf-c039-5cb7c5e0acb8-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-11-18  2:01 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: linux-rdma, Linux Kernel

[-- Attachment #1.1: Type: text/plain, Size: 4002 bytes --]

On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> On Thu, Nov 17, 2016 at 9:44 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 11/17/16 1:49 PM, Leon Romanovsky wrote:
>>> On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
>>>> Hi Linus,
>>>>
>>>> Due to various issues, I've been away and couldn't send a pull request
>>>> for about three weeks.  There were a number of -rc patches that built up
>>>> in the meantime (some where there already from the early -rc stages).
>>>> Obviously, there were way too many to send now, so I tried to pare the
>>>> list down to the more important patches for the -rc cycle.
> 
> Hi Doug,
> 
> Except for the hfi1 patches, all the rest (core, mlx5, mlx4 and rxe)
> are marked now as only 21 hours old in your 4.9-rc branch and they
> seems be made from you picking partial subsets of multiple series,

Correct.

> with none of them acked by you on the list.

I had an all day meeting today and had to get out the door early.  The
patches will be responded to.

> If you agree that I am describing things correctly - how are we
> expected to follow on your patch picking? I find it sort of impossible
> and error prone.

When I started this I said the official, canonical source of information
on patches like this is patchworks.  That still holds true.  In this
case, I pulled the full series of patches into a single bundle, then
reviewed every patch individually.  I checked for importance and
dependence on other patches.  Those that I thought could be moved to
4.10 were moved into a new bundle and then removed from the existing
bundle.  In this way, the patches were always in one or the other.  When
I was done, I used git am on the two bundles and one into the 4.9-rc and
the other into a -next branch.  In that way I made sure I didn't miss
any from the four series that I pulled.  Finally, I used the bundles to
mark the patches as accepted in patchworks.  By marking the entire
bundles as accepted, and not individual patches, it makes sure that what
I mark accepted is the same as what I ran git am on.  So, if the patch
shows in patchworks as accepted, then I got it.  If it doesn't, then I
missed it.

>>> Are you adding the rest to your for-next branch? We would like to have
>>> enough time to check that nothing is lost.
> 
>> Yes, it's already there in the mlx-next branch on github.
> 
> Re the patches there, this one
> 
> IB/mlx4: Set traffic class in AH
> 
> "Set traffic class within sl_tclass_flowlabel when create iboe AH.
> Without this the TOS value will be empty when running VLAN tagged
> traffic, because the TOS value is taken from the traffic class in the
> address handle attributes.
> 
> Fixes: 9106c41 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE')"
> 
> claims to fix my commit, I have approached Leon and Co for
> clarifications/questions over the list on the patch and nothing was
> answered.

I agree with you.  It doesn't fix your patch.  The commit message can
still be fixed up.

> Please do not send it to Linus and wait for them to respond. I
> disagree that it fixes my commit b/c my commit was prior to when
> route-able RoCE  was introduced and on that time TOS had no relation.

I agree.  A better fix tag would be the commit that added RoCEv2 support.

> and this one
> 
> "IB/mlx4: Put non zero value in max_ah device attribute
> 
> Use INT_MAX since this is the max value the attribute can hold, though
> hardware capability is unlimited.
> 
> Fixes: 225c7b1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')"
> 
> does a tiny enhancement for a 10y old commit of Roland, why you think
> we need it in 4.9-rc6 or 7??

I don't, it's in the mlx-next branch which means I'll queue it up for
the 4.10 merge window.  I have no plan on sending that branch for 4.9-rc.

-- 
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <20161117200203.GQ4240-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-11-17 22:24               ` Or Gerlitz
       [not found]                 ` <CAJ3xEMjXYYnhS6qUzM9F+yjtq8Aahn08MjsSU4OnLS66Cu7mgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-11-17 22:24 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma, Linux Kernel

On Thu, Nov 17, 2016 at 9:44 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 11/17/16 1:49 PM, Leon Romanovsky wrote:
>> On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
>>> Hi Linus,
>>>
>>> Due to various issues, I've been away and couldn't send a pull request
>>> for about three weeks.  There were a number of -rc patches that built up
>>> in the meantime (some where there already from the early -rc stages).
>>> Obviously, there were way too many to send now, so I tried to pare the
>>> list down to the more important patches for the -rc cycle.

Hi Doug,

Except for the hfi1 patches, all the rest (core, mlx5, mlx4 and rxe)
are marked now as only 21 hours old in your 4.9-rc branch and they
seems be made from you picking partial subsets of multiple series,
with none of them acked by you on the list.

If you agree that I am describing things correctly - how are we
expected to follow on your patch picking? I find it sort of impossible
and error prone.

>> Are you adding the rest to your for-next branch? We would like to have
>> enough time to check that nothing is lost.

> Yes, it's already there in the mlx-next branch on github.

Re the patches there, this one

IB/mlx4: Set traffic class in AH

"Set traffic class within sl_tclass_flowlabel when create iboe AH.
Without this the TOS value will be empty when running VLAN tagged
traffic, because the TOS value is taken from the traffic class in the
address handle attributes.

Fixes: 9106c41 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE')"

claims to fix my commit, I have approached Leon and Co for
clarifications/questions over the list on the patch and nothing was
answered.

Please do not send it to Linus and wait for them to respond. I
disagree that it fixes my commit b/c my commit was prior to when
route-able RoCE  was introduced and on that time TOS had no relation.

and this one

"IB/mlx4: Put non zero value in max_ah device attribute

Use INT_MAX since this is the max value the attribute can hold, though
hardware capability is unlimited.

Fixes: 225c7b1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')"

does a tiny enhancement for a 10y old commit of Roland, why you think
we need it in 4.9-rc6 or 7??

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <582E089A.3040106-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-17 20:02           ` Leon Romanovsky
       [not found]             ` <20161117200203.GQ4240-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-11-17 20:02 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Thu, Nov 17, 2016 at 02:44:26PM -0500, Doug Ledford wrote:
> On 11/17/16 1:49 PM, Leon Romanovsky wrote:
> > On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
> >> Hi Linus,
> >>
> >> Due to various issues, I've been away and couldn't send a pull request
> >> for about three weeks.  There were a number of -rc patches that built up
> >> in the meantime (some where there already from the early -rc stages).
> >> Obviously, there were way too many to send now, so I tried to pare the
> >> list down to the more important patches for the -rc cycle.
> >
> > Hi Doug,
> > Are you adding the rest to your for-next branch? We would like to have
> > enough time to check that nothing is lost.
> >
> > Thanks
> >
>
> Yes, it's already there in the mlx-next branch on github.

Thanks,
Do I understand you correctly that it is not final version and you
didn't upload general branch yet?

There is patch for the MAD which will be great to see in the list too.
https://patchwork.kernel.org/patch/9382745/
http://marc.info/?l=linux-rdma&m=147681123708587&w=2

Thanks

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>    GPG Key ID: 0E572FDD
>   Red Hat, Inc.
>   100 E. Davie St
>   Raleigh, NC 27601 USA
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <20161117184950.GP4240-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-11-17 19:44       ` Doug Ledford
       [not found]         ` <582E089A.3040106-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-11-17 19:44 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

On 11/17/16 1:49 PM, Leon Romanovsky wrote:
> On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
>> Hi Linus,
>>
>> Due to various issues, I've been away and couldn't send a pull request
>> for about three weeks.  There were a number of -rc patches that built up
>> in the meantime (some where there already from the early -rc stages).
>> Obviously, there were way too many to send now, so I tried to pare the
>> list down to the more important patches for the -rc cycle.
> 
> Hi Doug,
> Are you adding the rest to your for-next branch? We would like to have
> enough time to check that nothing is lost.
> 
> Thanks
> 

Yes, it's already there in the mlx-next branch on github.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>    GPG Key ID: 0E572FDD
  Red Hat, Inc.
  100 E. Davie St
  Raleigh, NC 27601 USA


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 907 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <58466423-c87e-3921-101e-bffab8989fd8-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-17 18:49   ` Leon Romanovsky
       [not found]     ` <20161117184950.GP4240-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-11-17 18:49 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Thu, Nov 17, 2016 at 07:13:54AM -0500, Doug Ledford wrote:
> Hi Linus,
>
> Due to various issues, I've been away and couldn't send a pull request
> for about three weeks.  There were a number of -rc patches that built up
> in the meantime (some where there already from the early -rc stages).
> Obviously, there were way too many to send now, so I tried to pare the
> list down to the more important patches for the -rc cycle.

Hi Doug,
Are you adding the rest to your for-next branch? We would like to have
enough time to check that nothing is lost.

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-11-17 12:13 Doug Ledford
       [not found] ` <58466423-c87e-3921-101e-bffab8989fd8-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-11-17 12:13 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 6015 bytes --]

Hi Linus,

Due to various issues, I've been away and couldn't send a pull request
for about three weeks.  There were a number of -rc patches that built up
in the meantime (some where there already from the early -rc stages).
Obviously, there were way too many to send now, so I tried to pare the
list down to the more important patches for the -rc cycle.  Most of the
code has had plenty of soak time at the various vendor's testing setups,
so I doubt there will be another -rc pull request this cycle.  I also
tried to limit the patches to those with smaller footprints, so even
though a shortlog is longer than I would like, the actual diffstat is
mostly very small with the exception of just three files that had more
changes, and a couple files with pure removals.  Here's the boilerplate:

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -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 5c6b2aaf9316fd0983c0c999d920306ddc65bd2d:

  iw_cxgb4: invalidate the mr when posting a read_w_inv wr (2016-11-16
20:10:36 -0500)

----------------------------------------------------------------
First round of -rc fixes

- Misc Intel hfi1 fixes
- Misc Mellanox mlx4, mlx5, and rxe fixes
- A couple cxgb4 fixes

----------------------------------------------------------------
Daniel Jurgens (2):
      IB/mlx5: Use cache line size to select CQE stride
      IB/mlx4: Check gid_index return value

Dasaratharaman Chandramouli (1):
      IB/hfi1: Fix ECN processing in prescan_rxq

Dennis Dalessandro (3):
      IB/rdmavt: rdmavt can handle non aligned page maps
      IB/hfi1: Remove leftover snoop references
      IB/hfi1: Remove incorrect IS_ERR check

Doug Ledford (1):
      Merge branches 'hfi1' and 'mlx' into k.o/for-4.9-rc

Easwar Hariharan (2):
      IB/hfi1: Clean up unused argument
      IB/hfi1: Delete unused lock

Eli Cohen (2):
      IB/mlx5: Fix fatal error dispatching
      IB/mlx5: Fix NULL pointer dereference on debug print

Ira Weiny (1):
      IB/hfi1: Fix rnr_timer addition

Jakub Pawlak (2):
      IB/hfi1: Fix integrity check flags default values
      IB/hfi1: Fix status error code for unsupported packets

Jianxin Xiong (2):
      IB/hfi1: Fix a potential memory leak in hfi1_create_ctxts()
      IB/hfi1: Prevent hardware counter names from being cut off

Krzysztof Blaszkowski (2):
      IB/hfi1: Return ENODEV for unsupported PCI device ids.
      IB/hfi1: Relocate rcvhdrcnt module parameter check.

Leon Romanovsky (1):
      IB/core: Set routable RoCE gid type for ipv4/ipv6 networks

Majd Dibbiny (1):
      IB/mlx5: Fix memory leak in query device

Maor Gottlieb (1):
      IB/mlx5: Validate requested RQT size

Mark Bloch (3):
      IB/cm: Mark stale CM id's whenever the mad agent was unregistered
      IB/core: Add missing check for addr_resolve callback return value
      IB/core: Avoid unsigned int overflow in sg_alloc_table

Matan Barak (1):
      IB/mlx4: Fix create CQ error flow

Moshe Lazer (1):
      IB/mlx5: Resolve soft lock on massive reg MRs

Steve Wise (2):
      iw_cxgb4: set *bad_wr for post_send/post_recv errors
      iw_cxgb4: invalidate the mr when posting a read_w_inv wr

Tadeusz Struk (2):
      IB/hfi1: Remove redundant sysfs irq affinity entry
      IB/hfi1: Fix an Oops on pci device force remove

Tariq Toukan (1):
      IB/uverbs: Fix leak of XRC target QPs

Yonatan Cohen (4):
      IB/rxe: Fix kernel panic in UDP tunnel with GRO and RX checksum
      IB/rxe: Fix handling of erroneous WR
      IB/rxe: Clear queue buffer when modifying QP to reset
      IB/rxe: Update qp state for user query

 drivers/infiniband/core/addr.c         |  11 ++-
 drivers/infiniband/core/cm.c           | 126
++++++++++++++++++++++++++++-----
 drivers/infiniband/core/cma.c          |  21 +++++-
 drivers/infiniband/core/umem.c         |   2 +-
 drivers/infiniband/core/uverbs_main.c  |   7 +-
 drivers/infiniband/hw/cxgb4/cq.c       |  17 +----
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h |   2 +-
 drivers/infiniband/hw/cxgb4/mem.c      |  12 ++++
 drivers/infiniband/hw/cxgb4/qp.c       |  20 +++---
 drivers/infiniband/hw/hfi1/affinity.c  |  72 -------------------
 drivers/infiniband/hw/hfi1/affinity.h  |   4 --
 drivers/infiniband/hw/hfi1/chip.c      |  27 +++----
 drivers/infiniband/hw/hfi1/chip.h      |   3 +
 drivers/infiniband/hw/hfi1/driver.c    |  37 +++++++---
 drivers/infiniband/hw/hfi1/file_ops.c  |  19 ++++-
 drivers/infiniband/hw/hfi1/hfi.h       |  89 +++++++++--------------
 drivers/infiniband/hw/hfi1/init.c      | 104 ++++++++++++++++-----------
 drivers/infiniband/hw/hfi1/pcie.c      |   3 +-
 drivers/infiniband/hw/hfi1/pio.c       |  13 +---
 drivers/infiniband/hw/hfi1/rc.c        |   2 +-
 drivers/infiniband/hw/hfi1/sdma.c      |  19 +----
 drivers/infiniband/hw/hfi1/sysfs.c     |  25 -------
 drivers/infiniband/hw/hfi1/trace_rx.h  |  60 ----------------
 drivers/infiniband/hw/hfi1/user_sdma.c |   2 +-
 drivers/infiniband/hw/mlx4/ah.c        |   5 +-
 drivers/infiniband/hw/mlx4/cq.c        |   5 +-
 drivers/infiniband/hw/mlx5/cq.c        |   3 +-
 drivers/infiniband/hw/mlx5/main.c      |  11 +--
 drivers/infiniband/hw/mlx5/mlx5_ib.h   |   2 +
 drivers/infiniband/hw/mlx5/mr.c        |   6 +-
 drivers/infiniband/hw/mlx5/qp.c        |  12 +++-
 drivers/infiniband/sw/rdmavt/dma.c     |   3 -
 drivers/infiniband/sw/rxe/rxe_net.c    |   8 +--
 drivers/infiniband/sw/rxe/rxe_qp.c     |   2 +
 drivers/infiniband/sw/rxe/rxe_queue.c  |   9 +++
 drivers/infiniband/sw/rxe/rxe_queue.h  |   2 +
 drivers/infiniband/sw/rxe/rxe_req.c    |  21 +++---
 37 files changed, 391 insertions(+), 395 deletions(-)

-- 
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-10-04 13:50 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-10-04 13:50 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 7017 bytes --]

Hi Linus,

This is the first pull request of the 4.9 merge window for the RDMA
subsystem.  It is only the hfi1 driver.  It had dependencies on code
that only landed late in the 4.7-rc cycle (around 4.7-rc7), so putting
this with my other for-next code would have create an ugly merge of lot
of 4.7-rc stuff.  For that reason, it's being submitted individually.
It's been through 0day and linux-next.  I'll be sending a different
topic branch through linux-next today and will make a new pull request
once you've picked this one up.  I expect there will be three or four
pull requests this cycle as I'm somewhat splitting things up into these
broad groups:

1) hfi1 driver update (needed late 4.7-rc code)
2) hns-roce driver (new driver, still waiting on last few patch
approvals from netdev@)
3) rest of the core stack (needs to wait until after DaveM's tree has
been pulled because it needed to be based on his net-next tree from
around 4.7-rc4)
4) there are four other brand new drivers on the list undergoing review,
and it's possible some of them might complete review in time to be sent,
if so, they will be separate pull requests

Here's the boilerplate for this pull request:

The following changes since commit e4618d40eb3dc1a6d1f55f7150ea25bb23ab410a:

  IB/rdmavt: Don't vfree a kzalloc'ed memory region (2016-09-16 14:14:23
-0400)

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 61347fa6087884305ea4a3a04501839fdb68dc76:

  IB/rdmavt: Trivial function comment corrected. (2016-10-03 10:55:27 -0400)

----------------------------------------------------------------
First pull request of the 4.9 merge window

- Updates to hfi1 driver

----------------------------------------------------------------
Dean Luick (6):
      IB/hfi1: Move serdes tune inside link start function
      IB/hfi1: Extend i2c timeout
      IB/hfi1: Act on external device timeout
      IB/hfi1: Restore EPROM read ability
      IB/hfi1: Add ability to read platform config from the EPROM
      IB/hfi1: Use EPROM platform configuration read

Dennis Dalessandro (3):
      IB/qib: Remove qpt_mask global
      IB/hfi1: Cleanup tasklet refs in comments
      IB/hfi1: Remove unused variable from devdata

Harish Chegondi (2):
      IB/hfi1: Fix the count of user packets submitted to an SDMA engine
      IB/hfi1: Adjust hardware buffering parameter

Jakub Pawlak (1):
      IB/hfi1: Fix resource release in context allocation

Jianxin Xiong (2):
      IB/hfi1: Increase default settings of max_cqes and max_qps
      IB/hfi1: Update SMA ingress checks for response packets

Mike Marciniszyn (12):
      IB/rdmavt: Add functions to get and release QP references
      IB/rdmavt, IB/qib, IB/hfi1: Use new QP put get routines
      IB/core: Add ib headers for general use
      IB/qib,IB/hfi: Use core common header file
      IB/rdmavt: Correct sparse annotation
      IB/hfi1: Move iowait_init() to priv allocate
      IB/rdmavt: Move reset calldown to reset path
      IB/rdmavt: Add qp init function
      IB/rdmavt, IB/hfi1: Add lockdep asserts for lock debug
      IB/hfi1: Consolidate pio control masks into single definition
      IB/hfi1: Fix defered ack race with qp destroy
      IB/hfi1: Fix trace of atomic ack

Parav Pandit (1):
      IB/rdmavt: Trivial function comment corrected.

Sebastian Sanchez (3):
      IB/hfi1: Remove filtering of Set(PkeyTable) in HFI SMA
      IB/hfi1: Do not read more than a SGE length
      IB/hfi1: Combine shift copy and byte copy for SGE reads

Tadeusz Struk (6):
      IB/hfi1: Fix locking scheme for affinity settings
      IB/hfi1: Add sysfs interface for affinity setup
      IB/hfi1: Add a new VL sysfs attribute for sdma engines
      IB/hfi1: Add irq affinity notification handler
      IB/hfi1: Add new debugfs sdma_cpu_list file
      IB/hfi1: Document new sysfs entries for hfi1 driver

Tymoteusz Kielan (1):
      IB/hfi1: Fix user-space buffers mapping with IOMMU enabled

 Documentation/infiniband/sysfs.txt        |  30 +++
 drivers/infiniband/hw/hfi1/affinity.c     | 203 ++++++++++++----
 drivers/infiniband/hw/hfi1/affinity.h     |   3 +-
 drivers/infiniband/hw/hfi1/chip.c         |  57 +++--
 drivers/infiniband/hw/hfi1/chip.h         |   8 +-
 drivers/infiniband/hw/hfi1/common.h       |   8 -
 drivers/infiniband/hw/hfi1/debugfs.c      |  38 +++
 drivers/infiniband/hw/hfi1/driver.c       |  35 ++-
 drivers/infiniband/hw/hfi1/eprom.c        | 185 +++++++++++++++
 drivers/infiniband/hw/hfi1/eprom.h        |   4 +-
 drivers/infiniband/hw/hfi1/file_ops.c     |  59 +++--
 drivers/infiniband/hw/hfi1/hfi.h          |  22 +-
 drivers/infiniband/hw/hfi1/init.c         |  45 ++--
 drivers/infiniband/hw/hfi1/mad.c          |   7 -
 drivers/infiniband/hw/hfi1/pio.c          |  20 +-
 drivers/infiniband/hw/hfi1/pio.h          |   2 +-
 drivers/infiniband/hw/hfi1/pio_copy.c     | 246 +++++--------------
 drivers/infiniband/hw/hfi1/platform.c     |  32 ++-
 drivers/infiniband/hw/hfi1/qp.c           |  32 +--
 drivers/infiniband/hw/hfi1/qsfp.c         |   2 +-
 drivers/infiniband/hw/hfi1/rc.c           | 146 ++++++------
 drivers/infiniband/hw/hfi1/ruc.c          |  10 +-
 drivers/infiniband/hw/hfi1/sdma.c         | 377
+++++++++++++++++++++++++++++-
 drivers/infiniband/hw/hfi1/sdma.h         |  13 +-
 drivers/infiniband/hw/hfi1/sysfs.c        | 103 +++++++-
 drivers/infiniband/hw/hfi1/trace.c        |  31 +--
 drivers/infiniband/hw/hfi1/trace_ctxts.h  |  13 +-
 drivers/infiniband/hw/hfi1/trace_ibhdrs.h |  14 +-
 drivers/infiniband/hw/hfi1/trace_rx.h     |   4 +-
 drivers/infiniband/hw/hfi1/uc.c           |  15 +-
 drivers/infiniband/hw/hfi1/ud.c           |  61 +++--
 drivers/infiniband/hw/hfi1/user_sdma.c    |  40 ++--
 drivers/infiniband/hw/hfi1/verbs.c        |  60 +++--
 drivers/infiniband/hw/hfi1/verbs.h        |  93 +-------
 drivers/infiniband/hw/hfi1/verbs_txreq.c  |   2 +-
 drivers/infiniband/hw/qib/qib.h           |   2 +-
 drivers/infiniband/hw/qib/qib_driver.c    |   7 +-
 drivers/infiniband/hw/qib/qib_iba7322.c   |   2 +-
 drivers/infiniband/hw/qib/qib_qp.c        |  13 +-
 drivers/infiniband/hw/qib/qib_rc.c        |  73 +++---
 drivers/infiniband/hw/qib/qib_ruc.c       |   4 +-
 drivers/infiniband/hw/qib/qib_uc.c        |   6 +-
 drivers/infiniband/hw/qib/qib_ud.c        |   6 +-
 drivers/infiniband/hw/qib/qib_verbs.c     |  16 +-
 drivers/infiniband/hw/qib/qib_verbs.h     |  94 +-------
 drivers/infiniband/sw/rdmavt/qp.c         | 119 ++++++----
 include/rdma/ib_hdrs.h                    | 178 ++++++++++++++
 include/rdma/rdmavt_qp.h                  |  19 ++
 48 files changed, 1660 insertions(+), 899 deletions(-)
 create mode 100644 include/rdma/ib_hdrs.h


-- 
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-09-16 20:19 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-09-16 20:19 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 2987 bytes --]

Hi Linus,

This is likely the last rdma pull request this cycle.  The new rxe
driver had a few issues (you probably saw the boot bot bug report) and
they should be addressed now.  There are a couple other fixes here,
mainly mlx4.  There are still two outstanding issues that need resolved
but I don't think their fix will make this kernel cycle.

Here's the boilerplate:

The following changes since commit 16170d9c102764f76c58aad244e947f4e3f44590:

  IB/hfi1: Rework debugfs to use SRCU (2016-09-02 14:26:55 -0400)

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 e4618d40eb3dc1a6d1f55f7150ea25bb23ab410a:

  IB/rdmavt: Don't vfree a kzalloc'ed memory region (2016-09-16 14:14:23
-0400)

----------------------------------------------------------------
Round three of 4.8 rc fixes

- Various fixes to rdmavt, ipoib, mlx5, mlx4, rxe

----------------------------------------------------------------
Alex Vesker (2):
      IB/ipoib: Don't allow MC joins during light MC flush
      IB/mlx4: Fix incorrect MC join state bit-masking on SR-IOV

Alexey Khoroshilov (1):
      IB/rxe: fix GFP_KERNEL in spinlock context

Colin Ian King (1):
      IB/rdmavt: Don't vfree a kzalloc'ed memory region

Jack Morgenstein (2):
      IB/mlx4: Fix code indentation in QP1 MAD flow
      IB/mlx4: Use correct subnet-prefix in QP1 mads under SR-IOV

Kamal Heib (1):
      IB/mlx4: Diagnostic HW counters are not supported in slave mode

Maor Gottlieb (1):
      IB/mlx5: Set source mac address in FTE

Noa Osherovich (1):
      IB/mlx5: Enable MAD_IFC commands for IB ports only

Yonatan Cohen (4):
      IB/rxe: Fix kernel panic in udp_setup_tunnel
      IB/rxe: Fix duplicate atomic request handling
      IB/rxe: Fix race condition between requester and completer
      IB/rxe: Fix kmem_cache leak

 drivers/infiniband/hw/mlx4/mad.c        | 23 +++++++++++++
 drivers/infiniband/hw/mlx4/main.c       |  3 ++
 drivers/infiniband/hw/mlx4/mcg.c        | 14 ++++----
 drivers/infiniband/hw/mlx4/mlx4_ib.h    |  2 +-
 drivers/infiniband/hw/mlx4/qp.c         | 37 +++++++++++----------
 drivers/infiniband/hw/mlx5/main.c       | 11 ++++++-
 drivers/infiniband/sw/rdmavt/mr.c       |  2 +-
 drivers/infiniband/sw/rxe/rxe.c         | 25 +++++++++++++--
 drivers/infiniband/sw/rxe/rxe_comp.c    | 13 ++++++++
 drivers/infiniband/sw/rxe/rxe_net.c     | 55
+++++++++++++++----------------
 drivers/infiniband/sw/rxe/rxe_net.h     |  5 ++-
 drivers/infiniband/sw/rxe/rxe_recv.c    |  2 +-
 drivers/infiniband/sw/rxe/rxe_req.c     | 57
+++++++++++++++++++++++++--------
 drivers/infiniband/sw/rxe/rxe_resp.c    | 11 ++++---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c |  9 ++++++
 15 files changed, 189 insertions(+), 80 deletions(-)

-- 
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-09-06 18:09 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-09-06 18:09 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 4696 bytes --]

Hi Linus,

This is the second pull request for the rdma subsystem.  Most of the
patches are small and obvious.  I took two patches in that are larger
than I wanted this late in the cycle.

The first is the hfi1 patch that implements a work queue to test the
QSFP read state.  I originally rejected the first patch for this (which
would have place up to 20 seconds worth of udelays in their probe
routine).  They then rewrote it the way I wanted (use delayed work tasks
to wait asynchronously up to 20 seconds for the QSFP to come alive), so
I can't really complain about the size of getting what I asked for :-/.

The second is large because it switches the rcu locking in the debugfs
code.  Since a locking change like this is done all at once, the size it
what it is.  It resolves a litany of debug messages from the kernel, so
I pulled it in for -rc.

The rest are all typical -rc worthy patches I think.

There will still be a third -rc pull request from the rdma subsystem
this release.  I hope to have that one ready to go by the end of this
week or early next.

Here's the boilerplate:

The following changes since commit 049b1e7c7e5c21bbb64dc3fc10bb0c53f30b0b70:

  Merge branch 'misc-fixes' into k.o/for-4.8-rc (2016-08-25 11:17:10 -0400)

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 16170d9c102764f76c58aad244e947f4e3f44590:

  IB/hfi1: Rework debugfs to use SRCU (2016-09-02 14:26:55 -0400)

----------------------------------------------------------------
Round two of 4.8 rc fixes

- A smattering of small fixes across the core, ipoib, i40iw, isert, cxgb4,
  and mlx4
- A slightly larger group of fixes to each of mlx5 and hfi1

----------------------------------------------------------------
Baoyou Xie (1):
      IB/cxgb4: Make _free_qp static to silence build warning

Christophe Jaillet (3):
      IB/hfi1: Clean up type used and casting
      IB/mlx5: Fix the size parameter to find_first_bit
      IB/hfi1: Fix the size parameter to find_first_bit

Chuck Lever (1):
      IB/mlx5: Return EINVAL when caller specifies too many SGEs

Dean Luick (1):
      IB/hfi1: Add QSFP sanity pre-check

Erez Shitrit (2):
      IB/core: Fix use after free in send_leave function
      IB/ipoib: Fix memory corruption in ipoib cm mode connect flow

Harish Chegondi (1):
      IB/hfi1: Make n_krcvqs be an unsigned long integer

Jubin John (1):
      IB/hfi1: Fix AHG KDETH Intr shift

Leon Romanovsky (4):
      Revert "IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one"
      IB/mlx4: Don't return errors from poll_cq
      IB/mlx5: Simplify code by removing return variable
      IB/mlx5: Don't return errors from poll_cq

Mike Marciniszyn (1):
      IB/hfi1: Rework debugfs to use SRCU

Mustafa Ismail (1):
      i40iw: Update hw_iwarp_state

Raju Rangoju (1):
      IB/isert: Properly release resources on DEVICE_REMOVAL

Sebastian Sanchez (1):
      IB/hfi1: Fix SGE length for misaligned PIO copy

Shiraz Saleem (1):
      i40iw: Receive notification events correctly

Yishai Hadas (1):
      IB/mlx5: Use TIR number based on selector

 drivers/infiniband/core/multicast.c       |  13 +--
 drivers/infiniband/hw/cxgb4/qp.c          |   2 +-
 drivers/infiniband/hw/hfi1/chip.c         |  92 ++++++++++++++++++---
 drivers/infiniband/hw/hfi1/chip.h         |   1 +
 drivers/infiniband/hw/hfi1/debugfs.c      | 132
++++++++++++------------------
 drivers/infiniband/hw/hfi1/hfi.h          |   4 +-
 drivers/infiniband/hw/hfi1/init.c         |   3 +-
 drivers/infiniband/hw/hfi1/mad.c          |  12 +--
 drivers/infiniband/hw/hfi1/pio_copy.c     |  12 +++
 drivers/infiniband/hw/hfi1/user_sdma.c    |   5 +-
 drivers/infiniband/hw/i40iw/i40iw_hw.c    |   1 +
 drivers/infiniband/hw/i40iw/i40iw_main.c  |   8 +-
 drivers/infiniband/hw/mlx4/cq.c           |  26 +-----
 drivers/infiniband/hw/mlx5/cq.c           |  22 +----
 drivers/infiniband/hw/mlx5/main.c         |   6 +-
 drivers/infiniband/hw/mlx5/mem.c          |   6 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h      |   1 +
 drivers/infiniband/hw/mlx5/qp.c           |  13 ++-
 drivers/infiniband/ulp/ipoib/ipoib.h      |   1 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c   |  16 ++++
 drivers/infiniband/ulp/ipoib/ipoib_main.c |   2 +-
 drivers/infiniband/ulp/isert/ib_isert.c   |  23 +++++-
 drivers/infiniband/ulp/isert/ib_isert.h   |   2 +
 23 files changed, 226 insertions(+), 177 deletions(-)


-- 
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <a4e3d830-71e5-76b1-927d-4e3b52a19ac5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-26 19:19                   ` Leon Romanovsky
  0 siblings, 0 replies; 186+ messages in thread
From: Leon Romanovsky @ 2016-08-26 19:19 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

On Fri, Aug 26, 2016 at 01:53:03PM -0400, Doug Ledford wrote:
> On 8/26/2016 1:16 PM, Leon Romanovsky wrote:
> > On Fri, Aug 26, 2016 at 12:12:07PM -0400, Doug Ledford wrote:
> >> On 8/26/2016 10:44 AM, Leon Romanovsky wrote:
> >>> On Thu, Aug 25, 2016 at 03:29:12PM -0400, Doug Ledford wrote:
> >>>
> >>> Hi Doug,
> >>>
> >>> These two patches were supposed to be carried by us [1] and I explicitly
> >>> said that. Especially, the last patch in this series is wrong. Please
> >>> revert it. The proper patch is [2] and it was supposed to be sent right
> >>> after our shared code.
> >>>
> >>>> Yuval Shaia (2):
> >>>>       IB/mlx4: Make function use_tunnel_data return void
> >>>>       IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one
> >>>
> >>> [1] https://www.spinics.net/lists/linux-rdma/msg38580.html
> >>> [2]
> >>> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/mlx-fixes&id=d5a1c56c3a49db6369b36aa04fbeabc7653ae107
> >>>
> >>
> >> I saw your request to carry it, but then never heard anything again from
> >> you.  The fix that the original patch implements is still valid and was
> >> something I wanted to get into 4.8, where as your patch is being held
> >> for 4.9 and goes down a different path to solving the issue.  IMO, the
> >> patch from Yuval is fine for 4.8, and if you want to apply yours to 4.9,
> >> that's fine too.  I don't see a need to revert the existing patch.  From
> >> what I can tell, the existing patch will work fine and do what Yuval
> >> intended, it just won't do what you intend to do in 4.9.  Please correct
> >> me if I'm wrong.
> >
> > By our HW design and SW implementation poll_cq never fails and returns
> > errors, so all these prints are to catch ULP bugs. In case of such bug, Yuval's
> > patch will cause to reentry (EAGAIN) and kprints storm again and again.
> > It is undesired and misleading behaviour.
> >
> > We targeted our patch to 4.9, because it is not actual fix, but help to
> > ULP developers and there is no real need to hurry up.
> >
> > Will it be acceptable by you, if I revert Yuval's patch before sending
> > our version for 4.9?
>
> Just post your version now.  I have another pull request for 4.8-rc,
> I'll merge in your version into the next pull request.

I will do it immediately after I'll return to my office (Sunday).

Thanks

>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: 0E572FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <20160826171638.GD594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-26 17:53               ` Doug Ledford
       [not found]                 ` <a4e3d830-71e5-76b1-927d-4e3b52a19ac5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-08-26 17:53 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 2273 bytes --]

On 8/26/2016 1:16 PM, Leon Romanovsky wrote:
> On Fri, Aug 26, 2016 at 12:12:07PM -0400, Doug Ledford wrote:
>> On 8/26/2016 10:44 AM, Leon Romanovsky wrote:
>>> On Thu, Aug 25, 2016 at 03:29:12PM -0400, Doug Ledford wrote:
>>>
>>> Hi Doug,
>>>
>>> These two patches were supposed to be carried by us [1] and I explicitly
>>> said that. Especially, the last patch in this series is wrong. Please
>>> revert it. The proper patch is [2] and it was supposed to be sent right
>>> after our shared code.
>>>
>>>> Yuval Shaia (2):
>>>>       IB/mlx4: Make function use_tunnel_data return void
>>>>       IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one
>>>
>>> [1] https://www.spinics.net/lists/linux-rdma/msg38580.html
>>> [2]
>>> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/mlx-fixes&id=d5a1c56c3a49db6369b36aa04fbeabc7653ae107
>>>
>>
>> I saw your request to carry it, but then never heard anything again from
>> you.  The fix that the original patch implements is still valid and was
>> something I wanted to get into 4.8, where as your patch is being held
>> for 4.9 and goes down a different path to solving the issue.  IMO, the
>> patch from Yuval is fine for 4.8, and if you want to apply yours to 4.9,
>> that's fine too.  I don't see a need to revert the existing patch.  From
>> what I can tell, the existing patch will work fine and do what Yuval
>> intended, it just won't do what you intend to do in 4.9.  Please correct
>> me if I'm wrong.
> 
> By our HW design and SW implementation poll_cq never fails and returns
> errors, so all these prints are to catch ULP bugs. In case of such bug, Yuval's
> patch will cause to reentry (EAGAIN) and kprints storm again and again.
> It is undesired and misleading behaviour.
> 
> We targeted our patch to 4.9, because it is not actual fix, but help to
> ULP developers and there is no real need to hurry up.
> 
> Will it be acceptable by you, if I revert Yuval's patch before sending
> our version for 4.9?

Just post your version now.  I have another pull request for 4.8-rc,
I'll merge in your version into the next pull request.


-- 
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <3aee5577-9600-db32-db7f-4fb39afdc429-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-26 17:16           ` Leon Romanovsky
       [not found]             ` <20160826171638.GD594-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-08-26 17:16 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

On Fri, Aug 26, 2016 at 12:12:07PM -0400, Doug Ledford wrote:
> On 8/26/2016 10:44 AM, Leon Romanovsky wrote:
> > On Thu, Aug 25, 2016 at 03:29:12PM -0400, Doug Ledford wrote:
> >
> > Hi Doug,
> >
> > These two patches were supposed to be carried by us [1] and I explicitly
> > said that. Especially, the last patch in this series is wrong. Please
> > revert it. The proper patch is [2] and it was supposed to be sent right
> > after our shared code.
> >
> >> Yuval Shaia (2):
> >>       IB/mlx4: Make function use_tunnel_data return void
> >>       IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one
> >
> > [1] https://www.spinics.net/lists/linux-rdma/msg38580.html
> > [2]
> > https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/mlx-fixes&id=d5a1c56c3a49db6369b36aa04fbeabc7653ae107
> >
>
> I saw your request to carry it, but then never heard anything again from
> you.  The fix that the original patch implements is still valid and was
> something I wanted to get into 4.8, where as your patch is being held
> for 4.9 and goes down a different path to solving the issue.  IMO, the
> patch from Yuval is fine for 4.8, and if you want to apply yours to 4.9,
> that's fine too.  I don't see a need to revert the existing patch.  From
> what I can tell, the existing patch will work fine and do what Yuval
> intended, it just won't do what you intend to do in 4.9.  Please correct
> me if I'm wrong.

By our HW design and SW implementation poll_cq never fails and returns
errors, so all these prints are to catch ULP bugs. In case of such bug, Yuval's
patch will cause to reentry (EAGAIN) and kprints storm again and again.
It is undesired and misleading behaviour.

We targeted our patch to 4.9, because it is not actual fix, but help to
ULP developers and there is no real need to hurry up.

Will it be acceptable by you, if I revert Yuval's patch before sending
our version for 4.9?

Thanks.

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: 0E572FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <20160826144415.GC594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-26 16:12       ` Doug Ledford
       [not found]         ` <3aee5577-9600-db32-db7f-4fb39afdc429-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-08-26 16:12 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 1452 bytes --]

On 8/26/2016 10:44 AM, Leon Romanovsky wrote:
> On Thu, Aug 25, 2016 at 03:29:12PM -0400, Doug Ledford wrote:
> 
> Hi Doug,
> 
> These two patches were supposed to be carried by us [1] and I explicitly
> said that. Especially, the last patch in this series is wrong. Please
> revert it. The proper patch is [2] and it was supposed to be sent right
> after our shared code.
> 
>> Yuval Shaia (2):
>>       IB/mlx4: Make function use_tunnel_data return void
>>       IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one
> 
> [1] https://www.spinics.net/lists/linux-rdma/msg38580.html
> [2]
> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/mlx-fixes&id=d5a1c56c3a49db6369b36aa04fbeabc7653ae107
> 

I saw your request to carry it, but then never heard anything again from
you.  The fix that the original patch implements is still valid and was
something I wanted to get into 4.8, where as your patch is being held
for 4.9 and goes down a different path to solving the issue.  IMO, the
patch from Yuval is fine for 4.8, and if you want to apply yours to 4.9,
that's fine too.  I don't see a need to revert the existing patch.  From
what I can tell, the existing patch will work fine and do what Yuval
intended, it just won't do what you intend to do in 4.9.  Please correct
me if I'm wrong.

-- 
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <e5da14cf-fd5a-895e-5fad-9020b6a7efb1-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-26 14:44   ` Leon Romanovsky
       [not found]     ` <20160826144415.GC594-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-08-26 14:44 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Torvalds, Linus, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Thu, Aug 25, 2016 at 03:29:12PM -0400, Doug Ledford wrote:

Hi Doug,

These two patches were supposed to be carried by us [1] and I explicitly
said that. Especially, the last patch in this series is wrong. Please
revert it. The proper patch is [2] and it was supposed to be sent right
after our shared code.

> Yuval Shaia (2):
>       IB/mlx4: Make function use_tunnel_data return void
>       IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one

[1] https://www.spinics.net/lists/linux-rdma/msg38580.html
[2]
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/mlx-fixes&id=d5a1c56c3a49db6369b36aa04fbeabc7653ae107

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-08-25 19:29 Doug Ledford
       [not found] ` <e5da14cf-fd5a-895e-5fad-9020b6a7efb1-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-08-25 19:29 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 5886 bytes --]

Hi Linus,

This should be the bulk of the -rc fixes for 4.8.  I only have a few
things that are still outstanding (two ipoib bugs for which the solution
is not yet fully known, and a few queued items that came in after my
last push and I didn't want to delay this pull request for late comers
again).  There shouldn't be any merge issues at all.  Even though the
patch count is kind of high, everything is minor fixes so the overall
churn is pretty low.

Here's the boilerplate:

The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -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 049b1e7c7e5c21bbb64dc3fc10bb0c53f30b0b70:

  Merge branch 'misc-fixes' into k.o/for-4.8-rc (2016-08-25 11:17:10 -0400)

----------------------------------------------------------------
Round one of 4.8 rc fixes

- Minor fixes to cxgb4
- Minor fixes to mlx4
- One minor fix each to core, rxe, isert, srpt, mlx5, ocrdma, and usnic
- Six or so fixes to i40iw fixes
- The rest are hfi1 fixes

----------------------------------------------------------------
Bharat Potnuri (1):
      iw_cxgb4: Fix cxgb4 arm CQ logic w/IB_CQ_REPORT_MISSED_EVENTS

Chris Wilson (1):
      IB/mlx5: Remove superfluous include of io-mapping.h

Christophe Jaillet (2):
      IB/hfi1: Add missing error code assignment before test
      IB/usnic: Fix error return code

Doug Ledford (2):
      IB/srpt: Update sport->port_guid with each port refresh
      Merge branch 'misc-fixes' into k.o/for-4.8-rc

Easwar Hariharan (2):
      IB/hfi1: Fetch monitor values on-demand for CableInfo query
      IB/hfi1: Return invalid field for non-QSFP CableInfo queries

Ira Weiny (1):
      IB/hfi1: Fix mm_struct use after free

Leon Romanovsky (1):
      MAINTAINERS: Fix Soft RoCE location

Markus Elfring (2):
      IB/qib: Use memdup_user() rather than duplicating its implementation
      IB/core: Use memdup_user() rather than duplicating its implementation

Mike Marciniszyn (4):
      IB/hfi1,IB/qib: Fix qp_stats sleep with rcu read lock held
      IB/hfi1: Pass packet ptr to set_armed_active
      IB/hfi1: Validate header in set_armed_active
      IB/rdmvat: Fix double vfree() in rvt_create_qp() error path

Mitko Haralanov (1):
      IB/hfi1: Improve J_KEY generation

Mustafa Ismail (5):
      i40iw: Protect req_resource_num update
      i40iw: Add missing check for interface already open
      i40iw: Do not set self-referencing pointer to NULL after kfree
      i40iw: Fix double free of allocated_buffer
      i40iw: Avoid writing to freed memory

Selvin Xavier (1):
      RDMA/ocrdma: Fix the max_sge reported from FW

Shiraz Saleem (2):
      i40iw: Change mem_resources pointer to a u8
      i40iw: Add missing NULL check for MPA private data

Steve Wise (2):
      iw_cxgb4: limit IRD/ORD advertised to ULP by device max.
      iw_cxgb4: use the MPA initiator's IRD if < our ORD

Tadeusz Struk (1):
      IB/hfi1: Allocate cpu mask on the heap to silence warning

Tatyana Nikolova (1):
      i40iw: Send last streaming mode message for loopback connections

Wei Yongjun (4):
      IB/core: Fix possible memory leak in cma_resolve_iboe_route()
      IB/isert: fix error return code in isert_alloc_login_buf()
      IB/hfi1: Remove duplicated include from affinity.c
      IB/hfi1: Using kfree_rcu() to simplify the code

Yuval Shaia (2):
      IB/mlx4: Make function use_tunnel_data return void
      IB/mlx4: Return EAGAIN for any error in mlx4_ib_poll_one

 MAINTAINERS                                 |  2 +-
 drivers/infiniband/core/cma.c               | 18 ++++++++++------
 drivers/infiniband/hw/cxgb4/cm.c            |  6 +++++-
 drivers/infiniband/hw/cxgb4/cq.c            | 10 ++++-----
 drivers/infiniband/hw/cxgb4/t4.h            |  5 +++++
 drivers/infiniband/hw/hfi1/affinity.c       | 21 +++++++++++--------
 drivers/infiniband/hw/hfi1/debugfs.c        | 14 ++++++++-----
 drivers/infiniband/hw/hfi1/driver.c         | 11 +++++-----
 drivers/infiniband/hw/hfi1/file_ops.c       |  4 +++-
 drivers/infiniband/hw/hfi1/hfi.h            | 20 ++++++++++++++++--
 drivers/infiniband/hw/hfi1/init.c           |  2 +-
 drivers/infiniband/hw/hfi1/mad.c            | 14 ++++++-------
 drivers/infiniband/hw/hfi1/qp.c             |  4 ----
 drivers/infiniband/hw/hfi1/qsfp.c           | 32
+++++++++++++++++++++++++++--
 drivers/infiniband/hw/hfi1/qsfp.h           |  3 +++
 drivers/infiniband/hw/i40iw/i40iw.h         |  4 ++--
 drivers/infiniband/hw/i40iw/i40iw_cm.c      | 26 +++--------------------
 drivers/infiniband/hw/i40iw/i40iw_main.c    |  4 ++++
 drivers/infiniband/hw/i40iw/i40iw_utils.c   |  5 ++++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c   |  4 +---
 drivers/infiniband/hw/mlx4/cq.c             | 20 +++++++++---------
 drivers/infiniband/hw/mlx5/main.c           |  1 -
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c    | 14 ++++++-------
 drivers/infiniband/hw/ocrdma/ocrdma_sli.h   | 12 +++++++----
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c |  4 ++--
 drivers/infiniband/hw/qib/qib_debugfs.c     | 12 ++++++++---
 drivers/infiniband/hw/qib/qib_fs.c          | 26 +++++------------------
 drivers/infiniband/hw/qib/qib_qp.c          |  4 ----
 drivers/infiniband/hw/usnic/usnic_ib_main.c |  3 ++-
 drivers/infiniband/sw/rdmavt/qp.c           |  3 ++-
 drivers/infiniband/ulp/isert/ib_isert.c     |  2 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c       |  9 ++++----
 include/rdma/ib_verbs.h                     | 11 +++-------
 33 files changed, 185 insertions(+), 145 deletions(-)

-- 
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-08-04 16:21 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-08-04 16:21 UTC (permalink / raw)
  To: Torvalds, Linus; +Cc: RDMA mailing list

[-- Attachment #1: Type: text/plain, Size: 17862 bytes --]

Hi Linus,

As we discussed offline, I've split this pull request into two parts
because of the need for different merge bases.  This first section is
the code that is based on the older 4.7-rc4 base.  While the pull
request is mostly normal, there is a new driver in here (the driver was
hosted outside the kernel for several years and is actually a fairly
mature and well coded driver).  It amounts to 13,000 of the 16,000
lines of added code in this pull request.

There should be one merge conflict in core/cma.c.  You can use the hunk
from my tree in its entirety and delete the common ancestor and your
HEAD chunks.

This pull request is on my k.o/for-4.8-1 branch and uses the signed tag
for-linus.

Here's the boilerplate:

The following changes since commit
33688abb2802ff3a230bd2441f765477b94cc89e:

  Linux 4.7-rc4 (2016-06-19 21:30:02 -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
7f1d25b47d919cef29388aff37e7b074e65bf512:

  Merge branches 'misc' and 'rxe' into k.o/for-4.8-1 (2016-08-04
11:13:47 -0400)

----------------------------------------------------------------
Round one of 4.8 code

- Updates/fixes for iw_cxgb4 driver
- Updates/fixes for mlx5 driver
- Add flow steering and RSS API
- Add hardware stats to mlx4 and mlx5 drivers
- Add firmware version API for RDMA driver use
- Add the rxe driver (this is a software RoCE driver that makes any
  Ethernet device a RoCE device)
- Fixes for i40iw driver
- Support for send only multicast joins in the cma layer
- Other minor fixes

----------------------------------------------------------------
Alex Vesker (3):
      IB/mlx5: Fix port counter ID association to QP offset
      IB/sa: Add cached attribute containing SM information to SA port
      IB/core: Support for CMA multicast join flags

Amitoj Kaur Chawla (1):
      RDMA/cxgb3: Use AF_INET for sin_family field

Artemy Kovalyov (2):
      IB/mlx5: Fix MODIFY_QP command input structure
      {net, IB}/mlx5: Refactor internal SRQ API

Bart Van Assche (2):
      IB/rdmavt: Disable by default
      IB/hfi1: Disable by default

Bodong Wang (1):
      IB/mlx5: Report mlx5 TSO capabilities when querying device

Doug Ledford (5):
      Merge tag 'shared' of http://git.kernel.org/.../leon/linux-rdma
into mlx5-4.8
      Merge branches 'cxgb4-4.8', 'mlx5-4.8' and 'fw-version' into
k.o/for-4.8
      Merge branches 'cxgb4' and 'mlx5' into k.o/for-4.8
      Merge branch 'i40iw' into k.o/for-4.8
      Merge branches 'misc' and 'rxe' into k.o/for-4.8-1

Hariprasad S (8):
      RDMA/iw_cxgb4: only read markers_enabled mod param once
      RDMA/iw_cxgb4: allocate enough space for debugfs "qps" dump
      RDMA/iw_cxgb4: clean up c4iw_reject_cr()
      RDMA/iw_cxgb4: Add missing error codes for act open cmd
      RDMA/iw_cxgb4: Low resource fixes for connection manager
      RDMA/iw_cxgb4: Low resource fixes for Memory registration
      RDMA/iw_cxgb4: Low resource fixes for Completion queue
      RDMA/iw_cxgb4: Use kfree_skb instead of kfree

Ira Weiny (13):
      IB/core: Add get FW version string to the core
      IB/cxgb3: Support device FW version string
      IB/cxgb4: Support device FW version string
      IB/i40iw: Support device FW version string
      IB/mlx4: Support device FW version string
      IB/mlx5: Support device FW version string
      IB/mthca: Supprot device FW version string
      IB/nes: Support device FW version string
      IB/ocrdma: Support device FW version string
      IB/usnic: Support device FW version string
      IB/ipoib: Use new device FW version string
      IB/core: Export a common fw_ver sysfs entry
      IB/hfi1: Add device FW version string

Jason Gunthorpe (1):
      IB/uverbs: Fix race between uverbs_close and remove_one

Maor Gottlieb (4):
      IB/mlx5: Implements disassociate_ucontext API
      IB/mlx5: Reset flow support for IB kernel ULPs
      IB/core: Add IPv6 support to flow steering
      IB/mlx5: Enable flow steering for IPv6 traffic

Mark Bloch (5):
      IB/mlx5: Add per port counters
      IB/mlx5: Add port protocol stats
      net/mlx4: Add diagnostic counters capability bit
      net/mlx4: Query performance and diagnostics counters
      IB/mlx4: Add diagnostic hardware counters

Markus Elfring (3):
      IB/hfi1: NULL arg to sc_return_credits is OK
      IB/mthca: NULL arg to pci_dev_put is OK
      IB/mthca: Clean up error unwind flow in mthca_reset()

Moni Shoua (1):
      Soft RoCE driver

Mustafa Ismail (9):
      IB/core: Add flow control to the portmapper netlink calls
      i40iw: Correct and use size parameter to i40iw_reg_phys_mr
      i40iw: Do not access pointer after free
      i40iw: Remove unnecessary parameter to i40iw_cq_poll_completion
      i40iw: Simplify code to set fragments in SQ WQE
      i40iw: Remove unnecessary check for moving CQ head
      i40iw: Change dup_ack_thresh to u8
      i40iw: Add NULL check for puda buffer
      Use smaller 512 byte messages for portmapper messages

Roland Dreier (1):
      IB/mlx4: Don't use GFP_ATOMIC for CQ resize struct

Saeed Mahameed (1):
      {net,IB}/mlx5: mlx5_ifc updates

Shiraz Saleem (1):
      i40iw: Fix return codes

Slava Shwartsman (1):
      IB/mlx5: Fix iteration overrun in GSI qps

Steve Wise (4):
      iw_cxgb4: stop MPA_REPLY timer when disconnecting
      iw_cxgb4: explicitly move the qp to ERROR state during flush
      iw_cxgb4: don't block in destroy_qp awaiting the last deref
      iw_cm: free cm_id resources on the last deref

Wei Yongjun (1):
      IB/mlx5: Fix duplicate const warning

Yishai Hadas (10):
      net/mlx5: Export required core functions to support RSS
      IB/core: Introduce Work Queue object and its verbs
      IB/uverbs: Add WQ support
      IB/mlx5: Add receive Work Queue verbs
      IB/core: Introduce Receive Work Queue indirection table
      IB/uverbs: Introduce RWQ Indirection table
      IB/mlx5: Add Receive Work Queue Indirection table operations
      IB/core: Extend create QP to get indirection table
      IB/uverbs: Extend create QP to get RWQ indirection table
      IB/mlx5: Add RSS QP support

Yuval Shaia (1):
      IB/ipoib: Report SG feature regardless of HW UD CSUM capability

 MAINTAINERS                                        |    9 +
 drivers/infiniband/Kconfig                         |    1 +
 drivers/infiniband/core/cma.c                      |  100 +-
 drivers/infiniband/core/device.c                   |    9 +
 drivers/infiniband/core/iwcm.c                     |   54 +-
 drivers/infiniband/core/iwcm.h                     |    2 +-
 drivers/infiniband/core/iwpm_util.c                |    3 +-
 drivers/infiniband/core/multicast.c                |   12 -
 drivers/infiniband/core/netlink.c                  |    6 +-
 drivers/infiniband/core/sa_query.c                 |   41 +
 drivers/infiniband/core/sysfs.c                    |   15 +-
 drivers/infiniband/core/ucma.c                     |   18 +-
 drivers/infiniband/core/uverbs.h                   |   14 +
 drivers/infiniband/core/uverbs_cmd.c               |  537 +++++++-
 drivers/infiniband/core/uverbs_main.c              |   75 +-
 drivers/infiniband/core/verbs.c                    |  163 ++-
 drivers/infiniband/hw/cxgb3/iwch_cm.c              |    4 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |   27 +-
 drivers/infiniband/hw/cxgb4/cm.c                   |  193 ++-
 drivers/infiniband/hw/cxgb4/cq.c                   |   42 +-
 drivers/infiniband/hw/cxgb4/device.c               |    2 +-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h             |   24 +-
 drivers/infiniband/hw/cxgb4/mem.c                  |  127 +-
 drivers/infiniband/hw/cxgb4/provider.c             |   31 +-
 drivers/infiniband/hw/cxgb4/qp.c                   |   40 +-
 drivers/infiniband/hw/hfi1/Kconfig                 |    1 -
 drivers/infiniband/hw/hfi1/file_ops.c              |    2 +-
 drivers/infiniband/hw/hfi1/hfi.h                   |    2 +
 drivers/infiniband/hw/hfi1/verbs.c                 |   15 +
 drivers/infiniband/hw/i40iw/i40iw_cm.c             |    4 +-
 drivers/infiniband/hw/i40iw/i40iw_d.h              |    3 +
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |    4 +
 drivers/infiniband/hw/i40iw/i40iw_type.h           |    2 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             |   29 +-
 drivers/infiniband/hw/i40iw/i40iw_user.h           |    2 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |   76 +-
 drivers/infiniband/hw/mlx4/cq.c                    |    4 +-
 drivers/infiniband/hw/mlx4/main.c                  |  222 +++-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |    9 +
 drivers/infiniband/hw/mlx5/cq.c                    |   87 +-
 drivers/infiniband/hw/mlx5/gsi.c                   |   19 +-
 drivers/infiniband/hw/mlx5/main.c                  |  429 +++++-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   74 ++
 drivers/infiniband/hw/mlx5/mr.c                    |    4 +
 drivers/infiniband/hw/mlx5/qp.c                    |  691 +++++++++-
 drivers/infiniband/hw/mlx5/srq.c                   |  112 +-
 drivers/infiniband/hw/mlx5/user.h                  |   88 +-
 drivers/infiniband/hw/mthca/mthca_provider.c       |   24 +-
 drivers/infiniband/hw/mthca/mthca_reset.c          |   42 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |   33 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c         |   19 +-
 drivers/infiniband/hw/usnic/usnic_ib_main.c        |   16 +
 drivers/infiniband/hw/usnic/usnic_ib_sysfs.c       |   17 -
 drivers/infiniband/sw/Makefile                     |    1 +
 drivers/infiniband/sw/rdmavt/Kconfig               |    1 -
 drivers/infiniband/sw/rxe/Kconfig                  |   24 +
 drivers/infiniband/sw/rxe/Makefile                 |   24 +
 drivers/infiniband/sw/rxe/rxe.c                    |  386 ++++++
 drivers/infiniband/sw/rxe/rxe.h                    |   77 ++
 drivers/infiniband/sw/rxe/rxe_av.c                 |   98 ++
 drivers/infiniband/sw/rxe/rxe_comp.c               |  734 +++++++++++
 drivers/infiniband/sw/rxe/rxe_cq.c                 |  165 +++
 drivers/infiniband/sw/rxe/rxe_dma.c                |  166 +++
 drivers/infiniband/sw/rxe/rxe_hdr.h                |  952
++++++++++++++
 drivers/infiniband/sw/rxe/rxe_icrc.c               |   96 ++
 drivers/infiniband/sw/rxe/rxe_loc.h                |  286 ++++
 drivers/infiniband/sw/rxe/rxe_mcast.c              |  190 +++
 drivers/infiniband/sw/rxe/rxe_mmap.c               |  173 +++
 drivers/infiniband/sw/rxe/rxe_mr.c                 |  643 +++++++++
 drivers/infiniband/sw/rxe/rxe_net.c                |  708 ++++++++++
 drivers/infiniband/sw/rxe/rxe_net.h                |   53 +
 drivers/infiniband/sw/rxe/rxe_opcode.c             |  961
++++++++++++++
 drivers/infiniband/sw/rxe/rxe_opcode.h             |  129 ++
 drivers/infiniband/sw/rxe/rxe_param.h              |  172 +++
 drivers/infiniband/sw/rxe/rxe_pool.c               |  502 +++++++
 drivers/infiniband/sw/rxe/rxe_pool.h               |  163 +++
 drivers/infiniband/sw/rxe/rxe_qp.c                 |  851 ++++++++++++
 drivers/infiniband/sw/rxe/rxe_queue.c              |  217 +++
 drivers/infiniband/sw/rxe/rxe_queue.h              |  178 +++
 drivers/infiniband/sw/rxe/rxe_recv.c               |  420 ++++++
 drivers/infiniband/sw/rxe/rxe_req.c                |  726 ++++++++++
 drivers/infiniband/sw/rxe/rxe_resp.c               | 1380
++++++++++++++++++++
 drivers/infiniband/sw/rxe/rxe_srq.c                |  193 +++
 drivers/infiniband/sw/rxe/rxe_sysfs.c              |  157 +++
 drivers/infiniband/sw/rxe/rxe_task.c               |  154 +++
 drivers/infiniband/sw/rxe/rxe_task.h               |   95 ++
 drivers/infiniband/sw/rxe/rxe_verbs.c              | 1330
+++++++++++++++++++
 drivers/infiniband/sw/rxe/rxe_verbs.h              |  480 +++++++
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |    6 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |    3 +-
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c         |   10 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h        |    2 +
 drivers/net/ethernet/mellanox/mlx4/fw.c            |   40 +
 drivers/net/ethernet/mellanox/mlx5/core/srq.c      |  265 ++--
 drivers/net/ethernet/mellanox/mlx5/core/transobj.c |    4 +
 include/linux/mlx4/device.h                        |    7 +
 include/linux/mlx5/cq.h                            |    2 +
 include/linux/mlx5/driver.h                        |    6 +-
 include/linux/mlx5/mlx5_ifc.h                      |  275 +++-
 include/linux/mlx5/qp.h                            |    4 +-
 include/linux/mlx5/srq.h                           |   25 +
 include/rdma/ib_sa.h                               |   13 +
 include/rdma/ib_verbs.h                            |  102 +-
 include/rdma/rdma_cm.h                             |    4 +-
 include/uapi/rdma/Kbuild                           |    1 +
 include/uapi/rdma/ib_user_verbs.h                  |   95 ++
 include/uapi/rdma/rdma_user_cm.h                   |    9 +-
 include/uapi/rdma/rdma_user_rxe.h                  |  144 ++
 108 files changed, 16804 insertions(+), 677 deletions(-)
 create mode 100644 drivers/infiniband/sw/rxe/Kconfig
 create mode 100644 drivers/infiniband/sw/rxe/Makefile
 create mode 100644 drivers/infiniband/sw/rxe/rxe.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_av.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_comp.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_cq.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_dma.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_hdr.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_icrc.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_loc.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_mcast.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_mmap.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_mr.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_net.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_net.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_opcode.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_opcode.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_param.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_pool.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_pool.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_qp.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_queue.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_queue.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_recv.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_req.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_resp.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_srq.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_sysfs.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_task.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_task.h
 create mode 100644 drivers/infiniband/sw/rxe/rxe_verbs.c
 create mode 100644 drivers/infiniband/sw/rxe/rxe_verbs.h
 create mode 100644 include/uapi/rdma/rdma_user_rxe.h

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-07-14 13:45 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-07-14 13:45 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 1785 bytes --]

Hi Linus,

This is a fairly small set of late rc fixes.  Nothing very controversial
or needing a lot of explanation.  Here's the boiler plate:

The following changes since commit 9903fd1374e913f5086b58af09d4e3fd6e9e86fe:

  Merge branches '4.7-rc-misc', 'hfi1-fixes', 'i40iw-rc-fixes' and
'mellanox-rc-fixes' into k.o/for-4.7-rc (2016-06-23 12:22:33 -0400)

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 8e0e7aedadb877d91a6e66611464165c969bc0a9:

  i40iw: Enable remote access rights for stag allocation (2016-07-12
10:46:34 -0400)

----------------------------------------------------------------
Round three of 4.7 rc fixes

- Two fixes for hfi1
- Two fixes for i40iw
- On ommission correction in the port table counter arrays

----------------------------------------------------------------
Christoph Lameter (1):
      IB core: Add port_xmit_wait counter

Mike Marciniszyn (1):
      IB/hfi1: Correct issues with sc5 computation

Nicolas Iooss (1):
      i40iw: do not print unitialized variables in error message

Shiraz Saleem (1):
      i40iw: Enable remote access rights for stag allocation

Tadeusz Struk (1):
      IB/hfi1: Fix sleep inside atomic issue in init_asic_data

 drivers/infiniband/core/sysfs.c           |  4 ++++
 drivers/infiniband/hw/hfi1/chip.c         | 16 +++++++++-------
 drivers/infiniband/hw/hfi1/ud.c           | 23 +++--------------------
 drivers/infiniband/hw/i40iw/i40iw_main.c  |  3 +--
 drivers/infiniband/hw/i40iw/i40iw_verbs.c |  1 +
 5 files changed, 18 insertions(+), 29 deletions(-)

-- 
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-06-24 23:12 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-06-24 23:12 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 5075 bytes --]

Hi Linus,

This is the second batch of queued up rdma patches for this rc cycle.
There isn't anything really major in here.  It's passed 0day,
linux-next, and local testing across a wide variety of hardware.  There
are still a few known issues to be tracked down, but this should amount
to the vast majority of the rdma RC fixes.

Here's the boilerplate:

The following changes since commit 8c5122e45a10a9262f872b53f151a592e870f905:

  IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs
(2016-06-17 19:36:54 -0400)

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 9903fd1374e913f5086b58af09d4e3fd6e9e86fe:

  Merge branches '4.7-rc-misc', 'hfi1-fixes', 'i40iw-rc-fixes' and
'mellanox-rc-fixes' into k.o/for-4.7-rc (2016-06-23 12:22:33 -0400)

----------------------------------------------------------------
Round two of 4.7 rc fixes

- A couple minor fixes to the rdma core
- Multiple minor fixes to hfi1
- Multiple minor fixes to mlx4/mlx4
- A few minor fixes to i40iw

----------------------------------------------------------------
Alex Vesker (1):
      IB/core: Fix RoCE v1 multicast join logic issue

Ashutosh Dixit (1):
      IB/hfi1: Don't zero out qp->s_ack_queue in rvt_reset_qp

Bart Van Assche (2):
      IB/cma: Make the code easier to verify
      IB/srpt: Reduce QP buffer size

Brian Welty (2):
      IB/rdmavt: Correct required callback functions for MODIFY_QP
      IB/rdmavt: Correct warning during QPN allocation

Chuck Lever (1):
      IB/mlx4: Prevent cross page boundary allocation

Dotan Barak (1):
      IB/mlx4: Fix memory leak if QP creation failed

Doug Ledford (1):
      Merge branches '4.7-rc-misc', 'hfi1-fixes', 'i40iw-rc-fixes' and
'mellanox-rc-fixes' into k.o/for-4.7-rc

Eli Cohen (2):
      IB/core: Fix false search of the IB_SA_WELL_KNOWN_GUID
      IB/mlx5: Fix post send fence logic

Faisal Latif (2):
      i40iw: Correct status check on i40iw_get_pble
      i40iw: Return correct max_fast_reg_page_list_len

Ira Weiny (2):
      IB/hfi1: Prevent context loss
      IB/qib: Prevent context loss

Jubin John (2):
      IB/hfi1: Fix credit return threshold adjustment
      IB/hfi1: Increase packet egress timeout

Maor Gottlieb (1):
      IB/uverbs: Initialize ib_qp_init_attr with zeros

Mike Marciniszyn (2):
      IB/hfi1: Fix deadlock with txreq allocation slow path
      IB/rdmavt: Correct qp_priv_alloc() return value test

Sebastian Sanchez (2):
      IB/hfi1: Remove FULL_MGMT_P_KEY from pkey table at link up
      IB/hfi1: Send a pkey change event on driver pkey update

Shiraz Saleem (2):
      i40iw: Correct CQ arming
      i40iw: Enable level-1 PBL for fast memory registration

Tadeusz Struk (2):
      IB/hfi1: Fix potential NULL ptr dereference
      IB/hfi1: Fix potential buffer overflow

Talat Batheesh (2):
      IB/core: Fix no default GIDs when netdevice reregisters
      IB/mlx5: Fix wrong naming of port_rcv_data counter

Yishai Hadas (3):
      IB/mlx4: Fix the SQ size of an RC QP
      IB/mlx4: Fix error flow when sending mads under SRIOV
      IB/mlx4: Verify port number in flow steering create flow

 drivers/infiniband/core/cache.c           |  4 +-
 drivers/infiniband/core/cma.c             | 62
+++++++++++++++----------------
 drivers/infiniband/core/uverbs_cmd.c      |  2 +-
 drivers/infiniband/core/verbs.c           | 16 +++++---
 drivers/infiniband/hw/hfi1/chip.c         | 28 ++++++++++----
 drivers/infiniband/hw/hfi1/file_ops.c     |  3 ++
 drivers/infiniband/hw/hfi1/init.c         |  2 +-
 drivers/infiniband/hw/hfi1/mad.c          | 19 ++++++----
 drivers/infiniband/hw/hfi1/mad.h          |  2 +
 drivers/infiniband/hw/hfi1/pio.c          | 26 +++++++++++--
 drivers/infiniband/hw/hfi1/qsfp.c         |  3 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.c  |  4 +-
 drivers/infiniband/hw/hfi1/verbs_txreq.h  |  1 +
 drivers/infiniband/hw/i40iw/i40iw.h       |  2 +
 drivers/infiniband/hw/i40iw/i40iw_verbs.c | 17 +++++++--
 drivers/infiniband/hw/mlx4/mad.c          | 24 +++++++++---
 drivers/infiniband/hw/mlx4/main.c         |  3 ++
 drivers/infiniband/hw/mlx4/mlx4_ib.h      |  2 +-
 drivers/infiniband/hw/mlx4/mr.c           | 34 ++++++++---------
 drivers/infiniband/hw/mlx4/qp.c           |  6 ++-
 drivers/infiniband/hw/mlx5/mad.c          |  2 +-
 drivers/infiniband/hw/mlx5/qp.c           |  7 ++--
 drivers/infiniband/hw/qib/qib_file_ops.c  |  5 +++
 drivers/infiniband/sw/rdmavt/qp.c         | 14 +++----
 drivers/infiniband/sw/rdmavt/vt.c         |  4 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c     |  3 +-
 drivers/infiniband/ulp/srpt/ib_srpt.h     |  1 +
 include/linux/mlx5/qp.h                   |  1 +
 include/rdma/rdma_vt.h                    |  4 +-
 29 files changed, 189 insertions(+), 112 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-06-09 16:32 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-06-09 16:32 UTC (permalink / raw)
  To: Torvalds, Linus, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 4963 bytes --]

Hi Linus,

This is the first -rc pull for the RDMA subsystem.  The patch count is
high, but they are all smallish patches fixing simple things for the
most part, and the overall line count of changes here is smaller than
the patch count would lead a person to believe.

Code is up and running in my labs, including direct testing of cxgb4,
mlx4, mlx5, ocrdma, and qib.

Here's the boilerplate:

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -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 61c78eea9516a921799c17b4c20558e2aa780fd3:

  IB/IPoIB: Don't update neigh validity for unresolved entries
(2016-06-07 10:49:48 -0400)

----------------------------------------------------------------
Round one of 4.7 rc fixes

- Multiple minor fixes to the rdma core
- Multiple minor fixes to hfi1
- Multiple minor fixes to mlx5
- A very few other minor fixes (SRP, IPoIB, usNIC, mlx4)

----------------------------------------------------------------
Achiad Shochat (1):
      IB/mlx5: Fix alternate path code

Aviv Heller (1):
      IB/core: Fix removal of default GID cache entry

Bart Van Assche (10):
      IB/cm: Fix a recently introduced locking bug
      IB/mlx4: Fix device managed flow steering support test
      IB/srp: Always initialize use_fast_reg and use_fmr
      IB/srp: Fix srp_map_sg_dma()
      RDMA/core: Fix indentation
      IB/mad: Fix indentation
      IB/rdmavt: Annotate rvt_reset_qp()
      IB/hfi1: Fix indentation
      IB/hfi1: Use bit 0 instead of bit 1
      IB/hfi1: Suppress sparse warnings

Colin Ian King (1):
      IB/core: fix null pointer deref and mem leak in error handling

Dan Carpenter (2):
      IB/hfi1: fix some indenting
      IB/core: fix an error code in ib_core_init()

Doug Ledford (2):
      IB/core: Fix array length allocation
      IB/core: fix error unwind in sysfs hw counters code

Eli Cohen (1):
      IB/core: Fix query port failure in RoCE

Eran Ben Elisha (1):
      IB/mlx5: Fix FW version diaplay in sysfs

Erez Shitrit (2):
      IB/IPoIB: Fix race between ipoib_remove_one to sysfs functions
      IB/IPoIB: Don't update neigh validity for unresolved entries

Krzysztof Kozlowski (1):
      IB/usnic: Remove unused DMA attributes

Leon Romanovsky (1):
      IB/hfi1: Avoid large frame size warning

Maor Gottlieb (1):
      IB/mlx5: Set flow steering capability bit

Mark Bloch (2):
      IB/IPoIB: Disable bottom half when dealing with device address
      IB/core: Initialize sysfs attributes before sysfs create group

Max Gurtovoy (2):
      IB/core: Fix bit curruption in ib_device_cap_flags structure
      IB/core: Make all casts in ib_device_cap_flags enum consistent

Noa Osherovich (7):
      IB/mlx5: Return PORT_ERR in Active to Initializing tranisition
      IB/mlx5: Limit query HCA clock
      IB/mlx5: Fix returned values of query QP
      IB/mlx5: Check BlueFlame HCA support
      IB/mlx5: Fix entries checks in mlx5_ib_create_cq
      IB/mlx5: Fix entries check in mlx5_ib_resize_cq
      IB/mlx5: Fix pkey_index length in the QP path record

 drivers/infiniband/core/cache.c                | 10 +++++--
 drivers/infiniband/core/cm.c                   |  4 +--
 drivers/infiniband/core/device.c               |  6 +++-
 drivers/infiniband/core/iwpm_msg.c             |  2 +-
 drivers/infiniband/core/mad.c                  |  6 ++--
 drivers/infiniband/core/sysfs.c                | 24 ++++++++++-----
 drivers/infiniband/hw/hfi1/affinity.c          | 31 +++++++++----------
 drivers/infiniband/hw/hfi1/chip.c              |  6 ++--
 drivers/infiniband/hw/hfi1/init.c              |  2 +-
 drivers/infiniband/hw/hfi1/trace.c             | 13 --------
 drivers/infiniband/hw/hfi1/user_sdma.c         |  6 ++--
 drivers/infiniband/hw/mlx4/main.c              |  4 +--
 drivers/infiniband/hw/mlx5/cq.c                | 12 ++++++--
 drivers/infiniband/hw/mlx5/main.c              | 22 +++++++++-----
 drivers/infiniband/hw/mlx5/qp.c                | 41
++++++++++++++++----------
 drivers/infiniband/hw/usnic/usnic_uiom.c       |  5 ----
 drivers/infiniband/sw/rdmavt/qp.c              |  6 ++++
 drivers/infiniband/ulp/ipoib/ipoib.h           |  1 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c        |  4 +++
 drivers/infiniband/ulp/ipoib/ipoib_ib.c        |  8 ++---
 drivers/infiniband/ulp/ipoib/ipoib_main.c      | 15 ++++++----
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |  6 ++--
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c      |  6 ++++
 drivers/infiniband/ulp/srp/ib_srp.c            |  7 ++---
 include/linux/mlx5/qp.h                        |  5 ++--
 include/rdma/ib_verbs.h                        |  6 ++--
 26 files changed, 148 insertions(+), 110 deletions(-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <20160527144427.GZ25500-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-05-27 15:14                       ` Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-05-27 15:14 UTC (permalink / raw)
  To: leon-DgEjT+Ai2ygdnm+yROfE0A
  Cc: Dennis Dalessandro, Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

On 05/27/2016 10:44 AM, Leon Romanovsky wrote:
> On Fri, May 27, 2016 at 09:32:33AM -0400, Doug Ledford wrote:
>> On 5/27/2016 9:13 AM, Leon Romanovsky wrote:
>>> On Fri, May 27, 2016 at 07:44:15AM -0400, Dennis Dalessandro wrote:

>>> Separate char device? IOCTLs per-device vs. global IOCTLs per subsystem?
>>> Role of the IB CORE code in the driver management?
>>
>> Really Leon?  The qib driver has the *exact* same issue, and it sits out
>> of staging.  If moving this driver out of staging somehow stops us from
>> making the new ABI while the qib driver not being in staging doesn't
>> prevent it, then we are a bunch of idiots.  This would appear to me to
>> be a very disingenuous complaint on your part.
> 
> Doug,
> Did you read my question?
> 
> I feel that I need to repeat my main point again: "It is OK to move hfi1 driver
> out-of-staging"

Good, I'm glad that's settled.

> and repeat the question too: "Will the hfi1 interface
> decisions limit our ABI work?".

And I answered this already: If it does, we are idiots.  If you would
prefer the answer a different way.  Of course not.  Why would you think
it would?

> There is no politics here, just my PERSONAL opinion and believe that ABI work can be
> done in months time frame. And again, "It is OK to move hfi1 driver out-of-staging".

If you really didn't object to the driver coming out of staging, then
maybe asking these questions in response to my pull request, thereby
throwing this conversation in Linus' lap, was not the most appropriate
thing to do.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <57484C71.309-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-05-27 14:44                   ` Leon Romanovsky
       [not found]                     ` <20160527144427.GZ25500-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-05-27 14:44 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Dennis Dalessandro, Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

On Fri, May 27, 2016 at 09:32:33AM -0400, Doug Ledford wrote:
> On 5/27/2016 9:13 AM, Leon Romanovsky wrote:
> > On Fri, May 27, 2016 at 07:44:15AM -0400, Dennis Dalessandro wrote:
> >> On Fri, May 27, 2016 at 07:51:57AM +0300, Leon Romanovsky wrote:
> >>> On Thu, May 26, 2016 at 06:34:28PM -0400, Doug Ledford wrote:
> >>>> Hi Linus,
> >>>>
> >>>> This is the second group of code for the 4.7 merge window.  It looks
> >>>> large, but only in one sense.  I'll get to that in a minute.  The list
> >>>> of changes here breaks down as follows:
> >>>>
> >>>> Round two of 4.7 merge window patches
> >>>>
> >>>
> >>> <...>
> >>>
> >>>> - The big item on the list: hfi1 driver updates, plus moving the hfi1
> >>>>  driver out of staging                             <- everything else
> >>>
> >>> Hi Doug and Linus,
> >>>
> >>> The move hfi1 from the staging is a right thing, it was there a long
> >>> time and it is almost ready.
> >>
> >> No, not almost, it is totally ready. We have bent over backwards to go well
> >> beyond what was in the TODO list. This is a clean, stable, and well
> >> performing driver.
> > 
> > It is your's TODO, not mine.
> 
> No, but Mellanox has been adding to the TODO list, changing the goal
> posts so to speak.  They really *have* bent over backwards to meet the
> TODO requirements and then some.
> 
> >>
> >>> However the timing of this move puzzle me, we are in the process of ABI
> >>> change [1, 2] as a response to security alert [3]. Moves like this with
> >>> proprietary char device and ABI scheme different from whole RDMA stack
> >>> will limit the ABI work without real need.
> >>
> >> The driver sitting in staging or not has no impact on the ABI re-design.
> >> They are two completely separate issues.
> > 
> > Separate char device? IOCTLs per-device vs. global IOCTLs per subsystem?
> > Role of the IB CORE code in the driver management?
> 
> Really Leon?  The qib driver has the *exact* same issue, and it sits out
> of staging.  If moving this driver out of staging somehow stops us from
> making the new ABI while the qib driver not being in staging doesn't
> prevent it, then we are a bunch of idiots.  This would appear to me to
> be a very disingenuous complaint on your part.

Doug,
Did you read my question?

I feel that I need to repeat my main point again: "It is OK to move hfi1 driver
out-of-staging" and repeat the question too: "Will the hfi1 interface
decisions limit our ABI work?".

There is no politics here, just my PERSONAL opinion and believe that ABI work can be
done in months time frame. And again, "It is OK to move hfi1 driver out-of-staging".

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <20160527131357.GX25500-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-05-27 13:32               ` Doug Ledford
       [not found]                 ` <57484C71.309-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-05-27 13:32 UTC (permalink / raw)
  To: leon-DgEjT+Ai2ygdnm+yROfE0A, Dennis Dalessandro
  Cc: Linus Torvalds, linux-rdma

[-- Attachment #1.1: Type: text/plain, Size: 3742 bytes --]

On 5/27/2016 9:13 AM, Leon Romanovsky wrote:
> On Fri, May 27, 2016 at 07:44:15AM -0400, Dennis Dalessandro wrote:
>> On Fri, May 27, 2016 at 07:51:57AM +0300, Leon Romanovsky wrote:
>>> On Thu, May 26, 2016 at 06:34:28PM -0400, Doug Ledford wrote:
>>>> Hi Linus,
>>>>
>>>> This is the second group of code for the 4.7 merge window.  It looks
>>>> large, but only in one sense.  I'll get to that in a minute.  The list
>>>> of changes here breaks down as follows:
>>>>
>>>> Round two of 4.7 merge window patches
>>>>
>>>
>>> <...>
>>>
>>>> - The big item on the list: hfi1 driver updates, plus moving the hfi1
>>>>  driver out of staging                             <- everything else
>>>
>>> Hi Doug and Linus,
>>>
>>> The move hfi1 from the staging is a right thing, it was there a long
>>> time and it is almost ready.
>>
>> No, not almost, it is totally ready. We have bent over backwards to go well
>> beyond what was in the TODO list. This is a clean, stable, and well
>> performing driver.
> 
> It is your's TODO, not mine.

No, but Mellanox has been adding to the TODO list, changing the goal
posts so to speak.  They really *have* bent over backwards to meet the
TODO requirements and then some.

>>
>>> However the timing of this move puzzle me, we are in the process of ABI
>>> change [1, 2] as a response to security alert [3]. Moves like this with
>>> proprietary char device and ABI scheme different from whole RDMA stack
>>> will limit the ABI work without real need.
>>
>> The driver sitting in staging or not has no impact on the ABI re-design.
>> They are two completely separate issues.
> 
> Separate char device? IOCTLs per-device vs. global IOCTLs per subsystem?
> Role of the IB CORE code in the driver management?

Really Leon?  The qib driver has the *exact* same issue, and it sits out
of staging.  If moving this driver out of staging somehow stops us from
making the new ABI while the qib driver not being in staging doesn't
prevent it, then we are a bunch of idiots.  This would appear to me to
be a very disingenuous complaint on your part.

>>
>>> Will this driver be **forced** to adjust to new ABI scheme whenever it
>>> comes? If it is not possible, the better solution to converge on ABI change will be
>>> to leave this driver in staging/rdma and wait till proper solution will be accepted.
>>
>> I think Doug has made it perfectly clear that hfi1 will need to adopt the
>> new ABI when it is available, and we are certainly on board with that.
> 
> It is too generic and not limited in time,

What's too generic and not limited in time is the switch to the new API
for the core.  Fundamental questions about what that API should look
like simply have not even begun to be addressed yet.  It is very
unlikely IMO that it will be read for 4.8, which means you are talking
about leaving a driver in staging for 6+ months for no fault of its own
other than the core hasn't modified itself over to the verbs 2.0 ABI
yet.  And you aren't suggesting all of the other RDMA drivers join hfi1
in staging while we wait.  They get a pass.

> I'm not against moving your
> driver out of staging, just want to be sure that ABI effort won't be
> limited by current hfi1 code which doesn't fit into current IB core
> model.

Like I said, the qib also doesn't fit into that model and I don't see
you jumping up and down about it ruining the ABI.  No, this feels more
like Mellanox trying to hinder Intel in my opinion.  And the amount of
inter-company politics that has come about by use of the staging area
has pretty much convinced me that I probably don't want to use it ever
again.  We're done with the staging area Leon.  Move on.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <20160527114414.GA27420-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
@ 2016-05-27 13:13           ` Leon Romanovsky
       [not found]             ` <20160527131357.GX25500-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-05-27 13:13 UTC (permalink / raw)
  To: Dennis Dalessandro; +Cc: Doug Ledford, Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On Fri, May 27, 2016 at 07:44:15AM -0400, Dennis Dalessandro wrote:
> On Fri, May 27, 2016 at 07:51:57AM +0300, Leon Romanovsky wrote:
> >On Thu, May 26, 2016 at 06:34:28PM -0400, Doug Ledford wrote:
> >>Hi Linus,
> >>
> >>This is the second group of code for the 4.7 merge window.  It looks
> >>large, but only in one sense.  I'll get to that in a minute.  The list
> >>of changes here breaks down as follows:
> >>
> >>Round two of 4.7 merge window patches
> >>
> >
> ><...>
> >
> >>- The big item on the list: hfi1 driver updates, plus moving the hfi1
> >>  driver out of staging                             <- everything else
> >
> >Hi Doug and Linus,
> >
> >The move hfi1 from the staging is a right thing, it was there a long
> >time and it is almost ready.
> 
> No, not almost, it is totally ready. We have bent over backwards to go well
> beyond what was in the TODO list. This is a clean, stable, and well
> performing driver.

It is your's TODO, not mine.

> 
> >However the timing of this move puzzle me, we are in the process of ABI
> >change [1, 2] as a response to security alert [3]. Moves like this with
> >proprietary char device and ABI scheme different from whole RDMA stack
> >will limit the ABI work without real need.
> 
> The driver sitting in staging or not has no impact on the ABI re-design.
> They are two completely separate issues.

Separate char device? IOCTLs per-device vs. global IOCTLs per subsystem?
Role of the IB CORE code in the driver management?

> 
> >Will this driver be **forced** to adjust to new ABI scheme whenever it
> >comes? If it is not possible, the better solution to converge on ABI change will be
> >to leave this driver in staging/rdma and wait till proper solution will be accepted.
> 
> I think Doug has made it perfectly clear that hfi1 will need to adopt the
> new ABI when it is available, and we are certainly on board with that.

It is too generic and not limited in time, I'm not against moving your
driver out of staging, just want to be sure that ABI effort won't be
limited by current hfi1 code which doesn't fit into current IB core
model.

> 
> -Denny

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <20160527045157.GW25500-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-05-27 11:44       ` Dennis Dalessandro
       [not found]         ` <20160527114414.GA27420-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Dennis Dalessandro @ 2016-05-27 11:44 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Doug Ledford, Linus Torvalds, linux-rdma

On Fri, May 27, 2016 at 07:51:57AM +0300, Leon Romanovsky wrote:
>On Thu, May 26, 2016 at 06:34:28PM -0400, Doug Ledford wrote:
>> Hi Linus,
>> 
>> This is the second group of code for the 4.7 merge window.  It looks
>> large, but only in one sense.  I'll get to that in a minute.  The list
>> of changes here breaks down as follows:
>> 
>> Round two of 4.7 merge window patches
>> 
>
><...>
>
>> - The big item on the list: hfi1 driver updates, plus moving the hfi1
>>   driver out of staging                             <- everything else
>
>Hi Doug and Linus,
>
>The move hfi1 from the staging is a right thing, it was there a long
>time and it is almost ready.

No, not almost, it is totally ready. We have bent over backwards to go well 
beyond what was in the TODO list. This is a clean, stable, and well 
performing driver.

>However the timing of this move puzzle me, we are in the process of ABI
>change [1, 2] as a response to security alert [3]. Moves like this with
>proprietary char device and ABI scheme different from whole RDMA stack
>will limit the ABI work without real need.

The driver sitting in staging or not has no impact on the ABI re-design.  
They are two completely separate issues.

>Will this driver be **forced** to adjust to new ABI scheme whenever it
>comes? If it is not possible, the better solution to converge on ABI change will be
>to leave this driver in staging/rdma and wait till proper solution will be accepted.

I think Doug has made it perfectly clear that hfi1 will need to adopt the 
new ABI when it is available, and we are certainly on board with that.

-Denny
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <166c87fa-09ef-f170-7351-d18062bc25cf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-05-27  4:51   ` Leon Romanovsky
       [not found]     ` <20160527045157.GW25500-2ukJVAZIZ/Y@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-05-27  4:51 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Thu, May 26, 2016 at 06:34:28PM -0400, Doug Ledford wrote:
> Hi Linus,
> 
> This is the second group of code for the 4.7 merge window.  It looks
> large, but only in one sense.  I'll get to that in a minute.  The list
> of changes here breaks down as follows:
> 
> Round two of 4.7 merge window patches
> 

<...>

> - The big item on the list: hfi1 driver updates, plus moving the hfi1
>   driver out of staging                             <- everything else

Hi Doug and Linus,

The move hfi1 from the staging is a right thing, it was there a long
time and it is almost ready.

However the timing of this move puzzle me, we are in the process of ABI
change [1, 2] as a response to security alert [3]. Moves like this with
proprietary char device and ABI scheme different from whole RDMA stack
will limit the ABI work without real need.

Will this driver be **forced** to adjust to new ABI scheme whenever it
comes? If it is not possible, the better solution to converge on ABI change will be
to leave this driver in staging/rdma and wait till proper solution will be accepted.

Thanks.

[1] http://marc.info/?l=linux-rdma&m=146407111911544&w=2
[2] http://marc.info/?l=linux-rdma&m=146410054120206&w=2
[3] https://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?id=e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-05-26 22:34 Doug Ledford
       [not found] ` <166c87fa-09ef-f170-7351-d18062bc25cf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-05-26 22:34 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 18639 bytes --]

Hi Linus,

This is the second group of code for the 4.7 merge window.  It looks
large, but only in one sense.  I'll get to that in a minute.  The list
of changes here breaks down as follows:

Round two of 4.7 merge window patches

- Dynamic counter infrastructure in the IB drivers  <- 1 patch
  This is a sysfs based code to allow free form access to the hardware
  counters RDMA devices might support so drivers don't need to code
  this up repeatedly themselves
- SendOnlyFullMember multicast support              <- 4 patches
- IB router support                                 <- 4 patches
- A couple misc fixes                               <- 4 or so here
- The big item on the list: hfi1 driver updates, plus moving the hfi1
  driver out of staging                             <- everything else

There was a group of 15 patches in the hfi1 list that I thought I had in
the first pull request but they weren't.  So that added to the length of
the hfi1 section here.

As far as these go, everything but the hfi1 is pretty straight forward.
The hfi1 is, if you recall, the driver that Al had complaints about how
it used the write/writev interfaces in an overloaded fashion.  The write
portion of their interface behaved like the write handler in the IB
stack proper and did bi-directional communications.  The writev
interface, on the other hand, only accepts SDMA request structures.  The
completions for those structures are sent back via an entirely different
event mechanism.  With the security patch, we put security checks on the
write interface, however, we also knew they would be going away soon.
Now, we've converted the write handler in the hfi1 driver to use ioctls
from the IB reserved magic area for its bidirectional communications.
With that change, Intel has addressed
all of the items originally on their TODO when they went into staging
(as well as many items added to the list later).  As such, I moved them
out, and since they were the last item in the staging/rdma directory,
and I don't have immediate plans to use the staging area again, I
removed the staging/rdma area.  Because of the move out of staging, as
well as a series of 5 patches in the hfi1 driver that removed code
people thought should be done in a different way and was optional to
begin with (a snoop debug interface, an eeprom driver for an eeprom
connected directory to their hfi1 chip and not via an i2c bus, and a few
other things like that), the line count, especially the removal count,
is high.

I know we have a long weekend coming up, so I wanted to get this out
before Friday so you had plenty of time to digest and look it over.  Let
me know if you see anything amiss.

Now the boilerplate:

The following changes since commit c16d2750a08c8ccaf98d65f287a8aec91bb9610d:

  IB/mlx5: Fire the CQ completion handler from tasklet (2016-05-18
10:45:49 -0400)

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 7a226f9c32b0481b0744e2726cd7f8349b866af5:

  staging/rdma: Remove the entire rdma subdirectory of staging
(2016-05-26 12:59:34 -0400)

----------------------------------------------------------------
Round two of 4.7 merge window patches

- Dynamic counter infrastructure in the IB drivers
  This is a sysfs based code to allow free form access to the hardware
  counters RDMA devices might support so drivers don't need to code
  this up repeatedly themselves
- SendOnlyFullMember multicast support
- IB router support
- A couple misc fixes
- The big item on the list: hfi1 driver updates, plus moving the hfi1
  driver out of staging

----------------------------------------------------------------
Ashutosh Dixit (1):
      IB/hfi1: Change hfi1_init loop to preserve error returns

Christoph Lameter (1):
      IB/core: Make device counter infrastructure dynamic

Dean Luick (3):
      IB/hfi1: Remove no-op QSFP reset code
      IB/hfi1: Immediately apply congestion setting MAD
      IB/hfi1: Correct 8051 link parameter settings

Dennis Dalessandro (11):
      IB/hfi1: Remove anti-pattern in cdev init
      IB/hfi1: Remove multiple device cdev
      IB/hfi1: Remove UI char device
      IB/hfi1: Remove EPROM functionality from data device
      IB/hfi1: Remove snoop/diag interface
      IB/hfi1: Remove unused user command
      IB/hfi1: Add ioctl() interface for user commands
      IB/hfi1: Remove write(), use ioctl() for user cmds
      IB/hfi1: Add trace message in user IOCTL handling
      IB/hfi1: Do not free hfi1 cdev parent structure early
      IB/hfi1: Move driver out of staging

Doug Ledford (3):
      Merge branches 'misc-4.7-2', 'ipoib' and 'ib-router' into k.o/for-4.7
      Merge branch 'hfi1-2' into k.o/for-4.7
      staging/rdma: Remove the entire rdma subdirectory of staging

Easwar Hariharan (3):
      IB/hfi1: Ignore non-temperature warnings on a downed link
      IB/hfi1: Wait for QSFP modules to initialize
      IB/hfi1: Correct external device configuration shift

Erez Shitrit (4):
      IB/core: Introduce capabilitymask2 field in ClassPortInfo mad
      IB/SA Agent: Add support for SA agent get ClassPortInfo
      IB/core: Support new type of join-state for multicast
      IB/ipoib: Support SendOnlyFullMember MCG for SendOnly join

Honggang Li (1):
      RDMA/cxgb3: device driver frees DMA memory with different size

Ira Weiny (1):
      IB/hfi1: Remove unnecessary comment

Jakub Pawlak (1):
      IB/hfi1: Correct log message strings

Jianxin Xiong (5):
      IB/hfi1: Keep SC_USER as the last send context type
      ib_pack.h: Add opcode definition for send with invalidate
      IB/hfi1: Fix bug that blocks process on exit after port bounce
      IB/hfi1, qib: Add ieth to the packet header definitions
      IB/hfi1: Add tracing support for send with invalidate opcode

Jubin John (6):
      IB/hfi1: Remove unnecessary header
      IB/hfi1: Fix hfi_rcvhdr tracepoint
      IB/rdmavt: Use kzalloc_node
      IB/hfi1: Fix sdma_event_names[] build warning
      IB/qib: Remove unused qib_7322_intr_msgs[]
      IB/hfi1: Fix pio map initialization

Leon Romanovsky (1):
      IB/core: Integrate IB address resolution module into core

Mark Bloch (6):
      IB/MAD: Integrate ib_mad module into ib_core module
      IB/SA: Integrate ib_sa module into ib_core module
      IB/netlink: Add a new local service operation
      IB/core: Register SA ibnl client during ib_core initialization
      IB/core: Add IP to GID netlink offload
      IB/IPoIB: Allow setting the device address

Mike Marciniszyn (7):
      IB/hfi1: Fix pio wait counter double increment
      IB/hfi1: Fix potential panic with sdma drained mechanism
      IB/rdmavt: Increase CQ callback thread priority
      IB/rdmavt: Insure QP vmalloc variants zero memory
      IB/hfi1: Fix hard lockup due to not using save/restore spin lock
      IB/rdmavt: Max atomic value should be a u8
      IB/rdamvt: Fix rdmavt s_ack_queue sizing

Mitko Haralanov (2):
      IB/hfi1: Improve performance of interval RB trees
      IB/hfi1: Fix an interval RB node reference count leak

Muhammad Falak R Wani (1):
      staging/rdma/hfi1: use RCU_INIT_POINTER() when NULLing.

Sebastian Sanchez (1):
      IB/hfi1: Update pkey table properly after link down or FM start

 Documentation/infiniband/sysfs.txt                 |   12 +
 MAINTAINERS                                        |   14 +-
 drivers/infiniband/Kconfig                         |    2 +
 drivers/infiniband/core/Makefile                   |   12 +-
 drivers/infiniband/core/addr.c                     |  226 ++-
 drivers/infiniband/core/core_priv.h                |   16 +
 drivers/infiniband/core/device.c                   |   58 +
 drivers/infiniband/core/mad.c                      |   13 +-
 drivers/infiniband/core/multicast.c                |   23 +-
 drivers/infiniband/core/sa_query.c                 |  211 ++-
 drivers/infiniband/core/sysfs.c                    |  366 ++--
 drivers/infiniband/hw/Makefile                     |    1 +
 drivers/infiniband/hw/cxgb3/cxio_hal.c             |    2 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |  147 +-
 drivers/infiniband/hw/cxgb4/provider.c             |   58 +-
 .../{staging/rdma => infiniband/hw}/hfi1/Kconfig   |    0
 .../{staging/rdma => infiniband/hw}/hfi1/Makefile  |    2 +-
 .../rdma => infiniband/hw}/hfi1/affinity.c         |    0
 .../rdma => infiniband/hw}/hfi1/affinity.h         |    0
 .../{staging/rdma => infiniband/hw}/hfi1/aspm.h    |    0
 .../{staging/rdma => infiniband/hw}/hfi1/chip.c    |   41 +-
 .../{staging/rdma => infiniband/hw}/hfi1/chip.h    |    6 +
 .../rdma => infiniband/hw}/hfi1/chip_registers.h   |    0
 .../{staging/rdma => infiniband/hw}/hfi1/common.h  |    5 +-
 .../{staging/rdma => infiniband/hw}/hfi1/debugfs.c |    0
 .../{staging/rdma => infiniband/hw}/hfi1/debugfs.h |    0
 .../{staging/rdma => infiniband/hw}/hfi1/device.c  |   18 +-
 .../{staging/rdma => infiniband/hw}/hfi1/device.h  |    3 +-
 drivers/{staging/rdma => infiniband/hw}/hfi1/dma.c |    0
 .../{staging/rdma => infiniband/hw}/hfi1/driver.c  |    2 +-
 .../{staging/rdma => infiniband/hw}/hfi1/efivar.c  |    0
 .../{staging/rdma => infiniband/hw}/hfi1/efivar.h  |    0
 drivers/infiniband/hw/hfi1/eprom.c                 |  102 ++
 .../{staging/rdma => infiniband/hw}/hfi1/eprom.h   |    0
 .../rdma => infiniband/hw}/hfi1/file_ops.c         |  549 ++----
 .../rdma => infiniband/hw}/hfi1/firmware.c         |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/hfi.h |    7 +-
 .../{staging/rdma => infiniband/hw}/hfi1/init.c    |   22 +-
 .../{staging/rdma => infiniband/hw}/hfi1/intr.c    |    0
 .../{staging/rdma => infiniband/hw}/hfi1/iowait.h  |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/mad.c |   99 +-
 drivers/{staging/rdma => infiniband/hw}/hfi1/mad.h |    0
 .../{staging/rdma => infiniband/hw}/hfi1/mmu_rb.c  |   22 +-
 .../{staging/rdma => infiniband/hw}/hfi1/mmu_rb.h  |    0
 .../rdma => infiniband/hw}/hfi1/opa_compat.h       |    0
 .../{staging/rdma => infiniband/hw}/hfi1/pcie.c    |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/pio.c |    3 +-
 drivers/{staging/rdma => infiniband/hw}/hfi1/pio.h |    8 +-
 .../rdma => infiniband/hw}/hfi1/pio_copy.c         |    0
 .../rdma => infiniband/hw}/hfi1/platform.c         |   27 +-
 .../rdma => infiniband/hw}/hfi1/platform.h         |    1 +
 drivers/{staging/rdma => infiniband/hw}/hfi1/qp.c  |    9 +-
 drivers/{staging/rdma => infiniband/hw}/hfi1/qp.h  |    0
 .../{staging/rdma => infiniband/hw}/hfi1/qsfp.c    |    0
 .../{staging/rdma => infiniband/hw}/hfi1/qsfp.h    |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/rc.c  |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/ruc.c |    0
 .../{staging/rdma => infiniband/hw}/hfi1/sdma.c    |    4 +-
 .../{staging/rdma => infiniband/hw}/hfi1/sdma.h    |    0
 .../rdma => infiniband/hw}/hfi1/sdma_txreq.h       |    0
 .../{staging/rdma => infiniband/hw}/hfi1/sysfs.c   |    4 +-
 .../{staging/rdma => infiniband/hw}/hfi1/trace.c   |    8 +
 .../{staging/rdma => infiniband/hw}/hfi1/trace.h   |    5 +-
 .../{staging/rdma => infiniband/hw}/hfi1/twsi.c    |    0
 .../{staging/rdma => infiniband/hw}/hfi1/twsi.h    |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/uc.c  |    0
 drivers/{staging/rdma => infiniband/hw}/hfi1/ud.c  |    0
 .../rdma => infiniband/hw}/hfi1/user_exp_rcv.c     |    0
 .../rdma => infiniband/hw}/hfi1/user_exp_rcv.h     |    0
 .../rdma => infiniband/hw}/hfi1/user_pages.c       |    0
 .../rdma => infiniband/hw}/hfi1/user_sdma.c        |   18 +-
 .../rdma => infiniband/hw}/hfi1/user_sdma.h        |    0
 .../{staging/rdma => infiniband/hw}/hfi1/verbs.c   |    4 +-
 .../{staging/rdma => infiniband/hw}/hfi1/verbs.h   |    1 +
 .../rdma => infiniband/hw}/hfi1/verbs_txreq.c      |    0
 .../rdma => infiniband/hw}/hfi1/verbs_txreq.h      |    0
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |  145 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |   15 -
 drivers/infiniband/hw/qib/qib_mad.c                |    6 +-
 drivers/infiniband/hw/qib/qib_verbs.h              |    1 +
 drivers/infiniband/sw/rdmavt/cq.c                  |    1 +
 drivers/infiniband/sw/rdmavt/mr.c                  |    4 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   30 +-
 drivers/infiniband/ulp/ipoib/ipoib.h               |    4 +
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |  109 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |  140 ++
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |   48 +-
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c         |    3 +
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c          |    2 +
 drivers/infiniband/ulp/srpt/ib_srpt.c              |    2 +-
 drivers/staging/Kconfig                            |    2 -
 drivers/staging/Makefile                           |    1 -
 drivers/staging/rdma/Kconfig                       |   27 -
 drivers/staging/rdma/Makefile                      |    2 -
 drivers/staging/rdma/hfi1/TODO                     |    6 -
 drivers/staging/rdma/hfi1/diag.c                   | 1925
--------------------
 drivers/staging/rdma/hfi1/eprom.c                  |  471 -----
 include/rdma/ib_mad.h                              |   60 +-
 include/rdma/ib_pack.h                             |    5 +
 include/rdma/ib_sa.h                               |   12 +
 include/rdma/ib_verbs.h                            |  126 +-
 include/rdma/rdma_vt.h                             |   13 +-
 include/rdma/rdmavt_qp.h                           |    5 +-
 include/uapi/rdma/hfi/hfi1_user.h                  |   80 +-
 include/uapi/rdma/rdma_netlink.h                   |   10 +
 105 files changed, 1986 insertions(+), 3400 deletions(-)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/Kconfig (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/Makefile (88%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/affinity.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/affinity.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/aspm.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/chip.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/chip.h (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/chip_registers.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/common.h (98%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/debugfs.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/debugfs.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/device.c (94%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/device.h (97%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/dma.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/driver.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/efivar.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/efivar.h (100%)
 create mode 100644 drivers/infiniband/hw/hfi1/eprom.c
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/eprom.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/file_ops.c (78%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/firmware.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/hfi.h (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/init.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/intr.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/iowait.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/mad.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/mad.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/mmu_rb.c (95%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/mmu_rb.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/opa_compat.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/pcie.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/pio.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/pio.h (98%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/pio_copy.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/platform.c (98%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/platform.h (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/qp.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/qp.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/qsfp.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/qsfp.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/rc.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/ruc.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/sdma.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/sdma.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/sdma_txreq.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/sysfs.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/trace.c (97%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/trace.h (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/twsi.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/twsi.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/uc.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/ud.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/user_exp_rcv.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/user_exp_rcv.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/user_pages.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/user_sdma.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/user_sdma.h (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/verbs.c (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/verbs.h (99%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/verbs_txreq.c (100%)
 rename drivers/{staging/rdma => infiniband/hw}/hfi1/verbs_txreq.h (100%)
 delete mode 100644 drivers/staging/rdma/Kconfig
 delete mode 100644 drivers/staging/rdma/Makefile
 delete mode 100644 drivers/staging/rdma/hfi1/TODO
 delete mode 100644 drivers/staging/rdma/hfi1/diag.c
 delete mode 100644 drivers/staging/rdma/hfi1/eprom.c


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-05-20 20:03 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-05-20 20:03 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 19368 bytes --]

Hi Linus,

This is the primary 4.7 pull.  There are a few more patches in the wings
but I'm not sending them yet.  There are a few known merge issues:

1) An mlx5 merge issue.  Two different patches both add new #include
directives in the same file.  This would have possibly been caught and
fixed up by our new working arrangement with Mellanox, but the patch I
took that induced the issue was an older one from the list that predated
the new working setup.  The fixup is a no-brainer, so I left it as is.

2) An NFSoRDMS merge issue.  The NFS tree has a cleanup patch that
touches the same for statement that one of our cleanup patches touches.
I've only got 2 lines of diff for the NFSoRDMA tree this time around and
we managed to get a conflict.  It's another simple fixup.

3) As per your comments a cycle or two ago, I used topic branches for my
work.  So if there's something you don't like in this pull request,
topic branches can be used to separate things out.  However, there are a
few patches that went directly onto the branch I'm having you pull from,
so if you see anything you don't like, please don't try to use the topic
branches to recreate things yourself.  That will only frustrate you and
get me yelled at.  Let me know what you want removed and I'll fix up a
new branch for you.

Otherwise, it's all typical stuff.  Here's the git boilerplate:

The following changes since commit e29bff46b9b8663e1789fbcd65d0ba05a52f08af:

  Merge branch 'k.o/for-4.6-rc' into testing/4.6 (2016-04-28 15:16:32 -0400)

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 c16d2750a08c8ccaf98d65f287a8aec91bb9610d:

  IB/mlx5: Fire the CQ completion handler from tasklet (2016-05-18
10:45:49 -0400)

----------------------------------------------------------------
Primary 4.7 merge window changes

- Updates to the new Intel X722 iWARP driver
- Updates to the hfi1 driver
- Fixes for the iw_cxgb4 driver
- Misc core fixes
- Generic RDMA READ/WRITE API addition
- SRP updates
- Misc ipoib updates
- Minor mlx5 updates

----------------------------------------------------------------
Andy Shevchenko (1):
      RDMA/nes: replace custom print_hex_dump()

Bart Van Assche (18):
      IB/srp: Fix a spelling error in a source code comment
      IB/srp: Fix a comment
      IB/srp: Document srp_map_data() return value
      IB/srp: Fix srp_map_data() error paths
      IB/srp: Introduce target->mr_pool_size
      IB/srp: Avoid that mapping failure triggers an infinite loop
      IB/srp: Move code out of a loop
      IB/srp: Move common code into the caller
      IB/srp: Print "ib_srp: " prefix once
      IB/srp: Fix a memory descriptor leak in an error path
      IB/srp: Fix srp_create_target() error handling
      IB/core: Enhance ib_map_mr_sg()
      IB/srp: Swap two code blocks in srp_add_one()
      IB/srp: Prevent mapping failures
      IB/srp: Do not register memory if never_register has been set
      iw_cxgb4: Convert a __force cast
      IB/srp: Fix a debug kernel crash
      iwcm: Fix a sparse warning

Chien Tin Tung (1):
      RDMA/i40iw: Correct STag mask to min of 14 bits

Christoph Hellwig (11):
      IB/iser: Fix max_sectors calculation
      IB/cma: pass the port number to ib_create_qp
      IB/core: Add passing an offset into the SG to ib_map_mr_sg
      IB/core: add a helper to check for READ WITH INVALIDATE support
      IB/core: refactor ib_create_qp
      IB/core: add a simple MR pool
      IB/core: generic RDMA READ/WRITE API
      target: enhance and export target_alloc_sgl/target_free_sgl
      IB/srpt: convert to the generic RDMA READ/WRITE API
      IB/core: add RW API support for signature MRs
      IB/isert: convert to the generic RDMA READ/WRITE API

Christoph Lameter (1):
      IB/core: Do not require CAP_NET_ADMIN for packet sniffing

Colin Ian King (4):
      i40iw: pass hw_stats by reference rather than by value
      i40iw: pass hw_stats by reference rather than by value
      IB/mlx4: trivial fix of spelling mistake on "argument"
      i40iw: pass hw_stats by reference rather than by value

Dean Luick (17):
      IB/hfi1: Fix sysfs file offset usage
      IB/hfi1: Fix i2c resource reservation checks
      IB/hfi1: Fix QOS num_vl bit width
      IB/hfi1: Remove invalid QOS check
      IB/hfi1: Fix QOS rule mappings
      IB/hfi1: Correctly obtain the full service class
      IB/hfi1: Simplify init_qpmap_table()
      IB/hfi1: Guard against concurrent I2C access across all chains
      IB/hfi1: Fix double QSFP resource acquire on cache refresh
      IB/hfi1: Extract RSM map table init from QOS
      IB/hfi1: Move QOS decision logic into its own function
      IB/hfi1: Create a routine to set a receive side mapping rule
      IB/hfi1: Add RSM rule for user FECN handling
      IB/hfi1: Ignore link downgrade with 0 lanes
      IB/hfi1: Use the neighbor link down reason only when valid
      IB/hfi1: Correctly report neighbor link down reason
      IB/hfi1: Fix MAD port poll for active cables

Denys Vlasenko (1):
      IB/nes: Deinline nes_free_qp_mem, save 1072 bytes

Doug Ledford (3):
      Merge branches 'hfi1' and 'iw_cxgb4' into k.o/for-4.7
      Merge branches 'mlx5-1' and 'srp-1' into k.o/for-4.7
      Merge branches 'cxgb4-2', 'i40iw-2', 'ipoib', 'misc-4.7' and
'mlx5-fcs' into k.o/for-4.7

Easwar Hariharan (2):
      IB/hfi1: Always turn on CDRs for low power QSFP modules
      IB/hfi1: Remove module presence check outside pre-LNI checks

Florian Westphal (1):
      RDMA/nes: don't leak skb if carrier down

Geliang Tang (1):
      IB/mlx4: Use list_for_each_entry_safe

Guy Levi (1):
      IB/mlx5: Add UARs write-combining and non-cached mapping

Hans Westgaard Ry (1):
      IB/ipoib: Add readout of statistics using ethtool

Hariprasad S (26):
      RDMA/iw_cxgb4: release ep resources on accept arp failure
      RDMA/iw_cxgb4: stop ep timer on close failure
      RDMA/iw_cxgb4: ensure eps don't get freed while the mutex is held
      RDMA/iw_cxgb4: remove connection abort from process_mpa_reply
      RDMA/iw_cxgb4: free resources when send_flowc() fails
      RDMA/iw_cxgb4: remove abort_connection() usage from accept/reject
      RDMA/iw_cxgb4: don't use abort_connection in process_mpa_request()
      RDMA/iw_cxgb4: move QP -> ERROR on fatal disconnect errors
      RDMA/iw_cxgb4: remove abort_connection() usage from ep_timeout()
      RDMA/iw_cxgb4: Add few history bits for ep
      RDMA/iw_cxgb4: Correct RFC number of MPA
      RDMA/iw_cxgb4: set the correct FID value in DSGL commands
      RDMA/iw_cxgb4: parent_ep has to be dereferenced in case of passive
accept failure
      RDMA/iw_cxgb4: Do not stop timer in case of incomplete messages
      RDMA/iw_cxgb4: stop_ep_timer() after MPA negotiation
      RDMA/iw_cxgb4: handle return value of c4iw_l2t_send() and
send_mpa_req()
      RDMA/iw_cxgb4: in process_timeout() don't move ep state to ABORTING
      RDMA/iw_cxgb4: Handle return value of c4iw_ofld_send() in
abort_arp_failure()
      RDMA/iw_cxgb4: atomically lookup ep and get a reference
      RDMA/iw_cxgb4: Free skb in case of arp failure in _c4iw_free_ep()
      RDMA/iw_cxgb4: Release ep for for FPDU_MODE and MPA_REQ_RCVD in
process_timeout
      RDMA/iw_cxgb4: Handle ULP accept/reject during ABORTING
      RDMA/iw_cxgb4: atomic find and reference for listening endpoints
      RDMA/iw_cxgb4: Handle ret value of process_mpa_reply() in rx_data
      RDMA/iw_cxgb4: Always wake up waiter in c4iw_peer_abort_intr()
      RDMA/iw_cxgb4: Add arp failure handlers to send_mpa_reply/reject()

Ismail, Mustafa (16):
      RDMA/i40iw: Fix overflow of region length
      RDMA/i40iw: Correct QP size calculation
      RDMA/i40iw: Fix refused connections
      RDMA/i40iw: Correct max message size in query port
      RDMA/i40iw: Do not set self-referencing pointer to NULL after free
      RDMA/i40iw: Add qp table lock around AE processing
      RDMA/i40iw: Set vendor_err only if there is an actual error
      RDMA/i40iw: Populate vendor_id and vendor_part_id fields
      RDMA/i40iw: Remove unused code and fix warning
      RDMA/i40iw: Add virtual channel message queue
      RDMA/i40iw: Correct return code check in add_pble_pool
      RDMA/i40iw: Initialize max enabled vfs variable
      RDMA/i40iw: Add base memory management extensions
      RDMA/i40iw: Fix endian issues and warnings
      RDMA/i40iw: Fix SD calculation for initial HMC creation
      RDMA/i40iw: Adding queue drain functions

Jianxin Xiong (1):
      IB/hfi1: Reduce kernel context pio buffer allocation

Jubin John (3):
      IB/rdmavt,hfi1,qib: Fix memory leak
      IB/hfi1: Change default number of user contexts
      IB/hfi1: Serialize hrtimer function calls

Julia Lawall (4):
      i40e: constify i40e_client_ops structure
      i40iw: constify i40iw_vf_cqp_ops structure
      i40iw: constify i40iw_vf_cqp_ops structure
      i40iw: constify i40iw_vf_cqp_ops structure

Lars-Peter Clausen (3):
      i40iw: Remove unnecessary synchronize_irq() before free_irq()
      i40iw: Remove unnecessary synchronize_irq() before free_irq()
      i40iw: Remove unnecessary synchronize_irq() before free_irq()

Majd Dibbiny (5):
      IB/core: Add extended device capability flags
      IB/core: Add Raw Scatter FCS device capability
      IB/core: Add Scatter FCS create flag
      IB/mlx5: Add Scatter FCS support for Raw Packet QP
      IB/mlx5: Report Scatter FCS device capability when supported

Mark Bloch (4):
      IB/IWPM: Fix a potential skb leak
      IB/core: Remove unnecessary check in ibnl_rcv_msg
      IB/core: Fix a potential array overrun in CMA and SA agent
      IB/SA: Use correct free function

Matan Barak (3):
      IB/mlx5: Allow mapping the free running counter on PROT_EXEC
      net/mlx5_core: Use tasklet for user-space CQ completion events
      IB/mlx5: Fire the CQ completion handler from tasklet

Mike Marciniszyn (4):
      IB/rdmavt: Fix adaptive pio hang
      IB/qib, IB/hfi1: Fix up UD loopback use of irq flags
      IB/hfi1: Remove unreachable code
      IB/hfi1: Use global defines for upper bits in opcode

Mitko Haralanov (6):
      IB/hfi1: Don't remove list entries if they are not in a list
      IB/hfi1: Fix memory leak in user ExpRcv and SDMA
      IB/hfi1: Protect the interval RB tree when cleaning up
      IB/hfi1: Correctly compute node interval
      IB/hfi1: Extract and reinsert MMU RB node on lookup
      IB/hfi1: Fix buffer cache races which may cause corruption

Mohammad Khan (1):
      RDMA/i40iw: Fix for a NOP WQE size

Saeed Mahameed (1):
      net/mlx5: Update mlx5_ifc hardware features

Sebastian Andrzej Siewior (1):
      infiniband/ulp/ipoib: remove pkey_mutex

Sebastian Sanchez (2):
      IB/hfi1: Adjust default MTU to be 10KB
      IB/hfi1: Check P_KEY for all sent packets from user mode

Shiraz Saleem (3):
      RDMA/i40iw: Fixes for WQE alignment
      RDMA/i40iw: Fix for the size of kernel mode SQ
      RDMA/i40iw: Fix for using one sge for RDMA READ

Steve Wise (1):
      IB/core: add a need_inval flag to struct ib_mr

Tariq Toukan (1):
      net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets

Tatyana Nikolova (3):
      RDMA/i40iw: Fix for checking if the QP is destroyed
      RDMA/i40iw: Fix for removing quad hash entries
      RDMA/nes: Adding queue drain functions

shamir rabinovitch (1):
      IB/mlx4: Fix unaligned access in send_reply_to_slave

 drivers/infiniband/core/Makefile                   |   4 +-
 drivers/infiniband/core/cma.c                      |   4 +-
 drivers/infiniband/core/iwcm.c                     |   4 +-
 drivers/infiniband/core/iwpm_util.c                |   1 +
 drivers/infiniband/core/mr_pool.c                  |  86 +++
 drivers/infiniband/core/netlink.c                  |   5 +-
 drivers/infiniband/core/rw.c                       | 727 ++++++++++++++++++
 drivers/infiniband/core/sa_query.c                 |   4 +-
 drivers/infiniband/core/uverbs_cmd.c               |  11 +-
 drivers/infiniband/core/verbs.c                    | 172 +++--
 drivers/infiniband/hw/cxgb3/iwch_provider.c        |   7 +-
 drivers/infiniband/hw/cxgb4/cm.c                   | 611 ++++++++++-----
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h             |  14 +-
 drivers/infiniband/hw/cxgb4/mem.c                  |  12 +-
 drivers/infiniband/hw/i40iw/i40iw.h                |   7 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c             | 148 ++--
 drivers/infiniband/hw/i40iw/i40iw_cm.h             |  10 +-
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           | 185 +++--
 drivers/infiniband/hw/i40iw/i40iw_d.h              |   4 +-
 drivers/infiniband/hw/i40iw/i40iw_hw.c             |  14 +-
 drivers/infiniband/hw/i40iw/i40iw_main.c           |  58 +-
 drivers/infiniband/hw/i40iw/i40iw_osdep.h          |   1 +
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |   9 +-
 drivers/infiniband/hw/i40iw/i40iw_puda.c           |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_status.h         |   1 +
 drivers/infiniband/hw/i40iw/i40iw_type.h           |  14 +-
 drivers/infiniband/hw/i40iw/i40iw_uk.c             | 106 +--
 drivers/infiniband/hw/i40iw/i40iw_user.h           |  36 +-
 drivers/infiniband/hw/i40iw/i40iw_utils.c          |  47 +-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          | 294 ++++++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.h          |   3 +
 drivers/infiniband/hw/i40iw/i40iw_vf.c             |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_vf.h             |   2 +-
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c       | 102 +--
 drivers/infiniband/hw/mlx4/main.c                  |   2 +-
 drivers/infiniband/hw/mlx4/mcg.c                   |   9 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h               |   5 +-
 drivers/infiniband/hw/mlx4/mr.c                    |   7 +-
 drivers/infiniband/hw/mlx5/cq.c                    |   5 +-
 drivers/infiniband/hw/mlx5/main.c                  | 102 ++-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |   8 +-
 drivers/infiniband/hw/mlx5/mr.c                    |  25 +-
 drivers/infiniband/hw/mlx5/qp.c                    |  20 +-
 drivers/infiniband/hw/nes/nes_nic.c                |   3 -
 drivers/infiniband/hw/nes/nes_utils.c              |  60 +-
 drivers/infiniband/hw/nes/nes_verbs.c              |  43 +-
 drivers/infiniband/hw/nes/nes_verbs.h              |   2 +
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c        |   7 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.h        |   5 +-
 drivers/infiniband/hw/qib/qib_init.c               |   4 +-
 drivers/infiniband/hw/qib/qib_rc.c                 |   2 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |   4 +-
 drivers/infiniband/hw/qib/qib_uc.c                 |   2 +-
 drivers/infiniband/hw/qib/qib_ud.c                 |  10 +-
 drivers/infiniband/hw/qib/qib_verbs.h              |   6 +-
 drivers/infiniband/sw/rdmavt/qp.c                  |   6 +-
 drivers/infiniband/sw/rdmavt/vt.c                  |  13 +
 drivers/infiniband/ulp/ipoib/ipoib_ethtool.c       |  67 ++
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |   2 -
 drivers/infiniband/ulp/iser/iscsi_iser.c           |  14 +-
 drivers/infiniband/ulp/iser/iser_memory.c          |   4 +-
 drivers/infiniband/ulp/isert/ib_isert.c            | 841
++-------------------
 drivers/infiniband/ulp/isert/ib_isert.h            |  69 +-
 drivers/infiniband/ulp/srp/ib_srp.c                | 229 ++++--
 drivers/infiniband/ulp/srp/ib_srp.h                |   2 +
 drivers/infiniband/ulp/srpt/ib_srpt.c              | 729 +++++++-----------
 drivers/infiniband/ulp/srpt/ib_srpt.h              |  31 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h        |   4 +
 drivers/net/ethernet/intel/i40e/i40e_client.h      |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/cq.c       |  59 ++
 drivers/net/ethernet/mellanox/mlx5/core/eq.c       |  12 +-
 drivers/net/ethernet/mellanox/mlx5/core/main.c     |  17 +
 .../net/ethernet/mellanox/mlx5/core/mlx5_core.h    |   2 +
 drivers/staging/rdma/hfi1/affinity.c               |  93 +--
 drivers/staging/rdma/hfi1/affinity.h               |  19 +-
 drivers/staging/rdma/hfi1/chip.c                   | 647 +++++++++++-----
 drivers/staging/rdma/hfi1/chip.h                   |   7 +-
 drivers/staging/rdma/hfi1/chip_registers.h         |   1 +
 drivers/staging/rdma/hfi1/diag.c                   |   3 +-
 drivers/staging/rdma/hfi1/driver.c                 |   3 +-
 drivers/staging/rdma/hfi1/firmware.c               |   9 +-
 drivers/staging/rdma/hfi1/hfi.h                    |  11 +-
 drivers/staging/rdma/hfi1/init.c                   |  25 +-
 drivers/staging/rdma/hfi1/mad.c                    |  16 +-
 drivers/staging/rdma/hfi1/mmu_rb.c                 |  35 +-
 drivers/staging/rdma/hfi1/mmu_rb.h                 |   2 +
 drivers/staging/rdma/hfi1/pio.c                    |  52 +-
 drivers/staging/rdma/hfi1/pio.h                    |   4 +-
 drivers/staging/rdma/hfi1/platform.c               |  99 +--
 drivers/staging/rdma/hfi1/qp.c                     |   6 +-
 drivers/staging/rdma/hfi1/qsfp.c                   |  58 +-
 drivers/staging/rdma/hfi1/qsfp.h                   |  15 +-
 drivers/staging/rdma/hfi1/rc.c                     |   9 +-
 drivers/staging/rdma/hfi1/ruc.c                    |  20 +-
 drivers/staging/rdma/hfi1/sysfs.c                  |   4 +-
 drivers/staging/rdma/hfi1/ud.c                     |   8 +-
 drivers/staging/rdma/hfi1/user_exp_rcv.c           |   7 +-
 drivers/staging/rdma/hfi1/user_sdma.c              |  97 ++-
 drivers/staging/rdma/hfi1/verbs.c                  | 108 ++-
 drivers/staging/rdma/hfi1/verbs.h                  |   4 +-
 drivers/target/target_core_transport.c             |  32 +-
 drivers/target/target_core_xcopy.c                 |   2 +-
 include/linux/mlx5/cq.h                            |   5 +
 include/linux/mlx5/driver.h                        |  10 +
 include/linux/mlx5/mlx5_ifc.h                      | 253 +++++--
 include/rdma/ib_verbs.h                            |  61 +-
 include/rdma/mr_pool.h                             |  25 +
 include/rdma/rdma_vt.h                             |   1 +
 include/rdma/rdmavt_qp.h                           |   5 +-
 include/rdma/rw.h                                  |  88 +++
 include/target/target_core_backend.h               |   1 -
 include/target/target_core_fabric.h                |   4 +
 include/uapi/rdma/ib_user_verbs.h                  |   1 +
 net/rds/ib_frmr.c                                  |   2 +-
 net/sunrpc/xprtrdma/frwr_ops.c                     |   2 +-
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c            |   2 +-
 116 files changed, 4308 insertions(+), 2689 deletions(-)
 create mode 100644 drivers/infiniband/core/mr_pool.c
 create mode 100644 drivers/infiniband/core/rw.c
 create mode 100644 include/rdma/mr_pool.h
 create mode 100644 include/rdma/rw.h


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-05-06 20:11 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-05-06 20:11 UTC (permalink / raw)
  To: Linus Torvalds, RDMA mailing list

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Hi Linus,

I have one more fix queued up for -rc.

The following changes since commit 4c8bb95921e9ac01b9dd0c3abbaf6514ce88af92:

  RDMA/nes: don't leak skb if carrier down (2016-04-28 21:11:09 -0400)

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 9c674815d346305068b27bf03b5e86b659a1b111:

  IB/iser: Fix max_sectors calculation (2016-05-05 12:41:24 -0400)

----------------------------------------------------------------
Late 4.6-rc fixes

- Fix for max sector calculation in iSER

----------------------------------------------------------------
Christoph Hellwig (1):
      IB/iser: Fix max_sectors calculation

 drivers/infiniband/ulp/iser/iscsi_iser.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-04-29  3:05 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-04-29  3:05 UTC (permalink / raw)
  To: Linus Torvalds, RDMA mailing list

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

Hi Linus,

I've collected up a number of patches that are all pretty small with the
exception of only a couple.  The hfi1 driver has a number of important
patches, and it is what really drives the line count of this pull
request up.  These are all small and I've got this kernel built and
running in the test lab (I have most of the hardware, I think nes is the
only thing in this patch set that I can't say I've personally tested and
have up and running).  This also includes the patch for the security
issue which I was intentionally holding on to and not intending to send
until the very last minute, but since you said this might be the last
-rc cycle, that seems like it might well be now.

Here's the boilerplate:

The following changes since commit 2fe7857176ad6b70e8b2a318506525410e774f34:

  i40iw: avoid potential uninitialized variable use (2016-04-06 10:37:16
-0400)

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 4c8bb95921e9ac01b9dd0c3abbaf6514ce88af92:

  RDMA/nes: don't leak skb if carrier down (2016-04-28 21:11:09 -0400)

----------------------------------------------------------------
Final set of -rc fixes for 4.6

- A number of collected fixes for oopses, memory corruptions, deadlocks,
  etc.  All of these fixes are small (many only 5-10 lines), obvious,
  and tested.
- Fix for the security issue related to the use of write for
  bi-directional communications.

----------------------------------------------------------------
Dean Luick (1):
      IB/hfi1: Use kernel default llseek for ui device

Doug Ledford (1):
      IB/core: Fix oops in ib_cache_gid_set_default_gid

Florian Westphal (1):
      RDMA/nes: don't leak skb if carrier down

Hariprasad S (1):
      RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips

Jason Gunthorpe (1):
      IB/security: Restrict use of the write() interface

Jubin John (1):
      IB/rdmavt: Fix send scheduling

Mike Marciniszyn (1):
      IB/hfi1: Fix missing lock/unlock in verbs drain callback

Mitko Haralanov (4):
      IB/hfi1: Prevent NULL pointer deferences in caching code
      IB/hfi1: Fix deadlock caused by locking with wrong scope
      IB/hfi1: Prevent unpinning of wrong pages
      IB/hfi1: Don't attempt to free resources if initialization failed

Sagi Grimberg (3):
      IB/core: Don't drain non-existent rq queue-pair
      IB/mlx5: Expose correct max_sge_rd limit
      MAINTAINERS: Update iser/isert maintainer contact info

Steve Wise (3):
      iw_cxgb4: initialize ibdev.iwcm->ifname for port mapping
      iw_cxgb3: initialize ibdev.iwcm->ifname for port mapping
      iw_cxgb4: handle draining an idle qp

 MAINTAINERS                                 |  4 +-
 drivers/infiniband/core/cache.c             |  3 +-
 drivers/infiniband/core/ucm.c               |  4 ++
 drivers/infiniband/core/ucma.c              |  3 +
 drivers/infiniband/core/uverbs_main.c       |  5 ++
 drivers/infiniband/core/verbs.c             |  3 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c |  2 +
 drivers/infiniband/hw/cxgb4/cq.c            |  2 +-
 drivers/infiniband/hw/cxgb4/provider.c      |  2 +
 drivers/infiniband/hw/cxgb4/qp.c            | 24 +++++++-
 drivers/infiniband/hw/mlx5/main.c           |  2 +-
 drivers/infiniband/hw/nes/nes_nic.c         |  3 -
 drivers/infiniband/hw/qib/qib_file_ops.c    |  5 ++
 drivers/infiniband/sw/rdmavt/qp.c           |  4 +-
 drivers/staging/rdma/hfi1/TODO              |  2 +-
 drivers/staging/rdma/hfi1/file_ops.c        | 91
+++++++++++------------------
 drivers/staging/rdma/hfi1/mmu_rb.c          | 40 ++++++++-----
 drivers/staging/rdma/hfi1/mmu_rb.h          |  3 +-
 drivers/staging/rdma/hfi1/qp.c              |  2 +
 drivers/staging/rdma/hfi1/user_exp_rcv.c    | 11 ++--
 drivers/staging/rdma/hfi1/user_sdma.c       | 33 +++++++----
 include/linux/mlx5/device.h                 | 11 ++++
 include/rdma/ib.h                           | 16 +++++
 23 files changed, 173 insertions(+), 102 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-04-06 18:23 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-04-06 18:23 UTC (permalink / raw)
  To: Torvalds Linus, RDMA mailing list

[-- Attachment #1.1: Type: text/plain, Size: 1276 bytes --]

Hi Linus,

I'm back from PTO.  These issues cropped up while I was gone and are
simple fixes.  I'll have more after I've caught up, but I wanted to get
these in quick.

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:

  Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)

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 2fe7857176ad6b70e8b2a318506525410e774f34:

  i40iw: avoid potential uninitialized variable use (2016-04-06 10:37:16
-0400)

----------------------------------------------------------------
Two minor fixes for 4.6-rc2

- Fix mlx5 build error when on demand paging is not enabled
- Fix possible uninit variable in new i40iw driver

----------------------------------------------------------------
Arnd Bergmann (2):
      IB/mlx5: fix VFs callback function prototypes
      i40iw: avoid potential uninitialized variable use

 drivers/infiniband/hw/i40iw/i40iw_cm.c | 10 +++-------
 drivers/infiniband/hw/mlx5/mlx5_ib.h   | 18 +++++++++---------
 2 files changed, 12 insertions(+), 16 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
     GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 907 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
  2016-04-01  2:18                           ` David Miller
@ 2016-04-01  2:46                             ` Leon Romanovsky
  0 siblings, 0 replies; 186+ messages in thread
From: Leon Romanovsky @ 2016-04-01  2:46 UTC (permalink / raw)
  To: David Miller
  Cc: dledford, torvalds, linux-rdma, netdev, matanb, ogerlitz, leonro

On Thu, Mar 31, 2016 at 10:18:47PM -0400, David Miller wrote:
> From: Leon Romanovsky <leon@leon.nu>
> Date: Fri, 1 Apr 2016 02:38:28 +0300
> 
> > On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
> >> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> >> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> >> >> So the *best* situation would be:
> >> >>
> >> >>  - your two groups talk it over, and figure out what the common commits are
> >> >>
> >> >>  - you put those common commits as a "base" branch in git
> >> >>
> >> >>  - you ask the two upper-level maintainers to both pull that base branch
> >> >>
> >> >>  - you then make sure that you send the later patches (whether as
> >> >> emailed patches or as pull requests) based on top of that base branch.
> >> > 
> >> > Hi David and Doug,
> >> > 
> >> > Are you OK with the approach suggested by Linus?
> >> > We are eager to know it, so we will adopt it as soon
> >> > as possible in our development flow.
> >> > 
> >> > The original thread [1].
> >> > 
> >> > [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
> >> > 
> >> > Thanks.
> >> > 
> >> 
> >> I'm fine with it.  Since I happen to use topic branches to build my
> >> for-next from anyway, I might need to be the one that Dave pulls from
> >> versus the other way around.
> > 
> > Resending to linux-netdev.
> > 
> > David,
> > Can you please express your opinion about Linus's suggestion to
> > eliminate merge conflicts in Mellanox related products?
> 
> Sure, sounds fine.

Thank you, I appreciate a lot Doug's and your openness and
willingness to help us eliminate the future merge obstacles.

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                         ` <20160331233828.GE2670-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-04-01  2:18                           ` David Miller
  2016-04-01  2:46                             ` Leon Romanovsky
  0 siblings, 1 reply; 186+ messages in thread
From: David Miller @ 2016-04-01  2:18 UTC (permalink / raw)
  To: leon-2ukJVAZIZ/Y
  Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
	torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	matanb-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
	leonro-VPRAkNaXOzVWk0Htik3J/w

From: Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org>
Date: Fri, 1 Apr 2016 02:38:28 +0300

> On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
>> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
>> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
>> >> So the *best* situation would be:
>> >>
>> >>  - your two groups talk it over, and figure out what the common commits are
>> >>
>> >>  - you put those common commits as a "base" branch in git
>> >>
>> >>  - you ask the two upper-level maintainers to both pull that base branch
>> >>
>> >>  - you then make sure that you send the later patches (whether as
>> >> emailed patches or as pull requests) based on top of that base branch.
>> > 
>> > Hi David and Doug,
>> > 
>> > Are you OK with the approach suggested by Linus?
>> > We are eager to know it, so we will adopt it as soon
>> > as possible in our development flow.
>> > 
>> > The original thread [1].
>> > 
>> > [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
>> > 
>> > Thanks.
>> > 
>> 
>> I'm fine with it.  Since I happen to use topic branches to build my
>> for-next from anyway, I might need to be the one that Dave pulls from
>> versus the other way around.
> 
> Resending to linux-netdev.
> 
> David,
> Can you please express your opinion about Linus's suggestion to
> eliminate merge conflicts in Mellanox related products?

Sure, sounds fine.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <56F29C32.305-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  2016-03-23 13:56                       ` Leon Romanovsky
@ 2016-03-31 23:38                       ` Leon Romanovsky
       [not found]                         ` <20160331233828.GE2670-2ukJVAZIZ/Y@public.gmane.org>
  1 sibling, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-03-31 23:38 UTC (permalink / raw)
  To: David S. Miller
  Cc: Doug Ledford, Linus Torvalds, RDMA mailing list, linux-netdev,
	Matan Barak, Or Gerlitz, Leon Romanovsky

On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> >> So the *best* situation would be:
> >>
> >>  - your two groups talk it over, and figure out what the common commits are
> >>
> >>  - you put those common commits as a "base" branch in git
> >>
> >>  - you ask the two upper-level maintainers to both pull that base branch
> >>
> >>  - you then make sure that you send the later patches (whether as
> >> emailed patches or as pull requests) based on top of that base branch.
> > 
> > Hi David and Doug,
> > 
> > Are you OK with the approach suggested by Linus?
> > We are eager to know it, so we will adopt it as soon
> > as possible in our development flow.
> > 
> > The original thread [1].
> > 
> > [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
> > 
> > Thanks.
> > 
> 
> I'm fine with it.  Since I happen to use topic branches to build my
> for-next from anyway, I might need to be the one that Dave pulls from
> versus the other way around.

Resending to linux-netdev.

David,
Can you please express your opinion about Linus's suggestion to
eliminate merge conflicts in Mellanox related products?

Thanks

> 
> -- 
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
> 
> 


--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <56F4068F.2070608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-03-28  9:42                   ` Or Gerlitz
  0 siblings, 0 replies; 186+ messages in thread
From: Or Gerlitz @ 2016-03-28  9:42 UTC (permalink / raw)
  To: Doug Ledford; +Cc: RDMA mailing list, Dennis Dalessandro, Mitko Haralanov

On Thu, Mar 24, 2016 at 6:23 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 03/23/2016 06:37 PM, Or Gerlitz wrote:
>> On Wed, Mar 23, 2016 at 3:46 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

>>> You made your arguments, which I thought were nebulous in the first
>>> place ("does not belong in the kernel" is not a well defined objection,
>>> it's like saying "I don't like that", you would need a more concise
>>> objection to carry stronger weight).

>> Doug, by all means my review was not in a "you should do X, period" or
>> "Y doesn't belong to the kernel, bump", take 5m and see:

> I read it all the first time Or.  I don't need to read it again.

You wrote that I was just pushing things back w.o any argumentation
why I find them wrong, which is simply not the case. You also did very
(very) little commenting (if any) on this thread (and many others
too). This brought me to a point where I couldn't see how you read the
reviewer comments and made this response, so I had to paste things.

>>> Their response to your argument
>>> was that putting it in the kernel saves multiple context switches per
>>> memory region in the cache.  This was a sufficient answer IMO (context
>>> switches are expensive and on 100GBit hardware, multiple context
>>> switches that aren't needed is positively huge).

>> So it tool quiet a lot of time and effort to have Denny make these
>> statements which are still not backed up by any published performance
>> data.

> Yes, so?  Do we have to have published performance numbers for every
> patch?  Especially ones that intuitively sound correct?  Because I don't
> see people putting those requirements on Mellanox, so I'm curious why
> you think that level of burden should be placed on Intel?

Someone suggests a kernel patch for something the reviewer pointed him
that can be put in user-space, and justifies pushing the code into the
kernel as of performance reasons. What's wrong for the reviewer to ask
for performance data? It's not a burden, it's a 100% legitimate
request as part of professional review session.

>> Any reason we can't hear you speaking in real time over a reviewing
>> thread, and have a fair chance to convince you that things are
>> actually the other way around vs. your position, but rather get your
>> opinion in the form of blank pulling of patches?

> You've already made your arguments.  I listened, I evaluated, I made my
> decision, I moved forward.  I had (and still have) too much work to do
> this merge cycle to belabor things just because you want to prevent
> Intel from architecting their driver they way they want.  I would be

Yes, we keep hearing you claiming that you don't have time. But this
is part of what we want to see from maintainer. You don't have to act
as the major reviewer if you don't want to, but if there is a review
that goes on, respect it and when the time comes, say your opinion or
even enforce it (but say you did it).

> more inclined to listen if this wasn't private to their driver, but it
> is, and you are trying to push in on their design with your own
> requirements that bear no relation to the core IB code or your company's
> drivers, and your requirement is one that Intel has already stated will
> have a negative impact on their performance.

The fact that the cache is private to their driver should make you
more worrying, not the other way around. The driver maintainer (the
author of the patches refuses to respond, are you okay with that BTW?)
claimed that this would have negative performance impact, but I
challenged his claims and asked for performance data, I know no other
way to do professional engineering.

As I wrote over the thread, AFAIK, two lead developers that were
involved in the past with this community (Roland D. and Pyte W.) were
working on user-space cache with small kernel part that only deals
with propagating MMU notifications to user-space, I don't think they
did it 10y ago just to stop hfi1 novel developments in 2016, do you
think so?

> Intel has worked their ass off in the name of your review requests so
> far.  The entire rdmavt code base was at your request.
[...]

And where are you Doug, re this code repetition in three drivers @ row?

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CAJ3xEMhu7pKONneEAMDhJUtiz2nqnibynHMWe8vmgPCy+7DH5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-03-24 15:23               ` Doug Ledford
       [not found]                 ` <56F4068F.2070608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-03-24 15:23 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: RDMA mailing list, Dennis Dalessandro, Mitko Haralanov

[-- Attachment #1: Type: text/plain, Size: 5220 bytes --]

On 03/23/2016 06:37 PM, Or Gerlitz wrote:
> On Wed, Mar 23, 2016 at 3:46 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 3/22/2016 6:23 PM, Or Gerlitz wrote:
>>> On Tue, Mar 22, 2016 at 10:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> 
>>>> Mitko Haralanov (41):
>>> [...]
>>>>       IB/hfi1: Re-factor MMU notification code
>>>>       IB/hfi1: Allow MMU function execution in IRQ context
>>>>       IB/hfi1: Prevent NULL pointer dereference
>>>>       IB/hfi1: Allow remove MMU callbacks to free nodes
>>>>       IB/hfi1: Remove the use of add/remove RB function pointers
>>>>       IB/hfi1: Notify remove MMU/RB callback of calling context
>>>>       IB/hfi1: Use interval RB trees
>>>>       IB/hfi1: Add MMU tracing
>>>>       IB/hfi1: Remove compare callback
>>>>       IB/hfi1: Add filter callback
>>>>       IB/hfi1: Adjust last address values for intervals
>>>>       IB/hfi1: Implement SDMA-side buffer caching
>>>>       IB/hfi1: Add pin query function
>>>>       IB/hfi1: Specify mm when releasing pages
>>>>       IB/hfi1: Switch to using the pin query function
>>>>       IB/hfi1: Add SDMA cache eviction algorithm
> 
>>> Doug, this series is under review and a reviewer (me...) have posted
>>> comments claiming that such pin down cache doesn't belong to kernel
>>> but rather to be part of a user-space library [1]
> 
>>> This comment still hold even though the cache is serving a proprietary
>>> (non verbs) user-space code b/c it claims that code X doesn't belong
>>> to the kernel and we need not load into the kernel what doesn't belong
>>> there.
> 
>>> Could you please comment why not let the discussion converge and/or
>>> hear your maintainer opinion on the matter before this is pushed up to Linus?
> 
>>> [1] http://marc.info/?t=145746462200001&r=1&w=2
> 
>> You made your arguments, which I thought were nebulous in the first
>> place ("does not belong in the kernel" is not a well defined objection,
>> it's like saying "I don't like that", you would need a more concise
>> objection to carry stronger weight).
> 
> Doug, by all means my review was not in a "you should do X, period" or
> "Y doesn't belong to the kernel, bump", take 5m and see:

[ snip ]

I read it all the first time Or.  I don't need to read it again.

>> Their response to your argument
>> was that putting it in the kernel saves multiple context switches per
>> memory region in the cache.  This was a sufficient answer IMO (context
>> switches are expensive and on 100GBit hardware, multiple context
>> switches that aren't needed is positively huge).
> 
> So it tool quiet a lot of time and effort to have Denny make these
> statements which are still not backed up by any published performance
> data.

Yes, so?  Do we have to have published performance numbers for every
patch?  Especially ones that intuitively sound correct?  Because I don't
see people putting those requirements on Mellanox, so I'm curious why
you think that level of burden should be placed on Intel?

> Any reason we can't hear you speaking in real time over a reviewing
> thread, and have a fair chance to convince you that things are
> actually the other way around vs. your position, but rather get your
> opinion in the form of blank pulling of patches?

You've already made your arguments.  I listened, I evaluated, I made my
decision, I moved forward.  I had (and still have) too much work to do
this merge cycle to belabor things just because you want to prevent
Intel from architecting their driver they way they want.  I would be
more inclined to listen if this wasn't private to their driver, but it
is, and you are trying to push in on their design with your own
requirements that bear no relation to the core IB code or your company's
drivers, and your requirement is one that Intel has already stated will
have a negative impact on their performance.

Intel has worked their ass off in the name of your review requests so
far.  The entire rdmavt code base was at your request.  And while
Mellanox originally promised to make their soft-rxe driver use the
rdmavt code base too, that appears to have been completely dropped at
this point.  So from my position, Intel lived up to their requirements
in regards to rdmavt, but Mellanox has not and does not appear to intend to.

So, no Or, when it comes to you being able to block Intel's work on
their hfi1 driver, you are now on a short leash.  If you make obviously
correct review comments, I'll listen.  If you make dubious review
comments, but third parties back them up, again I'll listen.  But if you
make a dubious comment, and Intel has valid reasoning for how things
are, then the burden of disproving Intel will fall on you.  At least for
a while.

> Should someone be Al
> V and/or Linus T to make comments over this list which will get you to
> speak up and have a conversation/discussion?

I have conversations on this list on a regular basis Or.  I just didn't
argue a point you wanted me to argue.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <56F1F579.3080403-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-03-23 22:37           ` Or Gerlitz
       [not found]             ` <CAJ3xEMhu7pKONneEAMDhJUtiz2nqnibynHMWe8vmgPCy+7DH5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-03-23 22:37 UTC (permalink / raw)
  To: Doug Ledford; +Cc: RDMA mailing list, Dennis Dalessandro, Mitko Haralanov

On Wed, Mar 23, 2016 at 3:46 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 3/22/2016 6:23 PM, Or Gerlitz wrote:
>> On Tue, Mar 22, 2016 at 10:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

>>> Mitko Haralanov (41):
>> [...]
>>>       IB/hfi1: Re-factor MMU notification code
>>>       IB/hfi1: Allow MMU function execution in IRQ context
>>>       IB/hfi1: Prevent NULL pointer dereference
>>>       IB/hfi1: Allow remove MMU callbacks to free nodes
>>>       IB/hfi1: Remove the use of add/remove RB function pointers
>>>       IB/hfi1: Notify remove MMU/RB callback of calling context
>>>       IB/hfi1: Use interval RB trees
>>>       IB/hfi1: Add MMU tracing
>>>       IB/hfi1: Remove compare callback
>>>       IB/hfi1: Add filter callback
>>>       IB/hfi1: Adjust last address values for intervals
>>>       IB/hfi1: Implement SDMA-side buffer caching
>>>       IB/hfi1: Add pin query function
>>>       IB/hfi1: Specify mm when releasing pages
>>>       IB/hfi1: Switch to using the pin query function
>>>       IB/hfi1: Add SDMA cache eviction algorithm

>> Doug, this series is under review and a reviewer (me...) have posted
>> comments claiming that such pin down cache doesn't belong to kernel
>> but rather to be part of a user-space library [1]

>> This comment still hold even though the cache is serving a proprietary
>> (non verbs) user-space code b/c it claims that code X doesn't belong
>> to the kernel and we need not load into the kernel what doesn't belong
>> there.

>> Could you please comment why not let the discussion converge and/or
>> hear your maintainer opinion on the matter before this is pushed up to Linus?

>> [1] http://marc.info/?t=145746462200001&r=1&w=2

> You made your arguments, which I thought were nebulous in the first
> place ("does not belong in the kernel" is not a well defined objection,
> it's like saying "I don't like that", you would need a more concise
> objection to carry stronger weight).

Doug, by all means my review was not in a "you should do X, period" or
"Y doesn't belong to the kernel, bump", take 5m and see:

OG:"Actually, the cache itself belongs to user space. What is needed
in the kernel is code that uses MMU notifications to invalidate the
cache when munmap and friends were done on a cache entry. This is too
generic functionality that you
can add to the IB core which does have a char device or (better) to a
generic char device you will write and PSM to use. There have been
some works on that in the 2000s, look for code from Roland Dreier
and/or Pete Wyckoff"

DD:"Our position continues to be that this is best located in the hfi1 driver."

DD: few more email w.o technical justifications for the cache to be in
the kernel

DD: "Taking a performance standpoint we don't want this in user space.
If the cache were at the user level there would end up being a system
call to pin the buffer, another to do the SDMA transfer from said
buffer, and another to unpin the buffer when the kernel notifier has
invalidated that buffer.  This gets even more complex when you
consider cache evictions due to reaching the limit on pinned pages.
These extra system calls add overhead, which may be acceptable for a
normal server or desktop environment, but are not acceptable when
dealing with a high performance interconnect where we want the
absolute best performance."

OG: "The cache comes to amortize the cost of pin/unpin and such,
correct? this means that over longs runs, if there's nice locality of
the same process using the same pages,  you pay the register/pin cost
once, later use lazy de-registration/pinning, and only do that when
MMU notifier tells you this is a must, or under some eviction policy.
Since the cost is amortized, the system calls over-head should be
negligible (also, the same system call can be used to evict X and
register Y), do you have performance data that shows otherwise?"

DD: "I did check into the performance aspect here and have been
assured there is a performance problem with the increased number of
system calls. Though I do not have any published data to point you to.
We are particularly worried about the eviction case which is where the
amortization argument doesn't hold up. If the eviction policy is set
to evict buffers which have not been used recently in favor of a new
buffer (which is a very common policy), this happens more often than
you realize.  We do not want any additional cost in this case."

> Their response to your argument
> was that putting it in the kernel saves multiple context switches per
> memory region in the cache.  This was a sufficient answer IMO (context
> switches are expensive and on 100GBit hardware, multiple context
> switches that aren't needed is positively huge).

So it tool quiet a lot of time and effort to have Denny make these
statements which are still not backed up by any published performance
data. This review is incomplete by far, we never heard the author of
the patches speaking and the driver maintainer made the comments deep
into the 4.6 merge window.

> This was a sufficient answer IMO

Any reason we can't hear you speaking in real time over a reviewing
thread, and have a fair chance to convince you that things are
actually the other way around vs. your position, but rather get your
opinion in the form of blank pulling of patches? Should someone be Al
V and/or Linus T to make comments over this list which will get you to
speak up and have a conversation/discussion?

In bunch of other cases w. reviews done over this list, e.g by you,
Jason, Ira, Sean and others to code posted e.g by Matan, Leon and
others the submitter had to work really hard and make lots of changes
in their code for the patches to go in and respond to reviewers in
proper time and with proper content. This is very far what what
happened here.

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <56F29C32.305-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-03-23 13:56                       ` Leon Romanovsky
  2016-03-31 23:38                       ` Leon Romanovsky
  1 sibling, 0 replies; 186+ messages in thread
From: Leon Romanovsky @ 2016-03-23 13:56 UTC (permalink / raw)
  To: Doug Ledford
  Cc: David S. Miller, Linus Torvalds, RDMA mailing list, Matan Barak,
	Or Gerlitz, Leon Romanovsky

On Wed, Mar 23, 2016 at 3:37 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
>> On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
>>> So the *best* situation would be:
>>>
>>>  - your two groups talk it over, and figure out what the common commits are
>>>
>>>  - you put those common commits as a "base" branch in git
>>>
>>>  - you ask the two upper-level maintainers to both pull that base branch
>>>
>>>  - you then make sure that you send the later patches (whether as
>>> emailed patches or as pull requests) based on top of that base branch.
>>
>> Hi David and Doug,
>>
>> Are you OK with the approach suggested by Linus?
>> We are eager to know it, so we will adopt it as soon
>> as possible in our development flow.
>>
>> The original thread [1].
>>
>> [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
>>
>> Thanks.
>>
>
> I'm fine with it.  Since I happen to use topic branches to build my
> for-next from anyway, I might need to be the one that Dave pulls from
> versus the other way around.

Doug,
Thank you,

>From your response, I can understand that you are ready to get pull
requests from us
with Mellanox core patches for common code. Our specific IB
patches/rfc will be based on
that "common" branch, so you won't need to deal with net parts of code at all.

Let's wait for response from David before moving forward.

Thanks
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <20160323105708.GP25216-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-03-23 13:37                   ` Doug Ledford
       [not found]                     ` <56F29C32.305-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-03-23 13:37 UTC (permalink / raw)
  To: David S. Miller, Linus Torvalds, RDMA mailing list, Matan Barak,
	Or Gerlitz, Leon Romanovsky

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
>> So the *best* situation would be:
>>
>>  - your two groups talk it over, and figure out what the common commits are
>>
>>  - you put those common commits as a "base" branch in git
>>
>>  - you ask the two upper-level maintainers to both pull that base branch
>>
>>  - you then make sure that you send the later patches (whether as
>> emailed patches or as pull requests) based on top of that base branch.
> 
> Hi David and Doug,
> 
> Are you OK with the approach suggested by Linus?
> We are eager to know it, so we will adopt it as soon
> as possible in our development flow.
> 
> The original thread [1].
> 
> [1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907
> 
> Thanks.
> 

I'm fine with it.  Since I happen to use topic branches to build my
for-next from anyway, I might need to be the one that Dave pulls from
versus the other way around.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFwNcyywn3gYQ=H_+6WMt=s+xZ5bgpX3O9z8b2o5EhDMGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-03-20  5:59               ` Leon Romanovsky
@ 2016-03-23 10:57               ` Leon Romanovsky
       [not found]                 ` <20160323105708.GP25216-2ukJVAZIZ/Y@public.gmane.org>
  1 sibling, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-03-23 10:57 UTC (permalink / raw)
  To: David S. Miller, Doug Ledford
  Cc: Linus Torvalds, RDMA mailing list, Matan Barak, Or Gerlitz,
	Leon Romanovsky

On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> So the *best* situation would be:
> 
>  - your two groups talk it over, and figure out what the common commits are
> 
>  - you put those common commits as a "base" branch in git
> 
>  - you ask the two upper-level maintainers to both pull that base branch
> 
>  - you then make sure that you send the later patches (whether as
> emailed patches or as pull requests) based on top of that base branch.

Hi David and Doug,

Are you OK with the approach suggested by Linus?
We are eager to know it, so we will adopt it as soon
as possible in our development flow.

The original thread [1].

[1] http://thread.gmane.org/gmane.linux.drivers.rdma/34907

Thanks.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CAJ3xEMhG0x_+DAAY+Cv0OAnW=2VmMuHZUv8DOP_YCkNHfSjX9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-03-23  1:46       ` Doug Ledford
       [not found]         ` <56F1F579.3080403-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-03-23  1:46 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: RDMA mailing list, Dennis Dalessandro, Mitko Haralanov

[-- Attachment #1.1: Type: text/plain, Size: 3078 bytes --]

On 3/22/2016 6:23 PM, Or Gerlitz wrote:
> On Tue, Mar 22, 2016 at 10:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> This is a monster pull request.  I held off on the hfi1 driver updates
>> (the hfi1 driver is intimately tied to the qib driver and the new rdmavt
>> software library that was created to help both of them) in my first pull
>> request.  The hfi1/qib/rdmavt update is probably 90% of this pull
>> request.  The hfi1 driver is being left in staging so that it can be
>> fixed up in regards to the API that Al and yourself didn't like.
> [...]
>> Round two of 4.6 merge window patches
> [...]
>> - A huge set of updates to the Intel hfi1 driver.  Of particular interest
>>   here is that we have left the driver in staging since it still has an
>>   API that people object to.  Intel is working on a fix, but getting
>>   these patches in now helps keep me sane as the upstream and Intel's
>>   trees were over 300 patches apart.
> 
>> Mitko Haralanov (41):
> [...]
>>       IB/hfi1: Re-factor MMU notification code
>>       IB/hfi1: Allow MMU function execution in IRQ context
>>       IB/hfi1: Prevent NULL pointer dereference
>>       IB/hfi1: Allow remove MMU callbacks to free nodes
>>       IB/hfi1: Remove the use of add/remove RB function pointers
>>       IB/hfi1: Notify remove MMU/RB callback of calling context
>>       IB/hfi1: Use interval RB trees
>>       IB/hfi1: Add MMU tracing
>>       IB/hfi1: Remove compare callback
>>       IB/hfi1: Add filter callback
>>       IB/hfi1: Adjust last address values for intervals
>>       IB/hfi1: Implement SDMA-side buffer caching
>>       IB/hfi1: Add pin query function
>>       IB/hfi1: Specify mm when releasing pages
>>       IB/hfi1: Switch to using the pin query function
>>       IB/hfi1: Add SDMA cache eviction algorithm
> 
> Doug, this series is under review and a reviewer (me...) have posted
> comments claiming that such pin down cache doesn't belong to kernel
> but rather to be part of a user-space library [1]
> 
> This comment still hold even though the cache is serving a proprietary
> (non verbs) user-space code b/c it claims that code X doesn't belong
> to the kernel and we need not load into the kernel what doesn't belong
> there.
> 
> Could you please comment why not let the discussion converge and/or
> hear your maintainer opinion on the matter before this is pushed up to
> Linus?
> 
> Or.
> 
> [1] http://marc.info/?t=145746462200001&r=1&w=2
> 

You made your arguments, which I thought were nebulous in the first
place ("does not belong in the kernel" is not a well defined objection,
it's like saying "I don't like that", you would need a more concise
objection to carry stronger weight).  Their response to your argument
was that putting it in the kernel saves multiple context switches per
memory region in the cache.  This was a sufficient answer IMO (context
switches are expensive and on 100GBit hardware, multiple context
switches that aren't needed is positively huge).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <56F1B00F.7010406-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-03-22 22:23   ` Or Gerlitz
       [not found]     ` <CAJ3xEMhG0x_+DAAY+Cv0OAnW=2VmMuHZUv8DOP_YCkNHfSjX9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-03-22 22:23 UTC (permalink / raw)
  To: Doug Ledford; +Cc: RDMA mailing list, Dennis Dalessandro, Mitko Haralanov

On Tue, Mar 22, 2016 at 10:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> This is a monster pull request.  I held off on the hfi1 driver updates
> (the hfi1 driver is intimately tied to the qib driver and the new rdmavt
> software library that was created to help both of them) in my first pull
> request.  The hfi1/qib/rdmavt update is probably 90% of this pull
> request.  The hfi1 driver is being left in staging so that it can be
> fixed up in regards to the API that Al and yourself didn't like.
[...]
> Round two of 4.6 merge window patches
[...]
> - A huge set of updates to the Intel hfi1 driver.  Of particular interest
>   here is that we have left the driver in staging since it still has an
>   API that people object to.  Intel is working on a fix, but getting
>   these patches in now helps keep me sane as the upstream and Intel's
>   trees were over 300 patches apart.

> Mitko Haralanov (41):
[...]
>       IB/hfi1: Re-factor MMU notification code
>       IB/hfi1: Allow MMU function execution in IRQ context
>       IB/hfi1: Prevent NULL pointer dereference
>       IB/hfi1: Allow remove MMU callbacks to free nodes
>       IB/hfi1: Remove the use of add/remove RB function pointers
>       IB/hfi1: Notify remove MMU/RB callback of calling context
>       IB/hfi1: Use interval RB trees
>       IB/hfi1: Add MMU tracing
>       IB/hfi1: Remove compare callback
>       IB/hfi1: Add filter callback
>       IB/hfi1: Adjust last address values for intervals
>       IB/hfi1: Implement SDMA-side buffer caching
>       IB/hfi1: Add pin query function
>       IB/hfi1: Specify mm when releasing pages
>       IB/hfi1: Switch to using the pin query function
>       IB/hfi1: Add SDMA cache eviction algorithm

Doug, this series is under review and a reviewer (me...) have posted
comments claiming that such pin down cache doesn't belong to kernel
but rather to be part of a user-space library [1]

This comment still hold even though the cache is serving a proprietary
(non verbs) user-space code b/c it claims that code X doesn't belong
to the kernel and we need not load into the kernel what doesn't belong
there.

Could you please comment why not let the discussion converge and/or
hear your maintainer opinion on the matter before this is pushed up to
Linus?

Or.

[1] http://marc.info/?t=145746462200001&r=1&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

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-03-22 20:50 Doug Ledford
       [not found] ` <56F1B00F.7010406-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-03-22 20:50 UTC (permalink / raw)
  To: Linus Torvalds, RDMA mailing list

[-- Attachment #1: Type: text/plain, Size: 41890 bytes --]

Hi Linus,

This is a monster pull request.  I held off on the hfi1 driver updates
(the hfi1 driver is intimately tied to the qib driver and the new rdmavt
software library that was created to help both of them) in my first pull
request.  The hfi1/qib/rdmavt update is probably 90% of this pull
request.  The hfi1 driver is being left in staging so that it can be
fixed up in regards to the API that Al and yourself didn't like.  Intel
has agreed to do the work, but in the meantime, this clears out 300+
patches in the backlog queue and brings my tree and their tree closer to
sync.  There were some conflicts in the linux-next merge process for
these patches, but they were all minor and basically the result of some
patches coming in via GKH and some from me.  It seems that no matter how
well we update the docs on the driver in staging to indicate that
patches should go to linux-rdma@, some still go to the typical staging
mailing list and invariably a few get picked up by GKH.  As soon as we
get the driver out of staging that issue will go away of course.

This also includes about 10 patches to the core and a few to mlx5 to
create an infrastructure for configuring SRIOV ports on IB devices.
That series includes one patch to the net core that we sent to netdev@
and Dave Miller with each of the three revisions to the series.  We
didn't get any response to the patch, so we took that as implicit approval.

Finally, this series includes Intel's new iWARP driver for their x722
cards.  It's not nearly the beast as the hfi1 driver.  It also has a
linux-next merge issue, but that has been resolved and it now passes
just fine.

I've not ever put in a pull request this large.  Let me know if you need
me to do things differently.

BTW, if you look at the topic branches that created this set, I should
note that there is one lone patch applied directly to the for-4.6 branch
before I merged the three topic branches.  Trying to avoid any surprises
in diffstat outputs or such like we had with the last pull request.

Here's the git request pull boilerplate:

The following changes since commit 082eaa50838c6b70a8244f8b01d7ed7d686f84db:

  Merge branches 'nes', 'cxgb4' and 'iwpm' into k.o/for-4.6 (2016-03-16
13:57:43 -0400)

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 520a07bff6fbb23cac905007d74c67058b189acb:

  Merge branches 'i40iw', 'sriov' and 'hfi1' into k.o/for-4.6
(2016-03-21 17:32:23 -0400)

----------------------------------------------------------------
Round two of 4.6 merge window patches

- A few minor core fixups needed for the next patch series
- The IB SRIOV series.  This has bounced around for several versions.
  Of note is the fact that the first patch in this series effects
  the net core.  It was directed to netdev and DaveM for each iteration
  of the series (three versions total).  Dave did not object, but did
  not respond either.  I've taken this as permission to move forward
  with the series.
- The new Intel X722 iWARP driver
- A huge set of updates to the Intel hfi1 driver.  Of particular interest
  here is that we have left the driver in staging since it still has an
  API that people object to.  Intel is working on a fix, but getting
  these patches in now helps keep me sane as the upstream and Intel's
  trees were over 300 patches apart.

----------------------------------------------------------------
Alex Estrin (1):
      IB/rdmavt: Post receive for QP in ERR state

Anjali Singhai Jain (1):
      i40e: Add support for client interface for IWARP driver

Ashutosh Dixit (1):
      staging/rdma/hfi1: Add support for enabling/disabling PCIe ASPM

Bryan Morgan (1):
      staging/rdma/hfi1: HFI reports wrong offline disabled reason when
cable removed

Dan Carpenter (1):
      ib_srpt: fix a WARN_ON() message

Dean Luick (35):
      staging/hfi1: set Gen3 half-swing for integrated devices
      staging/hfi1: Remove unneeded variable index
      staging/rdma/hfi1: Fix missing firmware NULL dereference
      staging/rdma/hfi1: Only warn when board description is not found
      staging/rdma/hfi1: Make firmware failure messages warnings
      staging/rdma/hfi1: No firmware retry for simulation
      staging/rdma/hfi1: Skip lcb init for simulation
      staging/rdma/hfi1: Fix for generic I2C interface
      staging/rdma/hfi1: Use device file minor to identify EPROM
      staging/rdma/hfi1: correctly check for post-interrupt packets
      staging/rdma/hfi1: Report physical state changes per device
instead of globally
      staging/rdma/hfi1: Fix fabric serdes reset by re-downloading firmware
      staging/rdma/hfi1: Split last 8 bytes of copy to user buffer
      staging/rdma/hfi1: Remove PCIe AER diagnostic message
      staging/rdma/hfi1: Correct TWSI reset
      staging/rdma/hfi1: Fix snoop packet length calculation
      staging/rdma/hfi1: Make EPROM check per device
      staging/rdma/hfi1: Remove unused variable nsbr
      staging/rdma/hfi1: Fix xmit discard error weight
      staging/rdma/hfi1: Fix debugfs access race
      staging/rdma/hfi1: Disclose more information when i2c fails
      staging/rdma/hfi1: Guard i2c access against cp
      staging/rdma/hfi1: Fix counter read for cp
      IB/hfi1: Remove ASIC block clear
      IB/hfi1: Add shared ASIC structure
      IB/hfi1: Add ASIC resource reservation functions
      IB/hfi1: Change EPROM handling to use resource reservation
      IB/hfi1: Change SBus handling to use resource reservation
      IB/hfi1: Change QSFP functions to use resource reservation
      IB/hfi1: Change thermal init to use resource reservation
      IB/hfi1: Remove unused HFI1_DO_INIT_ASIC flag
      IB/hfi1: Reduce hardware mutex timeout
      IB/hfi1: Hold i2c resource across debugfs open/close
      IB/hfi1: Add ASIC flag view/clear
      IB/hfi1: Add adaptive cacheless verbs copy

Dennis Dalessandro (100):
      IB/rdmavt: Create module framework and handle driver registration
      IB/rdmavt: Consolidate dma ops in rdmavt.
      IB/rdmavt: Add protection domain to rdmavt.
      IB/rdmavt: Add ib core device attributes to rvt driver params list
      IB/rdmavt: Macroize override checks during driver registration
      IB/rdmavt: Add query and modify device stubs
      IB/rdmavt: Add query and modify port stubs
      IB/rdmavt: Add pkey query stub
      IB/rdmavt: Add query gid stub
      IB/rdmavt: Alloc and dealloc ucontexts
      IB/rdmavt: Add queue pair function stubs
      IB/rdmavt: Add address handle stubs
      IB/rdmavt: Add memory region stubs
      IB/rdmavt: Add SRQ stubs
      IB/rdmavt: Add multicast stubs
      IB/rdmavt: Add process MAD stub
      IB/rdmavt: Add mmap stub
      IB/rdmavt: Add get port immutable stub
      IB/rdmavt: Add completion queue function stubs
      IB/rdmavt: Add post send and recv stubs
      IB/rdmavt: Move MR datastructures into rvt
      IB/rdmavt: Add queue pair data structure to rdmavt
      IB/rdmavt: Move driver helper functions to a common structure
      IB/rdmavt: Add device specific info prints
      IB/rdmavt: Add the start of capability flags
      IB/rdmavt: Move memory registration into rdmavt
      IB/rdmavt: Do not use rvt prints which rely on driver too early
      IB/rdmavt: Move SRQ data structure into rdmavt
      IB/rdmavt: Add an ibport data structure to rdmavt
      IB/rdmavt: Add driver notification for new AH
      IB/rdmavt: Break rdma_vt main include header file up
      IB/rdmavt: Initialize and teardown of qpn table
      IB/rdmavt: Add mmap related functions
      IB/rdmavt: Add pkey support
      IB/qib: Begin to use rdmavt for verbs
      IB/qib: Remove dma.c and use rdmavt version of dma functions
      IB/qib: Use rdmavt protection domain
      IB/qib: Remove most uses of QIB_PERMISSIVE_LID and
QIB_MULTICAST_LID_BASE
      IB/qib: Use rdmavt lid defines in qib
      IB/qib: Remove driver specific members from qib qp type
      IB/qib: Add device specific info prints
      IB/qib: Remove qp and mr functionality from qib
      IB/qib: Use address handle in rdmavt and remove from qib
      IB/qib: Remove srq from qib
      IB/rdmavt: Add R and S flags for queue pairs
      IB/rdmavt: Add create queue pair functionality
      IB/rdmavt: Export reset_qp in rdmavt
      IB/rdmavt: Add completion queue functions
      IB/rdmavt: Add post send to rdmavt
      IB/rdmavt: Add support for tracing events
      IB/rdmavt: Add modify qp
      IB/rdmavt: Add destroy qp verb
      IB/rdmavt: Add post receive to rdmavt
      IB/rdmavt: Add multicast functions
      IB/rdmavt: Add misc dev register functionality
      IB/rdmavt: Add device structure allocation
      IB/rdmavt: Add mad agents to rdmavt
      IB/rdmavt: Fix copyright date
      IB/qib: Use rdmavt device allocation function
      IB/qib: Remove create and free mad agents
      IB/rdmavt: Clean up distinction between port number and index
      IB/rdmavt: Add query gid support.
      IB/qib: Clean up register_ib_device
      IB/qib: Support query gid in rdmavt
      staging/rdma/hfi1: Begin to use rdmavt for verbs
      staging/rdma/hfi1: Add basic rdmavt capability flags for hfi1
      staging/rdma/hfi1: Use rdmavt protection domain
      staging/rdma/hfi1: Remove MR data structures from hfi1
      staging/rdma/hfi1: Remove driver specific members from hfi1 qp type
      staging/rdma/hfi1: Add device specific info prints
      staging/rdma/hfi1: Use correct rdmavt header files after move.
      staging/rdma/hfi1: Use address handle in rdmavt and remove from hfi1
      staging/rdma/hfi1: Implement hfi1 support for AH notification
      staging/rdma/hfi1: Remove hfi1 MR and hfi1 specific qp type
      staging/rdma/hfi1: Remove srq from hfi1
      staging/rdma/hfi1: Remove ibport and use rdmavt version
      staging/rdma/hfi1: Remove mmap from hfi1
      staging/rdma/hfi1: Use rdmavt pkey verbs function
      staging/rdma/hfi1: Use rdmavt send flags and recv flags
      staging/rdma/hfi1: Remove qpdev and qpn table from hfi1
      staging/rdma/hfi1: Remove create_qp functionality
      staging/rdma/hfi1: Remove CQ data structures and functions from hfi1
      staging/rdma/hfi1: Clean up return handling
      staging/rdma/hfi1: Use rdmavt version of post_send
      staging/rdma/hfi1: Remove multicast verbs functions
      staging/rdma/hfi1: Remove modify queue pair from hfi1
      staging/rdma/hfi1: Remove destroy qp verb
      staging/rdma/hfi1: Remove post_recv and use rdmavt version
      staging/rdma/hfi1: Clean up register device
      staging/rdma/hfi1: Use rdmavt device allocation function
      staging/rdma/hfi1: Remove create and free mad agents
      staging/rdma/hfi1: Support query gid in rdmavt
      IB/rdmavt: Clean up comments and add more documentation
      IB/rdmavt: Add per verb driver callback checking
      IB/qib: Setup notify free/create mad agent callbacks for rdmavt
      IB/qib,rdmavt: Move smi_ah to qib
      IB/rdmavt: Remove RVT_FLAGs
      IB/rdmavt: Remove signal_supported and comments
      IB/rdmavt: Remove unnecessary exported functions
      staging/rdma/hfi1: Remove header memcpy from sdma send path.

Doug Ledford (1):
      Merge branches 'i40iw', 'sriov' and 'hfi1' into k.o/for-4.6

Easwar Hariharan (13):
      staging/rdma/hfi1: cleanup messages on qsfp_read() failure
      staging/rdma/hfi1: Add active and optical cable support
      staging/rdma/hfi1: Get port type from configuration file
      staging/rdma/hfi1: Support external device configuration requests
from 8051
      staging/rdma/hfi1: Don't attempt to qualify or tune loopback plugs
      staging/rdma/hfi1: Reduce syslog message severity and provide
speed information
      staging/rdma/hfi1: Implement LED beaconing for maintenance
      staging/rdma/hfi1, IB/core: Fix LinkDownReason define for consistency
      staging/rdma/hfi1: Fetch platform configuration data from EFI variable
      staging/rdma/hfi1: Tune for unknown channel if configuration file
is absent
      staging/rdma/hfi1: Cleanup comments and logs in PHY code
      staging/rdma/hfi1: Fix reporting of LED status in Get(LedInfo) and
Get(PortInfo)
      IB/hfi1: Improve LED beaconing

Edward Mascarenhas (1):
      staging/hfi1: Clean up comments

Eli Cohen (10):
      net/core: Add support for configuring VF GUIDs
      IB/mlx5: Fix decision on using MAD_IFC
      IB/core: Add subnet prefix to port info
      IB/core: Support accessing SA in virtualized environment
      IB/core: Add interfaces to control VF attributes
      IB/ipoib: Add ndo operations for configuring VFs
      net/mlx5_core: Add VF param when querying vport counter
      net/mlx5_core: Implement modify HCA vport command
      IB/mlx5: Implement callbacks for manipulating VFs
      IB/ipoib: Allow mcast packets from other VFs

Faisal Latif (16):
      i40iw: add entry in rdma_netlink
      i40iw: add main, hdr, status
      i40iw: add connection management code
      i40iw: add puda code
      i40iw: add pble resource files
      i40iw: add hmc resource files
      i40iw: add hw and utils files
      i40iw: add files for iwarp interface
      i40iw: use shared code for port mapper
      i40iw: add file to handle cqp calls
      i40iw: add hardware related header files
      i40iw: add X722 register file
      i40iw: user kernel shared files
      i40iw: virtual channel handling files
      i40iw: Kconfig and Makefile for iwarp module
      i40iw: changes for build of i40iw module

Hari Prasath Gujulan Elango (1):
      IB/qib,staging/rdma/hfi1: use setup_timer api

Harish Chegondi (34):
      staging/hfi1: Move s_sde to read mostly section of hfi1_qp
      IB/rdmavt: Add IB user context allocation and de-alloction functions
      IB/rdmavt: Allow reserving just one qpn
      IB/rdmavt: Add support for rvt_query_device function
      IB/qib: Remove ibport and use rdmavt version
      IB/qib: Implement qib support for AH notification
      IB/qib: Remove mmap from qib
      IB/qib: Use rdmavt pkey verbs function
      IB/qib: Remove qpn, qp tables and related variables from qib
      IB/qib: Delete QIB user context allocation and de-alloction functions
      IB/qib: Remove qib_query_device function
      IB/qib: Use rdmavt send and receive flags
      IB/qib: Remove create qp and create qp table functionality
      IB/rdmavt: Add support for rvt_query_qp
      IB/qib: Remove completion queue data structures and functions from qib
      IB/qib: Use rdmavt version of post_send
      IB/qib: Remove qib_post_receive and use rdmavt version
      IB/qib: Remove qib multicast verbs functions
      IB/qib: Remove qib_query_qp function
      IB/rdmavt: Add support for query_port, modify_port and
get_port_immutable
      IB/qib: Remove qib_lookup_qpn and use rvt_lookup_qpn instead
      IB/qib: Remove modify queue pair code
      IB/qib: Remove destroy queue pair code
      IB/qib: Remove modify_port and port_immutable functions
      staging/rdma/hfi1: Remove user context allocation and de-alloction
functions
      staging/rdma/hfi1: Remove query_device function
      staging/rdma/hfi1: Remove hfi1_query_qp function
      staging/rdma/hfi1: Remove modify_port and port_immutable functions
      IB/qib: Rename several functions by adding a "qib_" prefix
      IB/rdmavt: Add trace and error print statements in post_one_wr
      IB/qib: Destroy SMI AH before de-allocating the protection domain
      IB/hfi1: Add the break statement that was removed in an earlier patch
      IB/hfi1: Move constant to the right in bitwise operations
      IB/hfi1: Replace kmalloc and memcpy with a kmemdup

Ira Weiny (8):
      staging/hfi1: add dd_dev_dbg
      staging/hfi1: Fix Xmit Wait calculation
      IB/rdmavt: Remove unused variable from Queue Pair
      IB/rdmavt: add modify queue pair driver helpers
      IB/rdmavt: Add hardware driver send work request check
      IB/rdmavt: Properly pass gfp to hw driver function
      staging/rdma/hfi1: Consolidate dma ops for hfi1
      staging/rdma/hfi1: Fix SL->SC checks

Jianxin Xiong (1):
      staging/rdma/hfi1: Fix header size calculation for RC/UC QPs with
GRH enabled

Jim Snow (1):
      staging/hfi1: check for ARMED->ACTIVE change in recv int

Jubin John (31):
      IB/rdmavt: Add srq functionality to rdmavt
      IB/qib: Remove srq functionality
      staging/rdma/hfi1: Remove srq functionality
      staging/rdma/hfi1: Clean up init_cntrs()
      staging/rdma/hfi1: Add s_sendcontext priv field
      staging/rdma/hfi1: Add qp to send context mapping for PIO
      staging/rdma/hfi1: Add send context sw index
      staging/rdma/hfi1: Add spaces around binary operators
      staging/rdma/hfi1: Remove multiple blank lines
      staging/rdma/hfi1: Remove space after cast
      staging/rdma/hfi1: Fix comparison to NULL
      staging/rdma/hfi1: Remove blank line after an open brace
      staging/rdma/hfi1: Remove blank line before close brace
      staging/rdma/hfi1: Fix logical continuations
      staging/rdma/hfi1: Add blank link after declarations
      staging/rdma/hfi1: Remove unnecessary parentheses
      staging/rdma/hfi1: Use BIT_ULL macro
      staging/rdma/hfi1: Split multiple assignments
      staging/rdma/hfi1: Fix misspellings
      staging/rdma/hfi1: Remove CamelCase
      staging/rdma/hfi1: Use pointer instead of struct name
      staging/rdma/hfi1: Remove void function return statement
      staging/rdma/hfi1: Add comment for spinlock_t definition
      staging/rdma/hfi1: Fix block comments
      staging/rdma/hfi1: Fix code alignment
      staging/rdma/hfi1: Add braces on all arms of statement
      staging/rdma/hfi1: Remove else after break
      staging/rdma/hfi1: Fix header
      IB/rdmavt: Check lkey_table_size value before use
      staging/rdma/hfi1: Fix memory leaks
      IB/hfi1: Handle host handshake timeout

Kaike Wan (4):
      staging/rdma/hfi1: Put QPs into error state after SL->SC table changes
      staging/rdma/hfi1: Avoid using upstream component if it is not
accessible
      staging/rdma/hfi1: Check interrupt registers mapping
      IB/hfi1: Don't call cond_resched in atomic mode when sending packets

Kamal Heib (2):
      IB/rdmavt: Add common LID defines to rdmavt
      IB/rdmavt: Add AH to rdmavt

Leon Romanovsky (4):
      net/mlx5_core: Fix caching ATOMIC endian mode capability
      net/mlx5_core: Refactor device capability function
      IB/core: Replace setting the zero values in ib_uverbs_ex_query_device
      IB/{core, ulp} Support above 32 possible device capability flags

Mark F. Brown (1):
      staging/hfi1: change krcvqs mod param from byte to uint

Mike Marciniszyn (36):
      IB/rdmavt: Support creating qps with GFP_NOIO flag
      staging/rdma/hfi1: Fix QSFP memory read/write across 128 byte boundary
      staging/rdma/hfi1: Fix per-VL transmit discard counts
      staging/rdma/hfi1: centralize timer routines into rc
      staging/rdma/hfi1: use new timer routines
      staging/rdma/hfi1: use mod_timer when appropriate
      staging/rdma/hfi1: add unique rnr timer
      staging/rdma/hfi1: use new RNR timer
      staging/rdma/hfi1: remove duplicate timeout print
      staging/rdma/hfi1: add s_retry to diagnostics
      staging/rdma/hfi1: Insure last cursor is updated prior to complete
      IB/qib: Insure last cursor is updated prior to complete
      IB/rdmavt: remove unused qp field
      staging/rdma/hfi1: actually use new RNR timer API in loopback path
      IB/qib, staging/rdma/hfi1: add s_hlock for use in post send
      staging/rdma/hfi1: add s_avail to qp_stats
      IB/rdmvt: close send engine struct holes
      staging/rdma/hfi1: move txreq header code
      staging/rdma/hfi1: remove s_rdma_mr
      staging/rdma/hfi1: avoid passing pmtu
      staging/rdma/hfi1: fix panic in send engine
      staging/rdma/hfi1: use u8 for vl/sl
      staging/rdma/hfi1: Adaptive PIO for short messages
      IB/qib, staging/rdma/hfi1, IB/rdmavt: progress selection changes
      staging/rdma/hfi: fix CQ completion order issue
      staging/rdma/hfi1: Determine actual operational VLs
      staging/rdma/hfi1: fix 0-day syntax error
      IB/rdamvt: fix cross build with rdmavt
      IB/hfi1: Report pid in qp_stats to aid debug
      IB/hfi1: Fix issues with qp_stats print
      IB/hfi1: Add unique trace point for pio and sdma send
      IB/hfi1: Fix ordering of trace for accuracy
      IB/hfi1: Fix PIO wakeup timing hole
      IB/hfi1: Fix panic in adaptive pio
      IB/hfi1: Fix adaptive pio packet corruption
      IB/hfi1: Enable adaptive pio by default

Mitko Haralanov (41):
      staging/hfi1: Add function stubs for TID caching
      uapi/hfi1_user: Correct comment for capability bit
      uapi/hfi1_user: Add command and event for TID caching
      staging/hfi1: Add definitions needed for TID cache
      staging/hfi1: Remove un-needed variable
      staging/hfi1: TID group definitions and support funcs
      staging/hfi1: Add building blocks for TID caching
      staging/hfi1: Convert lock to mutex
      staging/hfi1: Add TID cache receive init and free funcs
      staging/hfi1: Add MMU notifier callback function
      staging/hfi1: Add TID free/clear function bodies
      staging/hfi1: Add TID entry program function body
      staging/hfi1: Enable TID caching feature
      IB/rdmavt: Add Mem affinity support
      staging/rdma/hfi1: Correctly set RcvCtxtCtrl register
      staging/rdma/hfi1: Remove unused code
      staging/rdma/hfi1: Remove unnecessary duplicated variable
      staging/rdma/hfi1: Consolidate CPU/IRQ affinity support
      staging/rdma/hfi1: Allocate send ctxt on device NUMA node
      staging/rdma/hfi1: Verbs Mem affinity support
      staging/rdma/hfi1: Improve performance of TID cache look up
      staging/rdma/hfi1: Improve performance of SDMA transfers
      staging/rdma/hfi1: Properly determine error status of SDMA slots
      staging/rdma/hfi1: Improve performance of user SDMA
      staging/rdma/hfi1: Fix bug that could block the process on context
exit
      IB/hfi1: Re-factor MMU notification code
      IB/hfi1: Allow MMU function execution in IRQ context
      IB/hfi1: Prevent NULL pointer dereference
      IB/hfi1: Allow remove MMU callbacks to free nodes
      IB/hfi1: Remove the use of add/remove RB function pointers
      IB/hfi1: Notify remove MMU/RB callback of calling context
      IB/hfi1: Use interval RB trees
      IB/hfi1: Add MMU tracing
      IB/hfi1: Remove compare callback
      IB/hfi1: Add filter callback
      IB/hfi1: Adjust last address values for intervals
      IB/hfi1: Implement SDMA-side buffer caching
      IB/hfi1: Add pin query function
      IB/hfi1: Specify mm when releasing pages
      IB/hfi1: Switch to using the pin query function
      IB/hfi1: Add SDMA cache eviction algorithm

Sadanand Warrier (1):
      staging/rdma/hfi1: Add credits for VL0 to VL7 in snoop mode

Sagi Grimberg (1):
      net/mlx5_core: Introduce offload arithmetic hardware capabilities

Sebastian Sanchez (7):
      staging/rdma/hfi1: Fix for 32-bit counter overflow in driver and
hfi1stats
      staging/rdma/hfi1: Fix for module parameter rcvhdrcnt when it's
2097152
      staging/rdma/hfi1: Change for data type of port number
      staging/rdma/hfi1: Replacement of goto's for break/returns
      staging/rdma/hfi1: Adding support for hfi counters via sysfs
      staging/rdma/hfi1: Removing unused struct hfi1_verbs_counters
      staging/rdma/hfi1: Turning off LED without checking if stepping is Ax

Tatyana Nikolova (1):
      i40iw: Replace the obsolete crypto hash interface with shash

Vennila Megavannan (6):
      staging/hfi1: add per SDMA engine stats to hfistats
      staging/rdma/hfi1: Method to toggle "fast ECN" detection
      staging/rdma/hfi1: Change send_schedule counter to a per cpu counter
      staging/rdma/hfi1: Allow a fair scheduling of QPs
      IB/rdmavt, staging/rdma/hfi1: use qps to dynamically scale timeout
value
      staging/rdma/hfi1: add cq head and tail information to qpstats

jubin.john-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org (2):
      staging/hfi1: Use BIT macro
      staging/hfi1: Change default krcvqs

 Documentation/infiniband/sysfs.txt                 |    3 +-
 MAINTAINERS                                        |   16 +
 drivers/infiniband/Kconfig                         |    3 +
 drivers/infiniband/Makefile                        |    1 +
 drivers/infiniband/core/device.c                   |   15 +-
 drivers/infiniband/core/sa_query.c                 |    5 +
 drivers/infiniband/core/uverbs_cmd.c               |   17 +-
 drivers/infiniband/core/verbs.c                    |   40 +
 drivers/infiniband/hw/Makefile                     |    1 +
 drivers/infiniband/hw/i40iw/Kconfig                |    7 +
 drivers/infiniband/hw/i40iw/Makefile               |    9 +
 drivers/infiniband/hw/i40iw/i40iw.h                |  570 +++
 drivers/infiniband/hw/i40iw/i40iw_cm.c             | 4141 +++++++++++++++++
 drivers/infiniband/hw/i40iw/i40iw_cm.h             |  456 ++
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c           | 4743
++++++++++++++++++++
 drivers/infiniband/hw/i40iw/i40iw_d.h              | 1713 +++++++
 drivers/infiniband/hw/i40iw/i40iw_hmc.c            |  821 ++++
 drivers/infiniband/hw/i40iw/i40iw_hmc.h            |  241 +
 drivers/infiniband/hw/i40iw/i40iw_hw.c             |  730 +++
 drivers/infiniband/hw/i40iw/i40iw_main.c           | 1910 ++++++++
 drivers/infiniband/hw/i40iw/i40iw_osdep.h          |  215 +
 drivers/infiniband/hw/i40iw/i40iw_p.h              |  106 +
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |  618 +++
 drivers/infiniband/hw/i40iw/i40iw_pble.h           |  131 +
 drivers/infiniband/hw/i40iw/i40iw_puda.c           | 1436 ++++++
 drivers/infiniband/hw/i40iw/i40iw_puda.h           |  183 +
 drivers/infiniband/hw/i40iw/i40iw_register.h       | 1030 +++++
 drivers/infiniband/hw/i40iw/i40iw_status.h         |  100 +
 drivers/infiniband/hw/i40iw/i40iw_type.h           | 1312 ++++++
 drivers/infiniband/hw/i40iw/i40iw_ucontext.h       |  107 +
 drivers/infiniband/hw/i40iw/i40iw_uk.c             | 1204 +++++
 drivers/infiniband/hw/i40iw/i40iw_user.h           |  442 ++
 drivers/infiniband/hw/i40iw/i40iw_utils.c          | 1270 ++++++
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          | 2437 ++++++++++
 drivers/infiniband/hw/i40iw/i40iw_verbs.h          |  173 +
 drivers/infiniband/hw/i40iw/i40iw_vf.c             |   85 +
 drivers/infiniband/hw/i40iw/i40iw_vf.h             |   62 +
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c       |  748 +++
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.h       |  124 +
 drivers/infiniband/hw/mlx5/Makefile                |    2 +-
 drivers/infiniband/hw/mlx5/ib_virt.c               |  194 +
 drivers/infiniband/hw/mlx5/mad.c                   |    2 +-
 drivers/infiniband/hw/mlx5/main.c                  |   12 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h               |    8 +
 drivers/infiniband/hw/qib/Kconfig                  |    2 +-
 drivers/infiniband/hw/qib/Makefile                 |   10 +-
 drivers/infiniband/hw/qib/qib.h                    |   33 +-
 drivers/infiniband/hw/qib/qib_common.h             |    3 -
 drivers/infiniband/hw/qib/qib_cq.c                 |  545 ---
 drivers/infiniband/hw/qib/qib_driver.c             |   71 +-
 drivers/infiniband/hw/qib/qib_iba6120.c            |    8 +-
 drivers/infiniband/hw/qib/qib_iba7322.c            |    6 +-
 drivers/infiniband/hw/qib/qib_init.c               |   25 +-
 drivers/infiniband/hw/qib/qib_intr.c               |    2 +-
 drivers/infiniband/hw/qib/qib_keys.c               |  186 +-
 drivers/infiniband/hw/qib/qib_mad.c                |  338 +-
 drivers/infiniband/hw/qib/qib_mmap.c               |  174 -
 drivers/infiniband/hw/qib/qib_mr.c                 |  490 --
 drivers/infiniband/hw/qib/qib_qp.c                 | 1178 +----
 drivers/infiniband/hw/qib/qib_rc.c                 |  409 +-
 drivers/infiniband/hw/qib/qib_ruc.c                |  191 +-
 drivers/infiniband/hw/qib/qib_sdma.c               |   41 +-
 drivers/infiniband/hw/qib/qib_srq.c                |  380 --
 drivers/infiniband/hw/qib/qib_sysfs.c              |   85 +-
 drivers/infiniband/hw/qib/qib_uc.c                 |   79 +-
 drivers/infiniband/hw/qib/qib_ud.c                 |  142 +-
 drivers/infiniband/hw/qib/qib_verbs.c              | 1223 ++---
 drivers/infiniband/hw/qib/qib_verbs.h              |  812 +---
 drivers/infiniband/hw/qib/qib_verbs_mcast.c        |  363 --
 drivers/infiniband/sw/Makefile                     |    1 +
 drivers/infiniband/sw/rdmavt/Kconfig               |    6 +
 drivers/infiniband/sw/rdmavt/Makefile              |   13 +
 drivers/infiniband/sw/rdmavt/ah.c                  |  196 +
 drivers/infiniband/sw/rdmavt/ah.h                  |   59 +
 .../rdma/hfi1 => infiniband/sw/rdmavt}/cq.c        |  325 +-
 drivers/infiniband/sw/rdmavt/cq.h                  |   64 +
 drivers/infiniband/sw/rdmavt/dma.c                 |  184 +
 drivers/infiniband/sw/rdmavt/dma.h                 |   53 +
 drivers/infiniband/sw/rdmavt/mad.c                 |  171 +
 drivers/infiniband/sw/rdmavt/mad.h                 |   60 +
 .../verbs_mcast.c => infiniband/sw/rdmavt/mcast.c} |  262 +-
 drivers/infiniband/sw/rdmavt/mcast.h               |   58 +
 .../rdma/hfi1 => infiniband/sw/rdmavt}/mmap.c      |  142 +-
 drivers/infiniband/sw/rdmavt/mmap.h                |   63 +
 drivers/infiniband/sw/rdmavt/mr.c                  |  830 ++++
 drivers/infiniband/sw/rdmavt/mr.h                  |   92 +
 drivers/infiniband/sw/rdmavt/pd.c                  |  119 +
 drivers/infiniband/sw/rdmavt/pd.h                  |   58 +
 drivers/infiniband/sw/rdmavt/qp.c                  | 1696 +++++++
 drivers/infiniband/sw/rdmavt/qp.h                  |   69 +
 .../rdma/hfi1 => infiniband/sw/rdmavt}/srq.c       |  204 +-
 drivers/infiniband/sw/rdmavt/srq.h                 |   62 +
 drivers/infiniband/sw/rdmavt/trace.c               |   49 +
 drivers/infiniband/sw/rdmavt/trace.h               |  187 +
 drivers/infiniband/sw/rdmavt/vt.c                  |  873 ++++
 drivers/infiniband/sw/rdmavt/vt.h                  |  104 +
 drivers/infiniband/ulp/ipoib/ipoib.h               |    2 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c            |   27 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c          |   65 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c              |    2 +-
 drivers/net/ethernet/intel/i40e/Makefile           |    1 +
 drivers/net/ethernet/intel/i40e/i40e.h             |   22 +
 drivers/net/ethernet/intel/i40e/i40e_client.c      | 1012 +++++
 drivers/net/ethernet/intel/i40e/i40e_client.h      |  232 +
 drivers/net/ethernet/intel/i40e/i40e_main.c        |  115 +-
 drivers/net/ethernet/intel/i40e/i40e_type.h        |    3 +-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl.h    |   34 +
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  247 +-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h |    4 +
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c      |    6 +
 drivers/net/ethernet/mellanox/mlx5/core/fw.c       |   57 +-
 drivers/net/ethernet/mellanox/mlx5/core/main.c     |   24 +-
 drivers/net/ethernet/mellanox/mlx5/core/vport.c    |   72 +-
 drivers/staging/rdma/hfi1/Kconfig                  |   13 +-
 drivers/staging/rdma/hfi1/Makefile                 |   10 +-
 drivers/staging/rdma/hfi1/affinity.c               |  430 ++
 drivers/staging/rdma/hfi1/affinity.h               |   91 +
 drivers/staging/rdma/hfi1/aspm.h                   |  309 ++
 drivers/staging/rdma/hfi1/chip.c                   | 2457 +++++-----
 drivers/staging/rdma/hfi1/chip.h                   |  151 +-
 drivers/staging/rdma/hfi1/chip_registers.h         |   20 +-
 drivers/staging/rdma/hfi1/common.h                 |   12 +-
 drivers/staging/rdma/hfi1/debugfs.c                |  332 +-
 drivers/staging/rdma/hfi1/debugfs.h                |    5 +-
 drivers/staging/rdma/hfi1/device.c                 |    5 +-
 drivers/staging/rdma/hfi1/device.h                 |    5 +-
 drivers/staging/rdma/hfi1/diag.c                   |  103 +-
 drivers/staging/rdma/hfi1/dma.c                    |   17 +-
 drivers/staging/rdma/hfi1/driver.c                 |  346 +-
 drivers/staging/rdma/hfi1/efivar.c                 |    8 +-
 drivers/staging/rdma/hfi1/efivar.h                 |    5 +-
 drivers/staging/rdma/hfi1/eprom.c                  |  117 +-
 drivers/staging/rdma/hfi1/eprom.h                  |    7 +-
 drivers/staging/rdma/hfi1/file_ops.c               |  552 +--
 drivers/staging/rdma/hfi1/firmware.c               |  587 ++-
 drivers/staging/rdma/hfi1/hfi.h                    |  259 +-
 drivers/staging/rdma/hfi1/init.c                   |  183 +-
 drivers/staging/rdma/hfi1/intr.c                   |   29 +-
 drivers/staging/rdma/hfi1/iowait.h                 |  126 +-
 drivers/staging/rdma/hfi1/keys.c                   |  356 --
 drivers/staging/rdma/hfi1/mad.c                    | 1048 +++--
 drivers/staging/rdma/hfi1/mad.h                    |   14 +-
 drivers/staging/rdma/hfi1/mmu_rb.c                 |  292 ++
 drivers/staging/rdma/hfi1/mmu_rb.h                 |   73 +
 drivers/staging/rdma/hfi1/mr.c                     |  473 --
 drivers/staging/rdma/hfi1/opa_compat.h             |   20 +-
 drivers/staging/rdma/hfi1/pcie.c                   |  276 +-
 drivers/staging/rdma/hfi1/pio.c                    |  365 +-
 drivers/staging/rdma/hfi1/pio.h                    |  118 +-
 drivers/staging/rdma/hfi1/pio_copy.c               |   67 +-
 drivers/staging/rdma/hfi1/platform.c               |  893 ++++
 .../rdma/hfi1/{platform_config.h => platform.h}    |   58 +-
 drivers/staging/rdma/hfi1/qp.c                     | 1642 ++-----
 drivers/staging/rdma/hfi1/qp.h                     |  198 +-
 drivers/staging/rdma/hfi1/qsfp.c                   |  270 +-
 drivers/staging/rdma/hfi1/qsfp.h                   |   57 +-
 drivers/staging/rdma/hfi1/rc.c                     |  765 ++--
 drivers/staging/rdma/hfi1/ruc.c                    |  373 +-
 drivers/staging/rdma/hfi1/sdma.c                   |  365 +-
 drivers/staging/rdma/hfi1/sdma.h                   |  116 +-
 drivers/staging/rdma/hfi1/sdma_txreq.h             |  135 +
 drivers/staging/rdma/hfi1/sysfs.c                  |  136 +-
 drivers/staging/rdma/hfi1/trace.c                  |   53 +-
 drivers/staging/rdma/hfi1/trace.h                  | 1477 +++---
 drivers/staging/rdma/hfi1/twsi.c                   |  205 +-
 drivers/staging/rdma/hfi1/twsi.h                   |    9 +-
 drivers/staging/rdma/hfi1/uc.c                     |  164 +-
 drivers/staging/rdma/hfi1/ud.c                     |  250 +-
 drivers/staging/rdma/hfi1/user_exp_rcv.c           | 1044 +++++
 drivers/staging/rdma/hfi1/user_exp_rcv.h           |   13 +-
 drivers/staging/rdma/hfi1/user_pages.c             |   74 +-
 drivers/staging/rdma/hfi1/user_sdma.c              |  621 +--
 drivers/staging/rdma/hfi1/user_sdma.h              |   11 +-
 drivers/staging/rdma/hfi1/verbs.c                  | 1667 +++----
 drivers/staging/rdma/hfi1/verbs.h                  |  824 +---
 drivers/staging/rdma/hfi1/verbs_txreq.c            |  149 +
 drivers/staging/rdma/hfi1/verbs_txreq.h            |  116 +
 include/linux/mlx5/device.h                        |    6 +
 include/linux/mlx5/driver.h                        |    8 +-
 include/linux/mlx5/mlx5_ifc.h                      |   37 +-
 include/linux/mlx5/vport.h                         |    7 +-
 include/linux/netdevice.h                          |    3 +
 include/rdma/ib_verbs.h                            |   29 +-
 include/rdma/opa_port_info.h                       |    2 +-
 include/rdma/rdma_vt.h                             |  481 ++
 include/rdma/rdmavt_cq.h                           |   99 +
 include/rdma/rdmavt_mr.h                           |  139 +
 include/rdma/rdmavt_qp.h                           |  446 ++
 include/uapi/linux/if_link.h                       |    7 +
 include/uapi/rdma/hfi/hfi1_user.h                  |   14 +-
 include/uapi/rdma/rdma_netlink.h                   |    1 +
 net/core/rtnetlink.c                               |   36 +
 192 files changed, 49197 insertions(+), 15248 deletions(-)
 create mode 100644 drivers/infiniband/hw/i40iw/Kconfig
 create mode 100644 drivers/infiniband/hw/i40iw/Makefile
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_cm.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_cm.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_ctrl.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_d.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_hmc.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_hmc.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_hw.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_main.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_osdep.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_p.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_pble.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_pble.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_puda.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_puda.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_register.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_status.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_type.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_ucontext.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_uk.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_user.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_utils.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_verbs.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_verbs.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_vf.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_vf.h
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
 create mode 100644 drivers/infiniband/hw/i40iw/i40iw_virtchnl.h
 create mode 100644 drivers/infiniband/hw/mlx5/ib_virt.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_cq.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_mmap.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_mr.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_srq.c
 delete mode 100644 drivers/infiniband/hw/qib/qib_verbs_mcast.c
 create mode 100644 drivers/infiniband/sw/Makefile
 create mode 100644 drivers/infiniband/sw/rdmavt/Kconfig
 create mode 100644 drivers/infiniband/sw/rdmavt/Makefile
 create mode 100644 drivers/infiniband/sw/rdmavt/ah.c
 create mode 100644 drivers/infiniband/sw/rdmavt/ah.h
 rename drivers/{staging/rdma/hfi1 => infiniband/sw/rdmavt}/cq.c (72%)
 create mode 100644 drivers/infiniband/sw/rdmavt/cq.h
 create mode 100644 drivers/infiniband/sw/rdmavt/dma.c
 create mode 100644 drivers/infiniband/sw/rdmavt/dma.h
 create mode 100644 drivers/infiniband/sw/rdmavt/mad.c
 create mode 100644 drivers/infiniband/sw/rdmavt/mad.h
 rename drivers/{staging/rdma/hfi1/verbs_mcast.c =>
infiniband/sw/rdmavt/mcast.c} (58%)
 create mode 100644 drivers/infiniband/sw/rdmavt/mcast.h
 rename drivers/{staging/rdma/hfi1 => infiniband/sw/rdmavt}/mmap.c (55%)
 create mode 100644 drivers/infiniband/sw/rdmavt/mmap.h
 create mode 100644 drivers/infiniband/sw/rdmavt/mr.c
 create mode 100644 drivers/infiniband/sw/rdmavt/mr.h
 create mode 100644 drivers/infiniband/sw/rdmavt/pd.c
 create mode 100644 drivers/infiniband/sw/rdmavt/pd.h
 create mode 100644 drivers/infiniband/sw/rdmavt/qp.c
 create mode 100644 drivers/infiniband/sw/rdmavt/qp.h
 rename drivers/{staging/rdma/hfi1 => infiniband/sw/rdmavt}/srq.c (64%)
 create mode 100644 drivers/infiniband/sw/rdmavt/srq.h
 create mode 100644 drivers/infiniband/sw/rdmavt/trace.c
 create mode 100644 drivers/infiniband/sw/rdmavt/trace.h
 create mode 100644 drivers/infiniband/sw/rdmavt/vt.c
 create mode 100644 drivers/infiniband/sw/rdmavt/vt.h
 create mode 100644 drivers/net/ethernet/intel/i40e/i40e_client.c
 create mode 100644 drivers/net/ethernet/intel/i40e/i40e_client.h
 create mode 100644 drivers/staging/rdma/hfi1/affinity.c
 create mode 100644 drivers/staging/rdma/hfi1/affinity.h
 create mode 100644 drivers/staging/rdma/hfi1/aspm.h
 delete mode 100644 drivers/staging/rdma/hfi1/keys.c
 create mode 100644 drivers/staging/rdma/hfi1/mmu_rb.c
 create mode 100644 drivers/staging/rdma/hfi1/mmu_rb.h
 delete mode 100644 drivers/staging/rdma/hfi1/mr.c
 create mode 100644 drivers/staging/rdma/hfi1/platform.c
 rename drivers/staging/rdma/hfi1/{platform_config.h => platform.h} (89%)
 create mode 100644 drivers/staging/rdma/hfi1/sdma_txreq.h
 create mode 100644 drivers/staging/rdma/hfi1/user_exp_rcv.c
 create mode 100644 drivers/staging/rdma/hfi1/verbs_txreq.c
 create mode 100644 drivers/staging/rdma/hfi1/verbs_txreq.h
 create mode 100644 include/rdma/rdma_vt.h
 create mode 100644 include/rdma/rdmavt_cq.h
 create mode 100644 include/rdma/rdmavt_mr.h
 create mode 100644 include/rdma/rdmavt_qp.h


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFwNcyywn3gYQ=H_+6WMt=s+xZ5bgpX3O9z8b2o5EhDMGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-03-20  5:59               ` Leon Romanovsky
  2016-03-23 10:57               ` Leon Romanovsky
  1 sibling, 0 replies; 186+ messages in thread
From: Leon Romanovsky @ 2016-03-20  5:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Doug Ledford, RDMA mailing list, Matan Barak, Or Gerlitz,
	Leon Romanovsky

On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> On Fri, Mar 18, 2016 at 10:37 AM, Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org> wrote:
> > On Fri, Mar 18, 2016 at 09:52:16AM -0700, Linus Torvalds wrote:
> 
> So it requires a bit more care, and a bit more control. You need to be
> very confident about those shared commits that both the networking and
> rdma people take. But quite frankly, after the mess that has been
> Mellanox, that kind of care and effort just sounds like a good idea.
> 
> I hope that clarified.

Thank you for your such detailed explanation. It gave me a clear picture
on how to handle our future submissions.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <20160318173748.GL25216-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-03-19 21:37           ` Linus Torvalds
       [not found]             ` <CA+55aFwNcyywn3gYQ=H_+6WMt=s+xZ5bgpX3O9z8b2o5EhDMGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-03-19 21:37 UTC (permalink / raw)
  To: leon-2ukJVAZIZ/Y, Linus Torvalds, Doug Ledford,
	RDMA mailing list, Matan Barak, Or Gerlitz, Leon Romanovsky

On Fri, Mar 18, 2016 at 10:37 AM, Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org> wrote:
> On Fri, Mar 18, 2016 at 09:52:16AM -0700, Linus Torvalds wrote:
>>
>> It would be much better to have the shared pre-requisite not as a
>> _patch_, but as a separate branch. So that you actually share the
>> commits, not just the diff.
>>
>> Other subsystems have been able to do that.
>
> I'm not sure that my understanding is correct and will be glad
> if you can point us to the examples of such branches, so we will
> use it as soon as possible.

Ok, let me try to explain with a very rough example what I'm looking for.

What Mellanox has been doing is to have two different teams that touch
their "own" areas (networking vs rdma), but with a lot of overlap in
the same files.

So, for example, you might have twenty patches from one group, and
thirty from another, and most of them are pretty independent, but some
of them really touch not just the same file, but the same function -
either right next to each other or even the same lines.

Then the two groups send their code to two different maintainers, and
the end result is that the upper level maintainers need to sort out
the fact that two independent groups touched the same things.

That won't fly any more. I have a very simple solution for it if it
ever happens again: I'll just stop pulling anything from the rdma tree
that has any Mellanox patches in it. Why rdma? It's simply much less
important than the networking tree. It's not personal, that's just how
it is.

So that's what used to happen, and it's not an option any more.

What you are suggesting you do going forward is to have the two trees
at least talk to each other, and instead of having 20/30 separate
patches, maybe you'll have 15+5+25 patches, where the five patches in
the middle are stuff that both groups need and use as a base, and you
still send twenty patches (15+5) to one maintainer and thirty (25+5)
to another, but you guarantee that those five patches are exactly the
same.

So that definitely *improves* on things. It improves on things in
three very real ways:

 - we won't see the really *crazy* case, which is that you implemented
the exact same thing in two different ways, and now it's not just the
code that clashes, it's actually core functionality.

 - yes, there may still be 50 commits total, but now ten of those
fifty will be identical patches, which can make it more likely that
things merge cleanly.

 - when things clash, at least when I look at the conflicts, I can see
"ok, both branches did _this_ part the same, so I can ignore those two
commits that are the same from both sides".

So that's three real improvements, but note how actual conflicts are
still going to happen - they just might be easier to resolve (because
no core semantic clashes, and because the top-level maintainers can
see the "same thing" parts more easily).

The reason they will still happen is that when you send the same patch
to two different maintainers, and one of the maintainers then updates
his file in other ways *afterwards*, what git will see is that both
sides changed the same code *differently*. One did A+B, and one did
just A', and it will all conflict anyway. So it's better, but it's not
great.

So the *best* situation would be:

 - your two groups talk it over, and figure out what the common commits are

 - you put those common commits as a "base" branch in git

 - you ask the two upper-level maintainers to both pull that base branch

 - you then make sure that you send the later patches (whether as
emailed patches or as pull requests) based on top of that base branch.

In the above scenario, you actually don't have any duplicate commits,
so now there is only 45 commits total. But the big improvement is not
in "fewer commits", it's in what happens when you have that situation
of "A+B" vs "just A". Because "A" is now a single shared commit, git
really sees that as shared state, and the fact that one side then did
B on top of that really doesn't matter, and doesn't cause conflicts.

Of course, if one side does "A+B", and another does "A+C", and B and C
conflict, then you'll still see conflicts, but if that happens, you
guys screwed up on the whole "what is our common base" question. But
the conflict will still be smaller than it would have been with two
different copies of A.

NOTE! There is one downside to this model, and that's is that you guys
really have to be more careful about that shared base branch. Because
it's a shared branch that both upstream maintainers will pull from,
that branch really has to be very high quality, and it cannot be
rebased etc after you've asked upstream to pull, because that would
negate the whole point.

And it has to be higher quality, because now you really need to
convince *two* maintainers to take it, and they both need to feel
comfortable doing a "git pull" from you. So you'd need to make sure
that branch really looks good, and that it's based on a good base that
work for both your upstream maintainers. But if you can do that,
everybody will be happier.

So it requires a bit more care, and a bit more control. You need to be
very confident about those shared commits that both the networking and
rdma people take. But quite frankly, after the mess that has been
Mellanox, that kind of care and effort just sounds like a good idea.

I hope that clarified.

              Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFxxoO=i7neGBRGW_afHsSZ7K-x6fMO8v-8po3Ls_Ew0Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-03-18 17:37       ` Leon Romanovsky
@ 2016-03-18 18:17       ` Doug Ledford
  1 sibling, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-03-18 18:17 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: RDMA mailing list

[-- Attachment #1.1: Type: text/plain, Size: 2739 bytes --]

On 3/18/2016 12:52 PM, Linus Torvalds wrote:
> On Thu, Mar 17, 2016 at 10:31 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> There is the one merge issue between the net tree and this tree that was
>> simple and obvious to fix up.  I've had a phone call with Mellanox about
>> how to avoid this in the future (the result of that conversation was
>> that when they have a pre-req patch that is going through Dave's tree,
>> but the dependent patches are going through my tree, then they should
>> submit the pre-req patch to me as well, we can carry identical patches
>> in both trees, and when you merge the duplicate patches will just drop
>> one and then there will be no merge issue).
> 
> That will end up causing just more problems if there are then other
> patches on top in either tree.
> 
> It would be much better to have the shared pre-requisite not as a
> _patch_, but as a separate branch. So that you actually share the
> commits, not just the diff.
> 
> Other subsystems have been able to do that.

Fair enough, I'll "encourage" Mellanox to identify which patches will
have merge conflicts between the net/rdma trees, and when identified,
submit the patch series that contains the pre-req patch with a request
for a specific topic branch that I can pull from Dave, they can then be
on the hook for letting me know about the topic branch.

>>  drivers/infiniband/hw/mlx5/srq.c                  |  41 +-
> ..
>>  91 files changed, 3647 insertions(+), 1995 deletions(-)
>>  create mode 100644 drivers/infiniband/hw/mlx5/gsi.c
> 
> My diffstat doesn't match yours, and it's that "srq.c" file in
> particular that I have no changes to, and see no changes in your pull
> request.
> 
> Other than that it looks normal, but it makes me wonder how that diff
> was generated.

Sorry, that's my fault.  I have a little scriptlet that I feed whatever
kernel version I based my for-next work on and it spits out the pull
request using git request-pull and several static items and that kernel
version.  However, even though I had based my for-next work on v4.5-rc6
(I had been on v4.5-rc4 until I saw that Mellanox put the change to
their offset header file in via Dave's tree between rc5 and rc6, so I
rebased), I had also pulled in my final -rc pull request via this line
in my k.o/for-4.6-topics/ib_core:
bbdfcf18c3b5 Merge branch 'k.o/for-4.5-rc' into HEAD

That merge meant that the diffstat my pull request spit out is showing
the diffs from v4.5-rc6 to my last 4.5-rc pull request + the queued
for-next work.  So your diffstat should rightfully drop the changes to
that file since you have them already (and to three other core IB files).




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFxxoO=i7neGBRGW_afHsSZ7K-x6fMO8v-8po3Ls_Ew0Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-03-18 17:37       ` Leon Romanovsky
       [not found]         ` <20160318173748.GL25216-2ukJVAZIZ/Y@public.gmane.org>
  2016-03-18 18:17       ` Doug Ledford
  1 sibling, 1 reply; 186+ messages in thread
From: Leon Romanovsky @ 2016-03-18 17:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Doug Ledford, RDMA mailing list, Matan Barak, Or Gerlitz,
	Leon Romanovsky

On Fri, Mar 18, 2016 at 09:52:16AM -0700, Linus Torvalds wrote:
> On Thu, Mar 17, 2016 at 10:31 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > There is the one merge issue between the net tree and this tree that was
> > simple and obvious to fix up.  I've had a phone call with Mellanox about
> > how to avoid this in the future (the result of that conversation was
> > that when they have a pre-req patch that is going through Dave's tree,
> > but the dependent patches are going through my tree, then they should
> > submit the pre-req patch to me as well, we can carry identical patches
> > in both trees, and when you merge the duplicate patches will just drop
> > one and then there will be no merge issue).
> 
> That will end up causing just more problems if there are then other
> patches on top in either tree.
> 
> It would be much better to have the shared pre-requisite not as a
> _patch_, but as a separate branch. So that you actually share the
> commits, not just the diff.
> 
> Other subsystems have been able to do that.

Linus,

I'm not sure that my understanding is correct and will be glad
if you can point us to the examples of such branches, so we will
use it as soon as possible.

Thanks.

> 
> >  drivers/infiniband/hw/mlx5/srq.c                  |  41 +-
> ..
> >  91 files changed, 3647 insertions(+), 1995 deletions(-)
> >  create mode 100644 drivers/infiniband/hw/mlx5/gsi.c
> 
> My diffstat doesn't match yours, and it's that "srq.c" file in
> particular that I have no changes to, and see no changes in your pull
> request.
> 
> Other than that it looks normal, but it makes me wonder how that diff
> was generated.
> 
>                   Linus
> --
> 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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <56EAE9D6.2030908-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-03-18 16:52   ` Linus Torvalds
       [not found]     ` <CA+55aFxxoO=i7neGBRGW_afHsSZ7K-x6fMO8v-8po3Ls_Ew0Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-03-18 16:52 UTC (permalink / raw)
  To: Doug Ledford; +Cc: RDMA mailing list

On Thu, Mar 17, 2016 at 10:31 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> There is the one merge issue between the net tree and this tree that was
> simple and obvious to fix up.  I've had a phone call with Mellanox about
> how to avoid this in the future (the result of that conversation was
> that when they have a pre-req patch that is going through Dave's tree,
> but the dependent patches are going through my tree, then they should
> submit the pre-req patch to me as well, we can carry identical patches
> in both trees, and when you merge the duplicate patches will just drop
> one and then there will be no merge issue).

That will end up causing just more problems if there are then other
patches on top in either tree.

It would be much better to have the shared pre-requisite not as a
_patch_, but as a separate branch. So that you actually share the
commits, not just the diff.

Other subsystems have been able to do that.

>  drivers/infiniband/hw/mlx5/srq.c                  |  41 +-
..
>  91 files changed, 3647 insertions(+), 1995 deletions(-)
>  create mode 100644 drivers/infiniband/hw/mlx5/gsi.c

My diffstat doesn't match yours, and it's that "srq.c" file in
particular that I have no changes to, and see no changes in your pull
request.

Other than that it looks normal, but it makes me wonder how that diff
was generated.

                  Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-03-17 17:31 Doug Ledford
       [not found] ` <56EAE9D6.2030908-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-03-17 17:31 UTC (permalink / raw)
  To: Linus Torvalds, RDMA mailing list

[-- Attachment #1: Type: text/plain, Size: 13280 bytes --]

Hi Linus,

This is the first of two pull requests.  It is the smaller request, but
touches for more different things (this is everything but what is in or
going into staging).  The pull request for the code in staging/rdma is
on hold until after we decide what to do on the write/writev API issue
and may be partially deferred until 4.7 as a result.

There is the one merge issue between the net tree and this tree that was
simple and obvious to fix up.  I've had a phone call with Mellanox about
how to avoid this in the future (the result of that conversation was
that when they have a pre-req patch that is going through Dave's tree,
but the dependent patches are going through my tree, then they should
submit the pre-req patch to me as well, we can carry identical patches
in both trees, and when you merge the duplicate patches will just drop
one and then there will be no merge issue).

Here's the boilerplate of the request:

The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:

  Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)

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 082eaa50838c6b70a8244f8b01d7ed7d686f84db:

  Merge branches 'nes', 'cxgb4' and 'iwpm' into k.o/for-4.6 (2016-03-16
13:57:43 -0400)

----------------------------------------------------------------
Initial roundup of 4.6 merge window patches

- cxgb4 updates
- nes updates
- unification of iwarp portmapper code to core
- add drain_cq API
- various ib_core updates
- minor ipoib updates
- minor mlx4 updates
- more significant mlx5 updates (including a minor merge conflict with
  net-next tree...merge is simple to resolve and Stephen's resolution was
  confirmed by Mellanox)
- trivial net/9p rdma conversion
- ocrdma RoCEv2 update
- srpt updates

----------------------------------------------------------------
Abhilash Jindal (1):
      IB/mlx4: Use boottime

Amitoj Kaur Chawla (1):
      IB/core: Replace memset with eth_zero_addr

Arnd Bergmann (1):
      infiniband: cxgb4: use %pR format string for printing resources

Bart Van Assche (21):
      IB/srpt: Simplify srpt_handle_tsk_mgmt()
      IB/srpt: Add parentheses around sizeof argument
      IB/srpt: Remove struct srpt_node_acl
      IB/srpt: Inline srpt_sdev_name()
      IB/srpt: Inline srpt_get_ch_state()
      IB/srpt: Introduce target_reverse_dma_direction()
      IB/srpt: Use scsilun_to_int()
      IB/srpt: Simplify channel state management
      IB/srpt: Simplify srpt_shutdown_session()
      IB/srpt: Fix srpt_close_session()
      IB/srpt: Fix srpt_handle_cmd() error paths
      IB/srpt: Fix how aborted commands are processed
      IB/srpt: Inline trivial CM callback functions
      IB/srpt: Eliminate srpt_find_channel()
      IB/srpt: Log private data associated with REJ
      IB/srpt: Use a mutex to protect the channel list
      IB/srpt: Detect session shutdown reliably
      IB/srpt: Fix srpt_write_pending()
      IB/srpt: Log out all initiators if a port is disabled
      IB/srpt: Introduce srpt_process_wait_list()
      IB/srpt: Fix wait list processing

Ben Hutchings (1):
      RDMA/nes: Replace LRO with GRO

Christoph Hellwig (2):
      IB/mlx5: Convert UMR CQ to new CQ API
      net/9p: convert to new CQ API

Devesh Sharma (3):
      RDMA/ocrdma: Support RoCE-v2 in the UD path
      RDMA/ocrdma: Support RoCE-v2 in the RC path
      RDMA/ocrdma: Support user AH creation for RoCE-v2

Doug Ledford (5):
      Merge branch 'k.o/for-4.5-rc' into HEAD
      IB/mlx5: Make coding style more consistent
      Merge branches 'ib_core', 'ib_ipoib', 'srpt', 'drain-cq-v4' and
'net/9p' into k.o/for-4.6
      Merge branches 'mlx4', 'mlx5' and 'ocrdma' into k.o/for-4.6
      Merge branches 'nes', 'cxgb4' and 'iwpm' into k.o/for-4.6

Eli Cohen (3):
      IB/core: Avoid duplicate code
      IB/core: IB/core: Allow legacy verbs through extended interfaces
      IB/core: Modify conditional on ucontext existence

Erez Shitrit (3):
      IB/mlx5: Define interface bits for IPoIB offloads
      IB/mlx5: Implement UD QP offloads for IPoIB in the TX flow
      IB/mlx5: Add support for CSUM in RX flow

Faisal Latif (3):
      iwcm: common code for port mapper
      iw_nes: remove port mapper related code
      iwpm: crash fix for large connections test

Haggai Eran (10):
      IB/mlx5: Add support for setting source QP number
      IB/mlx5: Modify QP debugging prints
      IB/mlx5: Add GSI QP wrapper
      IB/mlx5: Create multiple transmission GSI QPs
      IB/mlx5: Create GSI transmission QPs when P_Key table is changed
      IB/mlx5: Generate completions in software
      IB/mlx5: Reorder GSI completions
      IB/mlx5: Pick the right GSI transmission QP for sending
      IB/mlx5: Eliminate GSI RX QP's send buffers
      IB/cma: Print warning on different inner and header P_Keys

Hal Rosenstock (1):
      IB/core: Documentation fix in the MAD header file

Hans Westgaard Ry (1):
      IB/ipoib: Add handling for sending of skb with many frags

Hariprasad S (4):
      iw_cxgb4: make queue allocation code more readable
      iw_cxgb4: remove false error log entry
      cxgb4/iw_cxgb4: TOS support
      iw_cxgb4: Max fastreg depth depends on DSGL support

Insu Yun (1):
      nes: handling failed allocation when creating workqueue

Leon Romanovsky (1):
      IB/core: Fix missed clean call in registration path

Majd Dibbiny (2):
      IB/mlx5: Avoid using user-index for SRQs
      IB/{core, mlx5}: Fix input len in vendor part of create_qp/srq

Maor Gottlieb (3):
      net/mlx5_core: Create anchor of last flow table
      net/mlx5_core: Introduce forward to next priority action
      IB/mlx5: Add support for don't trap rules

Marina Varshaver (2):
      IB/core: Add don't trap flag to flow creation
      IB/mlx4: Add support for the don't trap rule

Markus Elfring (3):
      IB/ocrdma: Delete unnecessary variable initialisations in 11 functions
      IB/ocrdma: Skip using unneeded intermediate variable
      IB/ocrdma: Skip using unneeded intermediate variable

Matan Barak (3):
      net/mlx5: Refactor mlx5_core_mr to mkey
      IB/core: Add vendor's specific data to alloc mw
      IB/mlx5: Add memory windows allocation support

Meny Yossefi (3):
      net/mlx5_core: Add helper function to read virtual port counters
      net/mlx5_core: Add helper function to read IB error counters
      IB/mlx5: Modify MAD reading counters method to use counter registers

Noa Osherovich (2):
      IB/mlx5: Refactoring register MR code
      IB/mlx5: Added support for re-registration of MRs

Parav Pandit (1):
      IB/core: trivial prink cleanup.

Sagi Grimberg (4):
      IB/mlx5: Expose correct max_fast_reg_page_list_len
      IB/core: Add arbitrary sg_list support
      mlx5: Add arbitrary sg list support
      iser: Accept arbitrary sg lists mapping if the device supports it

Somnath Kotur (1):
      RDMA/ocrdma: Export udp encapsulation capability

Steve Wise (6):
      IB: new common API for draining queues
      iw_cxgb4: add queue drain functions
      IB/srp: Use ib_drain_rq()
      IB/iser: Use ib_drain_sq()
      iw_cxgb4: remove port mapper related code
      iw_cxgb3: support for iWARP port mapping

 drivers/infiniband/core/cache.c                   |  15 +-
 drivers/infiniband/core/cma.c                     |  22 +-
 drivers/infiniband/core/device.c                  |  29 +-
 drivers/infiniband/core/fmr_pool.c                |  37 +-
 drivers/infiniband/core/iwcm.c                    | 190 ++++-
 drivers/infiniband/core/iwpm_msg.c                |  12 +-
 drivers/infiniband/core/iwpm_util.c               |  14 +-
 drivers/infiniband/core/iwpm_util.h               |   2 +-
 drivers/infiniband/core/packer.c                  |  14 +-
 drivers/infiniband/core/sa_query.c                |  13 +-
 drivers/infiniband/core/ucm.c                     |   8 +-
 drivers/infiniband/core/ucma.c                    |   6 +-
 drivers/infiniband/core/ud_header.c               |  23 +-
 drivers/infiniband/core/uverbs_cmd.c              |  25 +-
 drivers/infiniband/core/uverbs_main.c             |  80 +-
 drivers/infiniband/core/verbs.c                   | 166 ++++
 drivers/infiniband/hw/cxgb3/iwch_cm.c             |  16 +-
 drivers/infiniband/hw/cxgb3/iwch_provider.c       |   3 +-
 drivers/infiniband/hw/cxgb4/cm.c                  | 274 ++-----
 drivers/infiniband/hw/cxgb4/cq.c                  |   9 +-
 drivers/infiniband/hw/cxgb4/device.c              |  72 +-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h            |  49 +-
 drivers/infiniband/hw/cxgb4/mem.c                 |  12 +-
 drivers/infiniband/hw/cxgb4/provider.c            |   5 +-
 drivers/infiniband/hw/cxgb4/qp.c                  | 107 +--
 drivers/infiniband/hw/mlx4/alias_GUID.c           |   6 +-
 drivers/infiniband/hw/mlx4/main.c                 |  72 +-
 drivers/infiniband/hw/mlx4/mlx4_ib.h              |   3 +-
 drivers/infiniband/hw/mlx4/mr.c                   |   4 +-
 drivers/infiniband/hw/mlx5/Makefile               |   2 +-
 drivers/infiniband/hw/mlx5/cq.c                   | 104 ++-
 drivers/infiniband/hw/mlx5/gsi.c                  | 548 +++++++++++++
 drivers/infiniband/hw/mlx5/mad.c                  | 166 +++-
 drivers/infiniband/hw/mlx5/main.c                 | 119 ++-
 drivers/infiniband/hw/mlx5/mlx5_ib.h              | 108 ++-
 drivers/infiniband/hw/mlx5/mr.c                   | 601 +++++++++++---
 drivers/infiniband/hw/mlx5/odp.c                  |  10 +-
 drivers/infiniband/hw/mlx5/qp.c                   | 271 ++++++-
 drivers/infiniband/hw/mlx5/srq.c                  |  41 +-
 drivers/infiniband/hw/mlx5/user.h                 |   7 +
 drivers/infiniband/hw/nes/Kconfig                 |   1 -
 drivers/infiniband/hw/nes/nes.c                   |  25 -
 drivers/infiniband/hw/nes/nes_cm.c                | 361 ++-------
 drivers/infiniband/hw/nes/nes_cm.h                |  11 +-
 drivers/infiniband/hw/nes/nes_hw.c                |  44 +-
 drivers/infiniband/hw/nes/nes_hw.h                |   7 -
 drivers/infiniband/hw/nes/nes_nic.c               |   7 -
 drivers/infiniband/hw/nes/nes_verbs.c             |   5 +-
 drivers/infiniband/hw/ocrdma/ocrdma.h             |   8 +
 drivers/infiniband/hw/ocrdma/ocrdma_ah.c          |  77 +-
 drivers/infiniband/hw/ocrdma/ocrdma_ah.h          |   5 +-
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c          |  33 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c        |   4 +
 drivers/infiniband/hw/ocrdma/ocrdma_sli.h         |  16 +-
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c       |   4 +-
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c       |  38 +-
 drivers/infiniband/ulp/ipoib/ipoib.h              |   2 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c           |  23 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c           |  18 +
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c        |   5 +-
 drivers/infiniband/ulp/iser/iscsi_iser.c          |  11 +-
 drivers/infiniband/ulp/iser/iscsi_iser.h          |   7 -
 drivers/infiniband/ulp/iser/iser_initiator.c      |   7 -
 drivers/infiniband/ulp/iser/iser_verbs.c          |  38 +-
 drivers/infiniband/ulp/srp/ib_srp.c               |  40 +-
 drivers/infiniband/ulp/srpt/ib_srpt.c             | 912
++++++++--------------
 drivers/infiniband/ulp/srpt/ib_srpt.h             |  31 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h       |   2 +
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h     |   1 +
 drivers/net/ethernet/mellanox/mlx4/fw.c           |   5 +-
 drivers/net/ethernet/mellanox/mlx4/mcg.c          |   6 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h      |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c |  12 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 225 +++++-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.h |  15 +
 drivers/net/ethernet/mellanox/mlx5/core/main.c    |   6 +-
 drivers/net/ethernet/mellanox/mlx5/core/mr.c      |  54 +-
 drivers/net/ethernet/mellanox/mlx5/core/port.c    |  23 +
 drivers/net/ethernet/mellanox/mlx5/core/vport.c   |  40 +
 include/linux/mlx4/device.h                       |   3 +
 include/linux/mlx5/device.h                       |  33 +-
 include/linux/mlx5/driver.h                       |  26 +-
 include/linux/mlx5/fs.h                           |   5 +
 include/linux/mlx5/mlx5_ifc.h                     |  51 +-
 include/linux/mlx5/qp.h                           |   7 +-
 include/linux/mlx5/vport.h                        |   2 +
 include/rdma/ib_mad.h                             |   4 +-
 include/rdma/ib_verbs.h                           |  19 +-
 include/rdma/iw_cm.h                              |   6 +-
 include/uapi/rdma/rdma_netlink.h                  |   4 +-
 net/9p/trans_rdma.c                               |  86 +-
 91 files changed, 3647 insertions(+), 1995 deletions(-)
 create mode 100644 drivers/infiniband/hw/mlx5/gsi.c

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-03-04 17:04 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-03-04 17:04 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Hi Linus,

I have four patches today.  I had previously thought I had submitted two
of them last week, but they were accidentally skipped :-(.

The following changes since commit c2bab619813a525d3f58b5ffbfcdc4edee27e497:

  IB/mlx4: Add support for the port info class for RoCE ports
(2016-02-17 10:07:20 -0500)

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 11d8d645343efba0c975aefe7c2cf3b33c836c75:

  IB/core: Use GRH when the path hop-limit > 0 (2016-03-03 10:52:58 -0500)

----------------------------------------------------------------
Additional 4.5-rc6 fixes

- One fix to an error path in the core
- One fix for RoCE in the core
- Two related fixes for the core/mlx5

----------------------------------------------------------------
Leon Romanovsky (1):
      IB/core: Fix missed clean call in registration path

Majd Dibbiny (2):
      IB/mlx5: Avoid using user-index for SRQs
      IB/{core, mlx5}: Fix input len in vendor part of create_qp/srq

Or Gerlitz (1):
      IB/core: Use GRH when the path hop-limit > 0

 drivers/infiniband/core/device.c     |  1 +
 drivers/infiniband/core/sa_query.c   |  2 +-
 drivers/infiniband/core/uverbs_cmd.c |  9 +++++---
 drivers/infiniband/hw/mlx5/srq.c     | 41
+++++++++++++++++++-----------------
 4 files changed, 30 insertions(+), 23 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-02-21  1:14 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-02-21  1:14 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

Hi Linus,

The following changes since commit 75c1657e1d50730dc0130a67977f7831a4e241f4:

  IB/mlx5: Fix RC transport send queue overhead computation (2016-02-12
14:56:08 -0500)

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 c2bab619813a525d3f58b5ffbfcdc4edee27e497:

  IB/mlx4: Add support for the port info class for RoCE ports
(2016-02-17 10:07:20 -0500)

----------------------------------------------------------------
Additional 4.5-rc5 fixes

- One fix ocrdma - The new CQ API support was added to ocrdma, but they
  got the arming logic wrong, so without this, transfers eventually fail
  when they fail to arm the interrupt properly under load
- Two related fixes for mlx4 - When we added the 64bit extended counters
  support to the core IB code, they forgot to update the RoCE side of the
  mlx4 driver (the IB side they properly updated).  I debated whether or
  not to include these patches as they could be considered feature
  enablement patches, but the existing code will blindy copy the 32bit
  counters, whether any counters were requested at all (a bug).  These
  two patches make it A) check to see that counters were requested and
  B) copy the right counters (the 64bit support is new, the 32bit is
  not).  For that reason I went ahead and took them.

----------------------------------------------------------------
Devesh Sharma (1):
      RDMA/ocrdma: Fix arm logic to align with new cq API

Eran Ben Elisha (2):
      IB/mlx4: Add support for extended counters over RoCE ports
      IB/mlx4: Add support for the port info class for RoCE ports

 drivers/infiniband/hw/mlx4/mad.c            | 63
+++++++++++++++++++++++------
 drivers/infiniband/hw/ocrdma/ocrdma.h       |  3 --
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 18 ++-------
 3 files changed, 54 insertions(+), 30 deletions(-)

-- 
Doug Ledford <dledford-HHGe/kKACDifJOJzLBvvIA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-02-14  1:23 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-02-14  1:23 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Hi Linus,

I think we are getting pretty close to done now.  There are four one-off
fixes in this update, as documented in the tag message.  Thanks.

The following changes since commit 7425f410ca6cffe81400906286f80e8e15d9b301:

  RDMA/ocrdma: Fixing ocrdma debugfs directory remove (2016-02-05
15:14:28 -0500)

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 75c1657e1d50730dc0130a67977f7831a4e241f4:

  IB/mlx5: Fix RC transport send queue overhead computation (2016-02-12
14:56:08 -0500)

----------------------------------------------------------------
Additional 4.5-rc3 fixes

- One fix to ipoib multicast joins
- One fix to mlx4 error handling
- One fix to mlx5 size computation
- One fix to a thinko in core code

----------------------------------------------------------------
Alex Estrin (1):
      IB/ipoib: fix for rare multicast join race condition

Eran Ben Elisha (1):
      IB/core: Fix reading capability mask of the port info class

Leon Romanovsky (1):
      IB/mlx5: Fix RC transport send queue overhead computation

Rasmus Villemoes (1):
      net/mlx4: fix some error handling in mlx4_multi_func_init()

 drivers/infiniband/core/sysfs.c                |  5 ++---
 drivers/infiniband/hw/mlx5/qp.c                | 12 +++++++-----
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 24
+++++++++++++++++-------
 drivers/net/ethernet/mellanox/mlx4/cmd.c       |  2 +-
 4 files changed, 27 insertions(+), 16 deletions(-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-02-10 22:34 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-02-10 22:34 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

Hi Linus,

A few more minor fixes for rc3:

The following changes since commit b85d9905a7ca128f24e3a4e60ff2a1b0cd58ae7c:

  staging/rdma: remove deprecated ipath driver (2016-02-03 11:10:58 -0500)

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 7425f410ca6cffe81400906286f80e8e15d9b301:

  RDMA/ocrdma: Fixing ocrdma debugfs directory remove (2016-02-05
15:14:28 -0500)

----------------------------------------------------------------
4.5-rc3 fixes

- One fix to ipoib
- One fix to core sysfs code
- Four patches that resolve an oops found in testing of ocrdma and a couple
  other ocrdma issues

----------------------------------------------------------------
Carol L Soto (1):
      IB/IPoIB: Do not set skb truesize since using one linearskb

Colin Ian King (1):
      IB/sysfs: remove unused va_list args

Selvin Xavier (4):
      RDMA/ocrdma: Initialize stats resources in the driver before ib
device registration.
      RDMA/ocrdma: populate max_sge_rd in device attributes
      RDMA/ocrdma: Fix pkey_index returned by driver in rq work completion
      RDMA/ocrdma: Fixing ocrdma debugfs directory remove

 drivers/infiniband/core/sysfs.c             |  2 --
 drivers/infiniband/hw/ocrdma/ocrdma_main.c  |  6 ++++++
 drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 16 +++++-----------
 drivers/infiniband/hw/ocrdma/ocrdma_stats.h |  2 ++
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c |  7 +++----
 drivers/infiniband/ulp/ipoib/ipoib_ib.c     |  2 --
 6 files changed, 16 insertions(+), 19 deletions(-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-02-03 20:24 Doug Ledford
  0 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-02-03 20:24 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 13566 bytes --]

Hi Linus,

As per our off-list discussion, here is the pull request.

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

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 b85d9905a7ca128f24e3a4e60ff2a1b0cd58ae7c:

  staging/rdma: remove deprecated ipath driver (2016-02-03 11:10:58 -0500)

----------------------------------------------------------------
4.5-rc2 fixes

- One minor fix to the ib core
- Four minor fixes to the Mellanox drivers
- Remove three deprecated drivers from staging/rdma now that all of Greg's
  queued changes to them are merged

----------------------------------------------------------------
Doug Ledford (3):
      staging/rdma: remove deprecated amso1100 driver
      staging/rdma: remove deprecated ehca driver
      staging/rdma: remove deprecated ipath driver

Majd Dibbiny (2):
      IB/mlx5: Fix reqlen validation in mlx5_ib_alloc_ucontext
      IB/mlx5: Fix use of null pointer PD

Maor Gottlieb (1):
      IB/mlx5: Use MLX5_GET to correctly get end of padding mode

Matan Barak (1):
      IB/mlx5: Add CREATE_CQ and CREATE_QP to uverbs_ex_cmd_mask

Moni Shoua (1):
      IB/core: Set correct payload length for RoCEv2 over IPv6

 MAINTAINERS                                      |   20 -
 drivers/infiniband/core/ud_header.c              |    7 +-
 drivers/infiniband/hw/mlx5/main.c                |    8 +-
 drivers/infiniband/hw/mlx5/qp.c                  |   20 +-
 drivers/staging/rdma/Kconfig                     |    6 -
 drivers/staging/rdma/Makefile                    |    3 -
 drivers/staging/rdma/amso1100/Kbuild             |    6 -
 drivers/staging/rdma/amso1100/Kconfig            |   15 -
 drivers/staging/rdma/amso1100/TODO               |    4 -
 drivers/staging/rdma/amso1100/c2.c               | 1240 ----------
 drivers/staging/rdma/amso1100/c2.h               |  547 -----
 drivers/staging/rdma/amso1100/c2_ae.c            |  327 ---
 drivers/staging/rdma/amso1100/c2_ae.h            |  108 -
 drivers/staging/rdma/amso1100/c2_alloc.c         |  142 --
 drivers/staging/rdma/amso1100/c2_cm.c            |  458 ----
 drivers/staging/rdma/amso1100/c2_cq.c            |  437 ----
 drivers/staging/rdma/amso1100/c2_intr.c          |  219 --
 drivers/staging/rdma/amso1100/c2_mm.c            |  377 ---
 drivers/staging/rdma/amso1100/c2_mq.c            |  175 --
 drivers/staging/rdma/amso1100/c2_mq.h            |  106 -
 drivers/staging/rdma/amso1100/c2_pd.c            |   90 -
 drivers/staging/rdma/amso1100/c2_provider.c      |  862 -------
 drivers/staging/rdma/amso1100/c2_provider.h      |  182 --
 drivers/staging/rdma/amso1100/c2_qp.c            | 1024 --------
 drivers/staging/rdma/amso1100/c2_rnic.c          |  652 -----
 drivers/staging/rdma/amso1100/c2_status.h        |  158 --
 drivers/staging/rdma/amso1100/c2_user.h          |   82 -
 drivers/staging/rdma/amso1100/c2_vq.c            |  260 --
 drivers/staging/rdma/amso1100/c2_vq.h            |   63 -
 drivers/staging/rdma/amso1100/c2_wr.h            | 1520 ------------
 drivers/staging/rdma/ehca/Kconfig                |   10 -
 drivers/staging/rdma/ehca/Makefile               |   16 -
 drivers/staging/rdma/ehca/TODO                   |    4 -
 drivers/staging/rdma/ehca/ehca_av.c              |  279 ---
 drivers/staging/rdma/ehca/ehca_classes.h         |  481 ----
 drivers/staging/rdma/ehca/ehca_classes_pSeries.h |  208 --
 drivers/staging/rdma/ehca/ehca_cq.c              |  397 ---
 drivers/staging/rdma/ehca/ehca_eq.c              |  189 --
 drivers/staging/rdma/ehca/ehca_hca.c             |  414 ----
 drivers/staging/rdma/ehca/ehca_irq.c             |  870 -------
 drivers/staging/rdma/ehca/ehca_irq.h             |   77 -
 drivers/staging/rdma/ehca/ehca_iverbs.h          |  202 --
 drivers/staging/rdma/ehca/ehca_main.c            | 1118 ---------
 drivers/staging/rdma/ehca/ehca_mcast.c           |  131 -
 drivers/staging/rdma/ehca/ehca_mrmw.c            | 2202 -----------------
 drivers/staging/rdma/ehca/ehca_mrmw.h            |  127 -
 drivers/staging/rdma/ehca/ehca_pd.c              |  123 -
 drivers/staging/rdma/ehca/ehca_qes.h             |  260 --
 drivers/staging/rdma/ehca/ehca_qp.c              | 2256 ------------------
 drivers/staging/rdma/ehca/ehca_reqs.c            |  953 --------
 drivers/staging/rdma/ehca/ehca_sqp.c             |  245 --
 drivers/staging/rdma/ehca/ehca_tools.h           |  155 --
 drivers/staging/rdma/ehca/ehca_uverbs.c          |  309 ---
 drivers/staging/rdma/ehca/hcp_if.c               |  949 --------
 drivers/staging/rdma/ehca/hcp_if.h               |  265 --
 drivers/staging/rdma/ehca/hcp_phyp.c             |   82 -
 drivers/staging/rdma/ehca/hcp_phyp.h             |   90 -
 drivers/staging/rdma/ehca/hipz_fns.h             |   68 -
 drivers/staging/rdma/ehca/hipz_fns_core.h        |  100 -
 drivers/staging/rdma/ehca/hipz_hw.h              |  414 ----
 drivers/staging/rdma/ehca/ipz_pt_fn.c            |  289 ---
 drivers/staging/rdma/ehca/ipz_pt_fn.h            |  289 ---
 drivers/staging/rdma/ipath/Kconfig               |   16 -
 drivers/staging/rdma/ipath/Makefile              |   37 -
 drivers/staging/rdma/ipath/TODO                  |    5 -
 drivers/staging/rdma/ipath/ipath_common.h        |  851 -------
 drivers/staging/rdma/ipath/ipath_cq.c            |  483 ----
 drivers/staging/rdma/ipath/ipath_debug.h         |   99 -
 drivers/staging/rdma/ipath/ipath_diag.c          |  551 -----
 drivers/staging/rdma/ipath/ipath_dma.c           |  179 --
 drivers/staging/rdma/ipath/ipath_driver.c        | 2784
----------------------
 drivers/staging/rdma/ipath/ipath_eeprom.c        | 1183 ---------
 drivers/staging/rdma/ipath/ipath_file_ops.c      | 2619
--------------------
 drivers/staging/rdma/ipath/ipath_fs.c            |  415 ----
 drivers/staging/rdma/ipath/ipath_iba6110.c       | 1939 ---------------
 drivers/staging/rdma/ipath/ipath_init_chip.c     | 1062 ---------
 drivers/staging/rdma/ipath/ipath_intr.c          | 1271 ----------
 drivers/staging/rdma/ipath/ipath_kernel.h        | 1374 -----------
 drivers/staging/rdma/ipath/ipath_keys.c          |  270 ---
 drivers/staging/rdma/ipath/ipath_mad.c           | 1521 ------------
 drivers/staging/rdma/ipath/ipath_mmap.c          |  174 --
 drivers/staging/rdma/ipath/ipath_mr.c            |  370 ---
 drivers/staging/rdma/ipath/ipath_qp.c            | 1079 ---------
 drivers/staging/rdma/ipath/ipath_rc.c            | 1969 ---------------
 drivers/staging/rdma/ipath/ipath_registers.h     |  512 ----
 drivers/staging/rdma/ipath/ipath_ruc.c           |  733 ------
 drivers/staging/rdma/ipath/ipath_sdma.c          |  818 -------
 drivers/staging/rdma/ipath/ipath_srq.c           |  380 ---
 drivers/staging/rdma/ipath/ipath_stats.c         |  347 ---
 drivers/staging/rdma/ipath/ipath_sysfs.c         | 1237 ----------
 drivers/staging/rdma/ipath/ipath_uc.c            |  547 -----
 drivers/staging/rdma/ipath/ipath_ud.c            |  579 -----
 drivers/staging/rdma/ipath/ipath_user_pages.c    |  228 --
 drivers/staging/rdma/ipath/ipath_user_sdma.c     |  874 -------
 drivers/staging/rdma/ipath/ipath_user_sdma.h     |   52 -
 drivers/staging/rdma/ipath/ipath_verbs.c         | 2376 ------------------
 drivers/staging/rdma/ipath/ipath_verbs.h         |  941 --------
 drivers/staging/rdma/ipath/ipath_verbs_mcast.c   |  363 ---
 drivers/staging/rdma/ipath/ipath_wc_ppc64.c      |   49 -
 drivers/staging/rdma/ipath/ipath_wc_x86_64.c     |  144 --
 100 files changed, 20 insertions(+), 53101 deletions(-)
 delete mode 100644 drivers/staging/rdma/amso1100/Kbuild
 delete mode 100644 drivers/staging/rdma/amso1100/Kconfig
 delete mode 100644 drivers/staging/rdma/amso1100/TODO
 delete mode 100644 drivers/staging/rdma/amso1100/c2.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_ae.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_ae.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_alloc.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_cm.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_cq.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_intr.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_mm.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_mq.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_mq.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_pd.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_provider.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_provider.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_qp.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_rnic.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_status.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_user.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_vq.c
 delete mode 100644 drivers/staging/rdma/amso1100/c2_vq.h
 delete mode 100644 drivers/staging/rdma/amso1100/c2_wr.h
 delete mode 100644 drivers/staging/rdma/ehca/Kconfig
 delete mode 100644 drivers/staging/rdma/ehca/Makefile
 delete mode 100644 drivers/staging/rdma/ehca/TODO
 delete mode 100644 drivers/staging/rdma/ehca/ehca_av.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_classes.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_classes_pSeries.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_cq.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_eq.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_hca.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_irq.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_irq.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_iverbs.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_main.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_mcast.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_mrmw.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_mrmw.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_pd.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_qes.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_qp.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_reqs.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_sqp.c
 delete mode 100644 drivers/staging/rdma/ehca/ehca_tools.h
 delete mode 100644 drivers/staging/rdma/ehca/ehca_uverbs.c
 delete mode 100644 drivers/staging/rdma/ehca/hcp_if.c
 delete mode 100644 drivers/staging/rdma/ehca/hcp_if.h
 delete mode 100644 drivers/staging/rdma/ehca/hcp_phyp.c
 delete mode 100644 drivers/staging/rdma/ehca/hcp_phyp.h
 delete mode 100644 drivers/staging/rdma/ehca/hipz_fns.h
 delete mode 100644 drivers/staging/rdma/ehca/hipz_fns_core.h
 delete mode 100644 drivers/staging/rdma/ehca/hipz_hw.h
 delete mode 100644 drivers/staging/rdma/ehca/ipz_pt_fn.c
 delete mode 100644 drivers/staging/rdma/ehca/ipz_pt_fn.h
 delete mode 100644 drivers/staging/rdma/ipath/Kconfig
 delete mode 100644 drivers/staging/rdma/ipath/Makefile
 delete mode 100644 drivers/staging/rdma/ipath/TODO
 delete mode 100644 drivers/staging/rdma/ipath/ipath_common.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_cq.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_debug.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_diag.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_dma.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_driver.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_eeprom.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_file_ops.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_fs.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_iba6110.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_init_chip.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_intr.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_kernel.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_keys.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_mad.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_mmap.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_mr.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_qp.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_rc.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_registers.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_ruc.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_sdma.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_srq.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_stats.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_sysfs.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_uc.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_ud.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_user_pages.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_user_sdma.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_user_sdma.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_verbs.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_verbs.h
 delete mode 100644 drivers/staging/rdma/ipath/ipath_verbs_mcast.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_wc_ppc64.c
 delete mode 100644 drivers/staging/rdma/ipath/ipath_wc_x86_64.c

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                                 ` <CAJ3xEMhPj3jsXD5qBrJYLyf2LsB1c5UwzQsb=+HMGuvQqTK9ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-25  1:05                                                   ` Linus Torvalds
  0 siblings, 0 replies; 186+ messages in thread
From: Linus Torvalds @ 2016-01-25  1:05 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Doug Ledford, David Miller, linux-rdma, Saeed Mahameed,
	Achiad Shochat, Matan Barak, Alaa Hleihel, Leon Romanovsky,
	Haggai Eran, Stephen Rothwell

On Sun, Jan 24, 2016 at 2:13 PM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> That's news to me. When such things happen and caught by Stephen, we
> are getting an email saying something like
>
> "Today's linux-next merge of the infiniband tree got a conflict
> between commit X from net-next tree and commit Y from the infiniband
> tree. I fixed it up (see below) and can carry the fix as necessary (no
> action is required)."

So that's purely about linux-next, and Stephen carrying the merge
around there. He's informing you that he has resolved it in
linux-next, and you now should know about the issue, and that he won't
inform you again, because it's resolved in linux-next (sometimes -
very seldom - the clashes get so bad that he just throws out one tree
as unresolvable, and then that tree needs to actually work on getting
it resolved in linux-next).

>> In 99% of all conflicts, the answer is "it's a trivial conflict, both
>> sides did the rigth thing, I'm just fixing things up".
>
> Would it be correct to phrase the points you are trying to make in
> this email as:
>
> If the conflict doesn't fall into a category of being a trivial one,
> were both sides did the right thing and someone only has to fix things
> up to co-exist -- something is wrong, and the conflict should be
> resolved by a per-merge fix to at least one of the patches

So it's not entirely about the "trivial" part.

Sometimes we have complicated merges, simply because two different
people did very different things, and they clashed.

But of those two people had a good _reason_ to do different things,
and they were fundamentally independent things to do, then even a
non-trivial merge migth still be about everybody doing the right
thing, and it just happened to clash. Unfortunate, but it can happen.
For example, maybe Al Viro did some VFS re-organization that impacted
individual filesystems, and then one of the filesystem maintainers did
some independent changes for one of the filesystems that just happened
to clash. That would still be "everything is fine, we were just
slightly unlucky".

But when there are two groups in the same company, working on the
_same_ driver, then those two groups need to talk. When they clash,
it's not "we were just slightly unlucky, working on different things,
and normally these things don't interact that way".

This is not a matter of two independent groups working on independent
things that just have overlap. You're working on the same f*cking
driver, doing variations of the same f*cking thing, for chrissake.

So talk to each other.

We had the same thing happen with the NETDEV_CHANGEUPPER thing from
Mellanox. Again, it wasn't two different groups working on two
different things that just happened to get a clash. No, it was two
different groups inside of Mellanox working on the exact same thing,
inside the same company, and they just did the same thing (slightly
differently) without ever talking to each other, and sent it out to
two different maintainers.

See the difference? A _good_ merge conflict is when two groups work on
entirely different things and they just happen to have some
unfortunate overlap. A bad conflict is when two groups work on the
same exact thing and didn't talk it over.

                 Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                                     ` <56A4E25C.20905-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-24 23:18                                                       ` Or Gerlitz
  0 siblings, 0 replies; 186+ messages in thread
From: Or Gerlitz @ 2016-01-24 23:18 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Linus Torvalds, David Miller, linux-rdma, Saeed Mahameed,
	Achiad Shochat, Matan Barak, Eran Ben Elisha, Majd Dibbiny

On Sun, Jan 24, 2016 at 4:40 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Or, can you please make sure that the right people inside Mellanox
> review Linus tree for any merge issues ASAP.  Then let's have a separate
> conversation about preventing this in the future?

Yes, people will be reviewing/testing the bits they authored/submitted
in their merged form and if/where needed rc fixes will be sent.

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                             ` <CA+55aFy6ynd91QhGHyo=9vHb8HPj4yvsY10kYXPVpBSPemcxJg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24 22:13                                               ` Or Gerlitz
       [not found]                                                 ` <CAJ3xEMhPj3jsXD5qBrJYLyf2LsB1c5UwzQsb=+HMGuvQqTK9ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-01-24 22:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Doug Ledford, David Miller, linux-rdma, Saeed Mahameed,
	Achiad Shochat, Matan Barak, Alaa Hleihel, Leon Romanovsky,
	Haggai Eran, Stephen Rothwell

On Sun, Jan 24, 2016, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> On Sun, Jan 24, 2016, Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>>
>> It's possible that for a given merge cycle, we have networking changes that
>> require core changes and RDMA changes which require different core changes.
>
> Yes.
>
> However, you should synchronize it some way at least _internally_.
> Maybe by using a git tree inside Mellanox, so that the pain of your
> two development groups doesn't then hit people who don't know the
> hardware and can't test.

Yes, sounds like that's the right thing to do.

>> So I'd like to clarify with you a point re linux-next.
>>
>> From my experience working under few maintainers (Dave, Roland, Doug) over
>> the years...what the maintainer has to do is (A) register their for-next
>> tree/branch to linux-next merge tests and (B) respond to the linux-next
>> maintainer when he identifies conflicts and resolves them.
>
> Yes. And as far as I can tell, this conflict _was_ in linux-next.
>
> However, the fact that it got resolved in linux-next is purely
> informational. It doesn't "fix" the conflict - it just means that both
> sides should have gotten informed about it. That doesn't mean that the
> conflict goes away or becomes better.

That's news to me. When such things happen and caught by Stephen, we
are getting an email saying something like

"Today's linux-next merge of the infiniband tree got a conflict
between commit X from net-next tree and commit Y from the infiniband
tree. I fixed it up (see below) and can carry the fix as necessary (no
action is required)."

Also asked around a bit and got to learn on Stephen using git rerere,
so all (no action needed note + seeing git rerere in action...) that
leaded me to think that indeed no action is required from our side,
but after reading your email (twice, so far), I realized that this was
wrong conclusion.

> So what linux-next conflicts should have resulted in was that people
> were aware of it before it even hit my tree, and there might be
> mitigating efforts taken (where "mitigation" might be just informing
> me about it in the pull request, which didn't even happen).
>
> And Stephen is actually really really good at handling merge conflicts
> these days (he's probably the _one_ person who does more merges than I
> do), but at the same time, he tends to have a "merge and forget" model
> - not only does he use "git rerere" so that he never has to worry
> about the merge later, he doesn't tend to care very much about the end
> result and think about it.
>
> For example, I doubt Stephen spent a lot of time worrying about the
> byte offsets in that header file - he cares about getting things to
> compile. Or did he notice and notify people that the offsets were
> crap?

nope, the byte offsets party was not reported.

> In contrast, when I do a merge, I end up trying to see what the
> background for the conflict is. And that's not just about the code,
> it's explicitly about things like "why did these two trees conflict in
> the first place".
>
> Because _I_ care about not just trying to get things to compile, and
> not just about getting the right merge result, but in fact things like
> "is there some problem in code maintenance that causes this conflict -
> should we maybe split development some way?" is very much a primary
> concern for me.
>
> In 99% of all conflicts, the answer is "it's a trivial conflict, both
> sides did the rigth thing, I'm just fixing things up".

Would it be correct to phrase the points you are trying to make in
this email as:

If the conflict doesn't fall into a category of being a trivial one,
were both sides did the right thing and someone only has to fix things
up to co-exist -- something is wrong, and the conflict should be
resolved by a per-merge fix to at least one of the patches

?

[...]

> So no, "merge things right" is not the answer. Well, not the whole
> answer. I really want your two groups to be aware of each other. Talk
> before-hand. When you work on the same thing, TALK TO EACH OTHER - so
> that you share the same end result, so that it gets testing in both
> your groups.

>               Linus

Agree... we'll also share the internal practices for that
rdma-next/net-next shared-git tree with Doug to see he's happy with
how we act to improve things.

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                         ` <56A4F986.5070604-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
@ 2016-01-24 17:16                                           ` Linus Torvalds
       [not found]                                             ` <CA+55aFy6ynd91QhGHyo=9vHb8HPj4yvsY10kYXPVpBSPemcxJg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24 17:16 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Doug Ledford, David Miller, linux-rdma, Saeed Mahameed,
	Achiad Shochat, Matan Barak, Alaa Hleihel, Leon Romanovsky,
	Haggai Eran, Stephen Rothwell

On Sun, Jan 24, 2016 at 8:19 AM, Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>
> It's possible that for a given merge cycle, we have networking changes that
> require core changes and RDMA changes which require different core changes.

Yes.

However, you should synchronize it some way at least _internally_.
Maybe by using a git tree inside Mellanox, so that the pain of your
two development groups doesn't then hit people who don't know the
hardware and can't test.

> So I'd like to clarify with you a point re linux-next.
>
> From my experience working under few maintainers (Dave, Roland, Doug) over
> the years...what the maintainer has to do is (A) register their for-next
> tree/branch to linux-next merge tests and (B) respond to the linux-next
> maintainer when he identifies conflicts and resolves them.

Yes. And as far as I can tell, this conflict _was_ in linux-next.

However, the fact that it got resolved in linux-next is purely
informational. It doesn't "fix" the conflict - it just means that both
sides should have gotten informed about it. That doesn't mean that the
conflict goes away or becomes better.

So what linux-next conflicts should have resulted in was that people
were aware of it before it even hit my tree, and there might be
mitigating efforts taken (where "mitigation" might be just informing
me about it in the pull request, which didn't even happen).

And Stephen is actually really really good at handling merge conflicts
these days (he's probably the _one_ person who does more merges than I
do), but at the same time, he tends to have a "merge and forget" model
- not only does he use "git rerere" so that he never has to worry
about the merge later, he doesn't tend to care very much about the end
result and think about it.

For example, I doubt Stephen spent a lot of time worrying about the
byte offsets in that header file - he cares about getting things to
compile. Or did he notice and notify people that the offsets were
crap?

In contrast, when I do a merge, I end up trying to see what the
background for the conflict is. And that's not just about the code,
it's explicitly about things like "why did these two trees conflict in
the first place".

Because _I_ care about not just trying to get things to compile, and
not just about getting the right merge result, but in fact things like
"is there some problem in code maintenance that causes this conflict -
should we maybe split development some way?" is very much a primary
concern for me.

In 99% of all conflicts, the answer is "it's a trivial conflict, both
sides did the rigth thing, I'm just fixing things up".

But sometimes the conflicts are about fundamental problems. The ARM
SoC updates were one such area a few years ago, where the insane
devicetree people continually stepped on each others toes and it got
annoying conflicts many times.

I told the ARM people that their model wasn't working, and the ARM
situation has improved tremendously.

Now I'm telling you guys. There's something rotten in the state of
Mellanox. It needs to be fixed.

> A2nd question here, AFAIK, git rerere assumes some ordering... is it okay
> we'll assume that you will always pull the networking changes and only later
> the rdma changes?

No.

Also note that I do not use "rerere" myself. I do not import the state
from linux-next, although I _use_ linux-next to see what I still have
to merge, and sometimes to look at whether things had been resolved
there (which is why I know at least _some_ of the Mellanox issues
already showed up in linux-next).

So linux-next merging is very different. The merge I do is independent
of linux-next, and it's often done in a different order.

> And this brings me to the last point, merge tests should be done before
> sending you pull requests. I know Dave is doing that... we will be
> discussing this with Doug to agree on the details.

The thing is, merge tests are all god, and I appreciate them as a
heads-up. Some groups do pre-merges to verify that nothing bad
happened, and also to give pointers about what is going on when they
do happen. The ARM team does that, for example, probable exactly
because of the historical issues they used to have.

But at the same time I do *not* appreciate submaintainer pre-merging
the end result in order to hide problems in the development model. I
don't want to see "I did a merge for you because it was nasty". I'm
not trying to push the pain of merging onto Doug, just so that I don't
need to know about it. Because I _do_ need to know about it, because
problems during the merge are important information for me. They are a
sign that something is not right, and two groups are stomping on each
others feet.

Problematic merges often cause problems later. Sometimes they cause
problems for immediate reasons - the merge resulted in bugs, and it's
*really* nasty when mis-merges cause issues, because there is often
not a very legible patch to blame. But at other times, the merge is
fine, but it hides the conflict of people working on the same code,
which will just cause problems later when it happens again.

So no, "merge things right" is not the answer. Well, not the whole
answer. I really want your two groups to be aware of each other. Talk
before-hand. When you work on the same thing, TALK TO EACH OTHER - so
that you share the same end result, so that it gets testing in both
your groups.

              Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                     ` <CA+55aFy0OuZ+TOsNRkqyGbpJf1LvLAodO2DqUfpcrKsQHQWLxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-24  2:52                                       ` Linus Torvalds
  2016-01-24 14:27                                       ` Doug Ledford
@ 2016-01-24 16:19                                       ` Or Gerlitz
       [not found]                                         ` <56A4F986.5070604-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
  2 siblings, 1 reply; 186+ messages in thread
From: Or Gerlitz @ 2016-01-24 16:19 UTC (permalink / raw)
  To: Linus Torvalds, Doug Ledford
  Cc: David Miller, linux-rdma, Saeed Mahameed, Achiad Shochat,
	Matan Barak, Alaa Hleihel, Leon Romanovsky, Haggai Eran,
	Stephen Rothwell

On 1/24/2016 4:03 AM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 5:26 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 01/23/2016 07:38 PM, Linus Torvalds wrote:
>>> This kind of idiocy where one company has two different groups, and
>>> they are fighting over the same driver, and then expecting upstream to
>>> sort out their mental problems for them is not acceptable. It's not
>>> the job of either me or the subsystem maintainers to sort out your
>>> differences for you.
>> Can I get some specifics of what you are talking about here?  The reason
>> I ask is that I know in this merge cycle there was a function modified
>> in the mlx4 driver (I think, or maybe mlx5) where it was first modified
>> by a patch series that went through Dave's tree, then further modified
>> by a series in my tree.
> So these are in your tree:
>
>    mlx5_core: Break down the vport mac address query function
>    net/mlx5_core: Introduce access functions to enable/disable RoCE
>    net/mlx5_core: Introduce access functions to query vport RoCE fields
>
> and the networking tree has
>
>    net/mlx5: Update access functions to Query/Modify vport MAC address
>    net/mlx5: Introduce access functions to modify/query vport mac lists
>    net/mlx5: Introduce access functions to modify/query vport state
>    net/mlx5: Introduce access functions to modify/query vport promisc mode
>    net/mlx5: Introduce access functions to modify/query vport vlans
>
> which are _similar_ but different. The differences are small annoying
> details, like slightly different error handling ("goto out" vs just
> conditional), slightly different arguments (vport or not), and a mix
> of EXPORT_SYMBOL and EXPORT_SYMBOL_GPL.
>
> The differences are just *stupid*. They are doing very similar things
> in very similar areas, but the two groups didn't try to match things
> up or apparently talk to each other, or try to actively make it easier
> for maintainers to merge their annoying small differences to the exact
> same area of the file.
>
> So they just changed their driver as if they were the only people
> working on it. Two separate groups. In the same company.
> What is even more annoying to merge, though, is how the two groups
> again separately changed the structures that apparently describe the
> hardware layout of things.
>
> That "struct mlx5_ifc_cmd_hca_cap_bits" is a major pain in the arse,
> for example. It doesn't help that the *undocumented* parts of that
> array are described with things like
>
>      u8 reserved_66[0x8];
>     ...
>      u8 reserved_67[0x40];
>
> and then when one group documents something in the middle of that
> reserved region, it gets split up and the reserved_NNN[xyz] numbers
> change.

Linus,

Re different styling (branching, exporting), in the same driver, point 
taken.
We will work to improve on that through tighter internal codes reviews 
and briefing of people on such practices.

Re the header file that described the layout for the driver / firmware 
layouts, point taken too. We should be changing how the currently 
reserved fields are named, such that when one person opens feature X and 
a 2nd person opens feature Y, both on structure Z, the two people would 
have to change only distinct fields, and hence less noise which creates 
unneeded conflicts.

The Mellanox NIC HW is used for both plain Eth networking and RDMA. The 
upstream RDMA stack support IB, RoCE (RDMA over Eth) and user-space Eth 
offloading.As such, forboth mlx4 and mlx5 there's a core driver plus on 
top of Eth and RDMA driver.

It's possible that for a given merge cycle, we have networking changes that
require core changes and RDMA changes which require different core changes.

We aim to minimize that, but this happens (and is also too sensitive now,
as you pointed out re the mlx5_ifc header, which we need to fix), and... we
counted on linux-next merge tests, as the process to know things are on 
the righttrack.

So I'd like to clarify with you a point re linux-next.

 From my experience working under few maintainers (Dave, Roland, Doug) 
over the years...what the maintainer has to do is (A) register their 
for-next tree/branch to linux-next merge tests and (B) respond to the 
linux-next maintainer when he identifies conflicts and resolves them.

AFAIK, when the conflict is resolved, Stephen uses git rerere to produce 
corrective action and the result is applied from the rr-cache when you 
do the merge.

Can you confirm this is how things work?

A2nd question here, AFAIK, git rerere assumes some ordering... is it 
okay we'll assume that you will always pull the networking changes and 
only later the rdma changes?

The case you mentioned of conflict during one of the 2015 merge windows was
I think with a patch that either landed too late in the rdma-next 
branch, or that the branch wasn't registered for linux-next tests.

For this merge window there were 1-2 cases where Stephen reported and 
solved the conflict,and another one were we did that and sent him the 
rere files. We thought we're all Okay.

As Doug noted, the majority of the code for the merge window was in his 
tree since Dec 24. It's possible that some code landed there later or 
even really close to the point where the pull request sent to you, so 
one conflict went
unnoticed, this we (RDMA maintainer + Mellanox) need to make sure will 
not happen.

And this brings me to the last point, merge tests should be done before 
sending you pull requests. I know Dave is doing that... we will be 
discussing this with Doug to agree on the details.

Or.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                                 ` <CA+55aFxHrSB4cqs6Pzk3-AwJB17F2sTyunNGBjiCL0=Uijr-gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24 14:40                                                   ` Doug Ledford
       [not found]                                                     ` <56A4E25C.20905-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-24 14:40 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On 01/23/2016 10:13 PM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 7:05 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>> rdma had better not be this kind of pain in the arse in the future,
>> because I really will just stop pulling if it is.
> 
> Side note: I'd suggest you start using branches for rdma. Because I'm
> going to be very picky about my rdma pulls going forward, and if  you
> put everything in one big pile, the likelihood that it just gets
> rejected is now very very high.

Understood.  This release cycle was a bit of a flag day.  There were
early cleanups that the rest of the code depended on, hence the way it
was put together.  I tend to use branches if they can be merged easily
and don't have these sorts of early, intrusive dependencies.

> Using separate branches means that I can decide to merge the sane and
> easy stuff. The stuff that doesn't contain Mellanox shit, in other
> words. The stuff that isn't controversial.

Ok.

> At least that way you get *something* merged. Because right now I'm
> actually so fed up with this that if I hadn't already pushed it out, I
> would have decided to just undo the pull after all.

Or, can you please make sure that the right people inside Mellanox
review Linus tree for any merge issues ASAP.  Then let's have a separate
conversation about preventing this in the future?

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                     ` <CA+55aFy0OuZ+TOsNRkqyGbpJf1LvLAodO2DqUfpcrKsQHQWLxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-24  2:52                                       ` Linus Torvalds
@ 2016-01-24 14:27                                       ` Doug Ledford
  2016-01-24 16:19                                       ` Or Gerlitz
  2 siblings, 0 replies; 186+ messages in thread
From: Doug Ledford @ 2016-01-24 14:27 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On 01/23/2016 09:03 PM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 5:26 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 01/23/2016 07:38 PM, Linus Torvalds wrote:
>>>
>>> This kind of idiocy where one company has two different groups, and
>>> they are fighting over the same driver, and then expecting upstream to
>>> sort out their mental problems for them is not acceptable. It's not
>>> the job of either me or the subsystem maintainers to sort out your
>>> differences for you.
>>
>> Can I get some specifics of what you are talking about here?  The reason
>> I ask is that I know in this merge cycle there was a function modified
>> in the mlx4 driver (I think, or maybe mlx5) where it was first modified
>> by a patch series that went through Dave's tree, then further modified
>> by a series in my tree.
> 

[ snip detailed explanation of horrible merge mess ]

Thanks, that makes absolute sense.  Digging your eyeballs out with a
rusty spoon seems preferable in this case.

> In other words, there are lots of different alternatives to improve on
> what's going on. But this "throw crap against the wall and hope it
> sticks" approach that the two groups are clearly using now is *not*
> acceptable.

Agreed.

> If this was the first time it happened, I'd just be annoyed. As it is,
> something similar happened not that long ago, witht he same people. At
> this point I'm past "pissed", and firmly in "if this happens again,
> I'll just stop pulling the crap" camp.

Mellanox has been working to get one official Mellanox git repo through
which all of their patch submissions flow.  I'll simply stop taking
anything from them that doesn't come from this (yet to be announced
where it will live) git repo.  They can then merge their disparate
efforts prior to ever submitting them upstream to either Dave or myself.
 That should address the merge issue.  It won't, however, address
consistency issues in coding style.  That's something Mellanox will need
to address internally.  I know they have tapped Saeed to handle that
merge tree, and he's on the Cc: list here, so Saeed, you will need to
get your tree up sooner rather than later and I'll expect patch
submissions to start coming from you.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                       ` <CA+55aFw_-C5ek_bfw-2p=u38Ez5TN9=B_iBraUTF6jUQc2hSkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24  7:28                                         ` David Miller
  0 siblings, 0 replies; 186+ messages in thread
From: David Miller @ 2016-01-24  7:28 UTC (permalink / raw)
  To: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
  Cc: achiad-VPRAkNaXOzVWk0Htik3J/w, saeedm-VPRAkNaXOzVWk0Htik3J/w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	dledford-H+wXaHxf7aLQT0dZR+AlfA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w

From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Sat, 23 Jan 2016 22:51:34 -0800

> On Jan 23, 2016 9:58 PM, "David Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>
>> Nothing prevents you from pulling from my tree Doug.
> 
> I really don't think that will fix the fundamental problem.
> 
> Namely the fact that Mellanox has two teams each working on the same driver
> and not talking to each other.

Yes that's a large part of the problem.

> They should sort out their own differences, not have other outside
> people have to sort out their mess.

I agree.

But if they put all of their mlx{4,5}_core changes into my tree, then
they have to coordinate.

Because obviously all the screaming and complaining we've done the past
two merge windows is not working.  They still suck at this.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                 ` <56A42829.90401-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  2016-01-24  2:03                                   ` Linus Torvalds
@ 2016-01-24  5:58                                   ` David Miller
       [not found]                                     ` <CA+55aFw_-C5ek_bfw-2p=u38Ez5TN9=B_iBraUTF6jUQc2hSkQ@mail.gmail.com>
  1 sibling, 1 reply; 186+ messages in thread
From: David Miller @ 2016-01-24  5:58 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA, saeedm-VPRAkNaXOzVWk0Htik3J/w,
	ogerlitz-VPRAkNaXOzVWk0Htik3J/w, achiad-VPRAkNaXOzVWk0Htik3J/w

From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Sat, 23 Jan 2016 20:26:01 -0500

> Can I get some specifics of what you are talking about here?  The reason
> I ask is that I know in this merge cycle there was a function modified
> in the mlx4 driver (I think, or maybe mlx5) where it was first modified
> by a patch series that went through Dave's tree, then further modified
> by a series in my tree.  In both cases, the modification was part of a
> larger series that was specific either to the network tree or the rdma
> tree.  If that's the sort of thing you are talking about, I'm not sure
> how we can resolve that.  The fact that the mlx4_core and mlx5_core
> modules essentially straddle the networking and rdma trees presents a
> unique situation with its own difficulties.  If the problem I listed is
> what you are referring to, the only way I know to fix that is to have
> Mellanox send all of their patches through one tree, and that means
> either Dave or myself is going to have to deal with stuff they wouldn't
> normally deal with.  Of course, if I'm wrong about what you are
> referring to, then enlightenment would be appreciated ;-)

Nothing prevents you from pulling from my tree Doug.
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                             ` <CA+55aFzh4_T6MUM7CQsBc5AVe5WhiG=SDkXpRH_eNOZKPMAZMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24  3:13                                               ` Linus Torvalds
       [not found]                                                 ` <CA+55aFxHrSB4cqs6Pzk3-AwJB17F2sTyunNGBjiCL0=Uijr-gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24  3:13 UTC (permalink / raw)
  To: Doug Ledford
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

On Sat, Jan 23, 2016 at 7:05 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> rdma had better not be this kind of pain in the arse in the future,
> because I really will just stop pulling if it is.

Side note: I'd suggest you start using branches for rdma. Because I'm
going to be very picky about my rdma pulls going forward, and if  you
put everything in one big pile, the likelihood that it just gets
rejected is now very very high.

Using separate branches means that I can decide to merge the sane and
easy stuff. The stuff that doesn't contain Mellanox shit, in other
words. The stuff that isn't controversial.

At least that way you get *something* merged. Because right now I'm
actually so fed up with this that if I hadn't already pushed it out, I
would have decided to just undo the pull after all.

                    Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                         ` <CA+55aFymjONiSk+gVRk8XaViw9BuG1A6KgGWHgq=kj+XZsEw8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24  3:05                                           ` Linus Torvalds
       [not found]                                             ` <CA+55aFzh4_T6MUM7CQsBc5AVe5WhiG=SDkXpRH_eNOZKPMAZMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24  3:05 UTC (permalink / raw)
  To: Doug Ledford
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

On Sat, Jan 23, 2016 at 6:52 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> I picked one at random, not having the energy to figure out where
> those offsets went wrong.

My merge is out there now. Hopefully mellanox rdma works. And I cannot
for the life of me find it in myself to care.

rdma had better not be this kind of pain in the arse in the future,
because I really will just stop pulling if it is.

                Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                     ` <CA+55aFy0OuZ+TOsNRkqyGbpJf1LvLAodO2DqUfpcrKsQHQWLxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24  2:52                                       ` Linus Torvalds
       [not found]                                         ` <CA+55aFymjONiSk+gVRk8XaViw9BuG1A6KgGWHgq=kj+XZsEw8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-24 14:27                                       ` Doug Ledford
  2016-01-24 16:19                                       ` Or Gerlitz
  2 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24  2:52 UTC (permalink / raw)
  To: Doug Ledford
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

On Sat, Jan 23, 2016 at 6:03 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> That "struct mlx5_ifc_cmd_hca_cap_bits" is a major pain in the arse,
> for example.

So here is the end of this from the two branches before the merge:

 - from the networking tree:

        u8         reserved_60[0x1b];
        u8         log_max_wq_sz[0x5];

        u8         nic_vport_change_event[0x1];
        u8         reserved_61[0xa];
        u8         log_max_vlan_list[0x5];
        u8         reserved_62[0x3];
        u8         log_max_current_mc_list[0x5];
        u8         reserved_63[0x3];
        u8         log_max_current_uc_list[0x5];

        u8         reserved_64[0x80];

 - from your tree:

        u8         reserved_60[0x1b];
        u8         log_max_wq_sz[0x5];

        u8         reserved_61[0xa0];

(I've thrown out the common parts at the beginning of that structure).

Now, that's a split that makes sense: the "reserved_61[0xa0]" in the
second case has been split right. Good. It matches, and they both add
up to the same size (0xa0 bytes).

Then we have a common part (except the "reserved_xyz" numbers now
don't match due to the split:

 - networking tree again:

        u8         reserved_65[0x3];
        u8         log_max_l2_table[0x5];
        u8         reserved_66[0x8];
        u8         log_uar_page_sz[0x10];

 - your branch:

        u8         reserved_62[0x3];
        u8         log_max_l2_table[0x5];
        u8         reserved_63[0x8];
        u8         log_uar_page_sz[0x10];


Fine, still matching, just annoying to merge due to the different
names for the reserved areas.

Then, we have another split:

 - networking tree:

        u8         reserved_67[0x40];
        u8         device_frequency_khz[0x20];
        u8         reserved_68[0x5f];
        u8         cqe_zip[0x1];

        u8         cqe_zip_timeout[0x10];
        u8         cqe_zip_max_num[0x10];

        u8         reserved_69[0x220];

 - your branch:

        u8         reserved_64[0x20];
        u8         device_frequency_mhz[0x20];
        u8         device_frequency_khz[0x20];
        u8         reserved_65[0xa0];

        u8         reserved_66[0x1f];
        u8         cqe_zip[0x1];

        u8         cqe_zip_timeout[0x10];
        u8         cqe_zip_max_num[0x10];

        u8         reserved_67[0x220];

Ok, so your branch inserted that 32-byte "device_frequency_mhz" thing,
which is why the reserved area 67/64 changed in size.

But look at what happens *after* that. The networking tree has

        u8         reserved_68[0x5f];

but your branch has

        u8         reserved_65[0xa0];

        u8         reserved_66[0x1f];

before the cqe_zip[]. They no longer match up. Something bad happened
in one of the branches, and "cqe_zip[]" and the subsequent fields are
at different offsets.

This is impossible to merge. One of the branches is wrong.

I picked one at random, not having the energy to figure out where
those offsets went wrong.

But it annoys me enormously how much time and effort I had to put into
this merge.

Because it was all a complete waste of my time. I could have done more
productive, or at least more pleasant things. Like digging out my eyes
with a rusty spoon rather than look at this crap and trying to count
byte offsets.

If those "reserved" fields were named for the expected offset they are
at, then not only wouldn't the names have changed (which would have
made things much easier to merge - the parts that weren't split would
have auto-merged cleanly and correctly), but it would be much more
obvious which one was right and which one was wrong.

As it is, it's impossible to tell without knowing the hardware details
or going back in history and trying to see where the offsets magically
changed.

                Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                                 ` <56A42829.90401-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-24  2:03                                   ` Linus Torvalds
       [not found]                                     ` <CA+55aFy0OuZ+TOsNRkqyGbpJf1LvLAodO2DqUfpcrKsQHQWLxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-24  5:58                                   ` David Miller
  1 sibling, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24  2:03 UTC (permalink / raw)
  To: Doug Ledford
  Cc: David Miller, linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

On Sat, Jan 23, 2016 at 5:26 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 01/23/2016 07:38 PM, Linus Torvalds wrote:
>>
>> This kind of idiocy where one company has two different groups, and
>> they are fighting over the same driver, and then expecting upstream to
>> sort out their mental problems for them is not acceptable. It's not
>> the job of either me or the subsystem maintainers to sort out your
>> differences for you.
>
> Can I get some specifics of what you are talking about here?  The reason
> I ask is that I know in this merge cycle there was a function modified
> in the mlx4 driver (I think, or maybe mlx5) where it was first modified
> by a patch series that went through Dave's tree, then further modified
> by a series in my tree.

So these are in your tree:

  mlx5_core: Break down the vport mac address query function
  net/mlx5_core: Introduce access functions to enable/disable RoCE
  net/mlx5_core: Introduce access functions to query vport RoCE fields

and the networking tree has

  net/mlx5: Update access functions to Query/Modify vport MAC address
  net/mlx5: Introduce access functions to modify/query vport mac lists
  net/mlx5: Introduce access functions to modify/query vport state
  net/mlx5: Introduce access functions to modify/query vport promisc mode
  net/mlx5: Introduce access functions to modify/query vport vlans

which are _similar_ but different. The differences are small annoying
details, like slightly different error handling ("goto out" vs just
conditional), slightly different arguments (vport or not), and a mix
of EXPORT_SYMBOL and EXPORT_SYMBOL_GPL.

The differences are just *stupid*. They are doing very similar things
in very similar areas, but the two groups didn't try to match things
up or apparently talk to each other, or try to actively make it easier
for maintainers to merge their annoying small differences to the exact
same area of the file.

So they just changed their driver as if they were the only people
working on it. Two separate groups. In the same company.

What is even more annoying to merge, though, is how the two groups
again separately changed the structures that apparently describe the
hardware layout of things.

That "struct mlx5_ifc_cmd_hca_cap_bits" is a major pain in the arse,
for example. It doesn't help that the *undocumented* parts of that
array are described with things like

    u8 reserved_66[0x8];
   ...
    u8 reserved_67[0x40];

and then when one group documents something in the middle of that
reserved region, it gets split up and the reserved_NNN[xyz] numbers
change.

In fact, just looking at that particular "struct
mlx5_ifc_cmd_hca_cap_bits", I think one of the two branches got the
padding wrong at some point, because they no longer seem to agree
about the offsets in the structure.

Imagine what a joy it is to merge crap like that.

If it was two different independent groups, I'd go "ok, this is my
life now", take an extra dose of happy pills, and merge things.
Because I'd be the person who has to sort that shit out. It's my job.

But what annoys me about this situation is that the two groups that
crap on each other are in the same company. They should talk to each
other.

For example, to make those hardware descriptor structures easier to
keep track of (not just for merging, since apparently people got the
offsets wrong even outside of the merges), maybe instead of using a
random number for the reserved field, the code could use the expected
_offset_. So instead of

    u8 reserved_66[0x8];

it could be something like

    u8 reserved_at_0240[0x8];

to not cause the stupid things to change names just because some
_earlier_ reserved field was split. Add a few lines of
offsets-in-comments in the parts that don't have a lot of
"reserved_xyz[]" fields, and suddenly those hardware description
structures would be a hell of a lot easier to see what they do.

Because right now they literally have random noise in them. This is a
random sampling:

   ...
    u8 reserved_60[0x1b];
    u8 reserved_61[0xa];
    u8 reserved_62[0x3];
    u8 reserved_63[0x3];
    u8 reserved_64[0x80];
    u8 reserved_65[0x3];
    u8 reserved_66[0x8];
    u8 reserved_67[0x20];
    u8 reserved_68[0x5f];
    u8 reserved_69[0x220];
    u8 reserved_0[0x20];
    u8 reserved_0[0xa00];
   ...

and that's a _small_ random sampling: there are about 1500 lines of
those kinds of "reserved_nn[]" fields in that one file.

Just imagine how fun it is to see one of those random numbers (one of
the bigger ones), split - completely differently - in the two
different versions, and everything else get renumbered.

I wish I was kidding. I'm not.

[ I'm actually planning on re-doing my merge with something like that
in both branches before the merge, just because I want to make sure I
got the offsets right - maybe the reason I think somebody screwed up
their offsets earlier was just because I screwed up when trying to
merge this mess ]

But even more than things like that, I'd expect that two groups inside
of Mellanox would talk to each other, and NOT MERGE DIFFERENT CHANGES
TO THE SAME DRIVER THROUGH TWO DIFFERENT MAINTAINERS!

Or maybe they could use a shared git branch to at least handle the
common changes so that they don't conflict. Or maybe they should split
up their driver so that the two different groups don't step on each
others toes. Or maybe the could use tricks like that
"reserved_at_offset[]" thing to at least make the step-on-each-other
not be such a pain.

In other words, there are lots of different alternatives to improve on
what's going on. But this "throw crap against the wall and hope it
sticks" approach that the two groups are clearly using now is *not*
acceptable.

If this was the first time it happened, I'd just be annoyed. As it is,
something similar happened not that long ago, witht he same people. At
this point I'm past "pissed", and firmly in "if this happens again,
I'll just stop pulling the crap" camp.

                  Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                             ` <CA+55aFz9Dnu7Ri8XA291VdSYZ5gqyt+cmaaRNULQ0hVetoAJZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-24  1:26                               ` Doug Ledford
       [not found]                                 ` <56A42829.90401-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-24  1:26 UTC (permalink / raw)
  To: Linus Torvalds, David Miller
  Cc: linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]

On 01/23/2016 07:38 PM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 2:27 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>> So how ready and stable is this? IOW, if I do this pull, can I rely on
>>> that being "it", and really just get fixes.
>>
>> I still want to send the staging changes.
> 
> I'm not at all convinced I will pull them.
> 
> And I'm now looking at pulling the stuff you sent yesterday, and I'm
> close to just saying "screw this". Again.
> 
> This is now the *second* time that two different teams inside Mellanox
> decided to play games with the kernel maintainers, and I'm not at all
> sure the end result is not worth my time to sort out.

Understood.

> Doug, you need to stop taking patches from the Mellanox people until
> the get their shit together.  Really. I'll spend some time looking at
> this mess, but next time I see two Mellanox groups fighting inside
> their own driver, I will just not pull. It's that simple. If you take
> shit from them, I'll not take the end result.
> 
> I don't know what problem the Mellanox people have, but one group
> sends their changes through the networking tree, and another group
> sends it through you. They do similar things, but different enough to
> not be the same.
> 
> You tell them to stop sending that stuff to you, because I'm getting
> it through Davem. And I'm not interested in cleaning up after their
> mess.
> 
> Adding David and Mellanox people to the cc.
> 
> This kind of idiocy where one company has two different groups, and
> they are fighting over the same driver, and then expecting upstream to
> sort out their mental problems for them is not acceptable. It's not
> the job of either me or the subsystem maintainers to sort out your
> differences for you.

Can I get some specifics of what you are talking about here?  The reason
I ask is that I know in this merge cycle there was a function modified
in the mlx4 driver (I think, or maybe mlx5) where it was first modified
by a patch series that went through Dave's tree, then further modified
by a series in my tree.  In both cases, the modification was part of a
larger series that was specific either to the network tree or the rdma
tree.  If that's the sort of thing you are talking about, I'm not sure
how we can resolve that.  The fact that the mlx4_core and mlx5_core
modules essentially straddle the networking and rdma trees presents a
unique situation with its own difficulties.  If the problem I listed is
what you are referring to, the only way I know to fix that is to have
Mellanox send all of their patches through one tree, and that means
either Dave or myself is going to have to deal with stuff they wouldn't
normally deal with.  Of course, if I'm wrong about what you are
referring to, then enlightenment would be appreciated ;-)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                         ` <56A3FE6F.4000800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-24  0:38                           ` Linus Torvalds
       [not found]                             ` <CA+55aFz9Dnu7Ri8XA291VdSYZ5gqyt+cmaaRNULQ0hVetoAJZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-24  0:38 UTC (permalink / raw)
  To: Doug Ledford, David Miller
  Cc: linux-rdma, Saeed Mahameed, Or Gerlitz, Achiad Shochat

On Sat, Jan 23, 2016 at 2:27 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> So how ready and stable is this? IOW, if I do this pull, can I rely on
>> that being "it", and really just get fixes.
>
> I still want to send the staging changes.

I'm not at all convinced I will pull them.

And I'm now looking at pulling the stuff you sent yesterday, and I'm
close to just saying "screw this". Again.

This is now the *second* time that two different teams inside Mellanox
decided to play games with the kernel maintainers, and I'm not at all
sure the end result is not worth my time to sort out.

Doug, you need to stop taking patches from the Mellanox people until
the get their shit together.  Really. I'll spend some time looking at
this mess, but next time I see two Mellanox groups fighting inside
their own driver, I will just not pull. It's that simple. If you take
shit from them, I'll not take the end result.

I don't know what problem the Mellanox people have, but one group
sends their changes through the networking tree, and another group
sends it through you. They do similar things, but different enough to
not be the same.

You tell them to stop sending that stuff to you, because I'm getting
it through Davem. And I'm not interested in cleaning up after their
mess.

Adding David and Mellanox people to the cc.

This kind of idiocy where one company has two different groups, and
they are fighting over the same driver, and then expecting upstream to
sort out their mental problems for them is not acceptable. It's not
the job of either me or the subsystem maintainers to sort out your
differences for you.

                  Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                     ` <CA+55aFzeW-UjwWarz9hZ3dgnTFSJuNFJ2_YikJPbXAZ_i2+RSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-23 22:27                       ` Doug Ledford
       [not found]                         ` <56A3FE6F.4000800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-23 22:27 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]

On 01/23/2016 02:02 PM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 8:16 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> I don't think it's as "clearly not ready" as you think, but that's just
>> my opinion ;-)
> 
> So how ready and stable is this? IOW, if I do this pull, can I rely on
> that being "it", and really just get fixes.

I still want to send the staging changes.  But those are actually very
small: there are three drivers in staging/rdma that we put there as a
deprecation step and that need to be deleted, and I need to update the
maintainers file to exclude staging/rdma from the directory list for the
primary staging area so people quit sending patches for it to the normal
staging mailing list.  The problem we had with staging/rdma is that it's
waffled back and forth as to whether Greg or I would handle the patches,
but the hfi1 driver is now at a point where it needs to have its patches
coordinated with patches in the main rdma tree, and so it was agreed
that I would take over staging/rdma and Greg would ignore it, but Greg
needed to go ahead and push through all of his staged changes before we
put that in place and I'll take over starting with the next for-next
cycle.  Otherwise, yes, the pull request I sent you is "it" for this
release.  I have no other queued series or misc items, everything else
is relegated to for-next status (of which I have quite a few of those
and probably need to open my for-next quickly anyway).

> One of the reasons I absolutely detest the "last Friday" pull requests
> is that it really tends to smell like "this pull request was hurried
> to hit the merge window".

I tried to carefully select what I felt was ready versus should wait
when I processed patches upon my return from PTO.  There are 171 patches
total in the pull request.  Of those, 99 have been there since before
Dec. 24th.  There were 57 that I processed on Monday and Tuesday when I
got back from PTO.  That broke down to 34 one off patches that include a
smattering of things like sparse and other checker fixes, actual oops
fixes, and cleanups; 12 patches for the NFSoRDMA stack that were
previously in Bruce's tree; and a series specific to the mlx4 driver.  I
let this sit specifically for linux-next automated runs.  On Thursday I
decided to take a series I had previously skipped (support for raw QP
types in the mlx5 driver) and I took one fix I had previously missed and
was brought to my attention, and I took one fix that didn't get authored
until that morning and needs to go into your tree even if the rest of
the pull request doesn't.  I then let that sit overnight again just to
get another round of linux-next testing.  It goes without saying that I
got positive 0day results on all of these, and generally much faster
than waiting overnight and checking to see if any failure messages came
back.

>  I much prefer seeing early pull requests
> because that just shows that the subsystem is on top of the timing.
> And that in turn means that I also get that warm and fuzzy feeling
> that if the subsystem has its act together, I'll be getting just fixes
> after the merge window is over.
> 
> (The _other_ reason I don't like the last-Friday pull requests and
> prefer the early ones is that then I'm not hurried, and I can take my
> time and do the pull requests in sensible groups - filesystems
> together etc)
> 
> So if I end up pulling this, can I rely on getting just fixes for the
> next ~6-7 weeks?

Yes, that much I can assure you.  And if you don't take it, I can also
attest that there will be roughly 20 fixes coming your way shortly ;-)


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]                 ` <56A3A777.3-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-23 19:02                   ` Linus Torvalds
       [not found]                     ` <CA+55aFzeW-UjwWarz9hZ3dgnTFSJuNFJ2_YikJPbXAZ_i2+RSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-23 19:02 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

On Sat, Jan 23, 2016 at 8:16 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> There is a schedule document somewhere?

For just the schedule? No. But there's this, for example:

    Documentation/development-process/2.Process

which talks about it and says "The merge window lasts for
approximately two weeks".

The easiest way to find that piece of documentation is actually to
just google "merge window". It's the first hit.

> I don't think it's as "clearly not ready" as you think, but that's just
> my opinion ;-)

So how ready and stable is this? IOW, if I do this pull, can I rely on
that being "it", and really just get fixes.

One of the reasons I absolutely detest the "last Friday" pull requests
is that it really tends to smell like "this pull request was hurried
to hit the merge window".  I much prefer seeing early pull requests
because that just shows that the subsystem is on top of the timing.
And that in turn means that I also get that warm and fuzzy feeling
that if the subsystem has its act together, I'll be getting just fixes
after the merge window is over.

(The _other_ reason I don't like the last-Friday pull requests and
prefer the early ones is that then I'm not hurried, and I can take my
time and do the pull requests in sensible groups - filesystems
together etc)

So if I end up pulling this, can I rely on getting just fixes for the
next ~6-7 weeks?

                Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFzhwDNiBr0MKyFYn8WCLxhPrBxU0TPTSskm5B3VkzhD9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-23 15:06               ` Christoph Lameter
@ 2016-01-23 16:16               ` Doug Ledford
       [not found]                 ` <56A3A777.3-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  1 sibling, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-23 16:16 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 6527 bytes --]

On 01/23/2016 12:42 AM, Linus Torvalds wrote:
> On Fri, Jan 22, 2016 at 9:01 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> I obviously have my understanding of the development cycle here wrong.
>> I had thought that the merge window was 4 weeks with a following 8 weeks
>> of RC candidates resulting in roughly quarterly pace.  But you tagged
>> v4.4 on 1/10/16, so this Sunday is only 2 weeks.  That certainly changes
>> things.  I did not believe that the merge window was so short when I
>> sent this request.
> 
> We've had this model now for ten years by now. Yes, it's really been that long.
> 
> Two weeks of merge window, followed by weekly release candidates until
> it's "ready" (where the most common last one tends to be rc7, but that
> has certainly fluctuated - we had 3.1 go to rc10 before release, and
> we've had a few that only got to rc6).
> 
> This all is not new,

I never said it was new.

> and it's not undocumented.

There is a schedule document somewhere?

> I have absolutely no
> idea why you suddenly started multiplying all the times by two.

Only the merge window, not all of it.  Probably too many years working
internally at Red Hat and dealing with schedules that fall into
alignment with quarters without seeming to have any effort to make it
that way.

> It's actually been very stable over the years. We've had exceptions
> where travel schedules (or just holidays etc) have moved things around
> by a week here and there, but on the whole it's actually not varied a
> lot.
> 
>> But also, really?  Even ignoring that misconception,  it's the merge
>> window.  And it has a deadline.
> 
> It's a *MERGE* window.
> 
> Not a *DEVELOPMENT* window.
> 
> See the difference?

I know the difference, there's no need to resort to yelling.

> This is not new either. The rule has been that things should basically
> be ready by the time the merge window *opens*. Things should have been
> in linux-next so that they get some testing, and so that people get a
> heads-up not only about what is coming up, but how it interacts with
> other things coming up.

Certainly.  And most of it was there prior to Dec 23rd when I went on
PTO.  It had linux-next and 0day and other testing.  The things I added
since then were either A) local to the rdma subsystem or B) had been in
linux-next via someone else's tree prior to my going on PTO (the
NFSoRDMA changes qualify here) and were moved to my tree to resolve
dependency issues after I returned.  I made a specific point of
preserving this testing, that's part of why my changes were sent as late
as they were.

> And no, not everything ends up being in linux-next. But I think we've
> been hitting almost 90% most recent releases, so that whole "things
> should be in linux-next beforehand" is not just some theoretical goal,
> it's something we actually hit in practice pretty well.

Indeed.  I strove for that myself.  The only problem here is that there
is no positive result from linux-next, only negative.  So, I just had to
wait and see if I got a notification email about failure or not.

> And yes, I do pull requests until the last minute (although I have
> been known to hurry up the last minute and release -rc1 a day early
> just because I don't want people to game my timing).
> 
> But generally at the last minute I want to feel that there was some
> _reason_ for the last minute behavior.

Fair enough.  What I'm used to is that a deadline is a deadline and as
long as you meet it, you've done your job, no special explanation
necessary.  As previously mentioned, I *thought* the deadline was later,
that was a mistake.  But regardless of that, I did meet the final
deadline anyway, hence I didn't provide a detailed explanation of my
reasons for being on the latter half of the merge window.  But from what
you just wrote, I get the impression that I should have.  The is a
difference between what you are looking for and what I dealt with in my
previous responsibilities.  Difference noted.

> And no, the reason is not "I am hurrying up to get everything done by
> 5pm on a Friday afternoon, and I didn't even get everything done, so
> I'll send the rest on Monday".

I sent the request when I was reasonably sure I wasn't going to get a
linux-next failure notification, not when I was rushing to get out the
door.  You should have gotten it about 9am your time, so I wouldn't have
expected you to think this characterization would have been accurate.

> Because that just makes me go "ok, this is clearly not ready".

I don't think it's as "clearly not ready" as you think, but that's just
my opinion ;-)

> [ And as to why the merge window is two weeks and not just "one single
> day" if everything is supposed to be ready before-hand..
> 
>   That's actually a valid question, but it's at least partially about
> _me_ (but also about flexibility for others, so that we don't have to
> make the 90% be 100%).
> 
>   In particular, just the merging process itself would take me one
> week. I can do about 20-30 merges a day for the first few days, and I
> don't feel I could do more while still actually feeling like I had
> some kind of overview of what I'm merging (the merge itself is often
> quick, it's looking at it and doing a basic build test etc that takes
> time).
> 
>   So one week would be the absolute minimum with the amount of
> different trees I merge - and that assumes that every single tree is
> ready and done at the beginning.
> 
>   In practice, things slow down after a few days as I catch up with
> the queue of pull requests.  So in the end the average over the two
> week period is about 10-15 merges per day for me.
> 
>   By the end of the two weeks, it really should have turned into a
> slow trickle of merges of things that had dependencies or some other
> valid reason to be late.. Or rather, I _wish_ it turned into a
> trickle, but sadly the last Friday afternoon is seldom anything but
> slow.
> 
>   So two weeks "works" - and has worked for the last ten years. It may
> not be perfect, but I think it has worked exceptionally well in the
> end - certainly better than people thought initially when we started
> trying this whole no-longer-very-new-thing.]

Thanks for the explanation.  It all makes sense to me.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]             ` <CA+55aFzhwDNiBr0MKyFYn8WCLxhPrBxU0TPTSskm5B3VkzhD9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-23 15:06               ` Christoph Lameter
  2016-01-23 16:16               ` Doug Ledford
  1 sibling, 0 replies; 186+ messages in thread
From: Christoph Lameter @ 2016-01-23 15:06 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Doug Ledford, linux-rdma

Well Doug is a relatively new maintainer. And the problem we have in the
rdma subsystem is a pretty high degree of change with various
infrastructure changes (new protocols, new drivers, new features, 100G
support, code cleanup ongoing etc). He has trouble keeping up in
particular since he has just been back from maternity leave.

But ongoing development in this area is depending on these changes being
merged in order to move forward with further development and in
order to stabilize what work has been done over the last few month.

So please be generous and lets go through with this merge. We will ensure
that things work smoother in the future.

--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]         ` <56A30910.9010002-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-23  5:42           ` Linus Torvalds
       [not found]             ` <CA+55aFzhwDNiBr0MKyFYn8WCLxhPrBxU0TPTSskm5B3VkzhD9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-23  5:42 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

On Fri, Jan 22, 2016 at 9:01 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> I obviously have my understanding of the development cycle here wrong.
> I had thought that the merge window was 4 weeks with a following 8 weeks
> of RC candidates resulting in roughly quarterly pace.  But you tagged
> v4.4 on 1/10/16, so this Sunday is only 2 weeks.  That certainly changes
> things.  I did not believe that the merge window was so short when I
> sent this request.

We've had this model now for ten years by now. Yes, it's really been that long.

Two weeks of merge window, followed by weekly release candidates until
it's "ready" (where the most common last one tends to be rc7, but that
has certainly fluctuated - we had 3.1 go to rc10 before release, and
we've had a few that only got to rc6).

This all is not new, and it's not undocumented. I have absolutely no
idea why you suddenly started multiplying all the times by two.

It's actually been very stable over the years. We've had exceptions
where travel schedules (or just holidays etc) have moved things around
by a week here and there, but on the whole it's actually not varied a
lot.

> But also, really?  Even ignoring that misconception,  it's the merge
> window.  And it has a deadline.

It's a *MERGE* window.

Not a *DEVELOPMENT* window.

See the difference?

This is not new either. The rule has been that things should basically
be ready by the time the merge window *opens*. Things should have been
in linux-next so that they get some testing, and so that people get a
heads-up not only about what is coming up, but how it interacts with
other things coming up.

And no, not everything ends up being in linux-next. But I think we've
been hitting almost 90% most recent releases, so that whole "things
should be in linux-next beforehand" is not just some theoretical goal,
it's something we actually hit in practice pretty well.

And yes, I do pull requests until the last minute (although I have
been known to hurry up the last minute and release -rc1 a day early
just because I don't want people to game my timing).

But generally at the last minute I want to feel that there was some
_reason_ for the last minute behavior.

And no, the reason is not "I am hurrying up to get everything done by
5pm on a Friday afternoon, and I didn't even get everything done, so
I'll send the rest on Monday".

Because that just makes me go "ok, this is clearly not ready".

[ And as to why the merge window is two weeks and not just "one single
day" if everything is supposed to be ready before-hand..

  That's actually a valid question, but it's at least partially about
_me_ (but also about flexibility for others, so that we don't have to
make the 90% be 100%).

  In particular, just the merging process itself would take me one
week. I can do about 20-30 merges a day for the first few days, and I
don't feel I could do more while still actually feeling like I had
some kind of overview of what I'm merging (the merge itself is often
quick, it's looking at it and doing a basic build test etc that takes
time).

  So one week would be the absolute minimum with the amount of
different trees I merge - and that assumes that every single tree is
ready and done at the beginning.

  In practice, things slow down after a few days as I catch up with
the queue of pull requests.  So in the end the average over the two
week period is about 10-15 merges per day for me.

  By the end of the two weeks, it really should have turned into a
slow trickle of merges of things that had dependencies or some other
valid reason to be late.. Or rather, I _wish_ it turned into a
trickle, but sadly the last Friday afternoon is seldom anything but
slow.

  So two weeks "works" - and has worked for the last ten years. It may
not be perfect, but I think it has worked exceptionally well in the
end - certainly better than people thought initially when we started
trying this whole no-longer-very-new-thing. ]

                Linus
--
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	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found]     ` <CA+55aFziXhmMRk3HqvrUtVv+SaUM0zu3=LKbxo0w9HZPVmDuyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-23  5:01       ` Doug Ledford
       [not found]         ` <56A30910.9010002-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-23  5:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-rdma

[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]

On 01/22/2016 08:12 PM, Linus Torvalds wrote:
> On Fri, Jan 22, 2016 at 10:18 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> This is a rather large update, and it's not entirely complete.  I have
>> some changes to merge for the staging/rdma tree too, but I wanted to get
>> this set in first for dependency reasons, then I'll make a new branch
>> against Greg's staging tree, then send the changes relative to that.
>> Expect that pull request early next week.  Thanks.
> 
> No Doug.
> 
> The merge window closes this Sunday.

I obviously have my understanding of the development cycle here wrong.
I had thought that the merge window was 4 weeks with a following 8 weeks
of RC candidates resulting in roughly quarterly pace.  But you tagged
v4.4 on 1/10/16, so this Sunday is only 2 weeks.  That certainly changes
things.  I did not believe that the merge window was so short when I
sent this request.

> It's already damn late to send me anything at all,

See above about the 2 vs. 4 week misconception.

But also, really?  Even ignoring that misconception,  it's the merge
window.  And it has a deadline.  And if you give me a deadline, then
even though I don't try to cut it too close, I, generally speaking,
*will* use my available time if needed.  But from your description here,
there is an additional deadline in the merge window that is an
unwritten, unspoken, visceral thing that you feel.

Ok, so be it.  A little guidance on that would be appreciated.  Is the
deadline really 1 week after the merge window opens?  10 days?  4 days?
 I ask because this stuff is actually important in terms of planning.  I
had PTO and was off in Hawaii when the merge window opened.  We all have
personal lives, and schedules don't always line up with the merge
window.  Knowing how small the merge window *really* is is important for
me to be able to plan and prioritize actions when I return from
something like this.  So, for my future planning purpses, some
elucidation here would be appreciated.

> it is *much* too
> late to say "this is just part of it".

There were some issues of coordination between work being committed by
GKH and myself.  I needed to make the last things relative to what he
submitted already.  My branch with the code on it that I sent the pull
request for was based on 4.4-rc6 and therefore did no have GKH's work in
it.  I didn't like the idea of just blindly merging his branch into mine
so that his commits were there and I could make my follow on commits, so
it seemed I needed a new branch based upon either GKH's branch that he
submitted to you, or on your current master, to plop the last commits
into.  Given that I thought it was still a couple weeks to go to the
close of the window, Monday seemed reasonable.  I'll probably still
submit the deletes to you sometime tomorrow.

> This can all wait for 4.6, and maybe you'll have the pull requests
> lined up at the *beginning* of the merge window rather than trying to
> push them in whan I'm already trying to calm things down for the end
> of it.

Sure.  I can just merge it up to a 4.5-rc sometime then resubmit next
window.  However, I'm going to have to pull at least a few patches out
and send them separate as they are needed fixes for the code in tree
already.  But those are all -rc appropriate patches anyway so it doesn't
matter if they land by Sunday.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 186+ messages in thread

* Re: [PULL REQUEST] Please pull rdma.git
       [not found] ` <56A2727B.8040809-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-01-23  1:12   ` Linus Torvalds
       [not found]     ` <CA+55aFziXhmMRk3HqvrUtVv+SaUM0zu3=LKbxo0w9HZPVmDuyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Linus Torvalds @ 2016-01-23  1:12 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-rdma

On Fri, Jan 22, 2016 at 10:18 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> This is a rather large update, and it's not entirely complete.  I have
> some changes to merge for the staging/rdma tree too, but I wanted to get
> this set in first for dependency reasons, then I'll make a new branch
> against Greg's staging tree, then send the changes relative to that.
> Expect that pull request early next week.  Thanks.

No Doug.

The merge window closes this Sunday.

It's already damn late to send me anything at all, it is *much* too
late to say "this is just part of it".

This can all wait for 4.6, and maybe you'll have the pull requests
lined up at the *beginning* of the merge window rather than trying to
push them in whan I'm already trying to calm things down for the end
of it.

                  Linus
--
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	[flat|nested] 186+ messages in thread

* [PULL REQUEST] Please pull rdma.git
@ 2016-01-22 18:18 Doug Ledford
       [not found] ` <56A2727B.8040809-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 186+ messages in thread
From: Doug Ledford @ 2016-01-22 18:18 UTC (permalink / raw)
  To: Linus Torvalds, linux-rdma

[-- Attachment #1: Type: text/plain, Size: 24567 bytes --]

Hi Linus,

The following changes since commit 4ef7675344d687a0ef5b0d7c0cee12da005870c0:

  Linux 4.4-rc6 (2015-12-20 16:06:09 -0800)

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 34356f64ac0df2326fa50e2d4bca6f7c03ed16c1:

  IB/mlx5: Unify CQ create flags check (2016-01-21 12:05:37 -0500)

This is a rather large update, and it's not entirely complete.  I have
some changes to merge for the staging/rdma tree too, but I wanted to get
this set in first for dependency reasons, then I'll make a new branch
against Greg's staging tree, then send the changes relative to that.
Expect that pull request early next week.  Thanks.

----------------------------------------------------------------
Initial roundup of 4.5 merge window patches

- Remove usage of ib_query_device and instead store attributes in
  ib_device struct
- Move iopoll out of block and into lib, rename to irqpoll, and use
  in several places in the rdma stack as our new completion queue
  polling library mechanism.  Update the other block drivers that
  already used iopoll to use the new mechanism too.
- Replace the per-entry GID table locks with a single GID table lock
- IPoIB multicast cleanup
- Cleanups to the IB MR facility
- Add support for 64bit extended IB counters
- Fix for netlink oops while parsing RDMA nl messages
- RoCEv2 support for the core IB code
- mlx4 RoCEv2 support
- mlx5 RoCEv2 support
- Cross Channel support for mlx5
- Timestamp support for mlx5
- Atomic support for mlx5
- Raw QP support for mlx5
- MAINTAINERS update for mlx4/mlx5
- Misc ocrdma, qib, nes, usNIC, cxgb3, cxgb4, mlx4, mlx5 updates
- Add support for remote invalidate to the iSER driver (pushed through the
  RDMA tree due to dependencies, acknowledged by nab)
- Update to NFSoRDMA (pushed through the RDMA tree due to dependencies,
  acknowledged by Bruce)

----------------------------------------------------------------
Achiad Shochat (10):
      IB/mlx5: Support IB device's callback for getting the link layer
      IB/mlx5: Support IB device's callback for getting its netdev
      net/mlx5_core: Break down the vport mac address query function
      net/mlx5_core: Introduce access functions to enable/disable RoCE
      net/mlx5_core: Introduce access functions to query vport RoCE fields
      IB/mlx5: Extend query_device/port to support RoCE
      IB/mlx5: Set network_hdr_type upon RoCE responder completion
      IB/mlx5: Support IB device's callbacks for adding/deleting GIDs
      IB/mlx5: Add RoCE fields to Address Vector
      IB/mlx5: Support RoCE

Bart Van Assche (4):
      IB/core: Remove set-but-not-used variable from ib_sg_to_pages()
      irq_poll: Fix irq_poll_sched()
      IB/srpt: Fix the RDMA completion handlers
      IB/cm: Fix a recently introduced deadlock

Bodong Wang (1):
      IB/mlx5: report tx/rx checksum cap in query results

Christoph Hellwig (23):
      irq_poll: make blk-iopoll available outside the block layer
      irq_poll: don't disable new irq_poll instances
      irq_poll: fold irq_poll_sched_prep into irq_poll_sched
      irq_poll: fold irq_poll_disable_pending into irq_poll_softirq
      irq_poll: mark __irq_poll_complete static
      irq_poll: remove unused data and max fields
      IB: add a proper completion queue abstraction
      IB/srpt: chain RDMA READ/WRITE requests
      IB/srp: use the new CQ API
      IB/iser: Convert to CQ abstraction
      IB: start documenting device capabilities
      IB: remove ib_query_mr
      IB: remove support for phys MRs
      IB: remove in-kernel support for memory windows
      cxgb3: simplify iwch_get_dma_wr
      nes: simplify nes_reg_phys_mr calling conventions
      amso1100: fold c2_reg_phys_mr into c2_get_dma_mr
      ehca: stop using struct ib_phys_buf
      IB: remove the struct ib_phys_buf definition
      IB: remove the write-only usecnt field from struct ib_mr
      IB/mad: pass ib_mad_send_buf explicitly to the recv_handler
      IB/mad: use CQ abstraction
      svc_rdma: use local_dma_lkey

Christoph Lameter (5):
      IB/IPoIB: factor out common multicast list removal code
      IB/IPoIB: Move multicast specific code out of ipoib_main.c
      IB/core: Create get_perf_mad function in sysfs.c
      IB/core: Specify attribute_id in port_table_attribute
      IB/core: Display extended counter set if available

Chuck Lever (10):
      svcrdma: Clean up rdma_create_xprt()
      svcrdma: Clean up process_context()
      svcrdma: Improve allocation of struct svc_rdma_op_ctxt
      svcrdma: Improve allocation of struct svc_rdma_req_map
      svcrdma: Remove unused req_map and ctxt kmem_caches
      svcrdma: Add gfp flags to svc_rdma_post_recv()
      svcrdma: Remove last two __GFP_NOFAIL call sites
      svcrdma: Make map_xdr non-static
      svcrdma: Define maximum number of backchannel requests
      svcrdma: Add class for RDMA backwards direction transport

Dan Carpenter (2):
      RDMA/nes: checking for NULL instead of IS_ERR
      IB/cma: allocating too much memory in make_cma_ports()

Dean Luick (1):
      IB/mad: Ensure fairness in ib_mad_completion_handler

Devesh Sharma (4):
      RDMA/ocrdma: Fix vlan-id assignment in qp parameters
      RDMA/ocrdma: Dispatch only port event when port state changes
      RDMA/ocrdma: Depend on async link events from CNA
      RDMA/be2net: Remove open and close entry points

Doug Ledford (2):
      Merge branch 'rdma-cq.2' of git://git.infradead.org/users/hch/rdma
into 4.5/rdma-cq
      Merge branches '4.5/Or-cleanup' and '4.5/rdma-cq' into k.o/for-4.5

Eran Ben Elisha (2):
      net/mlx5_core: Add setting ATOMIC endian mode
      IB/mlx5: Advertise atomic capabilities in query device

Erez Shitrit (1):
      IB/IPoIB: Fix kernel panic on multicast flow

Haggai Abramovsky (3):
      IB/mlx5: Fix data validation in mlx5_ib_alloc_ucontext
      IB/mlx5: Add CQE version 1 support to user QPs and SRQs
      IB/mlx5: Expose CQE version to user-space

Hal Rosenstock (1):
      IB/core: sysfs.c: Fix PerfMgt ClassPortInfo handling

Hariprasad S (5):
      iw_cxgb4: Pass qid range to user space driver
      iw_cxgb3: Fix incorrectly returning error on success
      iw_cxgb4: Fixes static checker warning in c4iw_rdev_open()
      iw_cxgb4: Fixes GW-Basic labels to meaningful error names
      iw_cxgb4: Take clip reference before starting IPv6 listen

Ira Weiny (2):
      IB/core: Save the device attributes on the device structure
      IB/sysfs: Fix sparse warning on attr_id

Jenny Derzhavetz (5):
      IB/iser: Don't register memory for all immediate data writes
      IB/iser: set intuitive values for mr_valid
      IB/isert: Declare correct flags when accepting a connection
      IB/isert: Support the remote invalidation exception
      IB/iser: Support the remote invalidation exception

Julia Lawall (4):
      IB/usnic: delete unneeded IS_ERR test
      RDMA/nes: constify nes_cm_ops structure
      IB/iser: constify iser_reg_ops structure
      IB/core: constify mmu_notifier_ops structures

Kaike Wan (1):
      IB/sa: Fix netlink local service GFP crash

Leon Romanovsky (9):
      IB/core: Align coding style of ib_device_cap_flags structure
      IB/core: Add cross-channel support
      IB/mlx5: Add driver cross-channel support
      IB/mlx4: Suppress non-fatal memory allocations
      IB/mlx4: Convert kmalloc to kmalloc_array for checkpatch
      IB/mlx5: Expose correct maximum number of CQE capacity
      IB/mlx5: Delete locally redefined variable
      IB/mlx5: Fix passing casted pointer in mlx5_query_port_roce
      IB/mlx5: Unify CQ create flags check

Lucas Tanure (1):
      infiniband: Replace memset with eth_zero_addr

Matan Barak (23):
      IB/core: Refactor GID cache's ib_dispatch_event
      IB/core: Change per-entry lock in RoCE GID table to one lock
      IB/core: don't search the GID table twice
      IB/core: Add gid_type to gid attribute
      IB/cm: Use the source GID index type
      IB/core: Add gid attributes to sysfs
      IB/core: Add ROCE_UDP_ENCAP (RoCE V2) type
      IB/core: Move rdma_is_upper_dev_rcu to header file
      IB/core: Validate route when we init ah
      IB/rdma_cm: Add wrapper for cma reference count
      IB/cma: Add configfs for rdma_cm
      IB/mlx5: Add create_cq extended command
      IB/core: Add ib_is_udata_cleared
      IB/mlx5: Add support for hca_core_clock and timestamp_mask
      IB/mlx5: Add hca_core_clock_offset to udata in init_ucontext
      IB/mlx5: Mmap the HCA's core clock register to user-space
      IB/cma: Fix RDMA port validation for iWarp
      IB/mlx4: Initialize hop_limit when creating address handle
      IB/core: Eliminate sparse false context imbalance warning
      IB/core: Fix dereference before check
      IB/core: Rename rdma_addr_find_dmac_by_grh
      IB/core: Use hop-limit from IP stack for RoCE
      IB/mlx4: Advertise RoCE v2 support

Mike Marciniszyn (2):
      IB/qib: fix mcast detach when qp not attached
      IB/qib: Improve ipoib UD performance

Moni Shoua (15):
      IB/core: Initialize UD header structure with IP and UDP headers
      IB/cma: Join and leave multicast groups with IGMP
      IB/mlx4: Take source mac from AH instead from the port
      net/mlx4: Remove unused macro
      net/mlx4: Query RoCE support
      IB/mlx4: Add gid_type to GID properties
      net/mlx4_core: Configure mlx4 hardware for mixed RoCE v1/v2 modes
      IB/mlx4: Add support for setting RoCEv2 gids in hardware
      net/mlx4_core: Add support for configuring RoCE v2 UDP port
      net/mlx4_core: Add support for RoCE v2 entropy
      IB/core: Add definition for the standard RoCE V2 UDP port
      IB/mlx4: Support modify_qp for RoCE v2
      IB/mlx4: Enable RoCE v2 when the IB device is added
      IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers
      IB/mlx4: Create and use another QP1 for RoCEv2

Nelson Escobar (7):
      IB/usnic: Remove unused prototype
      IB/usnic: Improve a failure message
      IB/usnic: Fix incorrect cast in usnic_ib_fw_string_to_u64
      IB/usnic: Fix message typo
      IB/usnic: Support more QP state transitions
      IB/usnic: Fix resource leak in error case
      IB/usnic: Handle 0 counts in resource allocation

Or Gerlitz (8):
      IB/core: Avoid calling ib_query_device
      IB/ulps: Avoid calling ib_query_device
      net/rds: Avoid calling ib_query_device
      xprtrdma: Avoid calling ib_query_device
      staging/o2iblnd: Avoid calling ib_query_device
      IB/core: Remove ib_query_device
      MAINTAINERS: Assign new maintainers to Mellanox mlx5 core and IB
drivers
      MAINTAINERS: Assign maintainer to Mellanox mlx4 core and IB drivers

Roi Dayan (1):
      IB/iser: Fix module init not cleaning up on error flow

Sagi Grimberg (7):
      IB/iser: Use a dedicated descriptor for login
      IB/iser: Use helper for container_of
      IB/iser: Reuse ib_sg_to_pages
      IB/iser,isert: Create and use new shared header
      IB/isert: Remove unused file iser_proto.h
      IB/iser: Change the increment rkey flow logic
      IB/srpt: Remove redundant wc array

Somnath Kotur (1):
      IB/core: Add rdma_network_type to wc

Vinit Agnihotri (1):
      IB/qib: Support creating qps with GFP_NOIO flag

majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org (10):
      net/mlx5_core: Export transport objects
      net/mlx5_core: Add RQ and SQ event handling
      net/mlx5_core: Warn on unsupported events of QP/RQ/SQ
      IB/mlx5: Allocate a Transport Domain for each ucontext
      IB/mlx5: Refactor mlx5_ib_qp to accommodate other QP types
      IB/mlx5: Add create and destroy functionality for Raw Packet QP
      IB/mlx5: Add Raw Packet QP query functionality
      IB/mlx5: Support setting Ethernet priority for Raw Packet QPs
      {IB, net}/mlx5: Move the modify QP operation table to mlx5_ib
      IB/mlx5: Expose Raw Packet QP to user space consumers

 Documentation/ABI/testing/configfs-rdma_cm         |   22 +
 Documentation/ABI/testing/sysfs-class-infiniband   |   16 +
 Documentation/infiniband/core_locking.txt          |    2 -
 Documentation/kernel-per-CPU-kthreads.txt          |    2 +-
 MAINTAINERS                                        |   32 +-
 block/Makefile                                     |    2 +-
 drivers/infiniband/Kconfig                         |   10 +
 drivers/infiniband/core/Makefile                   |    4 +-
 drivers/infiniband/core/addr.c                     |  194 +++-
 drivers/infiniband/core/cache.c                    |  345 +++++--
 drivers/infiniband/core/cm.c                       |   49 +-
 drivers/infiniband/core/cma.c                      |  265 ++++-
 drivers/infiniband/core/cma_configfs.c             |  321 +++++++
 drivers/infiniband/core/core_priv.h                |   45 +
 drivers/infiniband/core/cq.c                       |  209 ++++
 drivers/infiniband/core/device.c                   |   51 +-
 drivers/infiniband/core/fmr_pool.c                 |   20 +-
 drivers