* [PULL REQUEST] Please pull rdma.git
@ 2019-08-14 14:59 Doug Ledford
2019-08-14 18:25 ` pr-tracker-bot
2019-08-19 10:08 ` Geert Uytterhoeven
0 siblings, 2 replies; 196+ 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] 196+ 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
2019-08-19 10:08 ` Geert Uytterhoeven
1 sibling, 0 replies; 196+ 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] 196+ 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
@ 2019-08-19 10:08 ` Geert Uytterhoeven
2019-08-19 12:14 ` Jason Gunthorpe
1 sibling, 1 reply; 196+ messages in thread
From: Geert Uytterhoeven @ 2019-08-19 10:08 UTC (permalink / raw)
To: Doug Ledford, Bernard Metzler
Cc: Torvalds, Linus, Gunthorpe, Jason, linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-08-19 10:08 ` Geert Uytterhoeven
@ 2019-08-19 12:14 ` Jason Gunthorpe
2019-08-19 12:29 ` Geert Uytterhoeven
0 siblings, 1 reply; 196+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 12:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Doug Ledford, Bernard Metzler, Torvalds, Linus, linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-08-19 12:14 ` Jason Gunthorpe
@ 2019-08-19 12:29 ` Geert Uytterhoeven
2019-08-19 12:48 ` Jason Gunthorpe
0 siblings, 1 reply; 196+ messages in thread
From: Geert Uytterhoeven @ 2019-08-19 12:29 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Bernard Metzler, Torvalds, Linus, linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-08-19 12:29 ` Geert Uytterhoeven
@ 2019-08-19 12:48 ` Jason Gunthorpe
0 siblings, 0 replies; 196+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 12:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Doug Ledford, Bernard Metzler, Torvalds, Linus, linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-12-15 21:57 Doug Ledford
@ 2019-12-16 2:27 ` Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2019-12-16 2:27 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]
Pull request was taken, but because I forgot to include linux-kernel@ on
the Cc: list, we didn't get the pr-tracker bot reply.
On Sun, 2019-12-15 at 16:57 -0500, Doug Ledford wrote:
> Hi Linus,
>
> A small collection of -rc fixes. Mostly. One API addition, but
> that's
> because we wanted to use it in a fix. There's also a bug fix that is
> going to render the 5.5 kernel's soft-RoCE driver incompatible with
> all
> soft-RoCE versions prior, but it's required to actually implement the
> protocol according to the RoCE spec and required in order for the
> soft-
> RoCE driver to be able to successfully work with actual RoCE
> hardware.
> Commit log message has more details of what's in the pull request.
>
> Here's the git boilerplate:
>
> The following changes since commit
> e42617b825f8073569da76dc4510bfa019b1c35a:
>
> Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
>
> 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
> dc2316eba73ff03da6dde082a372c6b5209304c5:
>
> IB/mlx5: Fix device memory flows (2019-12-12 16:55:36 -0500)
>
> ----------------------------------------------------------------
> Pull request for 5.5-rc2
>
> - Update Steve Wise info
> - Fix for soft-RoCE crc calculations (will break back compatibility,
> but
> only with the soft-RoCE driver, which has had this bug since it was
> introduced and it is an on-the-wire bug, but will make soft-RoCE
> fully
> compatible with real RoCE hardware)
> - cma init fixup
> - counters oops fix
> - fix for mlx4 init/teardown sequence
> - fix for mkx5 steering rules
> - introduce a cleanup API, which isn't a fix, but we want to use it in
> the next fix
> - fix for mlx5 memory management that uses API in previous patch
>
> Signed-off-by: Doug Ledford <dledford@redhat.com>
>
> ----------------------------------------------------------------
> Chuhong Yuan (1):
> RDMA/cma: add missed unregister_pernet_subsys in init failure
>
> Maor Gottlieb (1):
> IB/mlx5: Fix steering rule of drop and count
>
> Mark Zhang (1):
> RDMA/counter: Prevent auto-binding a QP which are not tracked
> with res
>
> Parav Pandit (1):
> IB/mlx4: Follow mirror sequence of device add during device
> removal
>
> Steve Wise (2):
> Update mailmap info for Steve Wise
> rxe: correctly calculate iCRC for unaligned payloads
>
> Yishai Hadas (2):
> IB/core: Introduce rdma_user_mmap_entry_insert_range() API
> IB/mlx5: Fix device memory flows
>
> .mailmap | 2 +
> drivers/infiniband/core/cma.c | 1 +
> drivers/infiniband/core/counters.c | 3 +
> drivers/infiniband/core/ib_core_uverbs.c | 48 ++++++++---
> drivers/infiniband/hw/mlx4/main.c | 9 ++-
> drivers/infiniband/hw/mlx5/cmd.c | 16 ++--
> drivers/infiniband/hw/mlx5/cmd.h | 2 +-
> drivers/infiniband/hw/mlx5/main.c | 133 ++++++++++++++++++++
> -----------
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 19 ++++-
> drivers/infiniband/sw/rxe/rxe_recv.c | 2 +-
> drivers/infiniband/sw/rxe/rxe_req.c | 6 ++
> drivers/infiniband/sw/rxe/rxe_resp.c | 7 ++
> include/rdma/ib_verbs.h | 5 ++
> 13 files changed, 180 insertions(+), 73 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2019-12-15 21:57 Doug Ledford
2019-12-16 2:27 ` Doug Ledford
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2019-12-15 21:57 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]
Hi Linus,
A small collection of -rc fixes. Mostly. One API addition, but that's
because we wanted to use it in a fix. There's also a bug fix that is
going to render the 5.5 kernel's soft-RoCE driver incompatible with all
soft-RoCE versions prior, but it's required to actually implement the
protocol according to the RoCE spec and required in order for the soft-
RoCE driver to be able to successfully work with actual RoCE hardware.
Commit log message has more details of what's in the pull request.
Here's the git boilerplate:
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
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 dc2316eba73ff03da6dde082a372c6b5209304c5:
IB/mlx5: Fix device memory flows (2019-12-12 16:55:36 -0500)
----------------------------------------------------------------
Pull request for 5.5-rc2
- Update Steve Wise info
- Fix for soft-RoCE crc calculations (will break back compatibility, but
only with the soft-RoCE driver, which has had this bug since it was
introduced and it is an on-the-wire bug, but will make soft-RoCE fully
compatible with real RoCE hardware)
- cma init fixup
- counters oops fix
- fix for mlx4 init/teardown sequence
- fix for mkx5 steering rules
- introduce a cleanup API, which isn't a fix, but we want to use it in
the next fix
- fix for mlx5 memory management that uses API in previous patch
Signed-off-by: Doug Ledford <dledford@redhat.com>
----------------------------------------------------------------
Chuhong Yuan (1):
RDMA/cma: add missed unregister_pernet_subsys in init failure
Maor Gottlieb (1):
IB/mlx5: Fix steering rule of drop and count
Mark Zhang (1):
RDMA/counter: Prevent auto-binding a QP which are not tracked with res
Parav Pandit (1):
IB/mlx4: Follow mirror sequence of device add during device removal
Steve Wise (2):
Update mailmap info for Steve Wise
rxe: correctly calculate iCRC for unaligned payloads
Yishai Hadas (2):
IB/core: Introduce rdma_user_mmap_entry_insert_range() API
IB/mlx5: Fix device memory flows
.mailmap | 2 +
drivers/infiniband/core/cma.c | 1 +
drivers/infiniband/core/counters.c | 3 +
drivers/infiniband/core/ib_core_uverbs.c | 48 ++++++++---
drivers/infiniband/hw/mlx4/main.c | 9 ++-
drivers/infiniband/hw/mlx5/cmd.c | 16 ++--
drivers/infiniband/hw/mlx5/cmd.h | 2 +-
drivers/infiniband/hw/mlx5/main.c | 133 ++++++++++++++++++++-----------
drivers/infiniband/hw/mlx5/mlx5_ib.h | 19 ++++-
drivers/infiniband/sw/rxe/rxe_recv.c | 2 +-
drivers/infiniband/sw/rxe/rxe_req.c | 6 ++
drivers/infiniband/sw/rxe/rxe_resp.c | 7 ++
include/rdma/ib_verbs.h | 5 ++
13 files changed, 180 insertions(+), 73 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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-08-30 15:42 Doug Ledford
@ 2019-08-30 16:40 ` pr-tracker-bot
0 siblings, 0 replies; 196+ messages in thread
From: pr-tracker-bot @ 2019-08-30 16:40 UTC (permalink / raw)
To: Doug Ledford; +Cc: Torvalds, Linus, linux-rdma, linux-kernel, Gunthorpe, Jason
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
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2019-08-30 15:42 Doug Ledford
2019-08-30 16:40 ` pr-tracker-bot
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2019-08-30 15:42 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: linux-rdma, linux-kernel, Gunthorpe, Jason
[-- 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 --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2019-08-23 19:14 ` Doug Ledford
@ 2019-08-23 23:24 ` Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2019-08-23 23:24 UTC (permalink / raw)
To: dledford; +Cc: Gunthorpe, Jason, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 7112 bytes --]
The mixup with me sending the original pull request from the wrong
address kept the pull request from appearing on the lists, but not from
Linus' mailbox. As a result, it's been taken, but there doesn't appear
to be any pr-tracker-bot update forthcoming. So I decided I'd let y'all
know ;-)
Deet-doot-dot I am *not* a bot.
On Fri, 2019-08-23 at 15:14 -0400, Doug Ledford wrote:
> 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 --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] <5b0aa103f6007e1887f9b2cacaec8015834589b8.camel@xsintricity.com>
@ 2019-08-23 19:14 ` Doug Ledford
2019-08-23 23:24 ` Doug Ledford
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2019-08-23 19:14 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: Gunthorpe, Jason, linux-rdma, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2018-02-06 0:31 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-11-15 16:01 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-10-26 18:05 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-10-06 17:25 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-09-28 16:06 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-08-31 13:42 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-08-24 21:21 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-08-18 18:21 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-08-08 17:27 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-06-16 2:09 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-06-02 20:09 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-05-03 15:17 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-02-24 19:29 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-02-23 17:54 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-02-10 19:42 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2017-01-27 19:52 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
@ 2017-01-04 13:36 Yuval Shaia
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-12-22 21:40 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-10-04 13:50 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-09-16 20:19 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-09-06 18:09 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-08-04 16:21 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-07-14 13:45 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-06-24 23:12 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-06-09 16:32 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-05-20 20:03 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-05-06 20:11 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-04-29 3:05 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-04-06 18:23 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-03-04 17:04 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-02-21 1:14 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-02-14 1:23 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-02-10 22:34 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2016-02-03 20:24 Doug Ledford
0 siblings, 0 replies; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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] 196+ 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; 196+ 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/infiniband/core/mad.c | 162 ++--
drivers/infiniband/core/mad_priv.h | 2 +-
drivers/infiniband/core/multicast.c | 17 +-
drivers/infiniband/core/roce_gid_mgmt.c | 81 +-
drivers/infiniband/core/sa_query.c | 91 +-
drivers/infiniband/core/sysfs.c | 377 +++++++-
drivers/infiniband/core/ud_header.c | 155 ++-
drivers/infiniband/core/umem_odp.c | 2 +-
drivers/infiniband/core/user_mad.c | 1 +
drivers/infiniband/core/uverbs.h | 2 +
drivers/infiniband/core/uverbs_cmd.c | 38 +-
drivers/infiniband/core/uverbs_main.c | 13 +-
drivers/infiniband/core/uverbs_marshall.c | 1 +
drivers/infiniband/core/verbs.c | 238 +++--
drivers/infiniband/hw/cxgb3/iwch_cm.c | 4 +-
drivers/infiniband/hw/cxgb3/iwch_cq.c | 4 -
drivers/infiniband/hw/cxgb3/iwch_mem.c | 102 --
drivers/infiniband/hw/cxgb3/iwch_provider.c | 146 +--
drivers/infiniband/hw/cxgb3/iwch_provider.h | 15 -
drivers/infiniband/hw/cxgb3/iwch_qp.c | 82 --
drivers/infiniband/hw/cxgb4/cm.c | 14 +-
drivers/infiniband/hw/cxgb4/cq.c | 3 -
drivers/infiniband/hw/cxgb4/device.c | 57 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 13 -
drivers/infiniband/hw/cxgb4/mem.c | 251 -----
drivers/infiniband/hw/cxgb4/provider.c | 3 -
drivers/infiniband/hw/cxgb4/qp.c | 5 -
drivers/infiniband/hw/cxgb4/t4.h | 7 +
drivers/infiniband/hw/cxgb4/user.h | 2 +-
drivers/infiniband/hw/mlx4/ah.c | 3 +-
drivers/infiniband/hw/mlx4/cq.c | 3 -
drivers/infiniband/hw/mlx4/main.c | 102 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 10 +-
drivers/infiniband/hw/mlx4/mr.c | 22 -
drivers/infiniband/hw/mlx4/qp.c | 318 ++++--
drivers/infiniband/hw/mlx4/srq.c | 3 +-
drivers/infiniband/hw/mlx5/ah.c | 32 +-
drivers/infiniband/hw/mlx5/cq.c | 31 +-
drivers/infiniband/hw/mlx5/main.c | 445 ++++++++-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 129 ++-
drivers/infiniband/hw/mlx5/odp.c | 29 +-
drivers/infiniband/hw/mlx5/qp.c | 1014
+++++++++++++++++---
drivers/infiniband/hw/mlx5/srq.c | 41 +-
drivers/infiniband/hw/mlx5/user.h | 63 +-
drivers/infiniband/hw/mthca/mthca_cq.c | 3 -
drivers/infiniband/hw/mthca/mthca_provider.c | 84 --
drivers/infiniband/hw/mthca/mthca_qp.c | 2 +-
drivers/infiniband/hw/nes/nes_cm.c | 17 +-
drivers/infiniband/hw/nes/nes_cm.h | 2 +-
drivers/infiniband/hw/nes/nes_utils.c | 2 +-
drivers/infiniband/hw/nes/nes_verbs.c | 216 +----
drivers/infiniband/hw/nes/nes_verbs.h | 4 +
drivers/infiniband/hw/ocrdma/ocrdma.h | 10 +
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 7 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 49 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.h | 4 +-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 58 +-
drivers/infiniband/hw/ocrdma/ocrdma_sli.h | 49 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 165 +---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 3 -
drivers/infiniband/hw/qib/qib_mr.c | 51 +-
drivers/infiniband/hw/qib/qib_qp.c | 46 +-
drivers/infiniband/hw/qib/qib_verbs.c | 12 +-
drivers/infiniband/hw/qib/qib_verbs.h | 4 -
drivers/infiniband/hw/qib/qib_verbs_mcast.c | 35 +-
drivers/infiniband/hw/usnic/usnic_debugfs.c | 5 +-
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 4 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 24 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 2 -
drivers/infiniband/hw/usnic/usnic_vnic.c | 54 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 6 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 21 +-
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 14 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 40 +-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 45 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 13 +-
drivers/infiniband/ulp/iser/iscsi_iser.h | 156 +--
drivers/infiniband/ulp/iser/iser_initiator.c | 323 ++++---
drivers/infiniband/ulp/iser/iser_memory.c | 179 ++--
drivers/infiniband/ulp/iser/iser_verbs.c | 337 ++-----
drivers/infiniband/ulp/isert/ib_isert.c | 118 ++-
drivers/infiniband/ulp/isert/ib_isert.h | 41 +-
drivers/infiniband/ulp/isert/isert_proto.h | 47 -
drivers/infiniband/ulp/srp/ib_srp.c | 205 ++--
drivers/infiniband/ulp/srp/ib_srp.h | 7 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 443 +++------
drivers/infiniband/ulp/srpt/ib_srpt.h | 53 +-
drivers/net/ethernet/emulex/benet/be.h | 2 -
drivers/net/ethernet/emulex/benet/be_main.c | 4 -
drivers/net/ethernet/emulex/benet/be_roce.c | 36 -
drivers/net/ethernet/emulex/benet/be_roce.h | 4 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 39 +-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 5 +-
drivers/net/ethernet/mellanox/mlx4/port.c | 7 +
drivers/net/ethernet/mellanox/mlx4/qp.c | 26 +
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/main.c | 61 +-
drivers/net/ethernet/mellanox/mlx5/core/qp.c | 233 +++--
drivers/net/ethernet/mellanox/mlx5/core/srq.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 50 +-
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 139 ++-
drivers/scsi/Kconfig | 1 +
drivers/scsi/be2iscsi/Kconfig | 1 +
drivers/scsi/be2iscsi/be.h | 4 +-
drivers/scsi/be2iscsi/be_iscsi.c | 4 +-
drivers/scsi/be2iscsi/be_main.c | 20 +-
drivers/scsi/ipr.c | 25 +-
drivers/scsi/ipr.h | 4 +-
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 21 +-
drivers/staging/rdma/amso1100/c2_cq.c | 3 -
drivers/staging/rdma/amso1100/c2_provider.c | 72 +-
drivers/staging/rdma/ehca/ehca_classes.h | 5 +-
drivers/staging/rdma/ehca/ehca_iverbs.h | 16 -
drivers/staging/rdma/ehca/ehca_main.c | 4 -
drivers/staging/rdma/ehca/ehca_mrmw.c | 477 +--------
drivers/staging/rdma/ehca/ehca_mrmw.h | 5 -
drivers/staging/rdma/ehca/ehca_reqs.c | 1 -
drivers/staging/rdma/hfi1/mr.c | 51 +-
drivers/staging/rdma/hfi1/verbs.c | 1 -
drivers/staging/rdma/hfi1/verbs.h | 4 -
drivers/staging/rdma/ipath/ipath_mr.c | 55 --
drivers/staging/rdma/ipath/ipath_verbs.c | 1 -
drivers/staging/rdma/ipath/ipath_verbs.h | 4 -
include/linux/blk-iopoll.h | 46 -
include/linux/interrupt.h | 2 +-
include/linux/irq_poll.h | 25 +
include/linux/mlx4/cmd.h | 3 +-
include/linux/mlx4/device.h | 15 +-
include/linux/mlx4/qp.h | 15 +-
include/linux/mlx5/device.h | 45 +-
include/linux/mlx5/driver.h | 20 +-
include/linux/mlx5/mlx5_ifc.h | 50 +-
include/linux/mlx5/qp.h | 46 +-
.../mlx5/core => include/linux/mlx5}/transobj.h | 10 +-
include/linux/mlx5/vport.h | 8 +
include/linux/sunrpc/svc_rdma.h | 39 +-
include/rdma/ib_addr.h | 16 +-
include/rdma/ib_cache.h | 4 +
include/rdma/ib_mad.h | 2 +
include/rdma/ib_pack.h | 45 +-
include/rdma/ib_pma.h | 1 +
include/rdma/ib_sa.h | 3 +
include/rdma/ib_verbs.h | 356 ++++---
include/scsi/iser.h | 78 ++
include/trace/events/irq.h | 2 +-
lib/Kconfig | 5 +
lib/Makefile | 1 +
block/blk-iopoll.c => lib/irq_poll.c | 108 +--
net/rds/ib.c | 34 +-
net/rds/iw.c | 23 +-
net/sunrpc/xprt.c | 1 +
net/sunrpc/xprtrdma/Makefile | 2 +-
net/sunrpc/xprtrdma/frwr_ops.c | 7 +-
net/sunrpc/xprtrdma/svc_rdma.c | 41 +-
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 371 +++++++
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 56 +-
net/sunrpc/xprtrdma/svc_rdma_sendto.c | 33 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 360 ++++---
net/sunrpc/xprtrdma/transport.c | 30 +-
net/sunrpc/xprtrdma/verbs.c | 24 +-
net/sunrpc/xprtrdma/xprt_rdma.h | 21 +-
tools/lib/traceevent/event-parse.c | 2 +-
tools/perf/util/trace-event-parse.c | 2 +-
182 files changed, 7272 insertions(+), 4760 deletions(-)
create mode 100644 Documentation/ABI/testing/configfs-rdma_cm
create mode 100644 Documentation/ABI/testing/sysfs-class-infiniband
create mode 100644 drivers/infiniband/core/cma_configfs.c
create mode 100644 drivers/infiniband/core/cq.c
delete mode 100644 drivers/infiniband/ulp/isert/isert_proto.h
delete mode 100644 include/linux/blk-iopoll.h
create mode 100644 include/linux/irq_poll.h
rename {drivers/net/ethernet/mellanox/mlx5/core =>
include/linux/mlx5}/transobj.h (88%)
create mode 100644 include/scsi/iser.h
rename block/blk-iopoll.c => lib/irq_poll.c (55%)
create mode 100644 net/sunrpc/xprtrdma/svc_rdma_backchannel.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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-12-28 21:43 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-12-28 21:43 UTC (permalink / raw)
To: Linus Torvalds, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]
Hi Linus,
This should be the last pull request for the 4.4 cycle. There are three
fixes here. The first two were very small in terms of number of lines,
the third is more lines of change than I like this late in the cycle,
but there are positive test results from Avagotech and from my own test
setup with the target hardware, and given the problem was a 100% failure
case, I sent it through.
The following changes since commit ab5cdc31630c7596d81ca8fbe7d695f10666f39b:
IB/mlx5: Postpone remove_keys under knowledge of coming preemption
(2015-12-08 16:55: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 f41647ef06536199d3366530da050b411546979d:
RDMA/be2net: Remove open and close entry points (2015-12-28 11:45:55
-0500)
----------------------------------------------------------------
Three late 4.4-rc fixes
- A previous patch updated the mlx4 driver to use vmalloc when there was
not enough memory to get a contiguous region large enough for our needs,
so we need kvfree() whenever we free that item. We missed one place,
so fix that now.
- A previous patch added code to match incoming packets against a specific
device, but failed to compensate for devices that have both InfiniBand
and Ethernet ports. Fix that.
- Under certain vlan conditions, the ocrdma driver would fail to bring up
any vlan interfaces and would print out a circular locking failure. Fix
that.
----------------------------------------------------------------
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
Matan Barak (1):
IB/cma: cma_match_net_dev needs to take into account port_num
Wengang Wang (1):
IB/mlx4: Replace kfree with kvfree in mlx4_ib_destroy_srq
drivers/infiniband/core/cma.c | 16 ++++----
drivers/infiniband/hw/mlx4/srq.c | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma.h | 10 +++++
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 49 ++++++++++++++++++++-----
drivers/infiniband/hw/ocrdma/ocrdma_hw.h | 4 +-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 57
+++++++++++++----------------
drivers/infiniband/hw/ocrdma/ocrdma_sli.h | 49 +++++++++++++++++++++++--
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
drivers/net/ethernet/emulex/benet/be.h | 2 -
drivers/net/ethernet/emulex/benet/be_main.c | 4 --
drivers/net/ethernet/emulex/benet/be_roce.c | 36 ------------------
drivers/net/ethernet/emulex/benet/be_roce.h | 4 +-
12 files changed, 134 insertions(+), 101 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-12-10 21:00 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-12-10 21:00 UTC (permalink / raw)
To: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[-- Attachment #1: Type: text/plain, Size: 3425 bytes --]
Hi Linus,
The following changes since commit 527e9316f8ec44bd53d90fb9f611fa7ffff52bb9:
Linux 4.4-rc4 (2015-12-06 15:43:12 -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 ab5cdc31630c7596d81ca8fbe7d695f10666f39b:
IB/mlx5: Postpone remove_keys under knowledge of coming preemption
(2015-12-08 16:55:31 -0500)
----------------------------------------------------------------
Series of 4.4-rc fixes
Most are minor to important fixes. There is one performance enhancement
that I took on the grounds that failing to check if other processes can
run before running what's intended to be a background, idle-time task
is a bug, even though the primary effect of the fix is to improve
performance (and it was a very simple patch).
----------------------------------------------------------------
Arnd Bergmann (1):
IB/iser: use sector_div instead of do_div
Bart Van Assche (5):
IB/srp: Fix a memory leak
IB/srp: Fix indirect data buffer rkey endianness
IB/srp: Fix srp_map_sg_fr()
IB core: Fix ib_sg_to_pages()
IB/cma: Add a missing rcu_read_unlock()
Christoph Hellwig (1):
IB/srp: Initialize dma_length in srp_map_idb
Easwar Hariharan (1):
IB/qib: Minor fixes to qib per SFF 8636
Hal Rosenstock (1):
IB/mad: Require CM send method for everything except ClassPortInfo
Ira Weiny (1):
IB/qib: Fix qib_mr structure
Kaike Wan (1):
IB/sa: Put netlink request into the request list before sending
Leon Romanovsky (1):
IB/mlx5: Postpone remove_keys under knowledge of coming preemption
Mike Marciniszyn (2):
IB/core: Fix user mode post wr corruption
IB/core: use RCU for uverbs id lookup
Sagi Grimberg (3):
IB/srp: Fix possible send queue overflow
mlx4: Expose correct max_sge_rd limit
iser-target: Remove explicit mlx4 work-around
Wengang Wang (2):
IB/mlx4: Use correct order of variables in log message
IB/mlx4: Use vmalloc for WR buffers when needed
drivers/infiniband/core/cma.c | 5 +---
drivers/infiniband/core/mad.c | 5 ++++
drivers/infiniband/core/sa_query.c | 32 +++++++++++----------
drivers/infiniband/core/uverbs_cmd.c | 27 +++++++++++-------
drivers/infiniband/core/verbs.c | 43 ++++++++++++++--------------
drivers/infiniband/hw/mlx4/main.c | 2 +-
drivers/infiniband/hw/mlx4/qp.c | 19 +++++++++----
drivers/infiniband/hw/mlx4/srq.c | 11 ++++++--
drivers/infiniband/hw/mlx5/mr.c | 14 +++++++++-
drivers/infiniband/hw/qib/qib_qsfp.c | 4 +--
drivers/infiniband/hw/qib/qib_verbs.h | 2 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
drivers/infiniband/ulp/isert/ib_isert.c | 13 ++-------
drivers/infiniband/ulp/srp/ib_srp.c | 48
+++++++++++++++++---------------
drivers/infiniband/ulp/srp/ib_srp.h | 5 +---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +-
include/linux/mlx4/device.h | 11 ++++++++
include/rdma/ib_mad.h | 2 ++
include/rdma/ib_verbs.h | 1 +
19 files changed, 146 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-11-07 6:35 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-11-07 6:35 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 18181 bytes --]
Hi Linus,
This is my initial round of 4.4 merge window patches. There are a few
other things I wish to get in for 4.4 that aren't in this pull, as this
represents what has gone through merge/build/run testing and not what is
the last few items for which testing is not yet complete.
The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:
Linux 4.3-rc3 (2015-09-27 07:50:08 -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 db7489e07669073970358b6cacf6a9dd8dc9275e:
IB/core, cma: Make __attribute_const__ declarations sparse-friendly
(2015-10-3
0 17:57:49 -0400)
----------------------------------------------------------------
Initial 4.4 merge window submission
- "Checksum offload support in user space" enablement
- Misc cxgb4 fixes, add T6 support
- Misc usnic fixes
- 32 bit build warning fixes
- Misc ocrdma fixes
- Multicast loopback prevention extension
- Extend the GID cache to store and return attributes of GIDs
- Misc iSER updates
- iSER clustering update
- Network NameSpace support for rdma CM
- Work Request cleanup series
- New Memory Registration API
----------------------------------------------------------------
Arnd Bergmann (2):
RDMA/cxgb4: re-fix 32-bit build warning
IB/core: avoid 32-bit warning
Bart Van Assche (3):
IB/iser: Remove an unused variable
iser-target: Remove an unused variable
IB/core, cma: Make __attribute_const__ declarations sparse-friendly
Bodong Wang (2):
IB/core: Add support of checksum capability reporting for RC and RAW
IB/mlx4: Report checksum offload cap for RAW QP when query device
Christoph Hellwig (2):
IB: split struct ib_send_wr
IB: remove xrc_remote_srq_num from struct ib_send_wr
Christoph Lameter (2):
IB/ipoib: Expire sendonly multicast joins
IB/ipoib: For sendonly join free the multicast group on leave
Chuck Lever (1):
xprtrdma: Replace global lkey with lkey local to PD
Dave Goodell \(dgoodell\) (1):
MAINTAINERS: update usnic maintainer contacts
Devesh Sharma (1):
RDMA/ocrdma: Prevent CQ-Doorbell floods
Doron Tsur (2):
IB/core: Fix memory corruption in ib_cache_gid_set_default_gid
IB/cm: Fix rb-tree duplicate free and use-after-free
Doug Ledford (6):
Merge tag 'v4.3-rc2' into k.o/for-4.3-v1
IB/ipoib: Make sendonly multicast joins create the mcast group
IB/ipoib: increase the max mcast backlog queue
Merge branch 'k.o/for-4.3-v1' into k.o/for-4.4
Merge branch 'wr-cleanup' of
git://git.infradead.org/users/hch/rdma into w
r-cleanup
Merge branch 'wr-cleanup' into k.o/for-4.4
Eran Ben Elisha (5):
IB/core: Extend ib_uverbs_create_qp
IB/core: Allow setting create flags in QP init attribute
IB/mlx4: Add IB counters table
IB/mlx4: Add counter based implementation for QP multicast
loopback block
IB/mlx4: Add support for blocking multicast loopback QP creation
user flag
Geliang Tang (1):
IB/iser: fix a comment typo
Guy Shapiro (3):
IB/addr: Pass network namespace as a parameter
IB/cma: Add support for network namespaces
IB/ucma: Take the network namespace from the process
Haggai Eran (4):
IB/cma: Accept connection without a valid netdev on RoCE
IB/cma: Potential NULL dereference in cma_id_from_event
IB/cma: Use inner P_Key to determine netdev
IB/cma: Separate port allocation to network namespaces
Hal Rosenstock (1):
ib_pack.h: Fix commentary IBA reference for CNP in IB opcode enum
Hariprasad S (6):
iw_cxgb4: detect fatal errors while creating listening filters
iw_cxgb4: pass the ord/ird in connect reply events
iw_cxgb4: fix misuse of ep->ord for minimum ird calculation
iw_cxgb4: reverse the ord/ird in the ESTABLISHED upcall
cxgb4: T6 adapter lld support for iw_cxgb4 driver
iw_cxgb4: Adds support for T6 adapter
Insu Yun (2):
usnic: correctly check failed allocation
usnic: correctly handle kzalloc return value
Jeff Squyres (1):
usnic: add missing clauses to BSD license
Maor Gottlieb (2):
net/mlx4_core: Add support for filtering multicast loopback
net/mlx4_en: Implement mcast loopback prevention for ETH qps
Matan Barak (11):
IB/core: Fix use after free of ifa
IB/core: Add netdev and gid attributes paramteres to cache
IB/core: Expose and rename ib_find_cached_gid_by_port cache API
IB/core: Add netdev to path record
IB/cm: cm_init_av_by_path should find a GID by its netdevice
IB/cma: cma_validate_port should verify the port and netdevice
IB/cache: Add ib_find_gid_by_filter cache API
IB/core: Use GID table in AH creation and dmac resolution
IB/cm: Remove the usage of smac and vid of qp_attr and cm_av
IB/core: Remove smac and vlan id from qp_attr and ah_attr
IB/core: Remove smac and vlan id from path record
Naga Irrinki (1):
RDMA/ocrdma: Check resource ids received in Async CQE
Sagi Grimberg (34):
IB/iser: Add module parameter for always register memory
IB/mlx5: Remove support for IB_DEVICE_LOCAL_DMA_LKEY
IB/mlx5: Remove pa_lkey usages
xprtrdma: Don't require LOCAL_DMA_LKEY support for fastreg
IB/iser: set block queue_virt_boundary
IB/iser: Enable SG clustering
IB/core: Introduce new fast registration API
IB/mlx5: Remove dead fmr code
IB/mlx5: Support the new memory registration API
IB/mlx4: Support the new memory registration API
RDMA/ocrdma: Support the new memory registration API
RDMA/cxgb3: Support the new memory registration API
iw_cxgb4: Support the new memory registration API
IB/qib: Support the new memory registration API
RDMA/nes: Support the new memory registration API
IB/iser: Port to new fast registration API
iser-target: Port to new memory registration API
xprtrdma: Port to new memory registration API
svcrdma: Port to new memory registration API
RDS/IW: Convert to new memory registration API
IB/srp: Split srp_map_sg
IB/srp: Convert to new registration API
IB/srp: Remove srp_finish_mapping
IB/srp: Dont allocate a page vector when using fast_reg
IB/mlx5: Remove old FRWR API support
IB/mlx4: Remove old FRWR API support
RDMA/ocrdma: Remove old FRWR API
RDMA/cxgb3: Remove old FRWR API
iw_cxgb4: Remove old FRWR API
IB/qib: Remove old FRWR API
RDMA/nes: Remove old FRWR API
IB/hfi1: Remove fast registration from the code
IB/ipath: Remove fast registration from the code
IB/core: Remove old fast registration API
Sasha Levin (1):
IB/ucma: check workqueue allocation before usage
Selvin Xavier (3):
RDMA/ocrdma: Cleanup unused device list and rcu variables
RDMA/ocrdma: Avoid a possible crash in ocrdma_rem_port_stats
RDMA/ocrdma: Bump up ocrdma version number to 11.0.0.0
MAINTAINERS | 5 +-
drivers/infiniband/core/addr.c | 20 +-
drivers/infiniband/core/agent.c | 2 +-
drivers/infiniband/core/cache.c | 114 +++++-
drivers/infiniband/core/cm.c | 50 +--
drivers/infiniband/core/cma.c | 233 ++++++++----
drivers/infiniband/core/core_priv.h | 9 +-
drivers/infiniband/core/device.c | 19 +-
drivers/infiniband/core/mad.c | 42 +--
drivers/infiniband/core/mad_priv.h | 2 +-
drivers/infiniband/core/multicast.c | 3 +-
drivers/infiniband/core/roce_gid_mgmt.c | 35 +-
drivers/infiniband/core/sa_query.c | 19 +-
drivers/infiniband/core/sysfs.c | 2 +-
drivers/infiniband/core/ucma.c | 12 +-
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_cmd.c | 402
++++++++++++++-------
drivers/infiniband/core/uverbs_main.c | 1 +
drivers/infiniband/core/uverbs_marshall.c | 4 +-
drivers/infiniband/core/verbs.c | 295 ++++++++++-----
drivers/infiniband/hw/cxgb3/iwch_cq.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 39 +-
drivers/infiniband/hw/cxgb3/iwch_provider.h | 2 +
drivers/infiniband/hw/cxgb3/iwch_qp.c | 43 +--
drivers/infiniband/hw/cxgb4/cm.c | 331 ++++++++++-------
drivers/infiniband/hw/cxgb4/cq.c | 2 +-
drivers/infiniband/hw/cxgb4/device.c | 10 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 25 +-
drivers/infiniband/hw/cxgb4/mem.c | 63 ++--
drivers/infiniband/hw/cxgb4/provider.c | 5 +-
drivers/infiniband/hw/cxgb4/qp.c | 73 ++--
drivers/infiniband/hw/cxgb4/t4.h | 5 +-
drivers/infiniband/hw/mlx4/ah.c | 17 +-
drivers/infiniband/hw/mlx4/cq.c | 2 +-
drivers/infiniband/hw/mlx4/mad.c | 91 +++--
drivers/infiniband/hw/mlx4/main.c | 75 +++-
drivers/infiniband/hw/mlx4/mcg.c | 2 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 37 +-
drivers/infiniband/hw/mlx4/mr.c | 169 +++++----
drivers/infiniband/hw/mlx4/qp.c | 330 +++++++++++------
drivers/infiniband/hw/mlx5/cq.c | 4 +-
drivers/infiniband/hw/mlx5/main.c | 70 +---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 56 +--
drivers/infiniband/hw/mlx5/mr.c | 187 ++++++----
drivers/infiniband/hw/mlx5/qp.c | 231 ++++++------
drivers/infiniband/hw/mthca/mthca_av.c | 2 +-
drivers/infiniband/hw/mthca/mthca_qp.c | 84 ++---
drivers/infiniband/hw/nes/nes_hw.h | 6 -
drivers/infiniband/hw/nes/nes_verbs.c | 170 ++++-----
drivers/infiniband/hw/nes/nes_verbs.h | 4 +
drivers/infiniband/hw/ocrdma/ocrdma.h | 5 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 22 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 60 ++-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 19 +-
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 184 +++++-----
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 7 +-
drivers/infiniband/hw/qib/qib_keys.c | 41 ++-
drivers/infiniband/hw/qib/qib_mr.c | 46 +--
drivers/infiniband/hw/qib/qib_qp.c | 2 +-
drivers/infiniband/hw/qib/qib_rc.c | 38 +-
drivers/infiniband/hw/qib/qib_ruc.c | 20 +-
drivers/infiniband/hw/qib/qib_uc.c | 4 +-
drivers/infiniband/hw/qib/qib_ud.c | 20 +-
drivers/infiniband/hw/qib/qib_verbs.c | 29 +-
drivers/infiniband/hw/qib/qib_verbs.h | 19 +-
drivers/infiniband/hw/usnic/usnic.h | 21 +-
drivers/infiniband/hw/usnic/usnic_abi.h | 21 +-
drivers/infiniband/hw/usnic/usnic_common_pkt_hdr.h | 21 +-
drivers/infiniband/hw/usnic/usnic_common_util.h | 21 +-
drivers/infiniband/hw/usnic/usnic_debugfs.c | 21 +-
drivers/infiniband/hw/usnic/usnic_debugfs.h | 21 +-
drivers/infiniband/hw/usnic/usnic_fwd.c | 21 +-
drivers/infiniband/hw/usnic/usnic_fwd.h | 21 +-
drivers/infiniband/hw/usnic/usnic_ib.h | 21 +-
drivers/infiniband/hw/usnic/usnic_ib_main.c | 30 +-
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 29 +-
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.h | 21 +-
drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 21 +-
drivers/infiniband/hw/usnic/usnic_ib_sysfs.h | 21 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 21 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 21 +-
drivers/infiniband/hw/usnic/usnic_log.h | 21 +-
drivers/infiniband/hw/usnic/usnic_transport.c | 21 +-
drivers/infiniband/hw/usnic/usnic_transport.h | 21 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.h | 21 +-
.../infiniband/hw/usnic/usnic_uiom_interval_tree.c | 21 +-
.../infiniband/hw/usnic/usnic_uiom_interval_tree.h | 21 +-
drivers/infiniband/hw/usnic/usnic_vnic.c | 21 +-
drivers/infiniband/hw/usnic/usnic_vnic.h | 21 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 9 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 4 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 22 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 24 +-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 32 +-
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 6 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 25 +-
drivers/infiniband/ulp/iser/iscsi_iser.h | 26 +-
drivers/infiniband/ulp/iser/iser_initiator.c | 51 +--
drivers/infiniband/ulp/iser/iser_memory.c | 386
+++-----------------
drivers/infiniband/ulp/iser/iser_verbs.c | 41 +--
drivers/infiniband/ulp/isert/ib_isert.c | 269 +++++---------
drivers/infiniband/ulp/isert/ib_isert.h | 8 +-
drivers/infiniband/ulp/srp/ib_srp.c | 262 ++++++++------
drivers/infiniband/ulp/srp/ib_srp.h | 11 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 35 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 41 +--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 22 ++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4_chip_type.h | 85 +++++
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 48 +++
drivers/net/ethernet/mellanox/mlx4/en_main.c | 22 ++
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 25 ++
drivers/net/ethernet/mellanox/mlx4/fw.c | 6 +
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +-
drivers/net/ethernet/mellanox/mlx4/qp.c | 19 +-
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 30 +-
drivers/net/ethernet/mellanox/mlx5/core/fw.c | 22 --
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h | 6 +-
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 35 +-
drivers/staging/rdma/amso1100/c2_qp.c | 8 +-
drivers/staging/rdma/ehca/ehca_reqs.c | 53 +--
drivers/staging/rdma/hfi1/keys.c | 55 ---
drivers/staging/rdma/hfi1/mr.c | 33 +-
drivers/staging/rdma/hfi1/qp.c | 2 +-
drivers/staging/rdma/hfi1/rc.c | 24 +-
drivers/staging/rdma/hfi1/ruc.c | 18 +-
drivers/staging/rdma/hfi1/uc.c | 4 +-
drivers/staging/rdma/hfi1/ud.c | 20 +-
drivers/staging/rdma/hfi1/verbs.c | 26 +-
drivers/staging/rdma/hfi1/verbs.h | 14 +-
drivers/staging/rdma/ipath/ipath_rc.c | 24 +-
drivers/staging/rdma/ipath/ipath_ruc.c | 16 +-
drivers/staging/rdma/ipath/ipath_uc.c | 4 +-
drivers/staging/rdma/ipath/ipath_ud.c | 26 +-
drivers/staging/rdma/ipath/ipath_verbs.c | 17 +-
drivers/staging/rdma/ipath/ipath_verbs.h | 8 +-
include/linux/mlx4/device.h | 2 +
include/linux/mlx4/qp.h | 24 +-
include/linux/mlx5/device.h | 11 -
include/linux/mlx5/driver.h | 1 -
include/linux/sunrpc/svc_rdma.h | 6 +-
include/rdma/ib_addr.h | 18 +-
include/rdma/ib_cache.h | 40 +-
include/rdma/ib_pack.h | 2 +-
include/rdma/ib_sa.h | 12 +-
include/rdma/ib_verbs.h | 222 +++++++-----
include/rdma/rdma_cm.h | 8 +-
include/uapi/rdma/ib_user_verbs.h | 26 ++
net/9p/trans_rdma.c | 4 +-
net/rds/ib.c | 2 +-
net/rds/ib.h | 6 +-
net/rds/ib_cm.c | 2 +-
net/rds/ib_send.c | 71 ++--
net/rds/iw.c | 2 +-
net/rds/iw.h | 9 +-
net/rds/iw_cm.c | 2 +-
net/rds/iw_rdma.c | 129 +++----
net/rds/iw_send.c | 154 ++++----
net/rds/rdma_transport.c | 4 +-
net/sunrpc/xprtrdma/fmr_ops.c | 19 -
net/sunrpc/xprtrdma/frwr_ops.c | 124 ++++---
net/sunrpc/xprtrdma/physical_ops.c | 10 +-
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 122 ++++---
net/sunrpc/xprtrdma/svc_rdma_sendto.c | 18 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 38 +-
net/sunrpc/xprtrdma/verbs.c | 13 +-
net/sunrpc/xprtrdma/xprt_rdma.h | 4 +-
169 files changed, 4195 insertions(+), 3287 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/t4_chip_type.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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-10-22 14:34 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-10-22 14:34 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
Hi Linus,
It's late in the game, I know, but these fixes seemed important enough
to warrant a late pull request. They all involve oopses or use after
frees or corruptions. Explanation of each in the tag message. Thanks!
The following changes since commit 0b5c9279e568d90903acedc2b9b832d8d78e8288:
IB/ipoib: For sendonly join free the multicast group on leave
(2015-10-13 16:43:59 -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 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4:
IB/cm: Fix rb-tree duplicate free and use-after-free (2015-10-21
15:43:12 -0400)
----------------------------------------------------------------
Changes for 4.3-rc6
6 serious fixes:
1) Hold the mutex around the find and corresponding update of our gid
2) The ifa list is rcu protected, copy its contents under rcu to avoid
using a freed structure
3) On error, netdev might be null, so check it before trying to release it
4) On init, if workqueue alloc fails, fail init
5) The new demux patches exposed a bug in mlx5 and ipath drivers, we need
to use the payload P_Key to determine the P_Key the packet arrived on
because the hardware doesn't tell us the truth
6) Due to a couple convoluted error flows, it is possible for the CM to
trigger a use_after_free and a double_free of rb nodes. Add two
checks to prevent that. This code has worked for 10+ years. It is
likely that some of the recent changes have caused this issue to
surface. The current patch will protect us from nasty events for
now while we track down why this is just now showing up.
----------------------------------------------------------------
Doron Tsur (2):
IB/core: Fix memory corruption in ib_cache_gid_set_default_gid
IB/cm: Fix rb-tree duplicate free and use-after-free
Haggai Eran (2):
IB/cma: Potential NULL dereference in cma_id_from_event
IB/cma: Use inner P_Key to determine netdev
Matan Barak (1):
IB/core: Fix use after free of ifa
Sasha Levin (1):
IB/ucma: check workqueue allocation before usage
drivers/infiniband/core/cache.c | 2 +-
drivers/infiniband/core/cm.c | 10 +++++++++-
drivers/infiniband/core/cma.c | 6 +++---
drivers/infiniband/core/roce_gid_mgmt.c | 35
+++++++++++++++++++++++++--------
drivers/infiniband/core/ucma.c | 7 ++++++-
5 files changed, 46 insertions(+), 14 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-10-14 19:08 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-10-14 19:08 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]
Hi Linus,
We have four batched up patches for the current rc kernel.
Two of them are small fixes that are obvious.
One of them is larger than I would like for a late stage rc pull, but we
found an issue in the namespace lookup code related to RoCE and this
works around the issue for now (we allow a lookup with a namespace to
succeed on RoCE since RoCE namespaces aren't implemented yet). This
will go away in 4.4 when we put in support for namespaces in RoCE devices.
The last one is large in terms of lines, but is all legal and no
functional changes. Cisco needed to update their files to be more
specific about their license. They had intended the files to be dual
licensed as GPL/BSD all along, and specified that in their module
license tag, but their file headers were not up to par. They contacted
all of the contributors to get agreement and then submitted a patch to
update the license headers in the files.
Thanks!
The following changes since commit 2866196f294954ce9fa226825c8c1eaa64c7da8a:
IB/ipoib: increase the max mcast backlog queue (2015-09-25 22:30:24 -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 0b5c9279e568d90903acedc2b9b832d8d78e8288:
IB/ipoib: For sendonly join free the multicast group on leave
(2015-10-13 16:4
3:59 -0400)
----------------------------------------------------------------
Changes for 4.3-rc5
- Work around connection namespace lookup bug related to RoCE
- Change usnic license to Dual GPL/BSD (was intended to be that way
all along, but wasn't clear, permission from contributors was
chased down)
- Fix an issue between NFSoRDMA and mlx5 that could cause an oops
- Fix leak of sendonly multicast groups
----------------------------------------------------------------
Christoph Lameter (1):
IB/ipoib: For sendonly join free the multicast group on leave
Haggai Eran (1):
IB/cma: Accept connection without a valid netdev on RoCE
Jeff Squyres (1):
usnic: add missing clauses to BSD license
Sagi Grimberg (1):
xprtrdma: Don't require LOCAL_DMA_LKEY support for fastreg
drivers/infiniband/core/cma.c | 54
++++++++++++++++------
drivers/infiniband/hw/usnic/usnic.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_abi.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_common_pkt_hdr.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_common_util.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_debugfs.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_debugfs.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_fwd.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_fwd.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_main.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_sysfs.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_log.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_transport.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_transport.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.h | 21 +++++++--
.../infiniband/hw/usnic/usnic_uiom_interval_tree.c | 21 +++++++--
.../infiniband/hw/usnic/usnic_uiom_interval_tree.h | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_vnic.c | 21 +++++++--
drivers/infiniband/hw/usnic/usnic_vnic.h | 21 +++++++--
drivers/infiniband/ulp/ipoib/ipoib.h | 1 +
drivers/infiniband/ulp/ipoib/ipoib_main.c | 4 +-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 2 +-
net/sunrpc/xprtrdma/verbs.c | 8 ++--
30 files changed, 481 insertions(+), 94 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-09-29 18:04 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-09-29 18:04 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]
Hi Linus,
I have a few -rc fixes for you. One fix in particular, for the NFSoRDMA
code, relied upon changes that went in during the 4.3 merge window to
apply cleanly, but also relied on a group of related commits in this
set, making it need to come through my tree. So I merged up to 4.3-rc2,
and this is what's in my tree beyond that:
The following changes since commit 310b7cec8ea32dcd4e9978423717ce78dd89d45d:
Merge tag 'v4.3-rc2' into k.o/for-4.3-v1 (2015-09-25 10:46:07 -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 2866196f294954ce9fa226825c8c1eaa64c7da8a:
IB/ipoib: increase the max mcast backlog queue (2015-09-25 22:30:24 -0400)
----------------------------------------------------------------
Changes for 4.3-rc4
- Fixes for mlx5 related issues
- Fixes for ipoib multicast handling
----------------------------------------------------------------
Christoph Lameter (1):
IB/ipoib: Expire sendonly multicast joins
Chuck Lever (1):
xprtrdma: Replace global lkey with lkey local to PD
Doug Ledford (2):
IB/ipoib: Make sendonly multicast joins create the mcast group
IB/ipoib: increase the max mcast backlog queue
Sagi Grimberg (3):
IB/iser: Add module parameter for always register memory
IB/mlx5: Remove support for IB_DEVICE_LOCAL_DMA_LKEY
IB/mlx5: Remove pa_lkey usages
drivers/infiniband/hw/mlx5/main.c | 67
+-------------------------
drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 -
drivers/infiniband/hw/mlx5/qp.c | 4 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 4 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 18 +++++++
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 26 +++++-----
drivers/infiniband/ulp/iser/iscsi_iser.c | 5 ++
drivers/infiniband/ulp/iser/iscsi_iser.h | 1 +
drivers/infiniband/ulp/iser/iser_memory.c | 18 ++++---
drivers/infiniband/ulp/iser/iser_verbs.c | 21 +++++---
drivers/net/ethernet/mellanox/mlx5/core/fw.c | 22 ---------
include/linux/mlx5/device.h | 11 -----
include/linux/mlx5/driver.h | 1 -
net/sunrpc/xprtrdma/fmr_ops.c | 19 --------
net/sunrpc/xprtrdma/frwr_ops.c | 5 --
net/sunrpc/xprtrdma/physical_ops.c | 10 +---
net/sunrpc/xprtrdma/verbs.c | 2 +-
net/sunrpc/xprtrdma/xprt_rdma.h | 1 -
18 files changed, 70 insertions(+), 167 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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-09-18 16:01 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-09-18 16:01 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds; +Cc: Doug Ledford
Hi Linus,
The new hfi1 driver in staging/rdma has had a number of fixup patches
since being added to the tree. This is the first batch of those fixes.
The following changes since commit 447e9a4d27484175a84daaa8e03d35c650f443b7:
IB/ehca: Deprecate driver, move to staging, schedule deletion (2015-09-11 18:13:35 -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 e116a64fab650aed3d7b9b4db0b59c07f361bc9f:
IB/hfi: Properly set permissions for user device files (2015-09-18 11:28:47 -0400)
----------------------------------------------------------------
Changes for 4.3-rc1
- Batch of minor fixups to the new hfi1 driver
----------------------------------------------------------------
Dan Carpenter (6):
IB/hfi1: fix copy_to/from_user() error handling
IB/hfi1: checking for NULL instead of IS_ERR
IB/hfi1: fix a locking bug
IB/hfi1: info leak in get_ctxt_info()
IB/hfi1: clean up some defines
IB/hfi1: mask vs shift confusion
Ira Weiny (2):
IB/hfi1: fix pstateinfo from returning improperly byteswapped value
IB/hfi: Properly set permissions for user device files
Mike Marciniszyn (1):
IB/hfi1: fix sdma_descq_cnt parameter parsing
drivers/staging/rdma/hfi1/chip.c | 4 +--
drivers/staging/rdma/hfi1/device.c | 54 ++++++++++++++++++++++++++++++++----
drivers/staging/rdma/hfi1/device.h | 3 +-
drivers/staging/rdma/hfi1/diag.c | 36 ++++++++++++------------
drivers/staging/rdma/hfi1/file_ops.c | 10 +++++--
drivers/staging/rdma/hfi1/mad.c | 4 +--
drivers/staging/rdma/hfi1/sdma.c | 6 ++--
drivers/staging/rdma/hfi1/sdma.h | 36 ++++++++++++------------
drivers/staging/rdma/hfi1/verbs.c | 8 ++++--
include/rdma/opa_port_info.h | 4 +--
10 files changed, 107 insertions(+), 58 deletions(-)
--
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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-09-16 15:00 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-09-16 15:00 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds; +Cc: Doug Ledford
Hi Linus,
This is a move only, no functional changes. I tried to get it in prior
to the rc1 release, but we were waiting on IBM to get back to us that
they were OK with the deprecation and eventual removal of this driver.
That OK didn't materialize until last week, so integration and testing
time pushed us beyond the rc1 release. If you don't mind, I would
appreciate keeping this in this release so that all three drivers we
are deprecating and removing are all on the same schedule. Thanks!
The following changes since commit d1178cbcdcf91900ccf10a177350d7945703c151:
IB/ipoib: Suppress warning for send only join failures (2015-09-03 17:11:05 -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 447e9a4d27484175a84daaa8e03d35c650f443b7:
IB/ehca: Deprecate driver, move to staging, schedule deletion (2015-09-11 18:13:35 -0400)
----------------------------------------------------------------
Changes for 4.3-rc1
- Move ehca driver to staging/rdma and schedule for deletion
----------------------------------------------------------------
Doug Ledford (1):
IB/ehca: Deprecate driver, move to staging, schedule deletion
drivers/infiniband/Kconfig | 1 -
drivers/infiniband/hw/Makefile | 1 -
drivers/staging/rdma/Kconfig | 2 ++
drivers/staging/rdma/Makefile | 1 +
drivers/{infiniband/hw => staging/rdma}/ehca/Kconfig | 3 ++-
drivers/{infiniband/hw => staging/rdma}/ehca/Makefile | 0
drivers/staging/rdma/ehca/TODO | 4 ++++
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_av.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_classes.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_classes_pSeries.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_cq.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_eq.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_hca.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_irq.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_irq.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_iverbs.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_main.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mcast.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mrmw.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mrmw.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_pd.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_qes.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_qp.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_reqs.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_sqp.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_tools.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ehca_uverbs.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hcp_if.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hcp_if.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hcp_phyp.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hcp_phyp.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hipz_fns.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hipz_fns_core.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/hipz_hw.h | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ipz_pt_fn.c | 0
drivers/{infiniband/hw => staging/rdma}/ehca/ipz_pt_fn.h | 0
36 files changed, 9 insertions(+), 3 deletions(-)
rename drivers/{infiniband/hw => staging/rdma}/ehca/Kconfig (69%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/Makefile (100%)
create mode 100644 drivers/staging/rdma/ehca/TODO
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_av.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_classes.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_classes_pSeries.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_cq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_eq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_hca.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_irq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_irq.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_iverbs.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_main.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mcast.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mrmw.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_mrmw.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_pd.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_qes.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_qp.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_reqs.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_sqp.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_tools.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ehca_uverbs.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hcp_if.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hcp_if.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hcp_phyp.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hcp_phyp.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hipz_fns.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hipz_fns_core.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/hipz_hw.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ipz_pt_fn.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ehca/ipz_pt_fn.h (100%)
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55F05A2F.9090005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-10 16:35 ` Matan Barak
0 siblings, 0 replies; 196+ messages in thread
From: Matan Barak @ 2015-09-10 16:35 UTC (permalink / raw)
To: Doug Ledford, Linus Torvalds
Cc: Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Moni Shoua
On 9/9/2015 7:11 PM, Doug Ledford wrote:
> On 09/09/2015 12:10 PM, Linus Torvalds wrote:
>> On Wed, Sep 9, 2015 at 8:44 AM, Linus Torvalds
>> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>>
>>> Ok. I've merged it in my tree now, it's just waiting for the usual compile-test.
>>
>> Compile-test finished, and pushed out.
>>
>> Can somebody check that my conversion of roce_gid_mgmt.c actually
>> _works_ though? It compiles, but that's all I'm testing.
>
> Sure. Thanks!
>
>
I currently don't have a bonded setup available.
I have tested the tree by setting up an active-backup bond device,
selecting each slave as an active slave and made sure the bond's GID
was applied on the correct port.
Afterwards, I've made sure that when using the bond's IP device, RoCE
traffic was successfully sent and received (on the active port).
I think it verifies the conflicting parts of roce_gid_mgmt pretty well.
I'm adding Moni, whom I believe have such a bonded setup.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55F0B371.2090403-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-09 23:20 ` Stephen Rothwell
0 siblings, 0 replies; 196+ messages in thread
From: Stephen Rothwell @ 2015-09-09 23:20 UTC (permalink / raw)
To: Doug Ledford
Cc: Linus Torvalds, Matan Barak, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi Doug,
On Wed, 9 Sep 2015 18:32:17 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On 09/09/2015 05:45 PM, Stephen Rothwell wrote:
> >
> > The only branch of yours that I have ever fetched is
> > git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git#for-next
Turns out that that "branch", is actually a tag (the only one I fetch,
but it doesn't cause any hassle).
> Hmmm...I could have sworn I hadn't pushed that branch to k.o by the time
> you sent the merge request. If that's not the case, then I will have to
> figure out how I confused myself on that issue.
In case it helps, next-20150817 contained this as the for-next tag:
Initial roundup of 4.3 merge window candidates
# gpg: Signature made Sun 02 Aug 2015 07:21:56 AEST using RSA key ID 0E572FDD
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: Good signature from "Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>" [undefined]
# gpg: aka "Doug Ledford (Personal email) <dledford-HHGe/kKACDifJOJzLBvvIA@public.gmane.org>" [unknown]
# gpg: aka "[jpeg image of size 3057]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
And the associated commit was:
153b7306b7c6 ("Merge branch 'hfi1-v4' into to-be-rebased/for-4.3")
>From next-20150903, the for-next tag pointed back into Linus' tree
("Linux 4.2").
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <20150910074505.1b4eec1c-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
@ 2015-09-09 22:32 ` Doug Ledford
[not found] ` <55F0B371.2090403-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 22:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, Matan Barak, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On 09/09/2015 05:45 PM, Stephen Rothwell wrote:
> Hi Doug,
>
> On Tue, 8 Sep 2015 23:08:47 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> On 09/08/2015 08:35 PM, Linus Torvalds wrote:
>>
>>> (b) you rebased your commit series after it
>>
>> Yes. I rebased my tree a bunch of times. I keep two different git
>> repos. The one on kernel.org and one on github. I rebase the one on
>> github. I don't rebase the one on kernel.org. I had *thought* that
>> Stephen had pointed the for-next setup at my kernel.org stuff, but he
>> evidently has it pointed at my github setup. That's something I need to
>> address with Stephen.
>
> The only branch of yours that I have ever fetched is
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git#for-next
>
Hmmm...I could have sworn I hadn't pushed that branch to k.o by the time
you sent the merge request. If that's not the case, then I will have to
figure out how I confused myself on that issue.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55EFA2BF.7060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 3:33 ` Linus Torvalds
@ 2015-09-09 21:45 ` Stephen Rothwell
[not found] ` <20150910074505.1b4eec1c-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
1 sibling, 1 reply; 196+ messages in thread
From: Stephen Rothwell @ 2015-09-09 21:45 UTC (permalink / raw)
To: Doug Ledford
Cc: Linus Torvalds, Matan Barak, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi Doug,
On Tue, 8 Sep 2015 23:08:47 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On 09/08/2015 08:35 PM, Linus Torvalds wrote:
>
> > (b) you rebased your commit series after it
>
> Yes. I rebased my tree a bunch of times. I keep two different git
> repos. The one on kernel.org and one on github. I rebase the one on
> github. I don't rebase the one on kernel.org. I had *thought* that
> Stephen had pointed the for-next setup at my kernel.org stuff, but he
> evidently has it pointed at my github setup. That's something I need to
> address with Stephen.
The only branch of yours that I have ever fetched is
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git#for-next
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFwCwT-K_Qw3aQBXt_HbQX6v4d4EXHb3dJVCkD3kg83gzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-09-09 16:11 ` Doug Ledford
[not found] ` <55F05A2F.9090005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 16:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
On 09/09/2015 12:10 PM, Linus Torvalds wrote:
> On Wed, Sep 9, 2015 at 8:44 AM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>> Ok. I've merged it in my tree now, it's just waiting for the usual compile-test.
>
> Compile-test finished, and pushed out.
>
> Can somebody check that my conversion of roce_gid_mgmt.c actually
> _works_ though? It compiles, but that's all I'm testing.
Sure. Thanks!
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFxJovuBGpg04YM0AvrzL_TPDoHebkP21R7tO3=QMQUUXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 16:06 ` Doug Ledford
@ 2015-09-09 16:10 ` Linus Torvalds
[not found] ` <CA+55aFwCwT-K_Qw3aQBXt_HbQX6v4d4EXHb3dJVCkD3kg83gzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
1 sibling, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 16:10 UTC (permalink / raw)
To: Doug Ledford
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Wed, Sep 9, 2015 at 8:44 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> Ok. I've merged it in my tree now, it's just waiting for the usual compile-test.
Compile-test finished, and pushed out.
Can somebody check that my conversion of roce_gid_mgmt.c actually
_works_ though? It compiles, but that's all I'm testing.
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFxJovuBGpg04YM0AvrzL_TPDoHebkP21R7tO3=QMQUUXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-09-09 16:06 ` Doug Ledford
2015-09-09 16:10 ` Linus Torvalds
1 sibling, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 16:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On 09/09/2015 11:44 AM, Linus Torvalds wrote:
> Yes, I see them, thanks for the links.
>
> It would have helped if the commit logs had had a record of this
> somehow (ie a "Cc: netdev" etc so that I could tell during the merge
> that this was actually something the networking people knew about).
I'll make sure I include that in the future.
> That would have avoided a lot of my angst. Sorry,
No worries. And since I didn't spell it out in the commit logs, I
coordinated with Greg K-H on the staging changes and with Anna Schumaker
on the NFS client changes too.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55F02006.5020504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-09 15:44 ` Linus Torvalds
[not found] ` <CA+55aFxJovuBGpg04YM0AvrzL_TPDoHebkP21R7tO3=QMQUUXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 15:44 UTC (permalink / raw)
To: Doug Ledford
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Wed, Sep 9, 2015 at 5:03 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Me telling Matan to Cc: netdev on patches related to their subsystem:
> http://marc.info/?l=linux-rdma&m=143398479529819&w=4
>
> Above was v5 of the patchset. Both the v6 and v7 of the patchset had
> netdev Cc:ed on the cover letter and at least the first three patches.
Ok, good. That's the kind of information I was missing.
> Here's the v7 cover and the first three patches in the netdev archives:
> http://marc.info/?l=linux-netdev&m=143827052913936&w=4
.. and this is the one I will effectively have to revert because of
the conflict.
> Here Jason Gunthorpe is asking me if I was going to take netdev stuff
> without an ack from netdev in the netdev archives:
> http://marc.info/?l=linux-netdev&m=143836033706501&w=4
>
> And here is my response to Jason, again, in the netdev archives:
> http://marc.info/?l=linux-netdev&m=143836450808174&w=4
Good. So this was all done right, it just wasn't visible in the commit history.
> See above. This was done.
Ok. I've merged it in my tree now, it's just waiting for the usual compile-test.
Note that a correct merge (which looking at it, Stephen didn't
actually do after all) also involves getting rid of the "struct
netdev_changeupper_info" type that _isn't_ actually getting filled at
all, and converting your one user of it in
drivers/infiniband/core/roce_gid_mgmt.c to what the networking layer
actually does.
> I see perfectly well Linus. I am not new to engineering. You have
> stated several times that I'm missing the point, or do I see your point,
> please understand mine: I *did* the things you are assuming I didn't do.
Yes, I see them, thanks for the links.
It would have helped if the commit logs had had a record of this
somehow (ie a "Cc: netdev" etc so that I could tell during the merge
that this was actually something the networking people knew about).
That would have avoided a lot of my angst. Sorry,
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFwg+QCM=xaoK4ic+4AymqCYrF4Ny8WO9iY2hHFBLNT3VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 6:41 ` Jiri Pirko
@ 2015-09-09 12:03 ` Doug Ledford
[not found] ` <55F02006.5020504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 12:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 5219 bytes --]
Side note: it's very annoying to have Time Warner Cable decide to take
your internet down in the middle of writing a reply :-/
On 09/08/2015 11:33 PM, Linus Torvalds wrote:
> On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> With a comment that said "I can carry this merge forward, no further
>> action is necessary on your part". That combined with my lack of deep
>> internal knowledge of what it is that Stephen is doing made me go "Ok,
>> he says don't do anything, so I won't change it."
>
> So quite frankly, Stephen does a really good job at merging and most
> of his merges are very on point. He's been doing a lot of them as part
> of linux-next, and has seen more conflicts than just about anybody
> else.
>
> But I think to him it's mostly just an issue of "get the right end
> result". I don't think he goes: "this merge conflict is a result of a
> breakdown of the development process".
>
> Conversely, to me, one of the main reasons I want to do those merges
> is exactly because I think conflicts are more about the development
> process issues than about "just getting the right end result". Yes,
> obviously I want to get the rigth end result too, but I very much
> react to how/why the conflict happened in the first place. The end
> result is _almost_ secondary, although 99% of the time the primary
> issue doesn't really even raise its head.
>
> So I'm upset not because the conflict is hard to resolve (it isn't),
> but because I feel this was really badly handled.
>
> Yes, the fact that Mellanox people sent two different patches to two
> different maintainers that did the same thing in two different ways is
> odd. Matan and Jiri are cc'd, and I think that whole thing just smells
> really bad.
>
> But at the same time, I expect more of maintainers, and I don't see
> any sign that David and the networking people were notified about the
> _other_ patch to _their_ subsystem.
Me telling Matan to Cc: netdev on patches related to their subsystem:
http://marc.info/?l=linux-rdma&m=143398479529819&w=4
Above was v5 of the patchset. Both the v6 and v7 of the patchset had
netdev Cc:ed on the cover letter and at least the first three patches.
Here's the v7 cover and the first three patches in the netdev archives:
http://marc.info/?l=linux-netdev&m=143827046913908&w=4
http://marc.info/?l=linux-netdev&m=143827047413915&w=4
http://marc.info/?l=linux-netdev&m=143827052913936&w=4
http://marc.info/?l=linux-netdev&m=143827055013953&w=4
Here I am saying I've pulled the patchset in in the netdev archives:
http://marc.info/?l=linux-netdev&m=143834704701705&w=4
Here Jason Gunthorpe is asking me if I was going to take netdev stuff
without an ack from netdev in the netdev archives:
http://marc.info/?l=linux-netdev&m=143836033706501&w=4
And here is my response to Jason, again, in the netdev archives:
http://marc.info/?l=linux-netdev&m=143836450808174&w=4
Here is the initial notification from Stephen on the merge conflict:
http://marc.info/?l=linux-next&m=144072523831647&w=4
Here's is Jiri's response (on linux-netdev, but according to my records
also direct Cc: Dave Miller):
http://marc.info/?l=linux-netdev&m=144074372902869&w=4
> The fact that you weren't aware of the other patch in the networking
> subsystem is kind of to be expected. You're not the network
> maintainer, so why would you? But exactly because you're not the
> networking maintainer, I would have expected you to check with him
> when you apply patches to generic networking code.
See above. This was done.
> This time it conflicted, and I noticed, and I went "this is not how
> kernel development is supposed to go".
I didn't switch up for the newer patch, that didn't help. But
otherwise, I did what was needed.
> But say that the other networking patch hadn't even existed: in that
> case I *still* shouldn't have gotten a patch to net/core/dev.c from
> you without any sign that David had ack'ed it (or at the very least
> been notified, even if he hadn't reacted).
And such a thing wouldn't have happened.
> See?
I see perfectly well Linus. I am not new to engineering. You have
stated several times that I'm missing the point, or do I see your point,
please understand mine: I *did* the things you are assuming I didn't do.
The record is in the public archives. I didn't make a big deal about
it because it *isn't* a big deal unless you assume that I'm running
around nilly-willy throwing shit at the wall and hoping to make a
painting. As I knew very well that's not what I'm doing, *I* didn't
have those assumptions, and therefore I didn't think this merge fixup
was a big deal. As the efforts to bring this to the network
maintainer's attention is in the record above, you will likewise find if
you talk to Greg K-H that I worked with him both publicly and privately
on the changes I made in the drivers/staging area. I do now how to keep
responsible parties informed when I'm working in their domain.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55EFE932.5010401-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
@ 2015-09-09 11:05 ` Or Gerlitz
0 siblings, 0 replies; 196+ messages in thread
From: Or Gerlitz @ 2015-09-09 11:05 UTC (permalink / raw)
To: Linus Torvalds, Doug Ledford
Cc: Matan Barak, Jiri Pirko, Stephen Rothwell, David Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On 9/9/2015 11:09 AM, Matan Barak wrote:
>
> On 9/9/2015 9:41 AM, Jiri Pirko wrote:
>> Wed, Sep 09, 2015 at 05:33:28AM CEST,
>> torvalds-de/tnXTf+JLsfHDXvbKv3X+HMGWnyQKZs0AfqQuZ5sE@public.gmane.org:
>>> On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford
>>> <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>wrote:
>>>>
>>>> With a comment that said "I can carry this merge forward, no further
>>>> action is necessary on your part". That combined with my lack of deep
>>>> internal knowledge of what it is that Stephen is doing made me go "Ok,
>>>> he says don't do anything, so I won't change it."
>>>
>>> So quite frankly, Stephen does a really good job at merging and most
>>> of his merges are very on point. He's been doing a lot of them as part
>>> of linux-next, and has seen more conflicts than just about anybody
>>> else.
>>>
>>> But I think to him it's mostly just an issue of "get the right end
>>> result". I don't think he goes: "this merge conflict is a result of a
>>> breakdown of the development process".
>>>
>>> Conversely, to me, one of the main reasons I want to do those merges
>>> is exactly because I think conflicts are more about the development
>>> process issues than about "just getting the right end result". Yes,
>>> obviously I want to get the rigth end result too, but I very much
>>> react to how/why the conflict happened in the first place. The end
>>> result is _almost_secondary, although 99% of the time the primary
>>> issue doesn't really even raise its head.
>>>
>>> So I'm upset not because the conflict is hard to resolve (it isn't),
>>> but because I feel this was really badly handled.
>>>
>>> Yes, the fact that Mellanox people sent two different patches to two
>>> different maintainers that did the same thing in two different ways is
>>> odd. Matan and Jiri are cc'd, and I think that whole thing just smells
>>> really bad.
>>
>> It's not that odd. I'm not checking rdma tree. I work with net-next/net
>> tree only when I do net patches. I wasn't aware of Matan's patches,
>> different group.
>>
>
> Indeed, two different groups working on two different product lines.
> That's why I wasn't aware of Jiri's work. This patch (ccing netdev)
> was posted around June. Anyway, Stephen did a really good job merging
> the two versions.
Yep, Stephen reported on the conflict and Jiri acked the way he fixed
that, we were aware of things and didn't think any further action is
needed from our side. Both the mlx4 and mlx5 are stacked driver suites
that have a core and Ethernet drivers developed trough netdev and RDMA
driver that goes through the rdma tree, it's been working like this for
almost ten years, with net-next : rdma-next conflicts happening from
time to time and being solved successfully with Stephen & CO and the
subsystem maintainers. We're happily having now also our switch drivers
joining the party, and things should be OK, as long as the maintainer
-next tree is fully subscribed to linux-next merge tests.
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <20150909064123.GA2122-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
@ 2015-09-09 8:09 ` Matan Barak
[not found] ` <55EFE932.5010401-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Matan Barak @ 2015-09-09 8:09 UTC (permalink / raw)
To: Jiri Pirko, Linus Torvalds
Cc: Doug Ledford, Stephen Rothwell, David Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On 9/9/2015 9:41 AM, Jiri Pirko wrote:
> Wed, Sep 09, 2015 at 05:33:28AM CEST, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
>> On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>> With a comment that said "I can carry this merge forward, no further
>>> action is necessary on your part". That combined with my lack of deep
>>> internal knowledge of what it is that Stephen is doing made me go "Ok,
>>> he says don't do anything, so I won't change it."
>>
>> So quite frankly, Stephen does a really good job at merging and most
>> of his merges are very on point. He's been doing a lot of them as part
>> of linux-next, and has seen more conflicts than just about anybody
>> else.
>>
>> But I think to him it's mostly just an issue of "get the right end
>> result". I don't think he goes: "this merge conflict is a result of a
>> breakdown of the development process".
>>
>> Conversely, to me, one of the main reasons I want to do those merges
>> is exactly because I think conflicts are more about the development
>> process issues than about "just getting the right end result". Yes,
>> obviously I want to get the rigth end result too, but I very much
>> react to how/why the conflict happened in the first place. The end
>> result is _almost_ secondary, although 99% of the time the primary
>> issue doesn't really even raise its head.
>>
>> So I'm upset not because the conflict is hard to resolve (it isn't),
>> but because I feel this was really badly handled.
>>
>> Yes, the fact that Mellanox people sent two different patches to two
>> different maintainers that did the same thing in two different ways is
>> odd. Matan and Jiri are cc'd, and I think that whole thing just smells
>> really bad.
>
> It's not that odd. I'm not checking rdma tree. I work with net-next/net
> tree only when I do net patches. I wasn't aware of Matan's patches,
> different group.
>
Indeed, two different groups working on two different product lines.
That's why I wasn't aware of Jiri's work. This patch (ccing netdev) was
posted around June. Anyway, Stephen did a really good job merging the
two versions.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFwg+QCM=xaoK4ic+4AymqCYrF4Ny8WO9iY2hHFBLNT3VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-09-09 6:41 ` Jiri Pirko
[not found] ` <20150909064123.GA2122-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
2015-09-09 12:03 ` Doug Ledford
1 sibling, 1 reply; 196+ messages in thread
From: Jiri Pirko @ 2015-09-09 6:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Doug Ledford, Matan Barak, Stephen Rothwell, David Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Wed, Sep 09, 2015 at 05:33:28AM CEST, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
>On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> With a comment that said "I can carry this merge forward, no further
>> action is necessary on your part". That combined with my lack of deep
>> internal knowledge of what it is that Stephen is doing made me go "Ok,
>> he says don't do anything, so I won't change it."
>
>So quite frankly, Stephen does a really good job at merging and most
>of his merges are very on point. He's been doing a lot of them as part
>of linux-next, and has seen more conflicts than just about anybody
>else.
>
>But I think to him it's mostly just an issue of "get the right end
>result". I don't think he goes: "this merge conflict is a result of a
>breakdown of the development process".
>
>Conversely, to me, one of the main reasons I want to do those merges
>is exactly because I think conflicts are more about the development
>process issues than about "just getting the right end result". Yes,
>obviously I want to get the rigth end result too, but I very much
>react to how/why the conflict happened in the first place. The end
>result is _almost_ secondary, although 99% of the time the primary
>issue doesn't really even raise its head.
>
>So I'm upset not because the conflict is hard to resolve (it isn't),
>but because I feel this was really badly handled.
>
>Yes, the fact that Mellanox people sent two different patches to two
>different maintainers that did the same thing in two different ways is
>odd. Matan and Jiri are cc'd, and I think that whole thing just smells
>really bad.
It's not that odd. I'm not checking rdma tree. I work with net-next/net
tree only when I do net patches. I wasn't aware of Matan's patches,
different group.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55EFA2BF.7060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-09 3:33 ` Linus Torvalds
[not found] ` <CA+55aFwg+QCM=xaoK4ic+4AymqCYrF4Ny8WO9iY2hHFBLNT3VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 21:45 ` Stephen Rothwell
1 sibling, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 3:33 UTC (permalink / raw)
To: Doug Ledford
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> With a comment that said "I can carry this merge forward, no further
> action is necessary on your part". That combined with my lack of deep
> internal knowledge of what it is that Stephen is doing made me go "Ok,
> he says don't do anything, so I won't change it."
So quite frankly, Stephen does a really good job at merging and most
of his merges are very on point. He's been doing a lot of them as part
of linux-next, and has seen more conflicts than just about anybody
else.
But I think to him it's mostly just an issue of "get the right end
result". I don't think he goes: "this merge conflict is a result of a
breakdown of the development process".
Conversely, to me, one of the main reasons I want to do those merges
is exactly because I think conflicts are more about the development
process issues than about "just getting the right end result". Yes,
obviously I want to get the rigth end result too, but I very much
react to how/why the conflict happened in the first place. The end
result is _almost_ secondary, although 99% of the time the primary
issue doesn't really even raise its head.
So I'm upset not because the conflict is hard to resolve (it isn't),
but because I feel this was really badly handled.
Yes, the fact that Mellanox people sent two different patches to two
different maintainers that did the same thing in two different ways is
odd. Matan and Jiri are cc'd, and I think that whole thing just smells
really bad.
But at the same time, I expect more of maintainers, and I don't see
any sign that David and the networking people were notified about the
_other_ patch to _their_ subsystem.
The fact that you weren't aware of the other patch in the networking
subsystem is kind of to be expected. You're not the network
maintainer, so why would you? But exactly because you're not the
networking maintainer, I would have expected you to check with him
when you apply patches to generic networking code.
This time it conflicted, and I noticed, and I went "this is not how
kernel development is supposed to go".
But say that the other networking patch hadn't even existed: in that
case I *still* shouldn't have gotten a patch to net/core/dev.c from
you without any sign that David had ack'ed it (or at the very least
been notified, even if he hadn't reacted).
See?
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFytfSV5YqzUrZxBjAgnUn72WoJVHnaB14k5MKLkw-YnLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-09-09 3:19 ` Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 3:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]
On 09/08/2015 11:08 PM, Linus Torvalds wrote:
> On Tue, Sep 8, 2015 at 7:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Because the tree isn't buildable, let alone testable, without it.
>
> You're missing the ENTIRE POINT.
>
>> Well, I expected it to be handled without much effort on your part and
>> the existing network infrastructure to be the final version.
>
> There is indeed not much effort - I'd be throwing that commit away
> entirely in favor of the right one.
>
>> Is further explanation necessary, or have I answered your questions?
>
> Further explanation is necessary.
>
> Why did you rebase this thing?
As mentioned in my other email, Stephen is pointing at my github repo.
I had topic branches and a merge branch. There were various fixups that
happened during the devel window, and multiple times I rebased the merge
branch when topic branches had fixes. I made it very clear to people
when I set up the two repos that one was for official use, and one is a
WIP development repo that grants people early access but not a picture
of the final product. I was not aware that Stephen was pointing at my
github repo until this.
> And since you *did* rebase it, why did you still take the broken version?
As I mentioned in my other email, I could have replaced it and I didn't.
I didn't think it mattered, so I didn't.
> Why did you take a different commit than the networking people did in
> the first place?
I wasn't aware of the other one until Stephen notified me.
> Why did two different people at Mellanox write clearly different
> versions of the exact same thing? Don't tell me they didn't talk to
> each other - it's the exact same thing done at around the same time,
> and for the same reasons, just done with entirely different structure
> names and structure contents.
I can't speak to Mellanox's actions.
> Why did you make networking changes without talking to the networking people?
I had no intention of doing so. I had it in my tree, but I wouldn't
have pushed it without the networking people's approval. The
notification from Stephen rendered that approval moot so I didn't pursue
it further.
> The whole thing is one big mystery. And the problem is not how to
> merge this, but why this kind of crap happened, and why something as
> simple as "talk to the networking maintainer" didn't happen.
>
> Linus
>
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55EF9E82.70405-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-09 3:08 ` Linus Torvalds
[not found] ` <CA+55aFytfSV5YqzUrZxBjAgnUn72WoJVHnaB14k5MKLkw-YnLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 3:08 UTC (permalink / raw)
To: Doug Ledford
Cc: Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 8, 2015 at 7:50 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Because the tree isn't buildable, let alone testable, without it.
You're missing the ENTIRE POINT.
> Well, I expected it to be handled without much effort on your part and
> the existing network infrastructure to be the final version.
There is indeed not much effort - I'd be throwing that commit away
entirely in favor of the right one.
> Is further explanation necessary, or have I answered your questions?
Further explanation is necessary.
Why did you rebase this thing?
And since you *did* rebase it, why did you still take the broken version?
Why did you take a different commit than the networking people did in
the first place?
Why did two different people at Mellanox write clearly different
versions of the exact same thing? Don't tell me they didn't talk to
each other - it's the exact same thing done at around the same time,
and for the same reasons, just done with entirely different structure
names and structure contents.
Why did you make networking changes without talking to the networking people?
The whole thing is one big mystery. And the problem is not how to
merge this, but why this kind of crap happened, and why something as
simple as "talk to the networking maintainer" didn't happen.
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFyeLEab0qjNV1+V-mX2ZhExs1z5VtdusgpDnMeNBg-d6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-09-09 3:08 ` Doug Ledford
[not found] ` <55EFA2BF.7060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 3:08 UTC (permalink / raw)
To: Linus Torvalds, Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]
On 09/08/2015 08:35 PM, Linus Torvalds wrote:
> On Tue, Sep 8, 2015 at 5:21 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>> This needs a good explanation, because for now this pull request is dead to me.
>
> Just to clarify: it's really the combination of:
>
> (a) you were told about this
With a comment that said "I can carry this merge forward, no further
action is necessary on your part". That combined with my lack of deep
internal knowledge of what it is that Stephen is doing made me go "Ok,
he says don't do anything, so I won't change it."
> (b) you rebased your commit series after it
Yes. I rebased my tree a bunch of times. I keep two different git
repos. The one on kernel.org and one on github. I rebase the one on
github. I don't rebase the one on kernel.org. I had *thought* that
Stephen had pointed the for-next setup at my kernel.org stuff, but he
evidently has it pointed at my github setup. That's something I need to
address with Stephen.
> (c) you didn't fix it and never even mentioned the issue
Because I thought it was handled.
> that makes me just go "I want to have absolutely nothing to do with
> this disaster area of a pull request".
>
> The conflict itself? Big deal. Conflicts happen. But that patch
> shouldn't have gone through your tree in the first place, and it damn
> well should have had an ack from David or something if it did.
I agree. The entire patch series that this patch came from went through
about v7 during review process. The early versions had the patch mixed
in amongst the others and no Cc: to netdev. I specifically requested
that all of the netdev related patches be sent to netdev (they were),
and I had every intention of making sure that Dave acked the patch.
Until Stephen's setup caught the two identical patches, resolved it in
favor of Dave's tree's patch, rendering the issue moot.
> And the *same* company sent two different patches for the same thing
> to two different submaintainers? WTF guys?
>
> Kernel development isn't a sport where you throw shit on the wall to
> see what sticks.
>
> This could have been done correctly. You could have cc'd David, and
> you could also have just said "sorry, there's a conflict due to me
> taking a different version of a patch that also went through the
> networking tree". Or you could have tried to synchronize to begin
> with, and just used the same version of the patch from day one. Or if
> you had to rebase your patch series (why was that done, anyway?) you
> could just have fixed it to do what the networking tree already did.
>
> So this could have been done so much better in many ways. But none of
> that happened.
>
> Cross-subsystem conflicts do happen, and patches that cross said
> subsystems aren't evil per se. I have lost count of how many conflicts
> I've resolved in just this merge window. I do it all the time. But
> this one made me just go "Eww".
>
> The rebase and the complete lack of communication here just makes me angry.
As mentioned in my previous email, the rebase is because Stephen is
pointing at my github repo and not my k.o repo. The lack of
communication is because I thought it was handled and didn't need to be
flagged additionally.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2015-09-09 0:21 ` Linus Torvalds
2015-09-09 0:35 ` Linus Torvalds
@ 2015-09-09 2:50 ` Doug Ledford
[not found] ` <55EF9E82.70405-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-09 2:50 UTC (permalink / raw)
To: Linus Torvalds, Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On 09/08/2015 08:21 PM, Linus Torvalds wrote:
> On Tue, Sep 8, 2015 at 9:24 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Matan Barak (5):
>> net: Add info for NETDEV_CHANGEUPPER event
>
> Why the hell is this coming in through the infiniband tree? Especially
> with the networking tree having done the same thing differently?
Because the tree isn't buildable, let alone testable, without it.
> I see that Stephen Rothwell reported this almost two weeks ago, and
> informed you.
Yes, and he said he had a merge fixup and that it would carry forward.
I'm not real clear on how Stephen's stuff works, but when I'm told "I
can carry this going forward, no further action is needed on your part",
I took that at face value.
> The commit you send me, though, has been rebased since then, BUT IT
> STILL EXISTS.
Because I still need to be able to test. Originally you had said you
wanted the root of my pull requests to be based on something clean, such
as a known stable rc point or some such. But if I have to pull from
net-next in order to keep working on what I'm working on, that was a
no-no as I understood things. Unfortunately, overlap between the net
tree and the rdma tree is an all too common occurrence and so I'm going
to need to work out a workflow that satisfies all the various parties in
regards to it. Suggestions welcome.
> The commit is wrong, and you knew about it. So tell me, why the hell
> should I pull this shit?
I expected it to get fixed up properly by the merge commit Stephen was
carrying. I haven't seen any good documentation on exactly how his tree
works and what actions I might take and whether they will break it or
keep it from doing what it was supposed to do, but since the fixup was
there and meant to take care of this, I left things as they were. I
supposed I could have rebased and replaced that patch with the one in
Dave's tree. Would that have been preferable?
> Oh, yes, I can fix it in the merge. This is not a "I can't resolve
> this pull request" email. Resolving it in favor of the existing
> networking infrastructure is easy.
>
> This is a "why should I even bother?" email.
Well, I expected it to be handled without much effort on your part and
the existing network infrastructure to be the final version.
> The two different commits have very similar logic, somewhat similar
> names, but the details are different. Both were written by somebody
> with a "mellanox.com" address.
>
> One huge glaring difference is that one of them went through the
> networking maintainer, which matters a great deal since this is a
> networking notifier.
Sure, I agree.
> I did the pull, did most of the resolve, but then decided that I don't
> even want to merge this considering how questionable it was.
>
> This needs a good explanation, because for now this pull request is dead to me.
Is further explanation necessary, or have I answered your questions?
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
2015-09-09 0:21 ` Linus Torvalds
@ 2015-09-09 0:35 ` Linus Torvalds
[not found] ` <CA+55aFyeLEab0qjNV1+V-mX2ZhExs1z5VtdusgpDnMeNBg-d6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 2:50 ` Doug Ledford
1 sibling, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 0:35 UTC (permalink / raw)
To: Doug Ledford, Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 8, 2015 at 5:21 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> This needs a good explanation, because for now this pull request is dead to me.
Just to clarify: it's really the combination of:
(a) you were told about this
(b) you rebased your commit series after it
(c) you didn't fix it and never even mentioned the issue
that makes me just go "I want to have absolutely nothing to do with
this disaster area of a pull request".
The conflict itself? Big deal. Conflicts happen. But that patch
shouldn't have gone through your tree in the first place, and it damn
well should have had an ack from David or something if it did.
And the *same* company sent two different patches for the same thing
to two different submaintainers? WTF guys?
Kernel development isn't a sport where you throw shit on the wall to
see what sticks.
This could have been done correctly. You could have cc'd David, and
you could also have just said "sorry, there's a conflict due to me
taking a different version of a patch that also went through the
networking tree". Or you could have tried to synchronize to begin
with, and just used the same version of the patch from day one. Or if
you had to rebase your patch series (why was that done, anyway?) you
could just have fixed it to do what the networking tree already did.
So this could have been done so much better in many ways. But none of
that happened.
Cross-subsystem conflicts do happen, and patches that cross said
subsystems aren't evil per se. I have lost count of how many conflicts
I've resolved in just this merge window. I do it all the time. But
this one made me just go "Eww".
The rebase and the complete lack of communication here just makes me angry.
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <1441729478-19375-1-git-send-email-dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-09-09 0:21 ` Linus Torvalds
2015-09-09 0:35 ` Linus Torvalds
2015-09-09 2:50 ` Doug Ledford
0 siblings, 2 replies; 196+ messages in thread
From: Linus Torvalds @ 2015-09-09 0:21 UTC (permalink / raw)
To: Doug Ledford, Matan Barak, Stephen Rothwell, David Miller, Jiri Pirko
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 8, 2015 at 9:24 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Matan Barak (5):
> net: Add info for NETDEV_CHANGEUPPER event
Why the hell is this coming in through the infiniband tree? Especially
with the networking tree having done the same thing differently?
I see that Stephen Rothwell reported this almost two weeks ago, and
informed you.
The commit you send me, though, has been rebased since then, BUT IT
STILL EXISTS.
The commit is wrong, and you knew about it. So tell me, why the hell
should I pull this shit?
Oh, yes, I can fix it in the merge. This is not a "I can't resolve
this pull request" email. Resolving it in favor of the existing
networking infrastructure is easy.
This is a "why should I even bother?" email.
The two different commits have very similar logic, somewhat similar
names, but the details are different. Both were written by somebody
with a "mellanox.com" address.
One huge glaring difference is that one of them went through the
networking maintainer, which matters a great deal since this is a
networking notifier.
I did the pull, did most of the resolve, but then decided that I don't
even want to merge this considering how questionable it was.
This needs a good explanation, because for now this pull request is dead to me.
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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-09-08 16:24 Doug Ledford
[not found] ` <1441729478-19375-1-git-send-email-dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-09-08 16:24 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds; +Cc: Doug Ledford
Hi Linus,
This is a fairly sizeable set of changes. I've put them through a
decent amount of testing prior to sending the pull request due to
that. There are still a few fixups that I know are coming, but I
wanted to go ahead and get the big, sizable chunk into your hands
sooner rather than waiting for those last few fixups. Of note is
the fact that this creates what is intended to be a temporary area
in the drivers/staging tree specifically for some cleanups and
additions that are coming for the RDMA stack. We deprecated two
drivers (ipath and amso1100) and are waiting to hear back if we can
deprecate another one (ehca). We also put Intel's new hfi1 driver
into this area because it needs to be refactored and a transfer
library created out of the factored out code, and then it and the
qib driver and the soft-roce driver should all be modified to use
that library. I expect drivers/staging/rdma to be around for
three or four kernel releases and then to go away as all of the
work is completed and final deletions of deprecated drivers are
done.
The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
Linux 4.2-rc8 (2015-08-23 20:52:59 -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 d1178cbcdcf91900ccf10a177350d7945703c151:
IB/ipoib: Suppress warning for send only join failures (2015-09-03 17:11:05 -0400)
----------------------------------------------------------------
Changes for 4.3
- Create drivers/staging/rdma
- Move amso1100 driver to staging/rdma and schedule for deletion
- Move ipath driver to staging/rdma and schedule for deletion
- Add hfi1 driver to staging/rdma and set TODO for move to regular tree
- Initial support for namespaces to be used on RDMA devices
- Add RoCE GID table handling to the RDMA core caching code
- Infrastructure to support handling of devices with differing
read and write scatter gather capabilities
- Various iSER updates
- Kill off unsafe usage of global mr registrations
- Update SRP driver
- Misc. mlx4 driver updates
- Support for the mr_alloc verb
- Support for a netlink interface between kernel and user space cache
daemon to speed path record queries and route resolution
- Ininitial support for safe hot removal of verbs devices
----------------------------------------------------------------
Adir Lev (1):
IB/iser: Maintain connection fmr_pool under a single registration descriptor
Ariel Nahum (1):
IB/mlx4: Fix incorrect cq flushing in error state
Bart Van Assche (12):
IB/srp: Constify a function argument
IB/srp: Handle partial connection success correctly
IB/srp: Bump driver version and release date
IB/srp: Stop the scsi_eh_<n> and scsi_tmf_<n> threads if login fails
IB/srp: Re-enable FMR for non-page aligned buffers
IB/srp: Use multiple registrations for large memory regions
IB/srp: Add memory descriptor array pointer range checking
IB/srp: Remove the memory registration backtracking code
IB/srp: Remove use_mr argument from srp_map_sg_entry()
IB/srp: Introduce srp_device.use_fmr
IB/srp: Register the indirect data buffer descriptor
IB/srp: Create an insecure all physical rkey only if needed
Christoph Hellwig (1):
IB/uverbs: reject invalid or unknown opcodes
Dan Carpenter (1):
IB/core: missing curly braces in ib_find_gid()
Dennis Dalessandro (2):
IB/ipath: Deprecate ipath driver and move to staging.
IB/core: Add core header changes needed for OPA
Doug Ledford (3):
Staging: Add staging/rdma directory and update MAINTAINERS
IB/core: Remove needless bracketization
IB/ipoib: Clean up send-only multicast joins
Guy Shapiro (1):
IB/ipoib: Return IPoIB devices matching connection parameters
Haggai Eran (14):
IB/core: Add rwsem to allow reading device list or client list
IB/core: lock client data with lists_rwsem
IB/cm: Expose service ID in request events
IB/cm: Share listening CM IDs
IB/cma: Refactor RDMA IP CM private-data parsing code
IB/cma: Helper functions to access port space IDRs
IB/cm: Expose BTH P_Key in CM and SIDR request events
IB/cma: Add net_dev and private data checks to RDMA CM
IB/cma: Validate routing of incoming requests
IB/cma: Use found net_dev for passive connections
IB/cma: Share ib_cm_ids between rdma_cm_ids
IB/cm: Remove compare_data checks
IB/cma: Fix net_dev reference leak with failed requests
IB/mlx5: avoid destroying a NULL mr in reg_user_mr error flow
Hariprasad S (2):
iw_cxgb4: set the default MPA version to 2
iw_cxgb4: Add support for clip
Ira Weiny (3):
IB/hfi1: Add PSM2 user space header to header_install
IB/core: Remove unnecessary defines from ib_mad.h
IB/core: Move SM class defines from ib_mad.h to ib_smi.h
Jack Morgenstein (3):
IB/mlx4: Fix potential deadlock when sending mad to wire
IB/mlx4: Demote mcg message from warning to debug
IB/mlx4: Forbid using sysfs to change RoCE pkeys
Jason Gunthorpe (15):
IB/ucma: Fix theoretical user triggered use-after-free
IB/core: Make ib_alloc_device init the kobject
IB/core: Guarantee that a local_dma_lkey is available
IB/mad: Remove ib_get_dma_mr calls
IB/ipoib: Remove ib_get_dma_mr calls
IB/mlx4: Remove ib_get_dma_mr calls
IB/mlx5: Remove ib_get_dma_mr calls
IB/iser: Use pd->local_dma_lkey
iser-target: Remove ib_get_dma_mr calls
IB/srp: Use pd->local_dma_lkey
ib_srpt: Remove ib_get_dma_mr calls
net/9p: Remove ib_get_dma_mr calls
rds/ib: Remove ib_get_dma_mr calls
IB/core: Make ib_dealloc_pd return void
IB/ipoib: Suppress warning for send only join failures
Jeff Becker (1):
staging/hfi1: replace indent spaces with tabs
Jenny Falkovich (1):
IB/iser: Change some module parameters to be RO
Jubin John (1):
IB/hfi1: Add CSRs for CONFIG_SDMA_VERBOSITY
Kaike Wan (5):
IB/netlink: Add defines for local service requests through netlink
IB/core: Add rdma netlink helper functions
IB/sa: Allocate SA query with kzalloc
IB/sa: Route SA pathrecord query through netlink
IB/sa: Fix rdma netlink message flags
Matan Barak (5):
net/ipv6: Export addrconf_ifid_eui48
net: Add info for NETDEV_CHANGEUPPER event
net/bonding: Export bond_option_active_slave_get_rcu
IB/core: Add RoCE GID table management
IB/core: Add RoCE table bonding support
Mike Marciniszyn (3):
IB/qib: Change lkey table allocation to support more MRs
IB/hfi1: add driver files
IB/hfi1: Support ib_alloc_mr verb
Moni Shoua (3):
net/mlx4: Postpone the registration of net_device
IB/mlx4: Implement ib_device callbacks
IB/mlx4: Replace mechanism for RoCE GID management
Nicholas Krause (1):
IB/cxgb4: Fix if statement in pick_local_ip6adddrs
Noa Osherovich (1):
IB/mlx4: Use correct SL on AH query under RoCE
Roland Dreier (1):
IB/mlx5: Remove dead code from alloc_cached_mr()
Sagi Grimberg (40):
mlx5: Fix missing device local_dma_lkey
mlx5: Expose correct page_size_cap in device attributes
mlx4, mlx5, mthca: Expose max_sge_rd correctly
IB/core: Get rid of redundant verb ib_destroy_mr
IB: Modify ib_create_mr API
IB/iser: Convert to ib_alloc_mr
iser-target: Convert to ib_alloc_mr
IB/srp: Convert to ib_alloc_mr
xprtrdma, svcrdma: Convert to ib_alloc_mr
RDS: Convert to ib_alloc_mr
mlx5: Drop mlx5_ib_alloc_fast_reg_mr
mlx4: Support ib_alloc_mr verb
ocrdma: Support ib_alloc_mr verb
iw_cxgb4: Support ib_alloc_mr verb
cxgb3: Support ib_alloc_mr verb
nes: Support ib_alloc_mr verb
qib: Support ib_alloc_mr verb
IB/core: Drop ib_alloc_fast_reg_mr
IB/iser: Change minor assignments and logging prints
IB/iser: Remove '.' from log message
IB/iser: Fix missing return status check in iser_send_data_out
IB/iser: Get rid of un-maintained counters
IB/iser: Fix possible bogus DMA unmapping
IB/iser: Remove a redundant always-false condition
IB/iser: Remove an unneeded print for unaligned memory
IB/iser: Introduce struct iser_reg_resources
IB/iser: Rename struct fast_reg_descriptor -> iser_fr_desc
IB/iser: Remove dead code in fmr_pool alloc/free
IB/iser: Introduce iser_reg_ops
IB/iser: Move fastreg descriptor allocation to iser_create_fastreg_desc
IB/iser: Introduce iser registration pool struct
IB/iser: Rename iser_reg_page_vec to iser_fast_reg_fmr
IB/iser: Make reg_desc_get a per device routine
IB/iser: Unify fast memory registration flows
IB/iser: Pass registration pool a size parameter
IB/iser: Support up to 8MB data transfer in a single command
IB/iser: Add debug prints to the various memory registration methods
IB/iser: Chain all iser transaction send work requests
mlx5: Fix incorrect wc pkey_index assignment for GSI messages
IB/srp: Fix possible protection fault
Somnath Kotur (1):
RDMA/ocrdma: Incorporate the moving of GID Table mgmt to IB/Core
Spencer Baugh (1):
RDMA/cma: fix IPv6 address resolution
Steve Wise (6):
RDMA/iser: Limit sgs to the device fastreg depth
RDMA/amso1100: Deprecate the amso1100 driver and move to staging
ipath,qib: Expose max_sge_rd correctly
svcrdma: Use max_sge_rd for destination read depths
RDMA/Core: remove rdma_cap_read_multi_sge() helper
svcrdma: limit FRMR page list lengths to device max
Yishai Hadas (6):
IB/uverbs: Fix reference counting usage of event files
IB/uverbs: Fix race between ib_uverbs_open and remove_one
IB/uverbs: Explicitly pass ib_dev to uverbs commands
IB/uverbs: Enable device removal when there are active user space applications
IB/mlx4_ib: Disassociate support
IB/ucma: HW Device hot-removal support
Yotam Kenneth (1):
IB/core: Find the network device matching connection parameters
Documentation/infiniband/sysfs.txt | 20 +
MAINTAINERS | 9 +-
drivers/infiniband/Kconfig | 2 -
drivers/infiniband/core/Makefile | 3 +-
drivers/infiniband/core/cache.c | 773 +-
drivers/infiniband/core/cm.c | 215 +-
drivers/infiniband/core/cma.c | 657 +-
drivers/infiniband/core/core_priv.h | 54 +-
drivers/infiniband/core/device.c | 335 +-
drivers/infiniband/core/mad.c | 28 +-
drivers/infiniband/core/mad_priv.h | 1 -
drivers/infiniband/core/multicast.c | 7 +-
drivers/infiniband/core/netlink.c | 55 +
drivers/infiniband/core/roce_gid_mgmt.c | 730 ++
drivers/infiniband/core/sa_query.c | 515 +-
drivers/infiniband/core/sysfs.c | 51 +-
drivers/infiniband/core/ucm.c | 9 +-
drivers/infiniband/core/ucma.c | 146 +-
drivers/infiniband/core/user_mad.c | 6 +-
drivers/infiniband/core/uverbs.h | 16 +-
drivers/infiniband/core/uverbs_cmd.c | 147 +-
drivers/infiniband/core/uverbs_main.c | 448 +-
drivers/infiniband/core/verbs.c | 131 +-
drivers/infiniband/hw/Makefile | 2 -
drivers/infiniband/hw/cxgb3/iwch_provider.c | 14 +-
drivers/infiniband/hw/cxgb4/cm.c | 82 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 4 +-
drivers/infiniband/hw/cxgb4/mem.c | 12 +-
drivers/infiniband/hw/cxgb4/provider.c | 2 +-
drivers/infiniband/hw/mlx4/ah.c | 8 +-
drivers/infiniband/hw/mlx4/cq.c | 2 +-
drivers/infiniband/hw/mlx4/mad.c | 23 +-
drivers/infiniband/hw/mlx4/main.c | 891 +-
drivers/infiniband/hw/mlx4/mcg.c | 15 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 40 +-
drivers/infiniband/hw/mlx4/mr.c | 11 +-
drivers/infiniband/hw/mlx4/qp.c | 10 +-
drivers/infiniband/hw/mlx4/sysfs.c | 5 +-
drivers/infiniband/hw/mlx5/cq.c | 10 +-
drivers/infiniband/hw/mlx5/main.c | 30 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 14 +-
drivers/infiniband/hw/mlx5/mr.c | 124 +-
drivers/infiniband/hw/mlx5/qp.c | 5 -
drivers/infiniband/hw/mthca/mthca_provider.c | 1 +
drivers/infiniband/hw/nes/nes_verbs.c | 19 +-
drivers/infiniband/hw/ocrdma/ocrdma.h | 1 -
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 236 +-
drivers/infiniband/hw/ocrdma/ocrdma_sli.h | 2 +
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 56 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 15 +-
drivers/infiniband/hw/qib/qib_keys.c | 4 +
drivers/infiniband/hw/qib/qib_mad.h | 147 +-
drivers/infiniband/hw/qib/qib_mr.c | 9 +-
drivers/infiniband/hw/qib/qib_ruc.c | 1 +
drivers/infiniband/hw/qib/qib_verbs.c | 17 +-
drivers/infiniband/hw/qib/qib_verbs.h | 6 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 1 -
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 4 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 236 +-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 50 +-
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 22 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 91 +-
drivers/infiniband/ulp/iser/iscsi_iser.h | 206 +-
drivers/infiniband/ulp/iser/iser_initiator.c | 38 +-
drivers/infiniband/ulp/iser/iser_memory.c | 482 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 339 +-
drivers/infiniband/ulp/isert/ib_isert.c | 47 +-
drivers/infiniband/ulp/isert/ib_isert.h | 1 -
drivers/infiniband/ulp/srp/ib_srp.c | 282 +-
drivers/infiniband/ulp/srp/ib_srp.h | 25 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 22 +-
drivers/infiniband/ulp/srpt/ib_srpt.h | 1 -
drivers/net/bonding/bond_options.c | 13 -
drivers/net/ethernet/mellanox/mlx4/en_main.c | 36 +-
drivers/net/ethernet/mellanox/mlx4/intf.c | 3 +
drivers/net/ethernet/mellanox/mlx5/core/fw.c | 22 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/rdma/Kconfig | 31 +
drivers/staging/rdma/Makefile | 4 +
.../hw => staging/rdma}/amso1100/Kbuild | 0
.../hw => staging/rdma}/amso1100/Kconfig | 0
drivers/staging/rdma/amso1100/TODO | 4 +
.../{infiniband/hw => staging/rdma}/amso1100/c2.c | 0
.../{infiniband/hw => staging/rdma}/amso1100/c2.h | 0
.../hw => staging/rdma}/amso1100/c2_ae.c | 0
.../hw => staging/rdma}/amso1100/c2_ae.h | 0
.../hw => staging/rdma}/amso1100/c2_alloc.c | 0
.../hw => staging/rdma}/amso1100/c2_cm.c | 0
.../hw => staging/rdma}/amso1100/c2_cq.c | 0
.../hw => staging/rdma}/amso1100/c2_intr.c | 0
.../hw => staging/rdma}/amso1100/c2_mm.c | 0
.../hw => staging/rdma}/amso1100/c2_mq.c | 0
.../hw => staging/rdma}/amso1100/c2_mq.h | 0
.../hw => staging/rdma}/amso1100/c2_pd.c | 0
.../hw => staging/rdma}/amso1100/c2_provider.c | 0
.../hw => staging/rdma}/amso1100/c2_provider.h | 0
.../hw => staging/rdma}/amso1100/c2_qp.c | 0
.../hw => staging/rdma}/amso1100/c2_rnic.c | 0
.../hw => staging/rdma}/amso1100/c2_status.h | 0
.../hw => staging/rdma}/amso1100/c2_user.h | 0
.../hw => staging/rdma}/amso1100/c2_vq.c | 0
.../hw => staging/rdma}/amso1100/c2_vq.h | 0
.../hw => staging/rdma}/amso1100/c2_wr.h | 0
drivers/staging/rdma/hfi1/Kconfig | 37 +
drivers/staging/rdma/hfi1/Makefile | 19 +
drivers/staging/rdma/hfi1/TODO | 6 +
drivers/staging/rdma/hfi1/chip.c | 10798 +++++++++++++++++++
drivers/staging/rdma/hfi1/chip.h | 1035 ++
drivers/staging/rdma/hfi1/chip_registers.h | 1292 +++
drivers/staging/rdma/hfi1/common.h | 415 +
drivers/staging/rdma/hfi1/cq.c | 558 +
drivers/staging/rdma/hfi1/debugfs.c | 899 ++
drivers/staging/rdma/hfi1/debugfs.h | 78 +
drivers/staging/rdma/hfi1/device.c | 142 +
drivers/staging/rdma/hfi1/device.h | 61 +
drivers/staging/rdma/hfi1/diag.c | 1873 ++++
drivers/staging/rdma/hfi1/dma.c | 186 +
drivers/staging/rdma/hfi1/driver.c | 1241 +++
drivers/staging/rdma/hfi1/eprom.c | 475 +
drivers/staging/rdma/hfi1/eprom.h | 55 +
drivers/staging/rdma/hfi1/file_ops.c | 2140 ++++
drivers/staging/rdma/hfi1/firmware.c | 1620 +++
drivers/staging/rdma/hfi1/hfi.h | 1821 ++++
drivers/staging/rdma/hfi1/init.c | 1722 +++
drivers/staging/rdma/hfi1/intr.c | 207 +
drivers/staging/rdma/hfi1/iowait.h | 186 +
drivers/staging/rdma/hfi1/keys.c | 411 +
drivers/staging/rdma/hfi1/mad.c | 4257 ++++++++
drivers/staging/rdma/hfi1/mad.h | 325 +
drivers/staging/rdma/hfi1/mmap.c | 192 +
drivers/staging/rdma/hfi1/mr.c | 551 +
drivers/staging/rdma/hfi1/opa_compat.h | 129 +
drivers/staging/rdma/hfi1/pcie.c | 1253 +++
drivers/staging/rdma/hfi1/pio.c | 1771 +++
drivers/staging/rdma/hfi1/pio.h | 224 +
drivers/staging/rdma/hfi1/pio_copy.c | 858 ++
drivers/staging/rdma/hfi1/platform_config.h | 286 +
drivers/staging/rdma/hfi1/qp.c | 1687 +++
drivers/staging/rdma/hfi1/qp.h | 235 +
drivers/staging/rdma/hfi1/qsfp.c | 546 +
drivers/staging/rdma/hfi1/qsfp.h | 222 +
drivers/staging/rdma/hfi1/rc.c | 2426 +++++
drivers/staging/rdma/hfi1/ruc.c | 948 ++
drivers/staging/rdma/hfi1/sdma.c | 2962 +++++
drivers/staging/rdma/hfi1/sdma.h | 1123 ++
drivers/staging/rdma/hfi1/srq.c | 397 +
drivers/staging/rdma/hfi1/sysfs.c | 739 ++
drivers/staging/rdma/hfi1/trace.c | 221 +
drivers/staging/rdma/hfi1/trace.h | 1409 +++
drivers/staging/rdma/hfi1/twsi.c | 518 +
drivers/staging/rdma/hfi1/twsi.h | 68 +
drivers/staging/rdma/hfi1/uc.c | 585 +
drivers/staging/rdma/hfi1/ud.c | 885 ++
drivers/staging/rdma/hfi1/user_pages.c | 156 +
drivers/staging/rdma/hfi1/user_sdma.c | 1444 +++
drivers/staging/rdma/hfi1/user_sdma.h | 89 +
drivers/staging/rdma/hfi1/verbs.c | 2143 ++++
drivers/staging/rdma/hfi1/verbs.h | 1151 ++
drivers/staging/rdma/hfi1/verbs_mcast.c | 385 +
.../{infiniband/hw => staging/rdma}/ipath/Kconfig | 4 +-
.../{infiniband/hw => staging/rdma}/ipath/Makefile | 0
drivers/staging/rdma/ipath/TODO | 5 +
.../hw => staging/rdma}/ipath/ipath_common.h | 0
.../hw => staging/rdma}/ipath/ipath_cq.c | 0
.../hw => staging/rdma}/ipath/ipath_debug.h | 0
.../hw => staging/rdma}/ipath/ipath_diag.c | 0
.../hw => staging/rdma}/ipath/ipath_dma.c | 0
.../hw => staging/rdma}/ipath/ipath_driver.c | 0
.../hw => staging/rdma}/ipath/ipath_eeprom.c | 0
.../hw => staging/rdma}/ipath/ipath_file_ops.c | 0
.../hw => staging/rdma}/ipath/ipath_fs.c | 0
.../hw => staging/rdma}/ipath/ipath_iba6110.c | 0
.../hw => staging/rdma}/ipath/ipath_init_chip.c | 0
.../hw => staging/rdma}/ipath/ipath_intr.c | 0
.../hw => staging/rdma}/ipath/ipath_kernel.h | 0
.../hw => staging/rdma}/ipath/ipath_keys.c | 0
.../hw => staging/rdma}/ipath/ipath_mad.c | 0
.../hw => staging/rdma}/ipath/ipath_mmap.c | 0
.../hw => staging/rdma}/ipath/ipath_mr.c | 0
.../hw => staging/rdma}/ipath/ipath_qp.c | 0
.../hw => staging/rdma}/ipath/ipath_rc.c | 0
.../hw => staging/rdma}/ipath/ipath_registers.h | 0
.../hw => staging/rdma}/ipath/ipath_ruc.c | 0
.../hw => staging/rdma}/ipath/ipath_sdma.c | 0
.../hw => staging/rdma}/ipath/ipath_srq.c | 0
.../hw => staging/rdma}/ipath/ipath_stats.c | 0
.../hw => staging/rdma}/ipath/ipath_sysfs.c | 0
.../hw => staging/rdma}/ipath/ipath_uc.c | 0
.../hw => staging/rdma}/ipath/ipath_ud.c | 0
.../hw => staging/rdma}/ipath/ipath_user_pages.c | 0
.../hw => staging/rdma}/ipath/ipath_user_sdma.c | 0
.../hw => staging/rdma}/ipath/ipath_user_sdma.h | 0
.../hw => staging/rdma}/ipath/ipath_verbs.c | 1 +
.../hw => staging/rdma}/ipath/ipath_verbs.h | 0
.../hw => staging/rdma}/ipath/ipath_verbs_mcast.c | 0
.../hw => staging/rdma}/ipath/ipath_wc_ppc64.c | 0
.../hw => staging/rdma}/ipath/ipath_wc_x86_64.c | 0
include/linux/mlx4/device.h | 3 +-
include/linux/mlx4/driver.h | 1 +
include/linux/mlx5/device.h | 11 +
include/linux/mlx5/driver.h | 1 +
include/linux/netdevice.h | 14 +
include/linux/sunrpc/svc_rdma.h | 1 +
include/net/addrconf.h | 31 +
include/net/bonding.h | 7 +
include/rdma/ib_cm.h | 25 +-
include/rdma/ib_mad.h | 82 +-
include/rdma/ib_pack.h | 2 +
include/rdma/ib_smi.h | 47 +
include/rdma/ib_verbs.h | 203 +-
include/rdma/opa_port_info.h | 433 +
include/rdma/opa_smi.h | 47 +
include/rdma/rdma_netlink.h | 7 +
include/uapi/rdma/Kbuild | 1 +
include/uapi/rdma/hfi/Kbuild | 2 +
include/uapi/rdma/hfi/hfi1_user.h | 427 +
include/uapi/rdma/rdma_netlink.h | 82 +
net/9p/trans_rdma.c | 26 +-
net/core/dev.c | 12 +-
net/ipv6/addrconf.c | 31 -
net/rds/ib.c | 13 +-
net/rds/ib.h | 2 -
net/rds/ib_cm.c | 4 +-
net/rds/ib_recv.c | 6 +-
net/rds/ib_send.c | 8 +-
net/rds/iw.c | 10 +-
net/rds/iw_rdma.c | 5 +-
net/rds/iw_send.c | 5 +-
net/sunrpc/xprtrdma/frwr_ops.c | 6 +-
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 12 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 10 +-
net/sunrpc/xprtrdma/verbs.c | 2 +-
233 files changed, 64457 insertions(+), 2733 deletions(-)
create mode 100644 drivers/infiniband/core/roce_gid_mgmt.c
create mode 100644 drivers/staging/rdma/Kconfig
create mode 100644 drivers/staging/rdma/Makefile
rename drivers/{infiniband/hw => staging/rdma}/amso1100/Kbuild (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/Kconfig (100%)
create mode 100644 drivers/staging/rdma/amso1100/TODO
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_ae.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_ae.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_alloc.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_cm.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_cq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_intr.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_mm.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_mq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_mq.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_pd.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_provider.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_provider.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_qp.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_rnic.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_status.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_user.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_vq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_vq.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/amso1100/c2_wr.h (100%)
create mode 100644 drivers/staging/rdma/hfi1/Kconfig
create mode 100644 drivers/staging/rdma/hfi1/Makefile
create mode 100644 drivers/staging/rdma/hfi1/TODO
create mode 100644 drivers/staging/rdma/hfi1/chip.c
create mode 100644 drivers/staging/rdma/hfi1/chip.h
create mode 100644 drivers/staging/rdma/hfi1/chip_registers.h
create mode 100644 drivers/staging/rdma/hfi1/common.h
create mode 100644 drivers/staging/rdma/hfi1/cq.c
create mode 100644 drivers/staging/rdma/hfi1/debugfs.c
create mode 100644 drivers/staging/rdma/hfi1/debugfs.h
create mode 100644 drivers/staging/rdma/hfi1/device.c
create mode 100644 drivers/staging/rdma/hfi1/device.h
create mode 100644 drivers/staging/rdma/hfi1/diag.c
create mode 100644 drivers/staging/rdma/hfi1/dma.c
create mode 100644 drivers/staging/rdma/hfi1/driver.c
create mode 100644 drivers/staging/rdma/hfi1/eprom.c
create mode 100644 drivers/staging/rdma/hfi1/eprom.h
create mode 100644 drivers/staging/rdma/hfi1/file_ops.c
create mode 100644 drivers/staging/rdma/hfi1/firmware.c
create mode 100644 drivers/staging/rdma/hfi1/hfi.h
create mode 100644 drivers/staging/rdma/hfi1/init.c
create mode 100644 drivers/staging/rdma/hfi1/intr.c
create mode 100644 drivers/staging/rdma/hfi1/iowait.h
create mode 100644 drivers/staging/rdma/hfi1/keys.c
create mode 100644 drivers/staging/rdma/hfi1/mad.c
create mode 100644 drivers/staging/rdma/hfi1/mad.h
create mode 100644 drivers/staging/rdma/hfi1/mmap.c
create mode 100644 drivers/staging/rdma/hfi1/mr.c
create mode 100644 drivers/staging/rdma/hfi1/opa_compat.h
create mode 100644 drivers/staging/rdma/hfi1/pcie.c
create mode 100644 drivers/staging/rdma/hfi1/pio.c
create mode 100644 drivers/staging/rdma/hfi1/pio.h
create mode 100644 drivers/staging/rdma/hfi1/pio_copy.c
create mode 100644 drivers/staging/rdma/hfi1/platform_config.h
create mode 100644 drivers/staging/rdma/hfi1/qp.c
create mode 100644 drivers/staging/rdma/hfi1/qp.h
create mode 100644 drivers/staging/rdma/hfi1/qsfp.c
create mode 100644 drivers/staging/rdma/hfi1/qsfp.h
create mode 100644 drivers/staging/rdma/hfi1/rc.c
create mode 100644 drivers/staging/rdma/hfi1/ruc.c
create mode 100644 drivers/staging/rdma/hfi1/sdma.c
create mode 100644 drivers/staging/rdma/hfi1/sdma.h
create mode 100644 drivers/staging/rdma/hfi1/srq.c
create mode 100644 drivers/staging/rdma/hfi1/sysfs.c
create mode 100644 drivers/staging/rdma/hfi1/trace.c
create mode 100644 drivers/staging/rdma/hfi1/trace.h
create mode 100644 drivers/staging/rdma/hfi1/twsi.c
create mode 100644 drivers/staging/rdma/hfi1/twsi.h
create mode 100644 drivers/staging/rdma/hfi1/uc.c
create mode 100644 drivers/staging/rdma/hfi1/ud.c
create mode 100644 drivers/staging/rdma/hfi1/user_pages.c
create mode 100644 drivers/staging/rdma/hfi1/user_sdma.c
create mode 100644 drivers/staging/rdma/hfi1/user_sdma.h
create mode 100644 drivers/staging/rdma/hfi1/verbs.c
create mode 100644 drivers/staging/rdma/hfi1/verbs.h
create mode 100644 drivers/staging/rdma/hfi1/verbs_mcast.c
rename drivers/{infiniband/hw => staging/rdma}/ipath/Kconfig (81%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/Makefile (100%)
create mode 100644 drivers/staging/rdma/ipath/TODO
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_common.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_cq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_debug.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_diag.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_dma.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_driver.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_eeprom.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_file_ops.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_fs.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_iba6110.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_init_chip.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_intr.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_kernel.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_keys.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_mad.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_mmap.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_mr.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_qp.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_rc.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_registers.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_ruc.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_sdma.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_srq.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_stats.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_sysfs.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_uc.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_ud.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_user_pages.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_user_sdma.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_user_sdma.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_verbs.c (99%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_verbs.h (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_verbs_mcast.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_wc_ppc64.c (100%)
rename drivers/{infiniband/hw => staging/rdma}/ipath/ipath_wc_x86_64.c (100%)
create mode 100644 include/rdma/opa_port_info.h
create mode 100644 include/uapi/rdma/hfi/Kbuild
create mode 100644 include/uapi/rdma/hfi/hfi1_user.h
--
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] 196+ messages in thread
* [PULL REQUEST] please pull rdma.git
@ 2015-08-17 22:00 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-08-17 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rdma
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
Hi Linus,
I have a single bug fix for you to pull:
The following changes since commit b8f5595eb96c9fce1c907d13e89581e5061edf2e:
RDMA/ocrdma: update ocrdma module license string (2015-07-24 11:34:41 -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 3661df179bfbd1bb21cf2c782d3c5c084ebe3cf4:
iw_cxgb4: gracefully handle unknown CQE status errors (2015-07-28 11:24:51 -0400)
----------------------------------------------------------------
Changes for 4.2-rc
- Bugfix in iw_cxgb4
----------------------------------------------------------------
Hariprasad S (1):
iw_cxgb4: gracefully handle unknown CQE status errors
drivers/infiniband/hw/cxgb4/cq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
—
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-07-28 14:37 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-07-28 14:37 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]
The following changes since commit d8b2ba7c5928173fe1c12bd2545f5ed85d1c3c7a:
IB/core: Destroy ocrdma_dev_id IDR on module exit (2015-07-14 13:20: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 b8f5595eb96c9fce1c907d13e89581e5061edf2e:
RDMA/ocrdma: update ocrdma module license string (2015-07-24 11:34:41
-0400)
----------------------------------------------------------------
Changes for 4.2-rc
- Two minor bug fixes
- Relicense ocrdma driver to dual license, GPL or BSD
----------------------------------------------------------------
Devesh Sharma (2):
RDMA/ocrdma: update ocrdma license to dual-license
RDMA/ocrdma: update ocrdma module license string
Jason Gunthorpe (1):
IB/ipoib: Fix CONFIG_INFINIBAND_IPOIB_CM
Steve Wise (1):
RDMA/cxgb3: fail get_dma_mr on 64 bit arches
drivers/infiniband/hw/cxgb3/iwch_provider.c | 4 +++
drivers/infiniband/hw/ocrdma/ocrdma.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_abi.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_ah.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_hw.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 55
++++++++++++++++++-----------
drivers/infiniband/hw/ocrdma/ocrdma_sli.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_stats.h | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 53
+++++++++++++++++----------
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 53
+++++++++++++++++----------
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 3 +-
14 files changed, 415 insertions(+), 230 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] 196+ messages in thread
* RE: [PULL REQUEST] Please pull rdma.git
[not found] ` <20150716140157.GA27586-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2015-07-16 14:47 ` Suri Shelvapille
0 siblings, 0 replies; 196+ messages in thread
From: Suri Shelvapille @ 2015-07-16 14:47 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Hal Rosenstock, Doug Ledford, Linus Torvalds, linux-rdma
Christoph:
Is that a requirement? Because, we have a lot of proprietary things that is tied to our FPGA that is in the driver and to rip all of that to make it more consumable to the community would be another effort that we don't have resources for.
Please let me know.
Thanks,
Suri
-----Original Message-----
From: Christoph Hellwig [mailto:hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org]
Sent: Thursday, July 16, 2015 10:02 AM
To: Suri Shelvapille
Cc: Hal Rosenstock; Doug Ledford; Christoph Hellwig; Linus Torvalds; linux-rdma
Subject: Re: [PULL REQUEST] Please pull rdma.git
On Thu, Jul 16, 2015 at 01:59:37PM +0000, Suri Shelvapille wrote:
> Thanks Hal, we indeed do. And we would like to continue to do so, be it by setting a flag or otherwise. I hope removing that functionality from the kernel is not an option, as it would be a major inconvenience for us.
Hi Suri,
how about you submit the driver to the kernel tree?
This correspondence, and any attachments or files transmitted with this correspondence, contains information which may be confidential and privileged and is intended solely for the use of the addressee. Unless you are the addressee or are authorized to receive messages for the addressee, you may not use, copy, disseminate, or disclose this correspondence or any information contained in this correspondence to any third party. If you have received this correspondence in error, please notify the sender immediately and delete this correspondence and any attachments or files transmitted with this correspondence from your system, and destroy any and all copies thereof, electronic or otherwise. Your cooperation and understanding are greatly appreciated.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CY1PR03MB14409F7C639ADF21A2AD782FDE990-DUcFgbLRNhB/HYnSB+xpdWP7xZHs9kq/vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2015-07-16 14:01 ` Christoph Hellwig
[not found] ` <20150716140157.GA27586-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Christoph Hellwig @ 2015-07-16 14:01 UTC (permalink / raw)
To: Suri Shelvapille
Cc: Hal Rosenstock, Doug Ledford, Christoph Hellwig, Linus Torvalds,
linux-rdma
On Thu, Jul 16, 2015 at 01:59:37PM +0000, Suri Shelvapille wrote:
> Thanks Hal, we indeed do. And we would like to continue to do so, be it by setting a flag or otherwise. I hope removing that functionality from the kernel is not an option, as it would be a major inconvenience for us.
Hi Suri,
how about you submit the driver to the kernel tree?
--
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] 196+ messages in thread
* RE: [PULL REQUEST] Please pull rdma.git
[not found] ` <55A7B02C.6080009-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2015-07-16 13:59 ` Suri Shelvapille
[not found] ` <CY1PR03MB14409F7C639ADF21A2AD782FDE990-DUcFgbLRNhB/HYnSB+xpdWP7xZHs9kq/vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Suri Shelvapille @ 2015-07-16 13:59 UTC (permalink / raw)
To: Hal Rosenstock, Doug Ledford
Cc: Christoph Hellwig, Linus Torvalds, linux-rdma
Thanks Hal, we indeed do. And we would like to continue to do so, be it by setting a flag or otherwise. I hope removing that functionality from the kernel is not an option, as it would be a major inconvenience for us.
Thanks,
Suri
-----Original Message-----
From: Hal Rosenstock [mailto:hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org]
Sent: Thursday, July 16, 2015 9:23 AM
To: Doug Ledford
Cc: Christoph Hellwig; Linus Torvalds; linux-rdma; Suri Shelvapille
Subject: Re: [PULL REQUEST] Please pull rdma.git
On 7/16/2015 8:50 AM, Doug Ledford wrote:
> On 07/16/2015 08:45 AM, Christoph Hellwig wrote:
>> Hi Doug,
>>
>> the point is that there is no driver that even set the is_switch flag
>> in-tree and I can't find a publicly available one elsewhere either.
>
> Try looking on Mellanox.com for their source code. I know they use
> upstream linux kernels as the base for their switch OS and in their
> switch-X driver it should set this flag.
>
> However, this is a point that I don't really care about, but I
> inherited (and I know other people care about).
There are 2 vendors that I'm aware of that use linux for their embedded IB switch platforms: Mellanox and Bay Microsystems and there may be others.
Mellanox has switch drivers for the various different switch ICs that have been used over time (InfiniScale IV, SwitchX/SwitchX-2, and most Switch-IB).
-- Hal
This correspondence, and any attachments or files transmitted with this correspondence, contains information which may be confidential and privileged and is intended solely for the use of the addressee. Unless you are the addressee or are authorized to receive messages for the addressee, you may not use, copy, disseminate, or disclose this correspondence or any information contained in this correspondence to any third party. If you have received this correspondence in error, please notify the sender immediately and delete this correspondence and any attachments or files transmitted with this correspondence from your system, and destroy any and all copies thereof, electronic or otherwise. Your cooperation and understanding are greatly appreciated.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55A7A878.1090704-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-07-16 13:22 ` Hal Rosenstock
[not found] ` <55A7B02C.6080009-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Hal Rosenstock @ 2015-07-16 13:22 UTC (permalink / raw)
To: Doug Ledford
Cc: Christoph Hellwig, Linus Torvalds, linux-rdma, Suresh Shelvapille
On 7/16/2015 8:50 AM, Doug Ledford wrote:
> On 07/16/2015 08:45 AM, Christoph Hellwig wrote:
>> Hi Doug,
>>
>> the point is that there is no driver that even set the is_switch
>> flag in-tree and I can't find a publicly available one elsewhere
>> either.
>
> Try looking on Mellanox.com for their source code. I know they use
> upstream linux kernels as the base for their switch OS and in their
> switch-X driver it should set this flag.
>
> However, this is a point that I don't really care about, but I inherited
> (and I know other people care about).
There are 2 vendors that I'm aware of that use linux for their embedded
IB switch platforms: Mellanox and Bay Microsystems and there may be others.
Mellanox has switch drivers for the various different switch ICs that
have been used over time (InfiniScale IV, SwitchX/SwitchX-2, and most
Switch-IB).
-- Hal
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <20150716124507.GA5943-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2015-07-16 12:50 ` Doug Ledford
[not found] ` <55A7A878.1090704-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-07-16 12:50 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
On 07/16/2015 08:45 AM, Christoph Hellwig wrote:
> Hi Doug,
>
> the point is that there is no driver that even set the is_switch
> flag in-tree and I can't find a publicly available one elsewhere
> either.
Try looking on Mellanox.com for their source code. I know they use
upstream linux kernels as the base for their switch OS and in their
switch-X driver it should set this flag.
However, this is a point that I don't really care about, but I inherited
(and I know other people care about). This code has supported switches
via out-of-tree drivers since as long as I know. That was an early
decision that Roland made. Removing this code is more than just
removing this code, it is reversing that decision.
> So it's plain and simple dead code. I'll send a patch to kill this
> untestable code off once I find a little spare time.
> --
> 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
>
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55A7A6CD.4080900-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-07-16 12:45 ` Christoph Hellwig
[not found] ` <20150716124507.GA5943-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Christoph Hellwig @ 2015-07-16 12:45 UTC (permalink / raw)
To: Doug Ledford; +Cc: Christoph Hellwig, Linus Torvalds, linux-rdma
Hi Doug,
the point is that there is no driver that even set the is_switch
flag in-tree and I can't find a publicly available one elsewhere
either.
So it's plain and simple dead code. I'll send a patch to kill this
untestable code off once I find a little spare time.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <20150716075542.GA9093-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2015-07-16 12:42 ` Doug Ledford
[not found] ` <55A7A6CD.4080900-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-07-16 12:42 UTC (permalink / raw)
To: Christoph Hellwig, Linus Torvalds; +Cc: linux-rdma
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
On 07/16/2015 03:55 AM, Christoph Hellwig wrote:
> On Wed, Jul 15, 2015 at 05:07:46PM -0700, Linus Torvalds wrote:
>> Hmm. I've pulled this, but quite frankly, I don't think this was
>> appropriate for post-merge-window. It's not at all obvious that that
>> "rdma_cap_ib_switch helper" thing is a bugfix, and that goes for a few
>> of the other commits too. Some of them are _clearly_ not actual
>> bug-fixes, but just random commits.
>
> rdma_cap_ib_switch isn't even a bug fix, it clearly adds (or shuffles)
> dead code..
>
In the 4.2 merge window we added the code that mostly eliminated our
reliance on node_type as anything of value (instead of checking
node_type + link_layer to determine if certain features were supported,
we added a bitmap of the features themselves and now check that bitmap).
Then I went on PTO for several weeks during the merge window. While I
was gone, the rdma_cap_ib_switch helper patch was discussed and written
on the mailing list. When I got back (which was just before the first
rc), it took me a bit of time to get all of the appropriate patches
pulled together and submitted. I included that code because it was the
last remnant of node_type still in use, was a use that the original
patchset didn't address, and taking it allowed us to go from using
node_type to not using node_type at all in one kernel version instead of
going from using node_type, to using node_type for switches only, to not
using node_type at all across a series of two kernels.
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <CA+55aFzdE94JcGT3aF0+rp-ym6UdMCAcQD2LSCBeedv9dLRfhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-07-16 7:55 ` Christoph Hellwig
[not found] ` <20150716075542.GA9093-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Christoph Hellwig @ 2015-07-16 7:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Doug Ledford, linux-rdma
On Wed, Jul 15, 2015 at 05:07:46PM -0700, Linus Torvalds wrote:
> Hmm. I've pulled this, but quite frankly, I don't think this was
> appropriate for post-merge-window. It's not at all obvious that that
> "rdma_cap_ib_switch helper" thing is a bugfix, and that goes for a few
> of the other commits too. Some of them are _clearly_ not actual
> bug-fixes, but just random commits.
rdma_cap_ib_switch isn't even a bug fix, it clearly adds (or shuffles)
dead code..
--
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] 196+ messages in thread
* Re: [PULL REQUEST] Please pull rdma.git
[not found] ` <55A56640.2000206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2015-07-16 0:07 ` Linus Torvalds
[not found] ` <CA+55aFzdE94JcGT3aF0+rp-ym6UdMCAcQD2LSCBeedv9dLRfhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Linus Torvalds @ 2015-07-16 0:07 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma
On Tue, Jul 14, 2015 at 12:42 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> This comprises a number of various fixes (including the ones you've
> requested):
Hmm. I've pulled this, but quite frankly, I don't think this was
appropriate for post-merge-window. It's not at all obvious that that
"rdma_cap_ib_switch helper" thing is a bugfix, and that goes for a few
of the other commits too. Some of them are _clearly_ not actual
bug-fixes, but just random commits.
If this is going to be a pattern, I'm going to stop pulling things.
But as a one-off, I let it pass.
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] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-07-14 19:42 Doug Ledford
[not found] ` <55A56640.2000206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 196+ messages in thread
From: Doug Ledford @ 2015-07-14 19:42 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1: Type: text/plain, Size: 4568 bytes --]
Hi Linus,
This comprises a number of various fixes (including the ones you've
requested):
The following changes since commit bc197aad0daa:
Linux 4.2-rc2 (2015-07-12 15:10:30 -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 d8b2ba7c5928173fe1c12bd2545f5ed85d1c3c7a:
IB/core: Destroy ocrdma_dev_id IDR on module exit (2015-07-14 13:20:16
-0400)
----------------------------------------------------------------
Changes for 4.2-rc
- Mainly fix-ups for the various 4.2 items
----------------------------------------------------------------
Amir Vadai (1):
IB/IPoIB: Fix bad error flow in ipoib_add_port()
Carol L Soto (1):
IB/ucm: Fix bitmap wrap when devnum > IB_UCM_MAX_DEVICES
Doug Ledford (2):
IB/mlx4: Fix memory leak in do_slave_init
IB/mlx4: Optimize do_slave_init
Erez Shitrit (2):
IB/cm: Do not queue work to a device that's going away
IB/ipoib: Set MTU to max allowed by mode when mode changes
Haggai Eran (2):
IB/ucma: Fix lockdep warning in ucma_lock_files
IB/ipoib: Prevent lockdep warning in __ipoib_ib_dev_flush
Hal Rosenstock (1):
IB: Add rdma_cap_ib_switch helper and use where appropriate
Ira Weiny (2):
IB/mad: Fix compare between big endian and cpu endian
IB/mad: Remove improper use of BUG_ON
Johannes Thumshirn (2):
IB/core: Destroy multcast_idr on module exit
IB/core: Destroy ocrdma_dev_id IDR on module exit
Maninder Singh (1):
IB/mlx4: Optimize freeing of items on error unwind
Matan Barak (1):
IB/mlx4: Do not attemp to report HCA clock offset on VFs
Or Gerlitz (1):
IB/mlx4: Fix use of flow-counters for process_mad
Sagi Grimberg (1):
IB/srp: Avoid using uninitialized variable
Tatyana Nikolova (3):
RDMA/core: Fixes for port mapper client registration
RDMA/nes: Fix for resolving the neigh
RDMA/nes: Fix for incorrect recording of the MAC address
Vaishali Thakkar (2):
IB/srpt: Convert use of __constant_cpu_to_beXX to cpu_to_beXX
IB/ipath: Convert use of __constant_<foo> to <foo>
Wengang Wang (1):
rds: rds_ib_device.refcount overflow
Yuval Shaia (1):
IB/ipoib: Scatter-Gather support in connected mode
drivers/infiniband/core/agent.c | 4 +-
drivers/infiniband/core/cm.c | 61 ++++++++++++++++++++++---
drivers/infiniband/core/iwpm_msg.c | 33 +++++++-------
drivers/infiniband/core/iwpm_util.c | 12 ++++-
drivers/infiniband/core/iwpm_util.h | 28 +++++++++---
drivers/infiniband/core/mad.c | 47 +++++++-------------
drivers/infiniband/core/multicast.c | 8 +---
drivers/infiniband/core/opa_smi.h | 4 +-
drivers/infiniband/core/sa_query.c | 8 +---
drivers/infiniband/core/smi.c | 37 ++++++++--------
drivers/infiniband/core/smi.h | 4 +-
drivers/infiniband/core/sysfs.c | 2 +-
drivers/infiniband/core/ucm.c | 4 +-
drivers/infiniband/core/ucma.c | 5 ++-
drivers/infiniband/hw/ehca/ehca_sqp.c | 5 ++-
drivers/infiniband/hw/ipath/ipath_mad.c | 5 ++-
drivers/infiniband/hw/ipath/ipath_verbs.c | 4 +-
drivers/infiniband/hw/mlx4/mad.c | 34 +++++++++-----
drivers/infiniband/hw/mlx4/main.c | 33 +++++++-------
drivers/infiniband/hw/mlx5/mad.c | 5 ++-
drivers/infiniband/hw/mthca/mthca_mad.c | 5 ++-
drivers/infiniband/hw/nes/nes_cm.c | 5 ++-
drivers/infiniband/hw/nes/nes_hw.c | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 ++-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 1 +
drivers/infiniband/hw/qib/qib_mad.c | 5 ++-
drivers/infiniband/ulp/ipoib/ipoib.h | 29 +++++++++++-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 33 ++++++--------
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 49 ++++++++-------------
drivers/infiniband/ulp/ipoib/ipoib_main.c | 21 ++++-----
drivers/infiniband/ulp/srp/ib_srp.c | 23 +++-------
drivers/infiniband/ulp/srpt/ib_srpt.c | 71
+++++++++++++++---------------
drivers/scsi/scsi_transport_srp.c | 3 +-
include/rdma/ib_verbs.h | 20 +++++++--
include/scsi/scsi_transport_srp.h | 1 +
net/rds/ib_rdma.c | 4 +-
36 files changed, 351 insertions(+), 269 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-06-22 15:43 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-06-22 15:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rdma
[-- Attachment #1: Type: text/plain, Size: 13773 bytes --]
Hi Linus,
The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:
Linux 4.1-rc4 (2015-05-18 10:13:47 -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 8e4349d13f3365273d2ff17667b36f7e846df912:
IB/mad: Add final OPA MAD processing (2015-06-12 14:49:18 -0400)
----------------------------------------------------------------
Changes for 4.2
- A large cleanup of how device capabilities are checked for various
features
- Additional cleanups in the MAD processing
- Update to the srp driver
- Creation and use of centralized log message helpers
- Add const to a number of args to calls and clean up call chain
- Add support for extended cq create verb
- Add support for timestamps on cq completion
- Add support for processing OPA MAD packets
----------------------------------------------------------------
Bart Van Assche (13):
scsi_transport_srp: Introduce srp_wait_for_queuecommand()
scsi_transport_srp: Fix a race condition
IB/srp: Remove an extraneous scsi_host_put() from an error path
IB/srp: Fix a connection setup race
IB/srp: Fix connection state tracking
IB/srp: Fix reconnection failure handling
scsi_transport_srp: Reduce failover time
IB/srp: Remove superfluous casts
IB/srp: Rearrange module description
IB/srp: Remove a superfluous check from srp_free_req_data()
IB/srp: Remove !ch->target tests from the reconnect code
IB/srp: Add 64-bit LUN support
IB/ipoib: Fix RCU annotations in ipoib_neigh_hash_init()
Colin Ian King (1):
RDMA/ocrdma: fix double free on pd
Dan Carpenter (1):
IB/usnic: clean up some error handling code
Doug Ledford (3):
Merge branches 'bart-srp', 'generic-errors', 'ira-cleanups' and 'mwang-v8' into k.o/for-4.2
Merge branch 'for-4.2-misc' into k.o/for-4.2
Merge branch 'for-4.2-misc' into k.o/for-4.2
Fabian Frederick (1):
IB/mthca: use swap() in mthca_make_profile()
Faisal Latif (1):
RDMA/nes: Enable the use of the tos field in the nes driver
Hariprasad S (2):
cxgb4: Support for user mode bar2 mappings with T4
iw_cxgb4: support for bar2 qid densities exceeding the page size
Ira Weiny (29):
IB/core: Create common start/end port functions
IB/mad: Rename is_data_mad to is_rmpp_data_mad
IB/mad: Clean up comments in smi.c
IB/mad: Change validate_mad signature arguments
IB/mad: Change ib_response_mad signature arguments
IB/mad: Clean up rcv_has_same_class
IB/mad: Add const qualifiers to query only functions
IB/user_mad: Use new start/end port functions
IB/user_mad: Fix buggy usage of port index
IB/core: Add per port immutable struct to ib_device
IB/core: Convert core to use bitfield for caps
IB/core: Change rdma_protocol_iboe to roce
IB/core cleanup: Add const to RDMA helpers
IB/core cleanup: Add const on args - device->process_mad
IB/core cleanup: Add const to args - agent_send_response
IB/mad cleanup: Clean up function params -- find_mad_agent
IB/mad cleanup: Generalize processing of MAD data
IB/mad: Split IB SMI handling from MAD Recv handler
IB/mad: Create a generic helper for DR SMP Send processing
IB/mad: Create a generic helper for DR SMP Recv processing
IB/mad: Create a generic helper for DR forwarding checks
IB/mad: Support alternate Base Versions when creating MADs
IB/core: Add ability for drivers to report an alternate MAD size.
IB/mad: Convert allocations from kmem_cache to kzalloc
IB/mad: Add support for additional MAD info to/from drivers
IB/core: Add OPA MAD core capability flag
IB/mad: Add partial Intel OPA MAD support
IB/mad: Add partial Intel OPA MAD support
IB/mad: Add final OPA MAD processing
Matan Barak (8):
IB/core: Change provider's API of create_cq to be extendible
IB/core: Change ib_create_cq to use struct ib_cq_init_attr
IB/core: Add CQ creation time-stamping flag
IB/core: Extend ib_uverbs_create_cq
IB/core: Add timestamp_mask and hca_core_clock to query_device
IB/core: Pass hardware specific data in query_device
IB/mlx4: Add mmap call to map the hardware clock
IB/mlx4: Add support for CQ time-stamping
Michael Wang (24):
IB/Verbs: Implement new callback query_protocol()
IB/Verbs: Implement raw management helpers
IB/Verbs: Reform IB-core mad/agent/user_mad
IB/Verbs: Reform IB-core cm
IB/Verbs: Reform IB-core sa_query
IB/Verbs: Reform IB-core multicast
IB/Verbs: Reform IB-ulp ipoib
IB/Verbs: Reform IB-ulp xprtrdma
IB/Verbs: Reform IB-core verbs
IB/Verbs: Reform cm related part in IB-core cma/ucm
IB/Verbs: Reform route related part in IB-core cma
IB/Verbs: Reform mcast related part in IB-core cma
IB/Verbs: Reform cma_acquire_dev()
IB/Verbs: Reform rest part in IB-core cma
IB/Verbs: Use management helper rdma_cap_ib_mad()
IB/Verbs: Use management helper rdma_cap_ib_smi()
IB/Verbs: Use management helper rdma_cap_ib_cm()
IB/Verbs: Use management helper rdma_cap_iw_cm()
IB/Verbs: Use management helper rdma_cap_ib_sa()
IB/Verbs: Use management helper rdma_cap_ib_mcast()
IB/Verbs: Use management helper rdma_cap_read_multi_sge()
IB/Verbs: Use management helper rdma_cap_af_ib()
IB/Verbs: Use management helper rdma_cap_eth_ah()
IB/Verbs: Improve docs for rdma-helpers
Moni Shoua (2):
IB/core: Don't advertise SA in RoCE port capabilities
IB/core: Don't warn on no SA support in event handler
Roland Dreier (2):
RDMA/ocrdma: Fix memory leak in _ocrdma_alloc_pd()
IB/mlx4: Fix error paths in mlx4_ib_create_flow()
Sagi Grimberg (6):
IB/core, cma: Nice log-friendly string helpers
IB/srp: Align to generic logging helpers
IB/iser: Align to generic logging helpers
iser-target: Align to generic logging helpers
xprtrdma, svcrdma: Switch to generic logging helpers
RDS: Switch to generic logging helpers
Steve Wise (1):
RDMA/iw_cm: Export tos field to iwarp providers
Wengang Wang (1):
rds: re-entry of rds_ib_xmit/rds_iw_xmit
drivers/infiniband/core/addr.c | 4 +-
drivers/infiniband/core/agent.c | 23 +-
drivers/infiniband/core/agent.h | 6 +-
drivers/infiniband/core/cache.c | 69 +--
drivers/infiniband/core/cm.c | 26 +-
drivers/infiniband/core/cma.c | 287 +++++----
drivers/infiniband/core/device.c | 96 ++--
drivers/infiniband/core/mad.c | 639 ++++++++++++++-------
drivers/infiniband/core/mad_priv.h | 15 +-
drivers/infiniband/core/mad_rmpp.c | 33 +-
drivers/infiniband/core/multicast.c | 12 +-
drivers/infiniband/core/opa_smi.h | 78 +++
drivers/infiniband/core/sa_query.c | 33 +-
drivers/infiniband/core/smi.c | 228 +++++---
drivers/infiniband/core/sysfs.c | 8 +-
drivers/infiniband/core/ucm.c | 3 +-
drivers/infiniband/core/ucma.c | 25 +-
drivers/infiniband/core/user_mad.c | 64 ++-
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_cmd.c | 188 ++++--
drivers/infiniband/core/uverbs_main.c | 1 +
drivers/infiniband/core/verbs.c | 85 ++-
drivers/infiniband/hw/amso1100/c2_provider.c | 42 +-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 47 +-
drivers/infiniband/hw/cxgb4/cq.c | 31 +-
drivers/infiniband/hw/cxgb4/device.c | 16 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 13 +-
drivers/infiniband/hw/cxgb4/provider.c | 36 +-
drivers/infiniband/hw/cxgb4/qp.c | 64 ++-
drivers/infiniband/hw/cxgb4/t4.h | 60 +-
drivers/infiniband/hw/ehca/ehca_cq.c | 7 +-
drivers/infiniband/hw/ehca/ehca_hca.c | 6 +-
drivers/infiniband/hw/ehca/ehca_iverbs.h | 16 +-
drivers/infiniband/hw/ehca/ehca_main.c | 25 +-
drivers/infiniband/hw/ehca/ehca_sqp.c | 21 +-
drivers/infiniband/hw/ipath/ipath_cq.c | 9 +-
drivers/infiniband/hw/ipath/ipath_mad.c | 15 +-
drivers/infiniband/hw/ipath/ipath_verbs.c | 26 +-
drivers/infiniband/hw/ipath/ipath_verbs.h | 11 +-
drivers/infiniband/hw/mlx4/cq.c | 13 +-
drivers/infiniband/hw/mlx4/mad.c | 36 +-
drivers/infiniband/hw/mlx4/main.c | 95 ++-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 29 +-
drivers/infiniband/hw/mlx5/cq.c | 10 +-
drivers/infiniband/hw/mlx5/mad.c | 15 +-
drivers/infiniband/hw/mlx5/main.c | 37 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 15 +-
drivers/infiniband/hw/mthca/mthca_cmd.c | 4 +-
drivers/infiniband/hw/mthca/mthca_cmd.h | 4 +-
drivers/infiniband/hw/mthca/mthca_dev.h | 9 +-
drivers/infiniband/hw/mthca/mthca_mad.c | 21 +-
drivers/infiniband/hw/mthca/mthca_profile.c | 8 +-
drivers/infiniband/hw/mthca/mthca_provider.c | 34 +-
drivers/infiniband/hw/nes/nes_cm.c | 7 +
drivers/infiniband/hw/nes/nes_cm.h | 2 +
drivers/infiniband/hw/nes/nes_verbs.c | 41 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 13 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.h | 8 +-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 20 +
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 21 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 12 +-
drivers/infiniband/hw/qib/qib_cq.c | 11 +-
drivers/infiniband/hw/qib/qib_iba7322.c | 3 +-
drivers/infiniband/hw/qib/qib_mad.c | 20 +-
drivers/infiniband/hw/qib/qib_verbs.c | 25 +-
drivers/infiniband/hw/qib/qib_verbs.h | 11 +-
drivers/infiniband/hw/usnic/usnic_ib_main.c | 17 +
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 16 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 12 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 7 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 19 +-
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 8 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 33 +-
drivers/infiniband/ulp/isert/ib_isert.c | 24 +-
drivers/infiniband/ulp/srp/ib_srp.c | 146 +++--
drivers/infiniband/ulp/srp/ib_srp.h | 3 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 7 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/sge.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 7 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 19 +
drivers/net/ethernet/mellanox/mlx5/core/mad.c | 2 +-
drivers/scsi/ibmvscsi/ibmvscsi.c | 6 +-
drivers/scsi/scsi_transport_srp.c | 67 ++-
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 6 +-
include/linux/mlx4/device.h | 9 +
include/linux/mlx5/driver.h | 2 +-
include/rdma/ib_addr.h | 6 +-
include/rdma/ib_cache.h | 8 +-
include/rdma/ib_mad.h | 41 +-
include/rdma/ib_verbs.h | 394 ++++++++++++-
include/rdma/iw_cm.h | 1 +
include/rdma/opa_smi.h | 106 ++++
include/rdma/rdma_cm.h | 2 +
include/scsi/srp.h | 7 +-
include/uapi/rdma/ib_user_verbs.h | 19 +
net/9p/trans_rdma.c | 4 +-
net/rds/af_rds.c | 9 -
net/rds/ib.h | 1 -
net/rds/ib_cm.c | 43 +-
net/rds/ib_recv.c | 4 +-
net/rds/ib_send.c | 55 +-
net/rds/iw_cm.c | 7 +-
net/rds/iw_send.c | 18 +-
net/rds/rdma_transport.c | 34 +-
net/rds/rds.h | 3 +-
net/sunrpc/xprtrdma/frwr_ops.c | 4 +-
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 4 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 83 ++-
net/sunrpc/xprtrdma/verbs.c | 99 +---
112 files changed, 2901 insertions(+), 1364 deletions(-)
create mode 100644 drivers/infiniband/core/opa_smi.h
create mode 100644 include/rdma/opa_smi.h
—
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-05-20 22:35 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-05-20 22:35 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]
Hi Linus,
This should hopefully be the last request for 4.1-rc for the RDMA stack.
It contains some late ocrdma fixes that I'm including because they are
small and self contained. It also contains two bug fixes that are
simple and easily verified.
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git tags/for-linus
----------------------------------------------------------------
Changes for 4.1-rc4
A number of small, well contained bug fixes for ocrdma driver
A simple fix for the connection negotiation sequence on IB
Fix for broken AF_IB address on UD queue pair support
----------------------------------------------------------------
Devesh Sharma (3):
RDMA/ocrdma: Report EQ full fatal error
RDMA/ocrdma: Fix QP state transition in destroy_qp
RDMA/ocrdma: Use VID 0 if PFC is enabled and vlan is not configured
Matthew Finlay (1):
IB/cma: Fix broken AF_IB UD support
Mitesh Ahuja (3):
RDMA/ocrdma: Fix the request length for RDMA_QUERY_QP mailbox command to FW.
RDMA/ocrdma: Prevent allocation of DPP PDs if FW doesnt support it
RDMA/ocrdma: Fix dmac resolution for link local address
Naga Irrinki (1):
RDMA/ocrdma: Fail connection for MTU lesser than 512
Selvin Xavier (2):
RDMA/ocrdma: Fix EQ destroy failure during driver unload
RDMA/ocrdma: Update ocrdma version number
Ted Kim (1):
ib/cm: Change reject message type when destroying cm_id
drivers/infiniband/core/cm.c | 2 +-
drivers/infiniband/core/cma.c | 32 +++++++----
drivers/infiniband/hw/ocrdma/ocrdma.h | 4 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 12 ++++-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 83 +++++++++++++++++------------
drivers/infiniband/hw/ocrdma/ocrdma_sli.h | 9 ++++
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 +++--
7 files changed, 101 insertions(+), 53 deletions(-)
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PULL REQUEST] Please pull rdma.git
@ 2015-05-12 20:24 Doug Ledford
0 siblings, 0 replies; 196+ messages in thread
From: Doug Ledford @ 2015-05-12 20:24 UTC (permalink / raw)
To: Torvalds, Linus; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
Hi Linus,
Please pull these -rc fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
tags/for-linus
----------------------------------------------------------------
Changes for 4.1-rc3
Update MAINTAINERS git repo pointer
printk garbage fix
Fix for qib and iw_cxgb4 bugs introduced in 4.1 window
Fix for an older iWARP netlink bug
Fix a memcpy issue in ehca driver
----------------------------------------------------------------
Doug Ledford (1):
MAINTAINERS: update the official rdma git repo
Joe Perches (1):
infiniband: Remove duplicated KERN_<LEVEL> from pr_<level> uses
Mike Marciniszyn (1):
IB/qib: fix test of unsigned variable
Nicholas Mc Guire (1):
IB/ehca: use correct destination for memcpy
Steve Wise (1):
iw_cxgb4: use wildcard mapping for getting remote addr info
Tatyana Nikolova (1):
RDMA/core: Fix for parsing netlink string attribute
MAINTAINERS | 2 +-
drivers/infiniband/core/iwpm_msg.c | 2 +-
drivers/infiniband/hw/cxgb4/cm.c | 16 ++++++++--------
drivers/infiniband/hw/cxgb4/device.c | 4 ++--
drivers/infiniband/hw/ehca/ehca_mcast.c | 4 ++--
drivers/infiniband/hw/mlx4/main.c | 3 +--
drivers/infiniband/hw/mlx5/qp.c | 2 +-
drivers/infiniband/hw/qib/qib.h | 2 +-
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 3 ++-
9 files changed, 19 insertions(+), 19 deletions(-)
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
end of thread, other threads:[~2019-12-16 2:27 UTC | newest]
Thread overview: 196+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-14 14:59 [PULL REQUEST] Please pull rdma.git Doug Ledford
2019-08-14 18:25 ` pr-tracker-bot
2019-08-19 10:08 ` Geert Uytterhoeven
2019-08-19 12:14 ` Jason Gunthorpe
2019-08-19 12:29 ` Geert Uytterhoeven
2019-08-19 12:48 ` Jason Gunthorpe
-- strict thread matches above, loose matches on Subject: below --
2019-12-15 21:57 Doug Ledford
2019-12-16 2:27 ` Doug Ledford
2019-08-30 15:42 Doug Ledford
2019-08-30 16:40 ` pr-tracker-bot
[not found] <5b0aa103f6007e1887f9b2cacaec8015834589b8.camel@xsintricity.com>
2019-08-23 19:14 ` Doug Ledford
2019-08-23 23:24 ` Doug Ledford
2019-08-02 14:39 Doug Ledford
2019-08-02 22:10 ` pr-tracker-bot
2019-06-21 19:42 Doug Ledford
2019-06-21 22:35 ` pr-tracker-bot
2018-12-13 16:56 Doug Ledford
2018-12-13 21:15 ` pr-tracker-bot
2018-02-06 0:31 Doug Ledford
2017-11-16 21:39 Doug Ledford
[not found] ` <1510868362.8751.14.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-11-17 0:03 ` Jason Gunthorpe
2017-11-15 16:01 Doug Ledford
2017-10-26 18:05 Doug Ledford
2017-10-06 17:25 Doug Ledford
2017-09-28 16:06 Doug Ledford
2017-09-22 21:12 Doug Ledford
[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>
2017-09-23 14:25 ` Doug Ledford
[not found] ` <1506176753.120853.65.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-09-23 15:50 ` Linus Torvalds
2017-08-31 13:42 Doug Ledford
2017-08-24 21:21 Doug Ledford
2017-08-18 18:21 Doug Ledford
2017-08-08 17:27 Doug Ledford
2017-07-21 12:16 Doug Ledford
[not found] ` <1500639364.23761.22.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-21 12:25 ` Doug Ledford
2017-07-18 15:51 Doug Ledford
[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>
2017-07-18 19:07 ` Doug Ledford
[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>
2017-07-19 3:42 ` Robert LeBlanc
[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>
2017-07-19 20:40 ` Bart Van Assche
[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>
2017-07-19 22:56 ` Doug Ledford
2017-07-21 22:27 ` Robert LeBlanc
2017-07-19 17:46 ` Doug Ledford
2017-07-06 13:56 Doug Ledford
[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
2017-06-16 2:09 Doug Ledford
2017-06-02 20:09 Doug Ledford
2017-05-08 19:43 Doug Ledford
[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>
2017-05-09 14:23 ` Doug Ledford
2017-05-03 15:17 Doug Ledford
2017-03-25 18:29 Doug Ledford
[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>
2017-03-26 13:50 ` Doug Ledford
[not found] ` <1490536239.2404.80.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-26 14:45 ` Doug Ledford
2017-02-24 19:29 Doug Ledford
2017-02-23 17:54 Doug Ledford
2017-02-22 20:51 Doug Ledford
[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>
2017-02-23 16:39 ` Linus Torvalds
[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>
2017-02-23 17:53 ` Linus Torvalds
[not found] ` <CA+55aFzzLKu2SVQ0NG0ixpVftbD_SaK0h9MTrAyHFiaERS524A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-23 17:57 ` Doug Ledford
2017-02-10 19:42 Doug Ledford
2017-01-27 19:52 Doug Ledford
2017-01-04 13:36 Yuval Shaia
2016-12-22 21:40 Doug Ledford
2016-12-15 16:49 Doug Ledford
[not found] ` <ac96de9c-391b-70df-4c9d-d65d7dc28263-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-12-15 20:18 ` Linus Torvalds
2016-11-17 12:13 Doug Ledford
[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>
2016-11-17 19:44 ` Doug Ledford
[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>
2016-11-17 22:24 ` Or Gerlitz
[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>
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>
2016-11-20 12:53 ` Leon Romanovsky
2016-10-04 13:50 Doug Ledford
2016-09-16 20:19 Doug Ledford
2016-09-06 18:09 Doug Ledford
2016-08-25 19:29 Doug Ledford
[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>
2016-08-26 16:12 ` Doug Ledford
[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>
2016-08-26 17:53 ` Doug Ledford
[not found] ` <a4e3d830-71e5-76b1-927d-4e3b52a19ac5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-26 19:19 ` Leon Romanovsky
2016-08-04 16:21 Doug Ledford
2016-07-14 13:45 Doug Ledford
2016-06-24 23:12 Doug Ledford
2016-06-09 16:32 Doug Ledford
2016-05-26 22:34 Doug Ledford
[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>
2016-05-27 11:44 ` Dennis Dalessandro
[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>
2016-05-27 13:32 ` Doug Ledford
[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>
2016-05-27 15:14 ` Doug Ledford
2016-05-20 20:03 Doug Ledford
2016-05-06 20:11 Doug Ledford
2016-04-29 3:05 Doug Ledford
2016-04-06 18:23 Doug Ledford
2016-03-22 20:50 Doug Ledford
[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>
2016-03-23 1:46 ` Doug Ledford
[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>
2016-03-24 15:23 ` Doug Ledford
[not found] ` <56F4068F.2070608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-28 9:42 ` Or Gerlitz
2016-03-17 17:31 Doug Ledford
[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>
2016-03-18 17:37 ` Leon Romanovsky
[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>
2016-03-20 5:59 ` Leon Romanovsky
2016-03-23 10:57 ` Leon Romanovsky
[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>
2016-03-23 13:56 ` Leon Romanovsky
2016-03-31 23:38 ` Leon Romanovsky
[not found] ` <20160331233828.GE2670-2ukJVAZIZ/Y@public.gmane.org>
2016-04-01 2:18 ` David Miller
2016-04-01 2:46 ` Leon Romanovsky
2016-03-18 18:17 ` Doug Ledford
2016-03-04 17:04 Doug Ledford
2016-02-21 1:14 Doug Ledford
2016-02-14 1:23 Doug Ledford
2016-02-10 22:34 Doug Ledford
2016-02-03 20:24 Doug Ledford
2016-01-22 18:18 Doug Ledford
[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>
2016-01-23 5:01 ` Doug Ledford
[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>
2016-01-23 15:06 ` Christoph Lameter
2016-01-23 16:16 ` Doug Ledford
[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>
2016-01-23 22:27 ` Doug Ledford
[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>
2016-01-24 1:26 ` Doug Ledford
[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 2:52 ` Linus Torvalds
[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>
2016-01-24 3:13 ` Linus Torvalds
[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>
2016-01-24 23:18 ` Or Gerlitz
2016-01-24 14:27 ` Doug Ledford
2016-01-24 16:19 ` Or Gerlitz
[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>
2016-01-24 22:13 ` Or Gerlitz
[not found] ` <CAJ3xEMhPj3jsXD5qBrJYLyf2LsB1c5UwzQsb=+HMGuvQqTK9ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-25 1:05 ` Linus Torvalds
2016-01-24 5:58 ` David Miller
[not found] ` <CA+55aFw_-C5ek_bfw-2p=u38Ez5TN9=B_iBraUTF6jUQc2hSkQ@mail.gmail.com>
[not found] ` <CA+55aFw_-C5ek_bfw-2p=u38Ez5TN9=B_iBraUTF6jUQc2hSkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-24 7:28 ` David Miller
2015-12-28 21:43 Doug Ledford
2015-12-10 21:00 Doug Ledford
2015-11-07 6:35 Doug Ledford
2015-10-22 14:34 Doug Ledford
2015-10-14 19:08 Doug Ledford
2015-09-29 18:04 Doug Ledford
2015-09-18 16:01 Doug Ledford
2015-09-16 15:00 Doug Ledford
2015-09-08 16:24 Doug Ledford
[not found] ` <1441729478-19375-1-git-send-email-dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 0:21 ` Linus Torvalds
2015-09-09 0:35 ` Linus Torvalds
[not found] ` <CA+55aFyeLEab0qjNV1+V-mX2ZhExs1z5VtdusgpDnMeNBg-d6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 3:08 ` Doug Ledford
[not found] ` <55EFA2BF.7060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 3:33 ` Linus Torvalds
[not found] ` <CA+55aFwg+QCM=xaoK4ic+4AymqCYrF4Ny8WO9iY2hHFBLNT3VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 6:41 ` Jiri Pirko
[not found] ` <20150909064123.GA2122-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
2015-09-09 8:09 ` Matan Barak
[not found] ` <55EFE932.5010401-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-09-09 11:05 ` Or Gerlitz
2015-09-09 12:03 ` Doug Ledford
[not found] ` <55F02006.5020504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 15:44 ` Linus Torvalds
[not found] ` <CA+55aFxJovuBGpg04YM0AvrzL_TPDoHebkP21R7tO3=QMQUUXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 16:06 ` Doug Ledford
2015-09-09 16:10 ` Linus Torvalds
[not found] ` <CA+55aFwCwT-K_Qw3aQBXt_HbQX6v4d4EXHb3dJVCkD3kg83gzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 16:11 ` Doug Ledford
[not found] ` <55F05A2F.9090005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-10 16:35 ` Matan Barak
2015-09-09 21:45 ` Stephen Rothwell
[not found] ` <20150910074505.1b4eec1c-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2015-09-09 22:32 ` Doug Ledford
[not found] ` <55F0B371.2090403-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 23:20 ` Stephen Rothwell
2015-09-09 2:50 ` Doug Ledford
[not found] ` <55EF9E82.70405-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-09 3:08 ` Linus Torvalds
[not found] ` <CA+55aFytfSV5YqzUrZxBjAgnUn72WoJVHnaB14k5MKLkw-YnLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 3:19 ` Doug Ledford
2015-08-17 22:00 [PULL REQUEST] please " Doug Ledford
2015-07-28 14:37 [PULL REQUEST] Please " Doug Ledford
2015-07-14 19:42 Doug Ledford
[not found] ` <55A56640.2000206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-16 0:07 ` Linus Torvalds
[not found] ` <CA+55aFzdE94JcGT3aF0+rp-ym6UdMCAcQD2LSCBeedv9dLRfhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-16 7:55 ` Christoph Hellwig
[not found] ` <20150716075542.GA9093-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-07-16 12:42 ` Doug Ledford
[not found] ` <55A7A6CD.4080900-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-16 12:45 ` Christoph Hellwig
[not found] ` <20150716124507.GA5943-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-07-16 12:50 ` Doug Ledford
[not found] ` <55A7A878.1090704-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-16 13:22 ` Hal Rosenstock
[not found] ` <55A7B02C.6080009-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-07-16 13:59 ` Suri Shelvapille
[not found] ` <CY1PR03MB14409F7C639ADF21A2AD782FDE990-DUcFgbLRNhB/HYnSB+xpdWP7xZHs9kq/vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2015-07-16 14:01 ` Christoph Hellwig
[not found] ` <20150716140157.GA27586-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-07-16 14:47 ` Suri Shelvapille
2015-06-22 15:43 Doug Ledford
2015-05-20 22:35 Doug Ledford
2015-05-12 20:24 Doug Ledford
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).