Message-ID: <1521183244.19648.27.camel@mellanox.com>
Date:   Fri, 16 Mar 2018 06:54:08 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jason Gunthorpe <jgg@...lanox.com>,
        "dledford@...hat.com" <dledford@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Leon Romanovsky" <leonro@...lanox.com>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        Mark Bloch <markb@...lanox.com>
Subject: Re: linux-next: manual merge of the net-next tree with the rdma-fixes
 tree

On Thu, 2018-03-15 at 21:18 -0400, Doug Ledford wrote:
> On Fri, 2018-03-16 at 11:56 +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the net-next tree got a conflict in:
> > 
> >   drivers/infiniband/hw/mlx5/main.c
> > 
> > between commit:
> > 
> >   42cea83f9524 ("IB/mlx5: Fix cleanup order on unload")
> > 
> > from the rdma-fixes tree and commit:
> > 
> >   b5ca15ad7e61 ("IB/mlx5: Add proper representors support")
> > 
> > from the net-next tree.
> 
> We are aware of the merge conflict.  This is a result of the fact
> that
> code had been submitted to the for-next area (the representors
> support)
> and after that an issue was found by the syzkaller bot that deserved
> rc
> fix status and which conflicted.  The fixup you list below is
> insufficient to fix the merge conflict.  The full fixup can be found
> in
> the rdma tree from where I merged the for-rc branch into the for-next
> branch and created a complete fixup of the merge conflict.  The
> problem
> is that one patch change the device init stage flow, while the other
> patch duplicates the normal device init stage flow to the representor
> device stage flow.  To resolve the fix, you not only have to resolve
> the
> contextual diffs, but you have to duplicate the changes to the normal
> device stage flow into the representor device stage flow.  It is very
> far from a trivial merge.  We were planning on talking to Dave about
> this issue tomorrow, but you beat us to raising the issue ;-).
> 
> Here's the commit (from the rdma git repo) with the proper merge fix
> (although it also has other minor merge stuff that needs to be
> ignored):
> 
> 2d873449a202 (Merge branch 'k.o/wip/dl-for-rc' into k.o/wip/dl-for-
> next)
> 

Dave, Will you be able to take care of this? you will see this once the
rdma fix gets submitted to linus and you back merge rc into net-next.
after that we need to verify that net-next merges cleanly with rdma-
next (from mlx5 point of view) to make sure we won't run into trouble
in the next merge window.

I would like also to avoid such conflicts in the future, since now
rdma-rc is active we are more likely to run into such issues, to solve
this maybe the right way to go is to avoid touching rdma/netdev from
mlx5 shared code pull requests and keep mlx5 core stuff clean, the idea
is to run a pure mlx5 core incremental branch in parallel to netdev and
rdma, this branch will include all pure updates to mlx5 core, mlx5
netdev or rdma patches will be sent to netdev and rdma branches
separately they can be based on latest mlx5 core branch or not.

This way you don't need to pull in rdma stuff from shared code and
Doug/Jason won't need to pull in netdev stuff. it is more work for me,
but for you and rdma, you will see only clean mlx5 core stuff from
shared code, the stack part (netdev or rdma) will go only to the
specific maintainer respectively.

What do you think ? I can do a sample run in one of my next pull
requests and see how it goes.

Thanks,
Saeed.

Powered by blists - more mailing lists