rdma: Add Jason as a co-maintainer

PATCH In review Jason Gunthorpe 7 participants 14 messages Nov 16, 2017 – Nov 21, 2017 InfiniBand

Share & tools

Jason Gunthorpe

author

2017-11-16 20:44 UTC #0 lore raw

PATCH 1/1 rdma: Add Jason as a co-maintainer

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-VPRAkNaXOzVWk0Htik3J/[email protected]>

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

.mailmap +2 -0

index c021f29779a7a1..1469ff0d3f4d55 100644
@@ -73,6 +73,8 @@ James E Wilson <wilson-VMEwNUXQRiRWk0Htik3J/[email protected]>
 James Hogan <[email protected]> <[email protected]>
 James Hogan <[email protected]> <[email protected]>
 James Ketrenos <jketreno@io.(none)>
+Jason Gunthorpe <jgg-uk2M96/[email protected]> <jgg-VPRAkNaXOzVWk0Htik3J/[email protected]>
+Jason Gunthorpe <jgg-uk2M96/[email protected]> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
 Javi Merino <[email protected]> <[email protected]>
 <[email protected]> <javier.martinez-ZGY8ohtN/[email protected]>
 Jean Tourrilhes <[email protected]>

MAINTAINERS +1 -0

index 7f9c4f3fc9419d..d4e621e350f2cf 100644
@@ -6827,6 +6827,7 @@ F:	drivers/ipack/
 
 INFINIBAND SUBSYSTEM
 M:	Doug Ledford <[email protected]>
+M:	Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/[email protected]>
 L:	[email protected]
 W:	http://www.openfabrics.org/
 Q:	http://patchwork.kernel.org/project/linux-rdma/list/

Signature · 1 line

2.7.4

Bart Van Assche

2017-11-17 17:54 UTC #2 lore raw

In reply to Jason Gunthorpe

T24gVGh1LCAyMDE3LTExLTE2IGF0IDEzOjQ0IC0wNzAwLCBKYXNvbiBHdW50aG9ycGUgd3JvdGU6 DQo+IGRpZmYgLS1naXQgYS9NQUlOVEFJTkVSUyBiL01BSU5UQUlORVJTDQo+IGluZGV4IDdmOWM0 ZjNmYzk0MTlkLi5kNGU2MjFlMzUwZjJjZiAxMDA2NDQNCj4gLS0tIGEvTUFJTlRBSU5FUlMNCj4g KysrIGIvTUFJTlRBSU5FUlMNCj4gQEAgLTY4MjcsNiArNjgyNyw3IEBAIEY6CWRyaXZlcnMvaXBh Y2svDQo+ICANCj4gIElORklOSUJBTkQgU1VCU1lTVEVNDQo+ICBNOglEb3VnIExlZGZvcmQgPGRs ZWRmb3JkQHJlZGhhdC5jb20+DQo+ICtNOglKYXNvbiBHdW50aG9ycGUgPGpnZ0BtZWxsYW5veC5j b20+DQo+ICBMOglsaW51eC1yZG1hQHZnZXIua2VybmVsLm9yZw0KPiAgVzoJaHR0cDovL3d3dy5v cGVuZmFicmljcy5vcmcvDQo+ICBROglodHRwOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVj dC9saW51eC1yZG1hL2xpc3QvDQoNCkhlbGxvIERvdWcgYW5kIEphc29uLA0KDQpUaGFua3MgRG91 ZyBmb3IgaGF2aW5nIGFkZGVkIGEgY28tbWFpbnRhaW5lci4gSmFzb24sIHRoYW5rIHlvdSBmb3Ig d2lsbGluZw0KdG8gYmUgYSBjby1tYWludGFpbmVyLg0KDQpKYXNvbiwgaWYgeW91IGFyZSBnb2lu ZyB0byBzZW5kIHB1bGwgcmVxdWVzdHMgdG8gTGludXMgeW91IHNob3VsZCBiZSBhd2FyZQ0Kb2Yg dGhlIGZvbGxvd2luZzoNCiogTGludXMgdHJ1c3RzIHB1bGwgcmVxdWVzdHMgZnJvbSBhIGtlcm5l bC5vcmcgcmVwb3NpdG9yeSBtb3JlIHRoYW4gcHVsbA0KICByZXF1ZXN0cyBmcm9tIGEgcmVwb3Np dG9yeSBvdXRzaWRlIGtlcm5lbC5vcmcgKGUuZy4gZ2l0aHViKS4gQW55IHJlcXVlc3RzDQogIHRv IHB1bGwgZnJvbSBlLmcuIGdpdGh1YiBtdXN0IGJlIFBHUC1zaWduZWQuDQoqIElmIHlvdSBzZW5k IGFuIGUtbWFpbCB0byBXdSBGZW5nZ3VhbmcgdGhlbiBoZSB3aWxsIGFkZCBhIGJyYW5jaCBmcm9t IHlvdXINCiAgcmVwb3NpdG9yeSB0byBoaXMgemVyby1kYXkgdGVzdGluZy4gVGhpcyBpcyBhIGdy ZWF0IHdheSB0byBjYXRjaCBidWlsZA0KICBmYWlsdXJlcyBiZWZvcmUgbGludXgtbmV4dCBjYXRj aGVzIHRoZXNlLg0KKiBBbnkgcGF0Y2hlcyB0aGF0IHdpbGwgYmUgc2VudCB0byBMaW51cyBtdXN0 IGhhdmUgYmVlbiBpbiB0aGUgZm9yLW5leHQNCiAgcmVwb3NpdG9yeSBmb3IgYXQgbGVhc3QgYSBm ZXcgZGF5cy4gUmVxdWVzdHMgdG8gYWRkIGEgYnJhbmNoIHRvIGxpbnV4LW5leHQNCiAgc2hvdWxk IGJlIHNlbnQgdG8gU3RlcGhlbiBSb3Rod2VsbCB3aXRoIGxpbnV4LW5leHQgaW4gQ2MuDQoqIE1h aW50YWluZXJzIGFyZSBleHBlY3RlZCB0byBrZWVwIGFuIGV5ZSBvbiBtZXJnZSBjb25mbGljdHMg YW5kIG90aGVyIHJlcG9ydHMNCiAgc2VudCBvdXQgdG8gdGhlIGxpbnV4LW5leHQgbWFpbGluZyBs aXN0DQogIChodHRwOi8vdmdlci5rZXJuZWwub3JnL3ZnZXItbGlzdHMuaHRtbCNsaW51eC1uZXh0 KS4NCiogUmViYXNpbmcgYSB0cmVlIHRoYXQgd2lsbCBiZSBzZW50IHRvIExpbnVzIGlzIGNvbXBs ZXRlbHkgaW5hY2NlcHRhYmxlLiBBDQogIHF1b3RlIGZyb20gTGludXM6ICJBbmQgaW4gZ2VuZXJh bCwgeW91IHNpbXBseSBzaG91bGQgbmV2ZXIgcmViYXNlIGNvbW1pdHMNCiAgdGhhdCBoYXZlIGFs cmVhZHkgYmVlbiBwdWJsaWNpemVkLiIgU291cmNlOiBMaW51cyBUb3J2YWxkcywgUmU6IGxpbnV4 LW5leHQ6DQogIFNpZ25lZC1vZmYtYnkgbWlzc2luZyBmb3IgY29tbWl0IGluIHRoZSBkcml2ZXJz LXg4NiB0cmVlLCBsaW51eC1uZXh0IG1haWxpbmcNCiAgbGlzdCwgMiBBdWd1c3QgMjAxNyAoaHR0 cHM6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMva2VybmVsL21zZzI1NzE1ODQuaHRtbCkuDQoqIEJh Y2ttZXJnaW5nIChtZXJnaW5nIGEgbGF0ZXIgcmMgaW50byBhIG1haW50YWluZXIgdHJlZSkgdG8g cHVsbCBpbiByYyBmaXhlcw0KICBmcm9tIG90aGVyIG1haW50YWluZXJzIGlzIGNvbnNpZGVyZWQg aW5hY2NlcHRhYmxlIHRvby4gSWYgcGF0Y2hlcyBmcm9tIG90aGVyDQogIG1haW50YWluZXJzIGFy ZSByZWFsbHkgbmVlZGVkIEkgdGhpbmsgaXQgaXMgYWNjZXB0YWJsZSB0byBtZXJnZSBhIG1haW50 YWluZXINCiAgdHJlZSBpbnRvIExpbnVzJyB0cmVlIGFuZCB0byBhcHBseSBsYXRlIHJjIHBhdGNo ZXMgb24gdG9wIG9mIHRoYXQgbWVyZ2VkDQogIHRyZWUuDQoNClNlZSBhbHNvIGh0dHBzOi8vbHdu Lm5ldC9BcnRpY2xlcy8zMjg0MzYvLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkJhcnQu --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Jason Gunthorpe

2017-11-17 18:14 UTC #3 lore raw

Quoted 2 lines · Bart Van Assche

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

Thank you Bart!

Quoted 2 lines

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.

Quoted 3 lines

* 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

Quoted 3 lines

* 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

Quoted 3 lines

* 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

Quoted 3 lines

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

Quoted 5 lines

* 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

Quoted 5 lines

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

Doug Ledford

2017-11-17 19:45 UTC #4 lore raw

Quoted 7 lines · Jason Gunthorpe

Quoted 4 lines · Bart Van Assche
* 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.

Quoted 10 lines

Quoted 3 lines
* 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.

Signature · 3 lines

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

Jason Gunthorpe

2017-11-17 21:32 UTC #5 lore raw

Quoted 8 lines · Doug Ledford

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?

Quoted 7 lines

Quoted 6 lines
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

Quoted 10 lines

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

Doug Ledford

2017-11-18 01:44 UTC #6 lore raw

Quoted 11 lines · Jason Gunthorpe

Quoted 8 lines · Doug Ledford
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.

Quoted 2 lines

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

Signature · 3 lines

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

Leon Romanovsky

2017-11-18 07:26 UTC #7 lore raw

Quoted 6 lines · Doug Ledford

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

Quoted 5 lines

--
Doug Ledford <[email protected]>

    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

Amrani, Ram

2017-11-19 08:33 UTC #8 lore raw

In reply to Bart Van Assche

PiBIZWxsbyBEb3VnIGFuZCBKYXNvbiwNCj4gDQo+IFRoYW5rcyBEb3VnIGZvciBoYXZpbmcgYWRk ZWQgYSBjby1tYWludGFpbmVyLiBKYXNvbiwgdGhhbmsgeW91IGZvciB3aWxsaW5nDQo+IHRvIGJl IGEgY28tbWFpbnRhaW5lci4NCj4gDQoNCjxzbmlwPg0KDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+ IEJhcnQuTg0KDQoNCkkgZWNobyB0aGF0LCB0aGFuayB5b3UgYm90aCENClJhbQ0KDQo= --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Sagi Grimberg

2017-11-20 12:45 UTC #9 lore raw

In reply to Jason Gunthorpe

Jason,

Quoted 2 lines

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!

Leon Romanovsky

2017-11-20 16:10 UTC #10 lore raw

In reply to Jason Gunthorpe

Quoted 12 lines · Jason Gunthorpe

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-VPRAkNaXOzVWk0Htik3J/[email protected]>
---
 .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

Jason Gunthorpe

author

2017-11-20 18:06 UTC #11 lore raw

Quoted 13 lines · Leon Romanovsky

Quoted 11 lines · Jason Gunthorpe
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 <[email protected]>
 .mailmap    | 2 ++
 MAINTAINERS | 1 +
 2 files changed, 3 insertions(+)

Quoted 6 lines

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

Leon Romanovsky

2017-11-21 05:04 UTC #12 lore raw

Quoted 16 lines · Jason Gunthorpe

Quoted 15 lines · Leon Romanovsky
Quoted 11 lines · Jason Gunthorpe
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-VPRAkNaXOzVWk0Htik3J/[email protected]>
 .mailmap    | 2 ++
 MAINTAINERS | 1 +
 2 files changed, 3 insertions(+)
Doug and Jason,

Quoted 8 lines

Quoted 4 lines
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.

Quoted 6 lines

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.

Quoted 3 lines

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

Quoted 6 lines

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

Leon Romanovsky

2017-11-21 06:37 UTC #13 lore raw

Quoted 26 lines · Leon Romanovsky

Quoted 16 lines · Jason Gunthorpe
Quoted 15 lines · Leon Romanovsky
Quoted 11 lines · Jason Gunthorpe
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-VPRAkNaXOzVWk0Htik3J/[email protected]>
 .mailmap    | 2 ++
 MAINTAINERS | 1 +
 2 files changed, 3 insertions(+)
Doug and Jason,
Quoted 8 lines
Quoted 4 lines
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?

Quoted 5 lines

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