linux-next: manual merge of the rdma tree with the rdma-fixes tree

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Doug Ledford]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Leon Romanovsky]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Doug Ledford]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Jason Gunthorpe]

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

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Leon Romanovsky]

On Thu, Sep 28, 2023 at 11:38:51AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/mlx5/mr.c
> 
> between commit:
> 
>   374012b00457 ("RDMA/mlx5: Fix mkey cache possible deadlock on cleanup")
> 
> from the rdma-fixes tree and commit:
> 
>   57e7071683ef ("RDMA/mlx5: Implement mkeys management via LIFO queue")
> 
> 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/mr.c
> index 433f96459246,b0fa2d644973..000000000000
> --- a/drivers/infiniband/hw/mlx5/mr.c
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@@ -1025,21 -998,15 +999,21 @@@ void mlx5_mkey_cache_cleanup(struct mlx
>   	if (!dev->cache.wq)
>   		return;
>   
>  -	cancel_delayed_work_sync(&dev->cache.remove_ent_dwork);
>   	mutex_lock(&dev->cache.rb_lock);
>  +	dev->cache.disable = true;
>   	for (node = rb_first(root); node; node = rb_next(node)) {
>   		ent = rb_entry(node, struct mlx5_cache_ent, node);
> - 		xa_lock_irq(&ent->mkeys);
> + 		spin_lock_irq(&ent->mkeys_queue.lock);
>   		ent->disabled = true;
> - 		xa_unlock_irq(&ent->mkeys);
> + 		spin_unlock_irq(&ent->mkeys_queue.lock);
>  -		cancel_delayed_work_sync(&ent->dwork);
>   	}
>  +	mutex_unlock(&dev->cache.rb_lock);
>  +
>  +	/*
>  +	 * After all entries are disabled and will not reschedule on WQ,
>  +	 * flush it and all async commands.
>  +	 */
>  +	flush_workqueue(dev->cache.wq);
>   
>   	mlx5_mkey_cache_debugfs_cleanup(dev);
>   	mlx5_cmd_cleanup_async_ctx(&dev->async_ctx);

Thanks for the fix.

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/hw/mlx5/mr.c

between commit:

  374012b00457 ("RDMA/mlx5: Fix mkey cache possible deadlock on cleanup")

from the rdma-fixes tree and commit:

  57e7071683ef ("RDMA/mlx5: Implement mkeys management via LIFO queue")

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/mr.c
index 433f96459246,b0fa2d644973..000000000000
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@@ -1025,21 -998,15 +999,21 @@@ void mlx5_mkey_cache_cleanup(struct mlx
  	if (!dev->cache.wq)
  		return;
  
 -	cancel_delayed_work_sync(&dev->cache.remove_ent_dwork);
  	mutex_lock(&dev->cache.rb_lock);
 +	dev->cache.disable = true;
  	for (node = rb_first(root); node; node = rb_next(node)) {
  		ent = rb_entry(node, struct mlx5_cache_ent, node);
- 		xa_lock_irq(&ent->mkeys);
+ 		spin_lock_irq(&ent->mkeys_queue.lock);
  		ent->disabled = true;
- 		xa_unlock_irq(&ent->mkeys);
+ 		spin_unlock_irq(&ent->mkeys_queue.lock);
 -		cancel_delayed_work_sync(&ent->dwork);
  	}
 +	mutex_unlock(&dev->cache.rb_lock);
 +
 +	/*
 +	 * After all entries are disabled and will not reschedule on WQ,
 +	 * flush it and all async commands.
 +	 */
 +	flush_workqueue(dev->cache.wq);
  
  	mlx5_mkey_cache_debugfs_cleanup(dev);
  	mlx5_cmd_cleanup_async_ctx(&dev->async_ctx);

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

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Jason Gunthorpe]

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

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Jason Gunthorpe]

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

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Leon Romanovsky]

[-- 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 --]

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Leon Romanovsky]

[-- 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 --]

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Jason Gunthorpe]

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

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

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

linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Stephen Rothwell]

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