LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2018-05-01  0:10 Stephen Rothwell
  2018-05-01  0:55 ` Doug Ledford
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2018-05-01  0:10 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Zhu Yanjun

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

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;
  			}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-05-01  0:10 linux-next: manual merge of the rdma tree with the rdma-fixes tree Stephen Rothwell
@ 2018-05-01  0:55 ` Doug Ledford
  2018-05-02 10:22   ` Leon Romanovsky
  0 siblings, 1 reply; 18+ messages in thread
From: Doug Ledford @ 2018-05-01  0:55 UTC (permalink / raw)
  To: Stephen Rothwell, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Zhu Yanjun

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

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 <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-05-01  0:55 ` Doug Ledford
@ 2018-05-02 10:22   ` Leon Romanovsky
  2018-05-02 14:00     ` Doug Ledford
  0 siblings, 1 reply; 18+ messages in thread
From: Leon Romanovsky @ 2018-05-02 10:22 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Zhu Yanjun

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

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 <dledford@redhat.com>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-05-02 10:22   ` Leon Romanovsky
@ 2018-05-02 14:00     ` Doug Ledford
  2018-05-02 17:50       ` Jason Gunthorpe
  0 siblings, 1 reply; 18+ messages in thread
From: Doug Ledford @ 2018-05-02 14:00 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Stephen Rothwell, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Zhu Yanjun

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

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 <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-05-02 14:00     ` Doug Ledford
@ 2018-05-02 17:50       ` Jason Gunthorpe
  0 siblings, 0 replies; 18+ messages in thread
From: Jason Gunthorpe @ 2018-05-02 17:50 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Leon Romanovsky, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Zhu Yanjun

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2022-01-06  0:44 Stephen Rothwell
  0 siblings, 0 replies; 18+ messages in thread
From: Stephen Rothwell @ 2022-01-06  0:44 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Jason Gunthorpe, Jason Gunthorpe, Kees Cook,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Maor Gottlieb

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/hw/mlx5/mlx5_ib.h

between commit:

  4163cb3d1980 ("Revert "RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow"")

from the rdma-fixes tree and commit:

  e517f76a3cb2 ("RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr")

from the rdma tree.

I fixed it up (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/hw/mlx5/mlx5_ib.h
index e636e954f6bf,b6030ef8f7af..000000000000
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@@ -664,9 -665,8 +665,9 @@@ struct mlx5_ib_mr 
  
  	/* User MR data */
  	struct mlx5_cache_ent *cache_ent;
+ 	/* Everything after cache_ent is zero'd when MR allocated */
 +	struct ib_umem *umem;
  
- 	/* This is zero'd when the MR is allocated */
  	union {
  		/* Used only while the MR is in the cache */
  		struct {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2021-09-30  1:35 Stephen Rothwell
@ 2021-10-01 13:52 ` Jason Gunthorpe
  0 siblings, 0 replies; 18+ messages in thread
From: Jason Gunthorpe @ 2021-10-01 13:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Dennis Dalessandro, Guo Zhi,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Mike Marciniszyn

On Thu, Sep 30, 2021 at 11:35:18AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/hfi1/ipoib_tx.c
> 
> between commit:
> 
>   7d5cfafe8b40 ("RDMA/hfi1: Fix kernel pointer leak")
> 
> from the rdma-fixes tree and commit:
> 
>   f5dc70a0e142 ("IB/hfi1: Tune netdev xmit cachelines")
> 
> from the rdma tree.
> 
> I fixed it up (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.

It looks OK, thanks

Jason

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2021-09-30  1:35 Stephen Rothwell
  2021-10-01 13:52 ` Jason Gunthorpe
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2021-09-30  1:35 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Dennis Dalessandro, Guo Zhi, Jason Gunthorpe, Jason Gunthorpe,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Mike Marciniszyn

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/hw/hfi1/ipoib_tx.c

between commit:

  7d5cfafe8b40 ("RDMA/hfi1: Fix kernel pointer leak")

from the rdma-fixes tree and commit:

  f5dc70a0e142 ("IB/hfi1: Tune netdev xmit cachelines")

from the rdma tree.

I fixed it up (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/hw/hfi1/ipoib_tx.c
index 15b0cb0f363f,d1c2cf52ba48..000000000000
--- a/drivers/infiniband/hw/hfi1/ipoib_tx.c
+++ b/drivers/infiniband/hw/hfi1/ipoib_tx.c
@@@ -874,16 -826,15 +826,15 @@@ void hfi1_ipoib_tx_timeout(struct net_d
  {
  	struct hfi1_ipoib_dev_priv *priv = hfi1_ipoib_priv(dev);
  	struct hfi1_ipoib_txq *txq = &priv->txqs[q];
- 	u64 completed = atomic64_read(&txq->complete_txreqs);
  
 -	dd_dev_info(priv->dd, "timeout txq %llx q %u stopped %u stops %d no_desc %d ring_full %d\n",
 -		    (unsigned long long)txq, q,
 +	dd_dev_info(priv->dd, "timeout txq %p q %u stopped %u stops %d no_desc %d ring_full %d\n",
 +		    txq, q,
  		    __netif_subqueue_stopped(dev, txq->q_idx),
- 		    atomic_read(&txq->stops),
- 		    atomic_read(&txq->no_desc),
- 		    atomic_read(&txq->ring_full));
+ 		    atomic_read(&txq->tx_ring.stops),
+ 		    atomic_read(&txq->tx_ring.no_desc),
+ 		    atomic_read(&txq->tx_ring.ring_full));
 -	dd_dev_info(priv->dd, "sde %llx engine %u\n",
 -		    (unsigned long long)txq->sde,
 +	dd_dev_info(priv->dd, "sde %p engine %u\n",
 +		    txq->sde,
  		    txq->sde ? txq->sde->this_idx : 0);
  	dd_dev_info(priv->dd, "flow %x\n", txq->flow.as_int);
  	dd_dev_info(priv->dd, "sent %llu completed %llu used %llu\n",

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2019-08-23  2:22 Stephen Rothwell
@ 2019-08-23 15:02 ` Jason Gunthorpe
  0 siblings, 0 replies; 18+ messages in thread
From: Jason Gunthorpe @ 2019-08-23 15:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux Next Mailing List, Linux Kernel Mailing List,
	Moni Shoua, Parav Pandit, Leon Romanovsky

On Fri, Aug 23, 2019 at 12:22:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/mlx5/mlx5_ib.h
> 
> between commit:
> 
>   0e6613b41edd ("IB/mlx5: Consolidate use_umr checks into single function")
> 
> from the rdma-fixes tree and commit:
> 
>   3e1f000ff746 ("IB/mlx5: Support per device q counters in switchdev mode")
> 
> from the rdma tree.
> 
> I fixed it up (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.

Looks OK to me, thanks

Jason

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2019-08-23  2:22 Stephen Rothwell
  2019-08-23 15:02 ` Jason Gunthorpe
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2019-08-23  2:22 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Moni Shoua,
	Parav Pandit, Leon Romanovsky

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/hw/mlx5/mlx5_ib.h

between commit:

  0e6613b41edd ("IB/mlx5: Consolidate use_umr checks into single function")

from the rdma-fixes tree and commit:

  3e1f000ff746 ("IB/mlx5: Support per device q counters in switchdev mode")

from the rdma tree.

I fixed it up (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/hw/mlx5/mlx5_ib.h
index 9ae587b74b12,cb41a7e6255a..000000000000
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@@ -1475,18 -1475,5 +1475,19 @@@ int bfregn_to_uar_index(struct mlx5_ib_
  			bool dyn_bfreg);
  
  int mlx5_ib_qp_set_counter(struct ib_qp *qp, struct rdma_counter *counter);
+ u16 mlx5_ib_get_counters_id(struct mlx5_ib_dev *dev, u8 port_num);
 +
 +static inline bool mlx5_ib_can_use_umr(struct mlx5_ib_dev *dev,
 +				       bool do_modify_atomic)
 +{
 +	if (MLX5_CAP_GEN(dev->mdev, umr_modify_entity_size_disabled))
 +		return false;
 +
 +	if (do_modify_atomic &&
 +	    MLX5_CAP_GEN(dev->mdev, atomic) &&
 +	    MLX5_CAP_GEN(dev->mdev, umr_modify_atomic_disabled))
 +		return false;
 +
 +	return true;
 +}
  #endif /* MLX5_IB_H */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-07-10  1:17 Stephen Rothwell
@ 2018-07-10  5:19 ` Leon Romanovsky
  0 siblings, 0 replies; 18+ messages in thread
From: Leon Romanovsky @ 2018-07-10  5:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List

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

On Tue, Jul 10, 2018 at 11:17:40AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
>   drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
>   4fae7f170416 ("RDMA/uverbs: Fix slab-out-of-bounds in ib_uverbs_ex_create_flow")
>
> from the rdma-fixes tree and commit:
>
>   2cc1e3b80942 ("IB/uverbs: Replace file->ucontext with file in uverbs_cmd.c")
>
> from the rdma tree.
>
> I fixed it up (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.
>
> --

Thanks Stephen, Looks good.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2018-07-10  1:17 Stephen Rothwell
  2018-07-10  5:19 ` Leon Romanovsky
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2018-07-10  1:17 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Leon Romanovsky

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/core/uverbs_cmd.c

between commit:

  4fae7f170416 ("RDMA/uverbs: Fix slab-out-of-bounds in ib_uverbs_ex_create_flow")

from the rdma-fixes tree and commit:

  2cc1e3b80942 ("IB/uverbs: Replace file->ucontext with file in uverbs_cmd.c")

from the rdma tree.

I fixed it up (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/core/uverbs_cmd.c
index cc06e8404e9b,d048cabc4246..000000000000
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@@ -3559,11 -3505,11 +3505,16 @@@ int ib_uverbs_ex_create_flow(struct ib_
  		goto err_uobj;
  	}
  
 +	if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) {
 +		err = -EINVAL;
 +		goto err_put;
 +	}
 +
+ 	if (!qp->device->create_flow) {
+ 		err = -EOPNOTSUPP;
+ 		goto err_put;
+ 	}
+ 
  	flow_attr = kzalloc(struct_size(flow_attr, flows,
  				cmd.flow_attr.num_of_specs), GFP_KERNEL);
  	if (!flow_attr) {
@@@ -3583,15 -3529,13 +3534,15 @@@
  	flow_attr->flags = kern_flow_attr->flags;
  	flow_attr->size = sizeof(*flow_attr);
  
 -	kern_spec = kern_flow_attr + 1;
 +	kern_spec = kern_flow_attr->flow_specs;
  	ib_spec = flow_attr + 1;
  	for (i = 0; i < flow_attr->num_of_specs &&
 -	     cmd.flow_attr.size > offsetof(struct ib_uverbs_flow_spec, reserved) &&
 -	     cmd.flow_attr.size >=
 -	     ((struct ib_uverbs_flow_spec *)kern_spec)->size; i++) {
 -		err = kern_spec_to_ib_spec(file, kern_spec, ib_spec, uflow_res);
 +			cmd.flow_attr.size >= sizeof(*kern_spec) &&
 +			cmd.flow_attr.size >= kern_spec->size;
 +	     i++) {
 +		err = kern_spec_to_ib_spec(
- 				file->ucontext, (struct ib_uverbs_flow_spec *)kern_spec,
++				file, (struct ib_uverbs_flow_spec *)kern_spec,
 +				ib_spec, uflow_res);
  		if (err)
  			goto err_free;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-06-27  0:07 Stephen Rothwell
@ 2018-06-27  5:50 ` Leon Romanovsky
  0 siblings, 0 replies; 18+ messages in thread
From: Leon Romanovsky @ 2018-06-27  5:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List

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

On Wed, Jun 27, 2018 at 10:07:26AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
>   drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
>   940efcc8889f ("RDMA/uverbs: Protect from attempts to create flows on unsupported QP")
>
> from the rdma-fixes tree and commit:
>
>   e99028ad76e7 ("RDMA/uverbs: Check existence of create_flow callback")
>
> from the rdma tree.
>
> I fixed it up (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/core/uverbs_cmd.c
> index 87ffeebc0b28,5fc14fde274c..000000000000
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@@ -3559,11 -3554,11 +3554,16 @@@ int ib_uverbs_ex_create_flow(struct ib_
>   		goto err_uobj;
>   	}
>
>  +	if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) {
>  +		err = -EINVAL;
>  +		goto err_put;
>  +	}
>  +
> + 	if (!qp->device->create_flow) {
> + 		err = -EOPNOTSUPP;
> + 		goto err_put;
> + 	}
> +

Thanks Stephen, looks good.

>   	flow_attr = kzalloc(struct_size(flow_attr, flows,
>   				cmd.flow_attr.num_of_specs), GFP_KERNEL);
>   	if (!flow_attr) {



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2018-06-27  0:07 Stephen Rothwell
  2018-06-27  5:50 ` Leon Romanovsky
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2018-06-27  0:07 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Leon Romanovsky

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/core/uverbs_cmd.c

between commit:

  940efcc8889f ("RDMA/uverbs: Protect from attempts to create flows on unsupported QP")

from the rdma-fixes tree and commit:

  e99028ad76e7 ("RDMA/uverbs: Check existence of create_flow callback")

from the rdma tree.

I fixed it up (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/core/uverbs_cmd.c
index 87ffeebc0b28,5fc14fde274c..000000000000
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@@ -3559,11 -3554,11 +3554,16 @@@ int ib_uverbs_ex_create_flow(struct ib_
  		goto err_uobj;
  	}
  
 +	if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) {
 +		err = -EINVAL;
 +		goto err_put;
 +	}
 +
+ 	if (!qp->device->create_flow) {
+ 		err = -EOPNOTSUPP;
+ 		goto err_put;
+ 	}
+ 
  	flow_attr = kzalloc(struct_size(flow_attr, flows,
  				cmd.flow_attr.num_of_specs), GFP_KERNEL);
  	if (!flow_attr) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2018-03-22  0:45 Stephen Rothwell
  0 siblings, 0 replies; 18+ messages in thread
From: Stephen Rothwell @ 2018-03-22  0:45 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise,
	Leon Romanovsky

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

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/core/ucma.c

between commit:

  e8980d67d601 ("RDMA/ucma: Ensure that CM_ID exists prior to access it")

from the rdma-fixes tree and commit:

  00313983cda6 ("DMA/nldev: provide detailed CM_ID information")

from the rdma tree.

I fixed it up (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/core/ucma.c
index e5a1e7d81326,4bb5bed596c9..000000000000
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@@ -477,10 -476,10 +477,10 @@@ static ssize_t ucma_create_id(struct uc
  		return -ENOMEM;
  
  	ctx->uid = cmd.uid;
- 	cm_id = rdma_create_id(current->nsproxy->net_ns,
- 			       ucma_event_handler, ctx, cmd.ps, qp_type);
 -	ctx->cm_id = __rdma_create_id(current->nsproxy->net_ns,
 -			      ucma_event_handler, ctx, cmd.ps, qp_type, NULL);
 -	if (IS_ERR(ctx->cm_id)) {
 -		ret = PTR_ERR(ctx->cm_id);
++	cm_id = __rdma_create_id(current->nsproxy->net_ns,
++				ucma_event_handler, ctx, cmd.ps, qp_type, NULL);
 +	if (IS_ERR(cm_id)) {
 +		ret = PTR_ERR(cm_id);
  		goto err1;
  	}
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-01-17  1:55 ` Stephen Rothwell
@ 2018-01-17  3:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 18+ messages in thread
From: Jason Gunthorpe @ 2018-01-17  3:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Leon Romanovsky

On Wed, Jan 17, 2018 at 12:55:37PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 17 Jan 2018 12:51:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > diff --cc drivers/infiniband/hw/mlx5/qp.c
> > index cffe5966aef9,ae36db3d0deb..000000000000
> > +++ b/drivers/infiniband/hw/mlx5/qp.c
> > @@@ -4361,12 -4674,12 +4674,11 @@@ static void to_rdma_ah_attr(struct mlx5
> >   
> >   	memset(ah_attr, 0, sizeof(*ah_attr));
> >   
> > - 	if (!path->port || path->port > MLX5_CAP_GEN(dev, num_ports))
> >  -	ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, path->port);
> >  -	rdma_ah_set_port_num(ah_attr, path->port);
> >  -	if (rdma_ah_get_port_num(ah_attr) == 0 ||
> >  -	    rdma_ah_get_port_num(ah_attr) > ibdev->num_ports)
> > ++	if (!path->port || path->port > ibdev->num_ports))
> 
> I fixed up the extra ')'.  Sorry about that,

Thanks, this looks correct to me, and the conflict was expected..

Jason

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
  2018-01-17  1:51 Stephen Rothwell
@ 2018-01-17  1:55 ` Stephen Rothwell
  2018-01-17  3:03   ` Jason Gunthorpe
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2018-01-17  1:55 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Leon Romanovsky

Hi all,

On Wed, 17 Jan 2018 12:51:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> diff --cc drivers/infiniband/hw/mlx5/qp.c
> index cffe5966aef9,ae36db3d0deb..000000000000
> --- a/drivers/infiniband/hw/mlx5/qp.c
> +++ b/drivers/infiniband/hw/mlx5/qp.c
> @@@ -4361,12 -4674,12 +4674,11 @@@ static void to_rdma_ah_attr(struct mlx5
>   
>   	memset(ah_attr, 0, sizeof(*ah_attr));
>   
> - 	if (!path->port || path->port > MLX5_CAP_GEN(dev, num_ports))
>  -	ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, path->port);
>  -	rdma_ah_set_port_num(ah_attr, path->port);
>  -	if (rdma_ah_get_port_num(ah_attr) == 0 ||
>  -	    rdma_ah_get_port_num(ah_attr) > ibdev->num_ports)
> ++	if (!path->port || path->port > ibdev->num_ports))

I fixed up the extra ')'.  Sorry about that,

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 18+ messages in thread

* linux-next: manual merge of the rdma tree with the rdma-fixes tree
@ 2018-01-17  1:51 Stephen Rothwell
  2018-01-17  1:55 ` Stephen Rothwell
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Rothwell @ 2018-01-17  1:51 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Leon Romanovsky

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/hw/mlx5/qp.c

between commit:

  ae59c3f0b6cf ("RDMA/mlx5: Fix out-of-bound access while querying AH")

from the rdma-fixes tree and commit:

  508562d6f708 ("IB/mlx5: Reduce the use of num_port capability")

from the rdma tree.

I fixed it up (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/hw/mlx5/qp.c
index cffe5966aef9,ae36db3d0deb..000000000000
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@@ -4361,12 -4674,12 +4674,11 @@@ static void to_rdma_ah_attr(struct mlx5
  
  	memset(ah_attr, 0, sizeof(*ah_attr));
  
- 	if (!path->port || path->port > MLX5_CAP_GEN(dev, num_ports))
 -	ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, path->port);
 -	rdma_ah_set_port_num(ah_attr, path->port);
 -	if (rdma_ah_get_port_num(ah_attr) == 0 ||
 -	    rdma_ah_get_port_num(ah_attr) > ibdev->num_ports)
++	if (!path->port || path->port > ibdev->num_ports))
  		return;
  
 +	ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, path->port);
 +
  	rdma_ah_set_port_num(ah_attr, path->port);
  	rdma_ah_set_sl(ah_attr, path->dci_cfi_prio_sl & 0xf);
  

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-01-06  0:45 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-01  0:10 linux-next: manual merge of the rdma tree with the rdma-fixes tree Stephen Rothwell
2018-05-01  0:55 ` Doug Ledford
2018-05-02 10:22   ` Leon Romanovsky
2018-05-02 14:00     ` Doug Ledford
2018-05-02 17:50       ` Jason Gunthorpe
  -- strict thread matches above, loose matches on Subject: below --
2022-01-06  0:44 Stephen Rothwell
2021-09-30  1:35 Stephen Rothwell
2021-10-01 13:52 ` Jason Gunthorpe
2019-08-23  2:22 Stephen Rothwell
2019-08-23 15:02 ` Jason Gunthorpe
2018-07-10  1:17 Stephen Rothwell
2018-07-10  5:19 ` Leon Romanovsky
2018-06-27  0:07 Stephen Rothwell
2018-06-27  5:50 ` Leon Romanovsky
2018-03-22  0:45 Stephen Rothwell
2018-01-17  1:51 Stephen Rothwell
2018-01-17  1:55 ` Stephen Rothwell
2018-01-17  3:03   ` Jason Gunthorpe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).