Re: [PATCH] rdma: Add Jason as a co-maintainer
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 > > > > .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 signature.asc Description: PGP signature
Re: [PATCH] rdma: Add Jason as a co-maintainer
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 > > > .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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature
Re: [PATCH] rdma: Add Jason as a co-maintainer
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 > > .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
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 > --- > .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 signature.asc Description: PGP signature
Re: [PATCH] rdma: Add Jason as a co-maintainer
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
> Hello Doug and Jason, > > Thanks Doug for having added a co-maintainer. Jason, thank you for willing > to be a co-maintainer. > > Best regards, > > Bart.N I echo that, thank you both! Ram
Re: [PATCH] rdma: Add Jason as a co-maintainer
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
> GPG KeyID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: PGP signature
Re: [PATCH] rdma: Add Jason as a co-maintainer
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 GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
Re: [PATCH] rdma: Add Jason as a co-maintainer
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
On Fri, 2017-11-17 at 11:14 -0700, Jason Gunthorpe wrote: > On Fri, Nov 17, 2017 at 05:54:34PM +, 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 GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
Re: [PATCH] rdma: Add Jason as a co-maintainer
On Fri, Nov 17, 2017 at 05:54:34PM +, 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
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 > +M: Jason Gunthorpe > L: linux-r...@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
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 > --- > .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 > James Hogan > James Hogan > James Ketrenos > +Jason Gunthorpe > +Jason Gunthorpe > Javi Merino > > Jean Tourrilhes > 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 > +M: Jason Gunthorpe 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-r...@vger.kernel.org > W: http://www.openfabrics.org/ > Q: http://patchwork.kernel.org/project/linux-rdma/list/ > -- > 2.7.4 > signature.asc Description: PGP signature
