[PATCH] rdma: Add Jason as a co-maintainer

[PATCH] rdma: Add Jason as a co-maintainer

[Jason Gunthorpe]

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

As was discussed in September and October, add Jason along with
Doug to have a team maintainership model for the RDMA subystem.

Mellanox Technologies will be funding Jason's independent work on
the maintainership.

Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
---
 .mailmap    | 2 ++
 MAINTAINERS | 1 +
 2 files changed, 3 insertions(+)

My updated PGP key with the new email addresses is in the key servers
and available here:

 http://www.ziepe.ca/pgp/jgunthorpe.gpg

diff --git a/.mailmap b/.mailmap
index c021f29779a7a1..1469ff0d3f4d55 100644
--- a/.mailmap
+++ b/.mailmap
@@ -73,6 +73,8 @@ James E Wilson <wilson@specifix.com>
 James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
 James Hogan <jhogan@kernel.org> <james@albanarts.com>
 James Ketrenos <jketreno@io.(none)>
+Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
+Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
 Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
 <javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
 Jean Tourrilhes <jt@hpl.hp.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f9c4f3fc9419d..d4e621e350f2cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6827,6 +6827,7 @@ F:	drivers/ipack/
 
 INFINIBAND SUBSYSTEM
 M:	Doug Ledford <dledford@redhat.com>
+M:	Jason Gunthorpe <jgg@mellanox.com>
 L:	linux-rdma@vger.kernel.org
 W:	http://www.openfabrics.org/
 Q:	http://patchwork.kernel.org/project/linux-rdma/list/
-- 
2.7.4


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Leon Romanovsky]

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

On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote:
> As was discussed in September and October, add Jason along with
> Doug to have a team maintainership model for the RDMA subystem.
>
> Mellanox Technologies will be funding Jason's independent work on
> the maintainership.
>
> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> ---
>  .mailmap    | 2 ++
>  MAINTAINERS | 1 +
>  2 files changed, 3 insertions(+)
>
> My updated PGP key with the new email addresses is in the key servers
> and available here:
>
>  http://www.ziepe.ca/pgp/jgunthorpe.gpg
>
> diff --git a/.mailmap b/.mailmap
> index c021f29779a7a1..1469ff0d3f4d55 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -73,6 +73,8 @@ James E Wilson <wilson@specifix.com>
>  James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
>  James Hogan <jhogan@kernel.org> <james@albanarts.com>
>  James Ketrenos <jketreno@io.(none)>
> +Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
> +Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
>  Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
>  <javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
>  Jean Tourrilhes <jt@hpl.hp.com>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f9c4f3fc9419d..d4e621e350f2cf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6827,6 +6827,7 @@ F:	drivers/ipack/
>
>  INFINIBAND SUBSYSTEM
>  M:	Doug Ledford <dledford@redhat.com>
> +M:	Jason Gunthorpe <jgg@mellanox.com>


Jason,

I want to warn that you will have hard to use your @mellanox.com address
for any external to Mellanox communication, because of questionable IT
innovation - they rewrite links in all coming emails.

It will make your replies looking very bad and it will be unreadable for the people
who are using plain text readers to read emails.

The example of it, you can see here [1].

We (top Mellanox upstreamers) tried to fight for it for the more than half a year,
and gave up - using my external email for everything.

Thanks

[1] https://marc.info/?l=linux-rdma&m=151077009200628&w=2


>  L:	linux-rdma@vger.kernel.org
>  W:	http://www.openfabrics.org/
>  Q:	http://patchwork.kernel.org/project/linux-rdma/list/
> --
> 2.7.4
>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Bart Van Assche]

On Thu, 2017-11-16 at 13:44 -0700, Jason Gunthorpe wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f9c4f3fc9419d..d4e621e350f2cf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6827,6 +6827,7 @@ F:	drivers/ipack/
>  
>  INFINIBAND SUBSYSTEM
>  M:	Doug Ledford <dledford@redhat.com>
> +M:	Jason Gunthorpe <jgg@mellanox.com>
>  L:	linux-rdma@vger.kernel.org
>  W:	http://www.openfabrics.org/
>  Q:	http://patchwork.kernel.org/project/linux-rdma/list/

Hello Doug and Jason,

Thanks Doug for having added a co-maintainer. Jason, thank you for willing
to be a co-maintainer.

Jason, if you are going to send pull requests to Linus you should be aware
of the following:
* Linus trusts pull requests from a kernel.org repository more than pull
  requests from a repository outside kernel.org (e.g. github). Any requests
  to pull from e.g. github must be PGP-signed.
* If you send an e-mail to Wu Fengguang then he will add a branch from your
  repository to his zero-day testing. This is a great way to catch build
  failures before linux-next catches these.
* Any patches that will be sent to Linus must have been in the for-next
  repository for at least a few days. Requests to add a branch to linux-next
  should be sent to Stephen Rothwell with linux-next in Cc.
* Maintainers are expected to keep an eye on merge conflicts and other reports
  sent out to the linux-next mailing list
  (http://vger.kernel.org/vger-lists.html#linux-next).
* Rebasing a tree that will be sent to Linus is completely inacceptable. A
  quote from Linus: "And in general, you simply should never rebase commits
  that have already been publicized." Source: Linus Torvalds, Re: linux-next:
  Signed-off-by missing for commit in the drivers-x86 tree, linux-next mailing
  list, 2 August 2017 (https://www.spinics.net/lists/kernel/msg2571584.html).
* Backmerging (merging a later rc into a maintainer tree) to pull in rc fixes
  from other maintainers is considered inacceptable too. If patches from other
  maintainers are really needed I think it is acceptable to merge a maintainer
  tree into Linus' tree and to apply late rc patches on top of that merged
  tree.

See also https://lwn.net/Articles/328436/.

Best regards,

Bart.

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Jason Gunthorpe]

On Fri, Nov 17, 2017 at 05:54:34PM +0000, Bart Van Assche wrote:
> Thanks Doug for having added a co-maintainer. Jason, thank you for willing
> to be a co-maintainer.

Thank you Bart!

> Jason, if you are going to send pull requests to Linus you should be aware
> of the following:

I think we will work up to that, obviously I will be working with Doug
and his expertise and experience will guide what happens.

A new git tree has been setup for RDMA:

  https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/

This will replace Doug's personal k.o tree effective immediately as
the cannonical source for the RDMA work in progress.

Both Doug and I have write privileges to this tree.

> * Linus trusts pull requests from a kernel.org repository more than pull
>   requests from a repository outside kernel.org (e.g. github). Any requests
>   to pull from e.g. github must be PGP-signed.

Done

> * If you send an e-mail to Wu Fengguang then he will add a branch from your
>   repository to his zero-day testing. This is a great way to catch build
>   failures before linux-next catches these.

Thanks

> * Any patches that will be sent to Linus must have been in the for-next
>   repository for at least a few days. Requests to add a branch to linux-next
>   should be sent to Stephen Rothwell with linux-next in Cc.

Doug will send Stephen Rothwell a note to move his for-next pull for
RDMA from Doug's personal directory to:

git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git

Branch k.o/for-next

> * Maintainers are expected to keep an eye on merge conflicts and other reports
>   sent out to the linux-next mailing list
>   (http://vger.kernel.org/vger-lists.html#linux-next).

Good advice..

> * Rebasing a tree that will be sent to Linus is completely inacceptable. A
>   quote from Linus: "And in general, you simply should never rebase commits
>   that have already been publicized." Source: Linus Torvalds, Re: linux-next:
>   Signed-off-by missing for commit in the drivers-x86 tree, linux-next mailing
>   list, 2 August 2017 (https://www.spinics.net/lists/kernel/msg2571584.html).

Yes, of course

> * Backmerging (merging a later rc into a maintainer tree) to pull in rc fixes
>   from other maintainers is considered inacceptable too. If patches from other
>   maintainers are really needed I think it is acceptable to merge a maintainer
>   tree into Linus' tree and to apply late rc patches on top of that merged
>   tree.

Yes, this gets tricky if two trees have to coordinate..

Jason

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Doug Ledford]

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

On Fri, 2017-11-17 at 11:14 -0700, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 05:54:34PM +0000, Bart Van Assche wrote:
> > 
> > * If you send an e-mail to Wu Fengguang then he will add a branch from your
> >   repository to his zero-day testing. This is a great way to catch build
> >   failures before linux-next catches these.
> 
> Thanks

On that point...I have my github repo tied into the 0day infrastructure,
not the official repo.  I do that because I've publicly announced that
my github repo is a WIP repo, and that it might be rebased.  That allows
me to correct build issues by fixing up the broken patch and thereby
keep bisectability at its highest.  If you use a branch/tag on k.o for
your 0day testing, then fixes have to be incremental and depending on
which patch broke the build, there might be a significant segment of
code that is no longer bisectable.

> > * Any patches that will be sent to Linus must have been in the for-next
> >   repository for at least a few days. Requests to add a branch to linux-next
> >   should be sent to Stephen Rothwell with linux-next in Cc.
> 
> Doug will send Stephen Rothwell a note to move his for-next pull for
> RDMA from Doug's personal directory to:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
> 
> Branch k.o/for-next

Actually, the linux-next testing uses a tag instead of a branch.  That
allows for oddball scenarios that you might want to get testing.  Say,
for instance, that you have a for-next branch with most of your stuff,
but you also have a separate branch that simply isn't ready to be pushed
yet, but you still want to get some early merge analysis, then you
create a throwaway branch, merge your for-next and this topic branch
together, throw the for-next tag on it for a couple or three days, and
if Stephen doesn't find anything, you're on the right path with your
development code.  Then you just reset the tag prior to pushing to
Linus.

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

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

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Jason Gunthorpe]

On Fri, Nov 17, 2017 at 02:45:01PM -0500, Doug Ledford wrote:

> On that point...I have my github repo tied into the 0day infrastructure,
> not the official repo.  I do that because I've publicly announced that
> my github repo is a WIP repo, and that it might be rebased.  That allows
> me to correct build issues by fixing up the broken patch and thereby
> keep bisectability at its highest.  If you use a branch/tag on k.o for
> your 0day testing, then fixes have to be incremental and depending on
> which patch broke the build, there might be a significant segment of
> code that is no longer bisectable.

.. and this is because the k.o repo is setup to disallow force push
for each branch, so a 0 day testing branch cannot be rebased?

> > Doug will send Stephen Rothwell a note to move his for-next pull for
> > RDMA from Doug's personal directory to:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
> > 
> > Branch k.o/for-next
> 
> Actually, the linux-next testing uses a tag instead of a branch.  That
> allows for oddball scenarios that you might want to get testing.  Say,
> for instance, that you have a for-next branch with most of your stuff,
> but you also have a separate branch that simply isn't ready to be pushed
> yet, but you still want to get some early merge analysis, then you
> create a throwaway branch, merge your for-next and this topic branch
> together, throw the for-next tag on it for a couple or three days, and
> if Stephen doesn't find anything, you're on the right path with your
> development code.  Then you just reset the tag prior to pushing to
> Linus.

Makes sense, this is why I said you'll send the note, because you know
how it is setup :)

Jason

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Doug Ledford]

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

On Fri, 2017-11-17 at 14:32 -0700, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 02:45:01PM -0500, Doug Ledford wrote:
> 
> > On that point...I have my github repo tied into the 0day infrastructure,
> > not the official repo.  I do that because I've publicly announced that
> > my github repo is a WIP repo, and that it might be rebased.  That allows
> > me to correct build issues by fixing up the broken patch and thereby
> > keep bisectability at its highest.  If you use a branch/tag on k.o for
> > your 0day testing, then fixes have to be incremental and depending on
> > which patch broke the build, there might be a significant segment of
> > code that is no longer bisectable.
> 
> .. and this is because the k.o repo is setup to disallow force push
> for each branch, so a 0 day testing branch cannot be rebased?

Well, there are ways around the system if you really wanted to do so. 
You can push to k.o with an empty ref, aka something like 'git push k.o
:k.o/for-next', which will delete the old branch.  Then you could rebase
it locally and repush it.  But that would make you a very evil person
and if Linus found out he would (rightfully!) yell at you for many
paragraphs with lots of all caps ;-).

The other option is to delete the bad branch and push a new branch with
a different name and the rebase already done.  I did that a couple times
in the early days of this job.  Now a days, I wouldn't even do this for
anything short of a disk corrupting issue or something like that.  I've
come to appreciate just how much people rely on unchanging commit IDs.

So the fact that the k.o repos don't allow non-fast-forward pushes is an
inconvenience, but it doesn't stop you from doing it if you really
wanted to.  But it's very bad form to do so, and that's the real reason
that I keep my 0day source on github and tell people regularly that my
github repo is a "rebase allowed" repo.

So, my workflow in order to prevent getting a bad branch on k.o goes
something like this:

1) Bundle up patches that belong together as a bundle in patchworks
2) Review patches
3) Download bundle from patchworks, apply using git -am.  Do any edits
to commit messages at this stage, either by hand editing the bundle file
before you run git -am, or afterwards by doing a git rebase -i.
4) Build locally and frequently as you take stuff in.  I suggest a build
between each bundle.  It's much easier to fix up errors when they aren't
buried 40 patches deep in your day's work.  I use partial builds for the
intermediate builds (make SUBDIRS=drivers/infiniband usually, but other
directories if the bundle touched code elsewhere).
5) When I think I'm basically done for the day, then I do a final, full
kernel build.
6) Push to 0day repo, wait for results.  This is a good time to do
whatever run testing you plan on doing for this push.
7) Push to k.o once 0day and your testing has passed.

Following that workflow minimizes the chances of having a broken push to
k.o.  If something does actually slip through this workflow, then you
just fix it incrementally unless leaving the issue will cause a meltdown
of the Internet or something.

The one thing it doesn't catch, which is actually what caused the time
or two I had to delete a branch and make a new branch on k.o, is when
you have to manually apply a patch because git am said the patch didn't
apply cleanly.

Most times, just running patch -p1 -l < .git/rebase-apply/patch gets the
patch in.  Git am will reject patches for any fuzz.  If we were using
git merge/pull, there is often enough context for git to know when to
allow the fuzz, but the am mode of git doesn't have that info and dumps
on very minor issues.

So you manually apply the patch, accepting some fuzz, and inspect the
result.  Where I screwed up in the past, is when the patch adds a
totally new file to the repo.  My usual workflow after applying the
patch manually, and then inspecting any suspect areas and hand editing
files when hunks get rejected, is to run git add -u.  This fails to add
new files to the commit.  So, I had to add an additional git status step
to see if there are any new, untracked files before I run the final git
am --continue.

If you split step 5 above into 5a) Push from local work repo to local
prep repo and 5b) Do full kernel build in prep repo to test that all
code needed to compile is tracked by git, it would catch that mistake
before it makes it outside the firewall.  That's a change I may make
just to be on the safe side in the future.

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

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

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Leon Romanovsky]

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

On Fri, Nov 17, 2017 at 08:44:27PM -0500, Doug Ledford wrote:
>
> If you split step 5 above into 5a) Push from local work repo to local
> prep repo and 5b) Do full kernel build in prep repo to test that all
> code needed to compile is tracked by git, it would catch that mistake
> before it makes it outside the firewall.  That's a change I may make
> just to be on the safe side in the future.

I'm using git worktree command [1] for that.

If it helps, this is snippet from my scripts:

-----------------------------------------
REPORT_FILE=$(mktemp)

function do_one {
	SHA1=$1
	REPORT_FILE=$2
	PDIR=$(mktemp -d)

	git worktree add $PDIR $SHA1
	echo "Redirecting the output to $REPORT_FILE"
	pushd $PDIR &>> $REPORT_FILE
	x checkpatch HEAD $PDIR &>> $REPORT_FILE
	cp $KCONFIG . &>> $REPORT_FILE
	make olddefconfig &>> $REPORT_FILE
	echo "===== FULL COMPILE =========" &>> $REPORT_FILE
	make -s -j 4 &>> $REPORT_FILE
	echo "===== SUB COMPILE =========" &>> $REPORT_FILE
	make -s -j 4 W=1 drivers/infiniband/ drivers/net/ethernet/mellanox/ &>> $REPORT_FILE
	echo "===== SMATCH =========" &>> $REPORT_FILE
	make CHECK="$SMATCH -p=kernel" C=1 drivers/infiniband/ drivers/net/ethernet/mellanox/ -s -j 4 &>> $REPORT_FILE
	echo "===== SPARSE =========" &>> $REPORT_FILE
	make CHECK="$SPARSE" C=2 drivers/infiniband/ drivers/net/ethernet/mellanox/ -s -j 4  &>> $REPORT_FILE
	popd &>> $REPORT_FILE
	rm -rf $PDIR
	git worktree prune
	# TODO: separate checkpatch errors, sparse, smatch
	NUMB_OF_ERRORS=$(awk -F": " '{print $1}' $REPORT_FILE | grep ":" | sort | uniq |wc -l)
	echo "There are $NUMB_OF_ERRORS errors/warnings"
}

do_one $SHA1 $REPORT_FILE
------------------------------------------

Thanks

[1] https://git-scm.com/docs/git-worktree

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



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: [PATCH] rdma: Add Jason as a co-maintainer

[Amrani, Ram]

> Hello Doug and Jason,
> 
> Thanks Doug for having added a co-maintainer. Jason, thank you for willing
> to be a co-maintainer.
> 

<snip>

> Best regards,
> 
> Bart.N


I echo that, thank you both!
Ram

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Sagi Grimberg]

Jason,

> As was discussed in September and October, add Jason along with
> Doug to have a team maintainership model for the RDMA subystem.

Happy to see this happening, thanks for stepping up. Thanks to everyone
who allowed it to happen (especially Doug).

Good Luck!

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Leon Romanovsky]

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

On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote:
> As was discussed in September and October, add Jason along with
> Doug to have a team maintainership model for the RDMA subystem.
>
> Mellanox Technologies will be funding Jason's independent work on
> the maintainership.
>
> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> ---
>  .mailmap    | 2 ++
>  MAINTAINERS | 1 +
>  2 files changed, 3 insertions(+)
>

Doug and Jason,

Can you forward the current fixes to Linus?

I have more fixes from Parav and fix to iWARP from Daniel, but I prefer
to have proper RDMA branches before I'm posting them.

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Jason Gunthorpe]

On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote:
> On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote:
> > As was discussed in September and October, add Jason along with
> > Doug to have a team maintainership model for the RDMA subystem.
> >
> > Mellanox Technologies will be funding Jason's independent work on
> > the maintainership.
> >
> > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> >  .mailmap    | 2 ++
> >  MAINTAINERS | 1 +
> >  2 files changed, 3 insertions(+)
> >
> 
> Doug and Jason,
> 
> Can you forward the current fixes to Linus?
> 
> I have more fixes from Parav and fix to iWARP from Daniel, but I prefer
> to have proper RDMA branches before I'm posting them.

I belive Doug has already sent the pull request for this merge window,
and the new shared tree location is fully up to date, and there are
no accepted but unset patches at this time?

Do you see otherwise?

We are now doing patches for rc.

The iWarp security fix from Daniel is definitely rc material.

Can you split that 33 patch series into things you think are rc
material?

Jason

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Leon Romanovsky]

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

On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote:
> > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote:
> > > As was discussed in September and October, add Jason along with
> > > Doug to have a team maintainership model for the RDMA subystem.
> > >
> > > Mellanox Technologies will be funding Jason's independent work on
> > > the maintainership.
> > >
> > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> > >  .mailmap    | 2 ++
> > >  MAINTAINERS | 1 +
> > >  2 files changed, 3 insertions(+)
> > >
> >
> > Doug and Jason,
> >
> > Can you forward the current fixes to Linus?
> >
> > I have more fixes from Parav and fix to iWARP from Daniel, but I prefer
> > to have proper RDMA branches before I'm posting them.
>
> I belive Doug has already sent the pull request for this merge window,
> and the new shared tree location is fully up to date, and there are
> no accepted but unset patches at this time?

I still see for-rc points to old (4.14) code.
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-rc

There is a need to advance -rc to be equal to -next during merge window,
so we will be able to actually base our -rc/-next patches.

>
> Do you see otherwise?
>
> We are now doing patches for rc.
>
> The iWarp security fix from Daniel is definitely rc material.

There is no need to wait for -rc1 to send bug fixes and Linus accepts and
welcomes bug fixes during merge window, see the pull requests from Dave
and others.

>
> Can you split that 33 patch series into things you think are rc
> material?

I'll take a look, but most probably I'll skip the split exercise.

This patch set was tested as one series and separation will require
two addition passes for the verification: one for-rc and another for
for-next.

Thanks

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] rdma: Add Jason as a co-maintainer

[Leon Romanovsky]

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

On Tue, Nov 21, 2017 at 07:04:56AM +0200, Leon Romanovsky wrote:
> On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote:
> > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote:
> > > > As was discussed in September and October, add Jason along with
> > > > Doug to have a team maintainership model for the RDMA subystem.
> > > >
> > > > Mellanox Technologies will be funding Jason's independent work on
> > > > the maintainership.
> > > >
> > > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> > > >  .mailmap    | 2 ++
> > > >  MAINTAINERS | 1 +
> > > >  2 files changed, 3 insertions(+)
> > > >
> > >
> > > Doug and Jason,
> > >
> > > Can you forward the current fixes to Linus?
> > >
> > > I have more fixes from Parav and fix to iWARP from Daniel, but I prefer
> > > to have proper RDMA branches before I'm posting them.
> >
> > I belive Doug has already sent the pull request for this merge window,
> > and the new shared tree location is fully up to date, and there are
> > no accepted but unset patches at this time?
>
> I still see for-rc points to old (4.14) code.
> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-rc
>
> There is a need to advance -rc to be equal to -next during merge window,
> so we will be able to actually base our -rc/-next patches.

And for-next misses one patch, which I sent directly to Linus
https://patchwork.kernel.org/patch/10032391/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/infiniband/core/nldev.c?id=287683d027a3ff83feb6c7044430c79881664ecf
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-next

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]