Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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

On Thu, May 12, 2016 at 10:01:17PM -0400, Doug Ledford wrote:
> On 05/12/2016 01:44 PM, Leon Romanovsky wrote:
> > Hi Doug,
> > 
> > I prepared the base tree [1] with patches sent to RDMA mailing and passed review.
> 
> You can't know that.  The reason I say that is because they have to pass
> my review as well, and that's usually an implicit thing.  If I review
> them and they have already passed list review and they pass my review,
> then I include them.  If they don't pass my review (which isn't often if
> the other people on the list have already spoke up, but does happen),
> then I ask for revisions.  If you take them without an explicit review
> from me, then you don't know if I'll ask for a revision or not.  It's
> premature.

Yes, I don't know for sure, but you can see that patches which I chose
have no dispute over them and have no reasons do not to be accepted.

> 
> > This base tree is part of linux-next and kbuild system, and it passed
> > sanity checks.
> 
> Most, there was a linux-next build failure that I'm sure is related to a
> change I hadn't had a chance to look into yet but looked fishy to me
> (the move to put ib_addr into ib_core looks like it's broken, but I
> hadn't delved into the code to verify it...the linux-next build failure
> from tonight makes me thing that it is).

It is caused by **not merged and delayed** topic branches. Both topic/fix_core and
topic/rdwa-rw-api touched drivers/infiniband/core/Makefile and created merge
conflict.

The merge commit is here [1] and the simple fix is
diff --cc drivers/infiniband/core/Makefile
index 2c6dc6b,26987d9..f0a5276
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@@ -8,9 -8,9 +8,9 @@@ obj-$(CONFIG_INFINIBAND_USER_MAD) +=     ib
  obj-$(CONFIG_INFINIBAND_USER_ACCESS) +=       ib_uverbs.o ib_ucm.o \
                                          $(user_access-y)

- ib_core-y :=			packer.o ud_header.o verbs.o cq.o sysfs.o \
+ ib_core-y :=			packer.o ud_header.overbs.o cq.o rw.o sysfs.o \
				device.o fmr_pool.o cache.o netlink.o \
-                               roce_gid_mgmt.o addr.o
-                               roce_gid_mgmt.o mr_pool.o
++				roce_gid_mgmt.o addr.o mr_pool.o
ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
ib_core-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o umem_rbtree.o

Based on your methodology such merge failures are unavoidable and I'm
not feeling well with your conclusion that topic/fix_core broke the
build.

> 
> > I believe that it will save you a lot of work and time if you use it
> > as a base for next merge window submission (4.7).
> 
> Not really.  I still have to review the patches, and I still have to
> update patchworks, and when I'm sorting through patchworks is when I get
> the patches to include.  The incremental time to grab the patches out of
> patchworks and run git am -s on the bundle is negligible.  The real time
> is in reading the patches, and this doesn't save me any of that time.

I'm not working with patchworks, so I can't save here, but IMHO it still
valuable and save time:
1. Separated by topics
2. ROB tags
3. cleanpatch + checkpatch before merging
4. We (Intel and Mellanox) already run their test regressions on the upstream code
and we will run it on **almost** (pending your acceptance) latest ->next branch.
So the bugs will be caught before sending pull request to Linus.

> The help is appreciated though ;-)

Thanks,
Will you support my effort to continue publish ->next tree?

> 
> > The topics which were added:
> >  * topic/fix-core
> >  * topic/hfi1
> >  * topic/i40iw
> >  * topic/ipoib
> >  * topic/iw_cxgb4
> >  * topic/iwcm
> >  * topic/nes
> >  * topic/rdma-rw-api
> >  * topic/srp
> > 
> > [1]
> > Git repository:
> > git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next
> > 
> > Gitweb:
> > https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next
> > 
> > Thanks.
> > 


[1]
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=rdma-next&id=d77eb1c067de68982a63063dc391a28c450ebd64

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