Hi all,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/infiniband/sw/rxe/rxe_resp.c
between commit:
9fd4350ba895 ("B/rxe: avoid double kfree_skb")
from the rdma-fixes tree and commit:
2e47350789eb ("IB/rxe: optimize the function duplicate_request")
from the rdma tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/sw/rxe/rxe_resp.c
index 955ff3b6da9c,c45c1ff24497..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@@ -1121,23 -1123,13 +1120,12 @@@ static enum resp_states duplicate_reque
/* Find the operation in our list of responder resources. */
res = find_resource(qp, pkt->psn);
if (res) {
- struct sk_buff *skb_copy;
-
- skb_copy = skb_clone(res->atomic.skb, GFP_ATOMIC);
- if (skb_copy) {
- rxe_add_ref(qp); /* for the new SKB */
- } else {
- pr_warn("Couldn't clone atomic resp\n");
- rc = RESPST_CLEANUP;
- goto out;
- }
-
+ skb_get(res->atomic.skb);
/* Resend the result. */
rc = rxe_xmit_packet(to_rdev(qp->ibqp.device), qp,
- pkt, skb_copy);
+ pkt, res->atomic.skb);
if (rc) {
pr_err("Failed resending result. This flow is not handled - skb ignored\n");
- rxe_drop_ref(qp);
- kfree_skb(res->atomic.skb);
rc = RESPST_CLEANUP;
goto out;
}
On Tue, 2018-05-01 at 10:10 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/sw/rxe/rxe_resp.c
>
> between commit:
>
> 9fd4350ba895 ("B/rxe: avoid double kfree_skb")
>
> from the rdma-fixes tree and commit:
>
> 2e47350789eb ("IB/rxe: optimize the function duplicate_request")
>
> from the rdma tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
We will probably merge the for-rc branch into the for-next branch in the
next few days, at which point we will do the conflict resolution
ourselves and your need to carry anything should drop out.
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Mon, Apr 30, 2018 at 08:55:35PM -0400, Doug Ledford wrote:
> On Tue, 2018-05-01 at 10:10 +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the rdma tree got a conflict in:
> >
> > drivers/infiniband/sw/rxe/rxe_resp.c
> >
> > between commit:
> >
> > 9fd4350ba895 ("B/rxe: avoid double kfree_skb")
> >
> > from the rdma-fixes tree and commit:
> >
> > 2e47350789eb ("IB/rxe: optimize the function duplicate_request")
> >
> > from the rdma tree.
> >
> > I fixed it up (I think - see below) and can carry the fix as necessary.
> > This is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
>
> We will probably merge the for-rc branch into the for-next branch in the
> next few days, at which point we will do the conflict resolution
> ourselves and your need to carry anything should drop out.
Isn't "rdma/wip/for-testing" branch intended for this?
Thanks
>
> --
> Doug Ledford <[email protected]>
> GPG KeyID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Wed, 2018-05-02 at 13:22 +0300, Leon Romanovsky wrote:
> On Mon, Apr 30, 2018 at 08:55:35PM -0400, Doug Ledford wrote:
> > On Tue, 2018-05-01 at 10:10 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the rdma tree got a conflict in:
> > >
> > > drivers/infiniband/sw/rxe/rxe_resp.c
> > >
> > > between commit:
> > >
> > > 9fd4350ba895 ("B/rxe: avoid double kfree_skb")
> > >
> > > from the rdma-fixes tree and commit:
> > >
> > > 2e47350789eb ("IB/rxe: optimize the function duplicate_request")
> > >
> > > from the rdma tree.
> > >
> > > I fixed it up (I think - see below) and can carry the fix as necessary.
> > > This is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> > >
> >
> > We will probably merge the for-rc branch into the for-next branch in the
> > next few days, at which point we will do the conflict resolution
> > ourselves and your need to carry anything should drop out.
>
> Isn't "rdma/wip/for-testing" branch intended for this?
Not really. It's there to provide a pre-merged branch for people to
test. But, I've rarely seen a release cycle where, *sometime*, we
didn't get a patch set in the for-next that depends on changes in the
for-rc area, and in that case, you need to merge for-rc into for-next.
If we don't have that this cycle, then you're right, I won't merge for-
rc into for-next and for-testing will be the throwaway merge branch. On
occasion, if the merge fixups needed between for-rc and for-next get too
difficult for a non-RDMA person to sus out, then we will do a merge of
for-rc into for-next simply so we can provide the right merge fixup, but
I doubt this merge fixup rises to that level.
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Wed, May 02, 2018 at 10:00:52AM -0400, Doug Ledford wrote:
> On Wed, 2018-05-02 at 13:22 +0300, Leon Romanovsky wrote:
> > On Mon, Apr 30, 2018 at 08:55:35PM -0400, Doug Ledford wrote:
> > > On Tue, 2018-05-01 at 10:10 +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the rdma tree got a conflict in:
> > > >
> > > > drivers/infiniband/sw/rxe/rxe_resp.c
> > > >
> > > > between commit:
> > > >
> > > > 9fd4350ba895 ("B/rxe: avoid double kfree_skb")
> > > >
> > > > from the rdma-fixes tree and commit:
> > > >
> > > > 2e47350789eb ("IB/rxe: optimize the function duplicate_request")
> > > >
> > > > from the rdma tree.
> > > >
> > > > I fixed it up (I think - see below) and can carry the fix as necessary.
> > > > This is now fixed as far as linux-next is concerned, but any non trivial
> > > > conflicts should be mentioned to your upstream maintainer when your tree
> > > > is submitted for merging. You may also want to consider cooperating
> > > > with the maintainer of the conflicting tree to minimise any particularly
> > > > complex conflicts.
> > > >
> > >
> > > We will probably merge the for-rc branch into the for-next branch in the
> > > next few days, at which point we will do the conflict resolution
> > > ourselves and your need to carry anything should drop out.
> >
> > Isn't "rdma/wip/for-testing" branch intended for this?
>
> Not really. It's there to provide a pre-merged branch for people to
> test. But, I've rarely seen a release cycle where, *sometime*, we
> didn't get a patch set in the for-next that depends on changes in the
> for-rc area, and in that case, you need to merge for-rc into for-next.
> If we don't have that this cycle, then you're right, I won't merge for-
> rc into for-next and for-testing will be the throwaway merge branch. On
> occasion, if the merge fixups needed between for-rc and for-next get too
> difficult for a non-RDMA person to sus out, then we will do a merge of
> for-rc into for-next simply so we can provide the right merge fixup, but
> I doubt this merge fixup rises to that level.
What I've been doing is storing the resolutions in for-testing and
then when the PR is made I create two branches
merge for-testing, for-next, linus/master
merge for-next, linus/master
Then I directly diff them to ensure the merge resolutions are all
matching properly.
ditto when merging for-rc and linus/master
Basically for-testing becomes a place to store the merge resolutions
that we can create when the conflict comes up and people still
remember what the right resolution is...
Jason