[PULL REQUEST] Please pull rdma.git

[PULL REQUEST] Please pull rdma.git

[Doug Ledford]

[-- 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[pr-tracker-bot]

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

Re: [PULL REQUEST] Please pull rdma.git

[pr-tracker-bot]

The pull request you sent on Fri, 30 Aug 2019 11:42:36 -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/8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b

Thank you!

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

[PULL REQUEST] Please pull rdma.git

[Doug Ledford]

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

Hi Linus,

*Much* calmer week this week.  Just one -rc patch queued up.  The way
the siw driver was locking around the traversal of the list of ipv6
addresses on a device was causing a scheduling while atomic issue. 
Bernard straightened it out by using the rtnl_lock.

Here's the boiler plate:

The following changes since commit c536277e0db1ad2e9fbb9dfd940c3565a14d9c52:

  RDMA/siw: Fix 64/32bit pointer inconsistency (2019-08-23 12:08:27 -0400)

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 531a64e4c35bb9844b0cf813a6c9a87e00be05ff:

  RDMA/siw: Fix IPv6 addr_list locking (2019-08-28 10:29:19 -0400)

----------------------------------------------------------------
Pull request for 5.3-rc6

- Fix locking on list traversal (siw)

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

----------------------------------------------------------------
Bernard Metzler (1):
      RDMA/siw: Fix IPv6 addr_list locking

 drivers/infiniband/sw/siw/siw_cm.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[Doug Ledford]

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

Hi Linus,

I didn't notice I was on my personal email identity when I sent the pull
request.  Sorry about that.  It's really me ;-)

On Fri, 2019-08-23 at 14:48 -0400, Doug Ledford wrote:
> Hi Linus,
> 
> No beating around the bush: this is a monster pull request for an -rc5
> kernel.  Intel hit me with a series of fixes for TID processing. 
> Mellanox hit me with a series for their UMR memory support.
> 
> And we had one fix for siw that fixes the 32bit build warnings and
> because of the number of casts that had to be changed to properly
> silence the warnings, that one patch alone is a full 40% of the LOC of
> this entire pull request.  Given that this is the initial release
> kernel
> for siw, I'm trying to fix anything in it that we can, so that adds to
> the impetus to take fixes for it like this one.
> 
> I had to do a rebase early in the week.  Jason had thought he put a
> patch on the rc queue that he needed to be there so he could base some
> work off of it, and it had actually not been placed there.  So he
> asked
> me (on Tuesday) to fix that up before pushing my wip branch to the
> official rc branch.  I did, and that's why the early patches look like
> they were all committed at the same time on Tuesday.  That bunch had
> been in my queue prior.
> 
> The various patches all pass my test for being legitimate fixes and
> not
> attempts to slide new features or development into a late rc.  Well,
> they were all fixes with the exception of a couple clean up patches
> people wrote for making the fixes they also wrote better (like a
> cleanup
> patch to move UMR checking into a function so that the remaining UMR
> fix
> patches can reference that function), so I left those in place too.
> 
> My apologies for the LOC count and the number of patches here, it's
> just
> how the cards fell this cycle.  I hope you agree with me that they're
> justified fixes.
> 
> Here's the boilerplate:
> 
> The following changes since commit
> d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
> 
>   Linux 5.3-rc5 (2019-08-18 14:31:08 -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
> c536277e0db1ad2e9fbb9dfd940c3565a14d9c52:
> 
>   RDMA/siw: Fix 64/32bit pointer inconsistency (2019-08-23 12:08:27
> -0400)
> 
> ----------------------------------------------------------------
> Pull request for 5.3-rc5
> 
> - Fix siw buffer mapping issue
> - Fix siw 32/64 casting issues
> - Fix a KASAN access issue in bnxt_re
> - Fix several memory leaks (hfi1, mlx4)
> - Fix a NULL deref in cma_cleanup
> - Fixes for UMR memory support in mlx5 (4 patch series)
> - Fix namespace check for restrack
> - Fixes for counter support
> - Fixes for hfi1 TID processing (5 patch series)
> - Fix potential NULL deref in siw
> - Fix memory page calculations in mlx5
> 
> Signed-off-by: Doug Ledford <dledford@redhat.com>
> 
> ----------------------------------------------------------------
> Bernard Metzler (3):
>       RDMA/siw: Fix potential NULL de-ref
>       RDMA/siw: Fix SGL mapping issues
>       RDMA/siw: Fix 64/32bit pointer inconsistency
> 
> Ido Kalir (1):
>       IB/core: Fix NULL pointer dereference when bind QP to counter
> 
> Jason Gunthorpe (1):
>       RDMA/mlx5: Fix MR npages calculation for IB_ACCESS_HUGETLB
> 
> Kaike Wan (5):
>       IB/hfi1: Drop stale TID RDMA packets
>       IB/hfi1: Unsafe PSN checking for TID RDMA READ Resp packet
>       IB/hfi1: Add additional checks when handling TID RDMA READ RESP
> packet
>       IB/hfi1: Add additional checks when handling TID RDMA WRITE DATA
> packet
>       IB/hfi1: Drop stale TID RDMA packets that cause TIDErr
> 
> Leon Romanovsky (2):
>       RDMA/counters: Properly implement PID checks
>       RDMA/restrack: Rewrite PID namespace check to be reliable
> 
> Moni Shoua (4):
>       IB/mlx5: Consolidate use_umr checks into single function
>       IB/mlx5: Report and handle ODP support properly
>       IB/mlx5: Fix MR re-registration flow to use UMR properly
>       IB/mlx5: Block MR WR if UMR is not possible
> 
> Selvin Xavier (1):
>       RDMA/bnxt_re: Fix stack-out-of-bounds in
> bnxt_qplib_rcfw_send_message
> 
> Wenwen Wang (3):
>       IB/mlx4: Fix memory leaks
>       infiniband: hfi1: fix a memory leak bug
>       infiniband: hfi1: fix memory leaks
> 
> zhengbin (1):
>       RDMA/cma: fix null-ptr-deref Read in cma_cleanup
> 
>  drivers/infiniband/core/cma.c              |  6 ++-
>  drivers/infiniband/core/counters.c         | 10 ++--
>  drivers/infiniband/core/nldev.c            |  3 +-
>  drivers/infiniband/core/restrack.c         | 15 +++---
>  drivers/infiniband/core/umem.c             |  7 +--
>  drivers/infiniband/hw/bnxt_re/qplib_rcfw.c |  8 ++-
>  drivers/infiniband/hw/bnxt_re/qplib_rcfw.h | 11 ++--
>  drivers/infiniband/hw/hfi1/fault.c         | 12 +++--
>  drivers/infiniband/hw/hfi1/tid_rdma.c      | 76 ++++++++++-----------
> ------
>  drivers/infiniband/hw/mlx4/mad.c           |  4 +-
>  drivers/infiniband/hw/mlx5/main.c          |  6 +--
>  drivers/infiniband/hw/mlx5/mem.c           |  5 +-
>  drivers/infiniband/hw/mlx5/mlx5_ib.h       | 14 +++++
>  drivers/infiniband/hw/mlx5/mr.c            |  7 ++-
>  drivers/infiniband/hw/mlx5/odp.c           | 17 ++++---
>  drivers/infiniband/hw/mlx5/qp.c            | 24 +++++++--
>  drivers/infiniband/sw/siw/siw.h            |  8 +--
>  drivers/infiniband/sw/siw/siw_cm.c         | 82 ++++++++++++++-------
> ---------
>  drivers/infiniband/sw/siw/siw_cq.c         |  5 +-
>  drivers/infiniband/sw/siw/siw_mem.c        | 14 ++---
>  drivers/infiniband/sw/siw/siw_mem.h        |  2 +-
>  drivers/infiniband/sw/siw/siw_qp.c         |  2 +-
>  drivers/infiniband/sw/siw/siw_qp_rx.c      | 26 +++++-----
>  drivers/infiniband/sw/siw/siw_qp_tx.c      | 80 ++++++++++++++-------
> --------
>  drivers/infiniband/sw/siw/siw_verbs.c      | 40 +++++++--------
>  include/rdma/restrack.h                    |  3 +-
>  26 files changed, 248 insertions(+), 239 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[Jason Gunthorpe]

On Mon, Aug 19, 2019 at 02:29:46PM +0200, Geert Uytterhoeven wrote:
> Hi Jason,
> 
> On Mon, Aug 19, 2019 at 2:14 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Mon, Aug 19, 2019 at 12:08:16PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 14, 2019 at 5:00 PM Doug Ledford <dledford@redhat.com> wrote:
> > > > 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.
> > >
> > > [...]
> > >
> > > > - 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)
> > >
> > > > Bernard Metzler (1):
> > > >       RDMA/siw: Change CQ flags from 64->32 bits
> > >
> > > Obviously none of this was ever compiled for a 32-bit platform?!?
> >
> > It is puzzling that 0-day or anyone testing linux-next hasn't noticed
> > this in that last 7 weeks are so..
> 
> Fair enough. The autobuilders have become a bit overloaded lately.
> 
> Still, I would expect a commit that makes a last-minute ABI change to
> enable support for 32-bit platforms, to actually compile cleanly on
> these 32-bit platforms.
> To me, this looks like a big red flag...

Again, I don't know why 0-day didn't report anything. I have success
logs from it saying it compiled a tree including siw on i386
allmodconfig - I don't know why you are seeing 32 bit warnings when
0-day is not reporting anything.

Jason

Re: [PULL REQUEST] Please pull rdma.git

[Geert Uytterhoeven]

Hi Jason,

On Mon, Aug 19, 2019 at 2:14 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Mon, Aug 19, 2019 at 12:08:16PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 14, 2019 at 5:00 PM Doug Ledford <dledford@redhat.com> wrote:
> > > 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.
> >
> > [...]
> >
> > > - 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)
> >
> > > Bernard Metzler (1):
> > >       RDMA/siw: Change CQ flags from 64->32 bits
> >
> > Obviously none of this was ever compiled for a 32-bit platform?!?
>
> It is puzzling that 0-day or anyone testing linux-next hasn't noticed
> this in that last 7 weeks are so..

Fair enough. The autobuilders have become a bit overloaded lately.

Still, I would expect a commit that makes a last-minute ABI change to
enable support for 32-bit platforms, to actually compile cleanly on
these 32-bit platforms.
To me, this looks like a big red flag...


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PULL REQUEST] Please pull rdma.git

[Jason Gunthorpe]

On Mon, Aug 19, 2019 at 12:08:16PM +0200, Geert Uytterhoeven wrote:
> Hi Doug, Bernard,
> 
> On Wed, Aug 14, 2019 at 5:00 PM Doug Ledford <dledford@redhat.com> wrote:
> > 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.
> 
> [...]
> 
> > - 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)
> 
> > Bernard Metzler (1):
> >       RDMA/siw: Change CQ flags from 64->32 bits
> 
> Obviously none of this was ever compiled for a 32-bit platform?!?

It is puzzling that 0-day or anyone testing linux-next hasn't noticed
this in that last 7 weeks are so..

Jason

Re: [PULL REQUEST] Please pull rdma.git

[Geert Uytterhoeven]

Hi Doug, Bernard,

On Wed, Aug 14, 2019 at 5:00 PM Doug Ledford <dledford@redhat.com> wrote:
> 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.

[...]

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

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

Obviously none of this was ever compiled for a 32-bit platform?!?

Patch sent to kill the warnings.
But there may be deeper issues not exposed by them.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PULL REQUEST] Please pull rdma.git

[pr-tracker-bot]

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

[PULL REQUEST] Please pull rdma.git

[Doug Ledford]

[-- 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[pr-tracker-bot]

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

[PULL REQUEST] Please pull rdma.git

[Doug Ledford]

[-- 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[pr-tracker-bot]

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

[PULL REQUEST] Please pull rdma.git

[Doug Ledford]

[-- 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1482 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@redhat.com> 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[Doug Ledford]

[-- 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 --]

Re: [PULL REQUEST] Please pull rdma.git

[Or Gerlitz]

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

Re: [PULL REQUEST] Please pull rdma.git

[Doug Ledford]

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

On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> On Thu, Nov 17, 2016 at 9:44 PM, Doug Ledford <dledford@redhat.com> 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@redhat.com>
    GPG Key ID: 0E572FDD


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

Re: [PULL REQUEST] Please pull rdma.git

[Or Gerlitz]

On Thu, Nov 17, 2016 at 9:44 PM, Doug Ledford <dledford@redhat.com> 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.