linux-next: manual merge of the rdma tree with Linus' tree

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/core/uverbs_cmd.c
  drivers/infiniband/core/uverbs_std_types_cq.c

between commit:

  6876aaedc8a1 ("RDMA/uverbs: Pass udata on uverbs error unwind")

from Linus' tree and commit:

  e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core responsibility")

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 63fe14c7c68f,5c00d9a5698a..000000000000
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@@ -1053,8 -1045,10 +1056,10 @@@ static struct ib_ucq_object *create_cq(
  	return obj;
  
  err_cb:
 -	ib_destroy_cq(cq);
 +	ib_destroy_cq_user(cq, uverbs_get_cleared_udata(attrs));
- 
+ 	cq = NULL;
+ err_free:
+ 	kfree(cq);
  err_file:
  	if (ev_file)
  		ib_uverbs_release_ucq(attrs->ufile, ev_file, obj);
diff --cc drivers/infiniband/core/uverbs_std_types_cq.c
index 07ea4e3c4566,06b8c7d017b7..000000000000
--- a/drivers/infiniband/core/uverbs_std_types_cq.c
+++ b/drivers/infiniband/core/uverbs_std_types_cq.c
@@@ -135,8 -140,10 +140,10 @@@ static int UVERBS_HANDLER(UVERBS_METHOD
  
  	return 0;
  err_cq:
 -	ib_destroy_cq(cq);
 +	ib_destroy_cq_user(cq, uverbs_get_cleared_udata(attrs));
- 
+ 	cq = NULL;
+ err_free:
+ 	kfree(cq);
  err_event_file:
  	if (ev_file)
  		uverbs_uobject_put(ev_file_uobj);

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

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

[Doug Ledford]

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

On Fri, 2019-06-14 at 13:00 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got conflicts in:
> 
>   drivers/infiniband/core/uverbs_cmd.c
>   drivers/infiniband/core/uverbs_std_types_cq.c
> 
> between commit:
> 
>   6876aaedc8a1 ("RDMA/uverbs: Pass udata on uverbs error unwind")
> 
> from Linus' tree and commit:
> 
>   e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core
> responsibility")
> 
> 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.  There will be at least one more coming too.  We've had
a number of -rc patches and -next patches that touch the same area of
code this cycle.

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/sw/rxe/rxe_cq.c

between commit:

  0c7e314a6352 ("RDMA/rxe: Fix rxe_cq_post")

from the origin tree and commit:

  350b6dd4b2f8 ("RDMA/rxe: Simplify cq->notify code")

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/sw/rxe/rxe_cq.c
index 6ca2a05b6a2a,31a25aaa44a0..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_cq.c
+++ b/drivers/infiniband/sw/rxe/rxe_cq.c
@@@ -113,10 -113,11 +113,9 @@@ int rxe_cq_post(struct rxe_cq *cq, stru
  
  	queue_advance_producer(cq->queue, QUEUE_TYPE_TO_CLIENT);
  
- 	if ((cq->notify == IB_CQ_NEXT_COMP) ||
- 	    (cq->notify == IB_CQ_SOLICITED && solicited)) {
 -	spin_unlock_irqrestore(&cq->cq_lock, flags);
 -
+ 	if ((cq->notify & IB_CQ_NEXT_COMP) ||
+ 	    (cq->notify & IB_CQ_SOLICITED && solicited)) {
  		cq->notify = 0;
- 
  		cq->ibcq.comp_handler(&cq->ibcq, cq->ibcq.cq_context);
  	}
  

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/sw/rxe/rxe_comp.c

between commit:

  dc07628bd2bb ("RDMA/rxe: Return CQE error if invalid lkey was supplied")

from Linus' tree and commit:

  c8dcdda046b0 ("RDMA/rxe: Implement invalidate MW operations")

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/sw/rxe/rxe_comp.c
index a6712e373eed,207aa7ef52c4..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_comp.c
+++ b/drivers/infiniband/sw/rxe/rxe_comp.c
@@@ -345,11 -346,9 +346,11 @@@ static inline enum comp_state do_read(s
  
  	ret = copy_data(qp->pd, IB_ACCESS_LOCAL_WRITE,
  			&wqe->dma, payload_addr(pkt),
- 			payload_size(pkt), to_mr_obj, NULL);
+ 			payload_size(pkt), RXE_TO_MR_OBJ, NULL);
 -	if (ret)
 +	if (ret) {
 +		wqe->status = IB_WC_LOC_PROT_ERR;
  		return COMPST_ERROR;
 +	}
  
  	if (wqe->dma.resid == 0 && (pkt->mask & RXE_END_MASK))
  		return COMPST_COMP_ACK;
@@@ -367,13 -366,11 +368,13 @@@ static inline enum comp_state do_atomic
  
  	ret = copy_data(qp->pd, IB_ACCESS_LOCAL_WRITE,
  			&wqe->dma, &atomic_orig,
- 			sizeof(u64), to_mr_obj, NULL);
+ 			sizeof(u64), RXE_TO_MR_OBJ, NULL);
 -	if (ret)
 +	if (ret) {
 +		wqe->status = IB_WC_LOC_PROT_ERR;
  		return COMPST_ERROR;
 -	else
 -		return COMPST_COMP_ACK;
 +	}
 +
 +	return COMPST_COMP_ACK;
  }
  
  static void make_send_cqe(struct rxe_qp *qp, struct rxe_send_wqe *wqe,

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/hw/hfi1/hfi.h

between commit:

  5de61a47eb90 ("IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS")

from Linus' tree and commit:

  780278c2c8bb ("IB/hfi1: Rework AIP and VNIC dummy netdev usage")

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/hfi.h
index 2a9a040569eb,2183d02ccfa2..000000000000
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@@ -1408,8 -1402,7 +1402,8 @@@ struct hfi1_devdata 
  	/* Lock to protect IRQ SRC register access */
  	spinlock_t irq_src_lock;
  	int vnic_num_vports;
- 	struct net_device *dummy_netdev;
+ 	struct hfi1_netdev_rx *netdev_rx;
 +	struct hfi1_affinity_node *affinity_entry;
  
  	/* Keeps track of IPoIB RSM rule users */
  	atomic_t ipoib_rsm_usr_num;

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

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

[Martin Wilck]

On Wed, 2021-02-10 at 22:08 +0000, Pearson, Robert B wrote:
> Looks perfect. Thanks.

+1

Thanks everyone.

RE: linux-next: manual merge of the rdma tree with Linus' tree

[Pearson, Robert B]

Looks perfect. Thanks.

-----Original Message-----
From: Jason Gunthorpe <jgg@nvidia.com> 
Sent: Wednesday, February 10, 2021 2:37 PM
To: Pearson, Robert B <robert.pearson2@hpe.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>; Doug Ledford <dledford@redhat.com>; Bob Pearson <rpearsonhpe@gmail.com>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Linux Next Mailing List <linux-next@vger.kernel.org>; Martin Wilck <mwilck@suse.com>
Subject: Re: linux-next: manual merge of the rdma tree with Linus' tree

On Wed, Feb 10, 2021 at 06:57:24PM +0000, Pearson, Robert B wrote:

> It looks like f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code 
> leftovers from RXE"") has not been applied to rdma for-next which is 
> where I do my work. Not sure how it got upstream.

It was sent to the rc tree, don't worry this is stuff I fix up.

Stephen's note is to help ensure it is fixed properly, does the change look OK? It looks like this when applied (I changed Stephen's slightly)

static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb) {
	struct udphdr *udph;
	struct rxe_dev *rxe;
	struct net_device *ndev = skb->dev;
	struct rxe_pkt_info *pkt = SKB_TO_PKT(skb);

	/* takes a reference on rxe->ib_dev
	 * drop when skb is freed
	 */
	rxe = rxe_get_dev_from_net(ndev);
	if (!rxe && is_vlan_dev(rdev))
		rxe = rxe_get_dev_from_net(vlan_dev_real_dev(ndev));
	if (!rxe)
		goto drop;

Jason

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

[Jason Gunthorpe]

On Wed, Feb 10, 2021 at 06:57:24PM +0000, Pearson, Robert B wrote:

> It looks like f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code
> leftovers from RXE"") has not been applied to rdma for-next which is
> where I do my work. Not sure how it got upstream.

It was sent to the rc tree, don't worry this is stuff I fix up.

Stephen's note is to help ensure it is fixed properly, does the change
look OK? It looks like this when applied (I changed Stephen's slightly)

static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
{
	struct udphdr *udph;
	struct rxe_dev *rxe;
	struct net_device *ndev = skb->dev;
	struct rxe_pkt_info *pkt = SKB_TO_PKT(skb);

	/* takes a reference on rxe->ib_dev
	 * drop when skb is freed
	 */
	rxe = rxe_get_dev_from_net(ndev);
	if (!rxe && is_vlan_dev(rdev))
		rxe = rxe_get_dev_from_net(vlan_dev_real_dev(ndev));
	if (!rxe)
		goto drop;

Jason

RE: linux-next: manual merge of the rdma tree with Linus' tree

[Pearson, Robert B]

It looks like f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code leftovers from RXE"") has not been applied to rdma for-next which is where I do my work. Not sure how it got upstream.

bob

-----Original Message-----
From: Stephen Rothwell <sfr@canb.auug.org.au> 
Sent: Tuesday, February 9, 2021 8:16 PM
To: Doug Ledford <dledford@redhat.com>; Jason Gunthorpe <jgg@mellanox.com>
Cc: Pearson, Robert B <robert.pearson2@hpe.com>; Bob Pearson <rpearsonhpe@gmail.com>; Jason Gunthorpe <jgg@nvidia.com>; Jason Gunthorpe <jgg@ziepe.ca>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Linux Next Mailing List <linux-next@vger.kernel.org>; Martin Wilck <mwilck@suse.com>
Subject: linux-next: manual merge of the rdma tree with Linus' tree

Hi all,

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

  drivers/infiniband/sw/rxe/rxe_net.c

between commit:

  f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code leftovers from RXE"")

from Linus' tree and commit:

  899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()")

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/sw/rxe/rxe_net.c
index 943914c2a50c,36d56163afac..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@@ -153,15 -152,14 +153,19 @@@ static struct dst_entry *rxe_find_route
  static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
  {
  	struct udphdr *udph;
+ 	struct rxe_dev *rxe;
  	struct net_device *ndev = skb->dev;
 +	struct net_device *rdev = ndev;
- 	struct rxe_dev *rxe = rxe_get_dev_from_net(ndev);
  	struct rxe_pkt_info *pkt = SKB_TO_PKT(skb);
  
+ 	/* takes a reference on rxe->ib_dev
+ 	 * drop when skb is freed
+ 	 */
+ 	rxe = rxe_get_dev_from_net(ndev);
 +	if (!rxe && is_vlan_dev(rdev)) {
 +		rdev = vlan_dev_real_dev(ndev);
 +		rxe = rxe_get_dev_from_net(rdev);
 +	}
  	if (!rxe)
  		goto drop;
  

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/sw/rxe/rxe_net.c

between commit:

  f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code leftovers from RXE"")

from Linus' tree and commit:

  899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()")

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/sw/rxe/rxe_net.c
index 943914c2a50c,36d56163afac..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@@ -153,15 -152,14 +153,19 @@@ static struct dst_entry *rxe_find_route
  static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
  {
  	struct udphdr *udph;
+ 	struct rxe_dev *rxe;
  	struct net_device *ndev = skb->dev;
 +	struct net_device *rdev = ndev;
- 	struct rxe_dev *rxe = rxe_get_dev_from_net(ndev);
  	struct rxe_pkt_info *pkt = SKB_TO_PKT(skb);
  
+ 	/* takes a reference on rxe->ib_dev
+ 	 * drop when skb is freed
+ 	 */
+ 	rxe = rxe_get_dev_from_net(ndev);
 +	if (!rxe && is_vlan_dev(rdev)) {
 +		rdev = vlan_dev_real_dev(ndev);
 +		rxe = rxe_get_dev_from_net(rdev);
 +	}
  	if (!rxe)
  		goto drop;
  

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

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

[Stephen Rothwell]

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

Hi Jason,

On Tue, 5 Nov 2019 02:21:13 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> The rdma for-next tree is right as is, the xa_erase does not need to
> be the irq varient here.

OK, thanks.  I will fix up my resolution for tomorrow.

-- 
Cheers,
Stephen Rothwell

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

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

[Jason Gunthorpe]

On Tue, Nov 05, 2019 at 12:17:04PM +1100, 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:
> 
>   1524b12a6e02 ("RDMA/mlx5: Use irq xarray locking for mkey_table")
> 
> from Linus' tree and commit:
> 
>   806b101b2bfa ("RDMA/mlx5: Use a dedicated mkey xarray for ODP")
> 
> 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 7019c12005f4,077ca10d9ed9..000000000000
> --- a/drivers/infiniband/hw/mlx5/mr.c
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@@ -1967,8 -1945,7 +1945,7 @@@ int mlx5_ib_dealloc_mw(struct ib_mw *mw
>   	int err;
>   
>   	if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING)) {
> - 		xa_erase_irq(&dev->mdev->priv.mkey_table,
> - 			     mlx5_base_mkey(mmw->mmkey.key));
>  -		xa_erase(&dev->odp_mkeys, mlx5_base_mkey(mmw->mmkey.key));
> ++		xa_erase_irq(&dev->odp_mkeys, mlx5_base_mkey(mmw->mmkey.key));

The rdma for-next tree is right as is, the xa_erase does not need to
be the irq varient here.

Thanks,
Jason

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/hw/mlx5/mr.c

between commit:

  1524b12a6e02 ("RDMA/mlx5: Use irq xarray locking for mkey_table")

from Linus' tree and commit:

  806b101b2bfa ("RDMA/mlx5: Use a dedicated mkey xarray for ODP")

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 7019c12005f4,077ca10d9ed9..000000000000
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@@ -1967,8 -1945,7 +1945,7 @@@ int mlx5_ib_dealloc_mw(struct ib_mw *mw
  	int err;
  
  	if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING)) {
- 		xa_erase_irq(&dev->mdev->priv.mkey_table,
- 			     mlx5_base_mkey(mmw->mmkey.key));
 -		xa_erase(&dev->odp_mkeys, mlx5_base_mkey(mmw->mmkey.key));
++		xa_erase_irq(&dev->odp_mkeys, mlx5_base_mkey(mmw->mmkey.key));
  		/*
  		 * pagefault_single_data_segment() may be accessing mmw under
  		 * SRCU if the user bound an ODP MR to this MW.

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

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

[Jason Gunthorpe]

On Thu, Oct 24, 2019 at 11:01:15AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/mlx5/odp.c
> 
> between commit:
> 
>   9dc775e7f550 ("RDMA/odp: Lift umem_mutex out of ib_umem_odp_unmap_dma_pages()")
> 
> from Linus' tree and commit:
> 
>   a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters")
> 
> from the rdma tree.
> 
> I fixed it up (see below - but maybe the mlx5_update_odp_stats()
> also needs to move after the moved mutex_unlock()?) 

nope, this resolution is right, thanks

Jason

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/hw/mlx5/odp.c

between commit:

  9dc775e7f550 ("RDMA/odp: Lift umem_mutex out of ib_umem_odp_unmap_dma_pages()")

from Linus' tree and commit:

  a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters")

from the rdma tree.

I fixed it up (see below - but maybe the mlx5_update_odp_stats()
also needs to move after the moved mutex_unlock()?) 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/odp.c
index 3f9478d19376,2ab6e44aeaae..000000000000
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@@ -308,6 -282,10 +312,9 @@@ void mlx5_ib_invalidate_range(struct ib
  				   idx - blk_start_idx + 1, 0,
  				   MLX5_IB_UPD_XLT_ZAP |
  				   MLX5_IB_UPD_XLT_ATOMIC);
 -	mutex_unlock(&umem_odp->umem_mutex);
+ 
+ 	mlx5_update_odp_stats(mr, invalidations, invalidations);
+ 
  	/*
  	 * We are now sure that the device will not access the
  	 * memory. We can safely unmap it, and mark it as dirty if
@@@ -316,10 -294,10 +323,11 @@@
  
  	ib_umem_odp_unmap_dma_pages(umem_odp, start, end);
  
+ 
  	if (unlikely(!umem_odp->npages && mr->parent &&
  		     !umem_odp->dying)) {
 -		WRITE_ONCE(umem_odp->dying, 1);
 +		WRITE_ONCE(mr->live, 0);
 +		umem_odp->dying = 1;
  		atomic_inc(&mr->parent->num_leaf_free);
  		schedule_work(&umem_odp->work);
  	}
@@@ -567,8 -542,9 +573,10 @@@ struct mlx5_ib_mr *mlx5_ib_alloc_implic
  	init_waitqueue_head(&imr->q_leaf_free);
  	atomic_set(&imr->num_leaf_free, 0);
  	atomic_set(&imr->num_pending_prefetch, 0);
 +	smp_store_release(&imr->live, 1);
  
+ 	imr->is_odp_implicit = true;
+ 
  	return imr;
  }
  

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

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

[Doug Ledford]

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

On Thu, 2019-06-20 at 12:10 +1000, Stephen Rothwell wrote:
>   2d3c72ed5041 ("rdma: Remove nes")

Yeah, not much you can do about tree wide patchsets conflicting with a
removal ;-)

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    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 Linus' tree

[Doug Ledford]

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

On Thu, 2019-06-20 at 12:06 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   include/rdma/ib_verbs.h
> 
> between commit:
> 
>   dc1435c00fcd ("RDMA/srp: Rename SRP sysfs name after IB device
> rename trigger")
> 
> from Linus' tree and commit:
> 
>   0e2d00eb6fd4 ("RDMA: Add NLDEV_GET_CHARDEV to allow char dev
> discovery and autoload")
> 
> 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.
> 

Yep, this one was expected.  Thanks.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    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 --]

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/hw/nes/Kconfig
  drivers/infiniband/hw/nes/Makefile

between commit:

  ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")

from Linus' tree and commit:

  2d3c72ed5041 ("rdma: Remove nes")

from the rdma tree.

I fixed it up (I just removed the files) 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

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  include/rdma/ib_verbs.h

between commit:

  dc1435c00fcd ("RDMA/srp: Rename SRP sysfs name after IB device rename trigger")

from Linus' tree and commit:

  0e2d00eb6fd4 ("RDMA: Add NLDEV_GET_CHARDEV to allow char dev discovery and autoload")

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 include/rdma/ib_verbs.h
index 54873085f2da,6f09fcc21d7a..000000000000
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@@ -2698,7 -2690,9 +2690,10 @@@ struct ib_client 
  	const char *name;
  	void (*add)   (struct ib_device *);
  	void (*remove)(struct ib_device *, void *client_data);
 +	void (*rename)(struct ib_device *dev, void *client_data);
+ 	int (*get_nl_info)(struct ib_device *ibdev, void *client_data,
+ 			   struct ib_client_nl_info *res);
+ 	int (*get_global_nl_info)(struct ib_client_nl_info *res);
  
  	/* Returns the net_dev belonging to this ib_client and matching the
  	 * given parameters.

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

RE: linux-next: manual merge of the rdma tree with Linus' tree

[Parav Pandit]

Hi Stephen,

> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Thursday, September 27, 2018 7:01 PM
> To: Doug Ledford <dledford@redhat.com>; Jason Gunthorpe
> <jgg@mellanox.com>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Parav Pandit
> <parav@mellanox.com>
> Subject: linux-next: manual merge of the rdma tree with Linus' tree
> 
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/core/cache.c
> 
> between commit:
> 
>   5c5702e259dc ("RDMA/core: Set right entry state before releasing
> reference")
> 
> from Linus' tree and commit:
> 
>   43c7c851b9bc ("RDMA/core: Use dev_err/dbg/etc instead of pr_* + ibdev-
> >name")
> 
> 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.
> 

Sorry for the late reply. For some reason mail ended up in spam folder which I noticed now.
I should have watched the device naming series.
My fix went to for-rc and I guess it wasn't applied to for-next which resulted into this merge conflict.
My understanding is, maintainers usually try to avoid merge conflict between for-next and for-rc branches before sending pull request from rdma tree.
I will try to be more careful in future to notify maintainer about it.

Your changes below looks good. Thanks.
Reviewed-by: Parav Pandit <parav@mellanox.com> 
> --
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/infiniband/core/cache.c index
> 3208ad6ad540,ebc64418d809..000000000000
> --- a/drivers/infiniband/core/cache.c
> +++ b/drivers/infiniband/core/cache.c
> @@@ -337,39 -335,6 +335,38 @@@ static int add_roce_gid(struct ib_gid_t
>   	return 0;
>   }
> 
>  +/**
>  + * del_gid - Delete GID table entry
>  + *
>  + * @ib_dev:	IB device whose GID entry to be deleted
>  + * @port:	Port number of the IB device
>  + * @table:	GID table of the IB device for a port
>  + * @ix:		GID entry index to delete
>  + *
>  + */
>  +static void del_gid(struct ib_device *ib_dev, u8 port,
>  +		    struct ib_gid_table *table, int ix)
>  +{
>  +	struct ib_gid_table_entry *entry;
>  +
>  +	lockdep_assert_held(&table->lock);
>  +
> - 	pr_debug("%s device=%s port=%d index=%d gid %pI6\n", __func__,
> - 		 ib_dev->name, port, ix,
> - 		 table->data_vec[ix]->attr.gid.raw);
> ++	dev_dbg(&ib_dev->dev, "%s port=%d index=%d gid %pI6\n",
>__func__, port,
> ++		ix, table->data_vec[ix]->attr.gid.raw);
>  +
>  +	write_lock_irq(&table->rwlock);
>  +	entry = table->data_vec[ix];
>  +	entry->state = GID_TABLE_ENTRY_PENDING_DEL;
>  +	/*
>  +	 * For non RoCE protocol, GID entry slot is ready to use.
>  +	 */
>  +	if (!rdma_protocol_roce(ib_dev, port))
>  +		table->data_vec[ix] = NULL;
>  +	write_unlock_irq(&table->rwlock);
>  +
>  +	put_gid_entry_locked(entry);
>  +}
>  +
>   /**
>    * add_modify_gid - Add or modify GID table entry
>    *

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/core/cache.c

between commit:

  5c5702e259dc ("RDMA/core: Set right entry state before releasing reference")

from Linus' tree and commit:

  43c7c851b9bc ("RDMA/core: Use dev_err/dbg/etc instead of pr_* + ibdev->name")

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/cache.c
index 3208ad6ad540,ebc64418d809..000000000000
--- a/drivers/infiniband/core/cache.c
+++ b/drivers/infiniband/core/cache.c
@@@ -337,39 -335,6 +335,38 @@@ static int add_roce_gid(struct ib_gid_t
  	return 0;
  }
  
 +/**
 + * del_gid - Delete GID table entry
 + *
 + * @ib_dev:	IB device whose GID entry to be deleted
 + * @port:	Port number of the IB device
 + * @table:	GID table of the IB device for a port
 + * @ix:		GID entry index to delete
 + *
 + */
 +static void del_gid(struct ib_device *ib_dev, u8 port,
 +		    struct ib_gid_table *table, int ix)
 +{
 +	struct ib_gid_table_entry *entry;
 +
 +	lockdep_assert_held(&table->lock);
 +
- 	pr_debug("%s device=%s port=%d index=%d gid %pI6\n", __func__,
- 		 ib_dev->name, port, ix,
- 		 table->data_vec[ix]->attr.gid.raw);
++	dev_dbg(&ib_dev->dev, "%s port=%d index=%d gid %pI6\n", __func__, port,
++		ix, table->data_vec[ix]->attr.gid.raw);
 +
 +	write_lock_irq(&table->rwlock);
 +	entry = table->data_vec[ix];
 +	entry->state = GID_TABLE_ENTRY_PENDING_DEL;
 +	/*
 +	 * For non RoCE protocol, GID entry slot is ready to use.
 +	 */
 +	if (!rdma_protocol_roce(ib_dev, port))
 +		table->data_vec[ix] = NULL;
 +	write_unlock_irq(&table->rwlock);
 +
 +	put_gid_entry_locked(entry);
 +}
 +
  /**
   * add_modify_gid - Add or modify GID table entry
   *

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

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

[Stephen Rothwell]

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

Hi Jason,

On Mon, 6 Aug 2018 13:41:42 -0600 Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> The resolution should end up like this:
> 
>         srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
> 
>         if (!verify_command_mask(file, command, extended)) {
>                 ret = -EOPNOTSUPP;
>                 goto out;
>         }
> 
> (ie take the hunk from for-next, discard the for-rc stuff)
> 
> As commit 22fa27fbc64d01cbbe1e4da751e64cc22d24a6e4 also removed the
> 'file->ucontext' stuff

Thanks, I have fixed up my resolution today.

-- 
Cheers,
Stephen Rothwell

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

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

[Jason Gunthorpe]

On Mon, Aug 06, 2018 at 12:01:31PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/core/uverbs_main.c
> 
> between commit:
> 
>   1eb9364ce81d ("IB/uverbs: Fix ordering of ucontext check in ib_uverbs_write")
> 
> from Linus' tree and commit:
> 
>   a9b66d6453d7 ("IB/uverbs: Do not block disassociate during write()")
> 
> from the rdma tree.
> 
> I fixed it up (I am not entirely sure this is correct, but 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.

> diff --cc drivers/infiniband/core/uverbs_main.c
> index 2094d136513d,6f62146e9738..000000000000
> --- a/drivers/infiniband/core/uverbs_main.c
> +++ b/drivers/infiniband/core/uverbs_main.c
> @@@ -748,24 -758,8 +758,18 @@@ static ssize_t ib_uverbs_write(struct f
>   		return ret;
>   
>   	srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
> - 	ib_dev = srcu_dereference(file->device->ib_dev,
> - 				  &file->device->disassociate_srcu);
> - 	if (!ib_dev) {
> - 		ret = -EIO;
> - 		goto out;
> - 	}
>   
>  +	/*
>  +	 * Must be after the ib_dev check, as once the RCU clears ib_dev ==
>  +	 * NULL means ucontext == NULL
>  +	 */
>  +	if (!file->ucontext &&
>  +	    (command != IB_USER_VERBS_CMD_GET_CONTEXT || extended)) {
>  +		ret = -EINVAL;
>  +		goto out;
>  +	}
>  +
> - 	if (!verify_command_mask(ib_dev, command, extended)) {
> + 	if (!verify_command_mask(file, command, extended)) {
>   		ret = -EOPNOTSUPP;
>   		goto out;
>   	}

The resolution should end up like this:

        srcu_key = srcu_read_lock(&file->device->disassociate_srcu);

        if (!verify_command_mask(file, command, extended)) {
                ret = -EOPNOTSUPP;
                goto out;
        }

(ie take the hunk from for-next, discard the for-rc stuff)

As commit 22fa27fbc64d01cbbe1e4da751e64cc22d24a6e4 also removed the
'file->ucontext' stuff

Thanks,
Jason

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/infiniband/core/uverbs_main.c

between commit:

  1eb9364ce81d ("IB/uverbs: Fix ordering of ucontext check in ib_uverbs_write")

from Linus' tree and commit:

  a9b66d6453d7 ("IB/uverbs: Do not block disassociate during write()")

from the rdma tree.

I fixed it up (I am not entirely sure this is correct, but 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_main.c
index 2094d136513d,6f62146e9738..000000000000
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@@ -748,24 -758,8 +758,18 @@@ static ssize_t ib_uverbs_write(struct f
  		return ret;
  
  	srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
- 	ib_dev = srcu_dereference(file->device->ib_dev,
- 				  &file->device->disassociate_srcu);
- 	if (!ib_dev) {
- 		ret = -EIO;
- 		goto out;
- 	}
  
 +	/*
 +	 * Must be after the ib_dev check, as once the RCU clears ib_dev ==
 +	 * NULL means ucontext == NULL
 +	 */
 +	if (!file->ucontext &&
 +	    (command != IB_USER_VERBS_CMD_GET_CONTEXT || extended)) {
 +		ret = -EINVAL;
 +		goto out;
 +	}
 +
- 	if (!verify_command_mask(ib_dev, command, extended)) {
+ 	if (!verify_command_mask(file, command, extended)) {
  		ret = -EOPNOTSUPP;
  		goto out;
  	}

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/mellanox/mlx5/core/main.c

between commit:

  eeb66cdb6826 ("net/mlx5: Separate between E-Switch and MPFS")

from Linus' tree and commit:

  c85023e153e3 ("IB/mlx5: Add raw ethernet local loopback support")

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/net/ethernet/mellanox/mlx5/core/main.c
index 6dbd637b4e66,3cec683fd70f..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@@ -1155,6 -1168,16 +1168,12 @@@ static int mlx5_load_one(struct mlx5_co
  		goto err_fs;
  	}
  
+ 	err = mlx5_core_set_hca_defaults(dev);
+ 	if (err) {
+ 		dev_err(&pdev->dev, "Failed to set hca defaults\n");
+ 		goto err_fs;
+ 	}
+ 
 -#ifdef CONFIG_MLX5_CORE_EN
 -	mlx5_eswitch_attach(dev->priv.eswitch);
 -#endif
 -
  	err = mlx5_sriov_attach(dev);
  	if (err) {
  		dev_err(&pdev->dev, "sriov init failed %d\n", err);

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

[Leon Romanovsky]

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

On Fri, Jul 14, 2017 at 10:33:54AM -0400, Doug Ledford wrote:
> So, you need to take your pick.  Do you want continuous development, or
> do you want me bending over backwards to try and avoid your company's
> endless stream of conflicts so Linus isn't yelling about that?

Doug,

You are mixing my warning of merge conflict in mlx4 code, which we never
prepared for shared code and whole Mellanox submissions (IPoIB, mlx5,
core, e.t.c).

To make long story short, if you can assure that public branches will be
updated in WEEKLY manner, I'll do everything internally FOR ALL RDMA
related stuff (and not mlx5 only) to avoid merge conflicts, and you will
get clean and ready apply topics exactly as DaveM receiving,

It works pretty well for rdma-core, once the discussion is stopped,
we are checking go/no-go and applying or asking to resubmit. For very
major changes, the delay is a little bit longer.

So yes, I prefer truly continuous development over unclear future.

Thanks

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

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

[Doug Ledford]

On Fri, 2017-07-14 at 07:54 +0300, Leon Romanovsky wrote:
> On Fri, Jul 14, 2017 at 12:12:33AM -0400, Doug Ledford wrote:
> > On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote:
> > > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote:
> > > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> > > > > Hi Doug,
> > > > > 
> > > > > Today's linux-next merge of the rdma tree got conflicts in:
> > > > > 
> > > > >   drivers/infiniband/core/uverbs_cmd.c
> > > > >   drivers/infiniband/core/verbs.c
> > > > > 
> > > > > between commit:
> > > > > 
> > > > >   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> > > > > 
> > > > > from Linus' tree and commits:
> > > > > 
> > > > >   c7c0fb974caa ("IB/core: Introduce modify QP operation with
> > > > > udata")
> > > > >   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant
> > > > > to
> > > > > avoid
> > > > > resolving DMAC")
> > > > > 
> > > > > from the rdma tree.
> > > > > 
> > > > > I fixed it up (I used the latter version of uverbs_cmd.c and
> > > > > 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.
> > > > 
> > > > This was expected.  The SELinux changes went through the
> > > > SELinux
> > > > tree
> > > > and the referenced patches touch the same code.  Your fix is
> > > > correct.
> > > 
> > > Sorry Doug, but it is not expected at all for the code which will
> > > go
> > > to 4.14.
> > 
> > Who said anything about 4.14?  The merge window is not closed, and
> > a
> > current for-next tag need not represent code intended for
> > 4.14.  That
> > switchover doesn't happen until the merge window closes (and for
> > many
> > trees, a couple rc cycles past the merge window closing).
> 
> Really, "couple"?
> Your tree contains enormous amount of code, you was listed as one of
> top-pusher,
> and you still behave like your tree has one or two patches in the
> cycle.
> 
> All major trees with similar volume of patches are doing incremental
> development and not "one-time" shots.

I *did* do incremental development.  By LOC count, 3/4 of what's in my
current tree was there since back in June.  And I grabbed it and
started working on it as soon as I was told that the patch I was
waiting on, from your company, was finally in DaveM's tree so I could
finally pull a net-next starting point upon which to base your patches
on.  Once I had that starting point, I started taking code.  I started
with the Intel stuff this time since I started with Mellanox stuff last
time.

Or do you not remember that email conversation?  If not, I'll refresh
your memory (paraphrased):

Me: Are we ready to go yet, I pulled DaveM's net-next today? <- 6/14
You: Not quite yet.  Today's net-next is enough for two of three
conflicting patches, but to fix the third you need another one.
Me: OK, send it quickly.
You: We'll submit it right away. (and you didn't Cc: me or linux-rdma
on the patchset so I didn't see any of it)
<time passes>
Me: Hey, did you ever get that patch in? <- this was on 6/25
You: Oh, yeah, here's the commit hash. <- this was on 6/25 too

Then if you look in my tree, the hfi patches start here:

Commit:     Doug Ledford <dledford@redhat.com>
CommitDate: Tue Jun 27 16:56:33 2017 -0400

Now, Linus and I have already talked about this off list some, and one
of the things that will help with this is if I don't even try to merge
up all of my branches into one branch.  This way I can start branches
for people that don't have dependencies on Dave's tree as soon as I
want to.  The downside of this is that we won't necessarily have a
fully merged up tree to test against during development.

But, what's making me mad about this email exchange right now is that
you and your company routinely ask me to hold off until you have stuff
in Dave Miller's tree and then want me to do all of my work after that
and before the next merge window, and then you complain that I'm not
doing things as a continuous development process.  Look at the dates
above.  When I asked, and it wasn't ready, was 6/14.  Linus opened the
merge window on 7/3, which was not even three weeks later.  I didn't
get final notice that it *was* ready until 6/25, right at one week
before the merge window opened.

So, you need to take your pick.  Do you want continuous development, or
do you want me bending over backwards to try and avoid your company's
endless stream of conflicts so Linus isn't yelling about that?  But
complaining at me on a public list when you left me only one week to do
my work (even though I thought I had two) just doesn't cut it for me.

> > > Both patches in question were targeted for 4.13 and you was
> > > expected
> > > to
> > > see the merge conflicts during last month or so, prior to merge
> > > window of 4.13.
> > > 
> > > In 4.14, you should base your tree on Linus's tree and don't have
> > > ANY
> > > conflicts in your subsystem, between ANY subsystems and
> > > especially
> > > Linus, so we will be able to develop and test.
> > 
> > I'm sure for 4.14 that will be the issue.  I didn't put this tag on
> > my
> > 4.14 intended work.  I considered this patch series suitable as
> > possible -rc fixes, so it is under a for-next tag for now to get
> > the
> > for-next testing (which is not much different than a local merge
> > test
> > right now, what it does in addition to a local merge test is catch
> > the
> > situation where some other pending patches and this conflict).
> 
> I don't get it, linux-next is much more than simple merge test. The
> overall
> goal of linux-next is to allow other people to test it BEFORE it hits
> Linus.
> 
> We want to run our verification on it and catch bugs BETWEEN
> subsystems
> (RoCE, iWARP and IPoIB for netdev vs. rdma) in advance and not after.

Sure.  And by LOC count, 75% of my current branch has been in for-next
for weeks.  Only the patches I deemed as possible -rc candidates are
newly added.

> > 
> > > For me, this merge conflict puts a large sign, that your tree is
> > > not
> > > ready for 4.14.
> > > 
> > > Please base your tree on Linus's tree.
> > 
> > Two things here.  First, no one, and I mean *NO ONE*, bases their
> > for-
> > next branch on a middle of the merge window version of Linus' tree.
> > Second, I would be happy to base my work on a suitable base kernel
> > version from Linus' tree from now on (such as -rc2).  Please do
> > *NOT*
> > send me another patch set that requires I sync up from net-next in
> > order to make things work, because, as you say, I should sync up to
> > Linus' tree.
> 
> Really? Are you comparing base point of 4.14 development with your
> stalled
> for weeks branches?

Check the email record Leon.  He who stalls me is not the right person
to be bitching about me being stalled.

> Start to work incrementally, update your branches constantly and such
> requests will disappear, so we will be able to plan and not to guess.

I got your notice that the proper commit hash was ready in DaveM's
tree, I started with hfi1, I then switched to looking/working on the
-rc kernels, then there was a Holiday, then there was one last patch
for -rc that I was waiting on to fix the IPoIB issue, but, as has
already been pointed out, while I was working on these -rc fixes, the
merge window had already opened unbeknownst to me.  So I made myself
look foolish for sending a pull request for an -rc cycle that was
already closed.  After that, I tried to get my work on the for-next
branch done quickly, but because it wasn't done prior to July 3rd,
which really means June 30 because July 3rd was really only a partial
day because of the holiday on July 4th in the US, Linus rejected all of
it.  But go back and check those dates Leon.  I had 5 days from the
time you got me the commit hash to complete everything.  If I had known
that the -rc cycle was closed I probably could have gotten it all done,
but I wasted time on the wrong kernel, sorry.  But you have no right to
complain with these dates being what they are when they are that way
because of working with your needs.

> I respect your hard work and what you are doing, but struggling to
> understand
> why don't you want to make it more effective and less error prone.

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

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

[Leon Romanovsky]

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

On Fri, Jul 14, 2017 at 08:03:49AM -0400, Doug Ledford wrote:
> On Fri, 2017-07-14 at 07:55 +0300, Leon Romanovsky wrote:
> > On Fri, Jul 14, 2017 at 01:50:26PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky <leon@kernel.org
> > > > wrote:
> > > >
> > > > Sorry Doug, but it is not expected at all for the code which will
> > > > go to 4.14.
> > > >
> > > > Both patches in question were targeted for 4.13 and you was
> > > > expected to
> > > > see the merge conflicts during last month or so, prior to merge
> > > > window of 4.13.
> > > >
> > > > In 4.14, you should base your tree on Linus's tree and don't have
> > > > ANY
> > > > conflicts in your subsystem, between ANY subsystems and
> > > > especially
> > > > Linus, so we will be able to develop and test.
> > > >
> > > > For me, this merge conflict puts a large sign, that your tree is
> > > > not ready for 4.14.
> > > >
> > > > Please base your tree on Linus's tree.
> > >
> > > And if these commits are destined for v4.14, then they should not
> > > have
> > > been in linux-next yet.
> >
> > See, this announcement,
> > http://marc.info/?l=linux-rdma&m=149980130008834&w=2
>
> Yes, and the patch in question is one of the many that I pulled out as
> fixes that I would end up submitting during the -rc cycle.  Hence why I
> put the for-next tag on it.

OK, hope that the picture with your branches will be clear very soon.
Till when we can't create shared code.

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 Linus' tree

[Doug Ledford]

On Fri, 2017-07-14 at 07:55 +0300, Leon Romanovsky wrote:
> On Fri, Jul 14, 2017 at 01:50:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky <leon@kernel.org
> > > wrote:
> > > 
> > > Sorry Doug, but it is not expected at all for the code which will
> > > go to 4.14.
> > > 
> > > Both patches in question were targeted for 4.13 and you was
> > > expected to
> > > see the merge conflicts during last month or so, prior to merge
> > > window of 4.13.
> > > 
> > > In 4.14, you should base your tree on Linus's tree and don't have
> > > ANY
> > > conflicts in your subsystem, between ANY subsystems and
> > > especially
> > > Linus, so we will be able to develop and test.
> > > 
> > > For me, this merge conflict puts a large sign, that your tree is
> > > not ready for 4.14.
> > > 
> > > Please base your tree on Linus's tree.
> > 
> > And if these commits are destined for v4.14, then they should not
> > have
> > been in linux-next yet.
> 
> See, this announcement,
> http://marc.info/?l=linux-rdma&m=149980130008834&w=2

Yes, and the patch in question is one of the many that I pulled out as
fixes that I would end up submitting during the -rc cycle.  Hence why I
put the for-next tag on it.

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

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

[Leon Romanovsky]

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

On Fri, Jul 14, 2017 at 01:50:26PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky <leon@kernel.org> wrote:
> >
> > Sorry Doug, but it is not expected at all for the code which will go to 4.14.
> >
> > Both patches in question were targeted for 4.13 and you was expected to
> > see the merge conflicts during last month or so, prior to merge window of 4.13.
> >
> > In 4.14, you should base your tree on Linus's tree and don't have ANY
> > conflicts in your subsystem, between ANY subsystems and especially
> > Linus, so we will be able to develop and test.
> >
> > For me, this merge conflict puts a large sign, that your tree is not ready for 4.14.
> >
> > Please base your tree on Linus's tree.
>
> And if these commits are destined for v4.14, then they should not have
> been in linux-next yet.

See, this announcement,
http://marc.info/?l=linux-rdma&m=149980130008834&w=2

Thanks

>
> --
> Cheers,
> Stephen Rothwell

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

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

[Leon Romanovsky]

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

On Fri, Jul 14, 2017 at 12:12:33AM -0400, Doug Ledford wrote:
> On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote:
> > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote:
> > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> > > > Hi Doug,
> > > >
> > > > Today's linux-next merge of the rdma tree got conflicts in:
> > > >
> > > >   drivers/infiniband/core/uverbs_cmd.c
> > > >   drivers/infiniband/core/verbs.c
> > > >
> > > > between commit:
> > > >
> > > >   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> > > >
> > > > from Linus' tree and commits:
> > > >
> > > >   c7c0fb974caa ("IB/core: Introduce modify QP operation with
> > > > udata")
> > > >   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to
> > > > avoid
> > > > resolving DMAC")
> > > >
> > > > from the rdma tree.
> > > >
> > > > I fixed it up (I used the latter version of uverbs_cmd.c and 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.
> > >
> > > This was expected.  The SELinux changes went through the SELinux
> > > tree
> > > and the referenced patches touch the same code.  Your fix is
> > > correct.
> >
> > Sorry Doug, but it is not expected at all for the code which will go
> > to 4.14.
>
> Who said anything about 4.14?  The merge window is not closed, and a
> current for-next tag need not represent code intended for 4.14.  That
> switchover doesn't happen until the merge window closes (and for many
> trees, a couple rc cycles past the merge window closing).

Really, "couple"?
Your tree contains enormous amount of code, you was listed as one of top-pusher,
and you still behave like your tree has one or two patches in the cycle.

All major trees with similar volume of patches are doing incremental
development and not "one-time" shots.

>
> > Both patches in question were targeted for 4.13 and you was expected
> > to
> > see the merge conflicts during last month or so, prior to merge
> > window of 4.13.
> >
> > In 4.14, you should base your tree on Linus's tree and don't have ANY
> > conflicts in your subsystem, between ANY subsystems and especially
> > Linus, so we will be able to develop and test.
>
> I'm sure for 4.14 that will be the issue.  I didn't put this tag on my
> 4.14 intended work.  I considered this patch series suitable as
> possible -rc fixes, so it is under a for-next tag for now to get the
> for-next testing (which is not much different than a local merge test
> right now, what it does in addition to a local merge test is catch the
> situation where some other pending patches and this conflict).

I don't get it, linux-next is much more than simple merge test. The overall
goal of linux-next is to allow other people to test it BEFORE it hits Linus.

We want to run our verification on it and catch bugs BETWEEN subsystems
(RoCE, iWARP and IPoIB for netdev vs. rdma) in advance and not after.

>
> > For me, this merge conflict puts a large sign, that your tree is not
> > ready for 4.14.
> >
> > Please base your tree on Linus's tree.
>
> Two things here.  First, no one, and I mean *NO ONE*, bases their for-
> next branch on a middle of the merge window version of Linus' tree.
> Second, I would be happy to base my work on a suitable base kernel
> version from Linus' tree from now on (such as -rc2).  Please do *NOT*
> send me another patch set that requires I sync up from net-next in
> order to make things work, because, as you say, I should sync up to
> Linus' tree.

Really? Are you comparing base point of 4.14 development with your stalled
for weeks branches?

Start to work incrementally, update your branches constantly and such
requests will disappear, so we will be able to plan and not to guess.

I respect your hard work and what you are doing, but struggling to understand
why don't you want to make it more effective and less error prone.

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 Linus' tree

[Doug Ledford]

On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote:
> On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote:
> > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> > > Hi Doug,
> > > 
> > > Today's linux-next merge of the rdma tree got conflicts in:
> > > 
> > >   drivers/infiniband/core/uverbs_cmd.c
> > >   drivers/infiniband/core/verbs.c
> > > 
> > > between commit:
> > > 
> > >   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> > > 
> > > from Linus' tree and commits:
> > > 
> > >   c7c0fb974caa ("IB/core: Introduce modify QP operation with
> > > udata")
> > >   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to
> > > avoid
> > > resolving DMAC")
> > > 
> > > from the rdma tree.
> > > 
> > > I fixed it up (I used the latter version of uverbs_cmd.c and 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.
> > 
> > This was expected.  The SELinux changes went through the SELinux
> > tree
> > and the referenced patches touch the same code.  Your fix is
> > correct.
> 
> Sorry Doug, but it is not expected at all for the code which will go
> to 4.14.

Who said anything about 4.14?  The merge window is not closed, and a
current for-next tag need not represent code intended for 4.14.  That
switchover doesn't happen until the merge window closes (and for many
trees, a couple rc cycles past the merge window closing).

> Both patches in question were targeted for 4.13 and you was expected
> to
> see the merge conflicts during last month or so, prior to merge
> window of 4.13.
> 
> In 4.14, you should base your tree on Linus's tree and don't have ANY
> conflicts in your subsystem, between ANY subsystems and especially
> Linus, so we will be able to develop and test.

I'm sure for 4.14 that will be the issue.  I didn't put this tag on my
4.14 intended work.  I considered this patch series suitable as
possible -rc fixes, so it is under a for-next tag for now to get the
for-next testing (which is not much different than a local merge test
right now, what it does in addition to a local merge test is catch the
situation where some other pending patches and this conflict).

> For me, this merge conflict puts a large sign, that your tree is not
> ready for 4.14.
> 
> Please base your tree on Linus's tree.

Two things here.  First, no one, and I mean *NO ONE*, bases their for-
next branch on a middle of the merge window version of Linus' tree. 
Second, I would be happy to base my work on a suitable base kernel
version from Linus' tree from now on (such as -rc2).  Please do *NOT*
send me another patch set that requires I sync up from net-next in
order to make things work, because, as you say, I should sync up to
Linus' tree.

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

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

[Stephen Rothwell]

Hi all,

On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky <leon@kernel.org> wrote:
>
> Sorry Doug, but it is not expected at all for the code which will go to 4.14.
> 
> Both patches in question were targeted for 4.13 and you was expected to
> see the merge conflicts during last month or so, prior to merge window of 4.13.
> 
> In 4.14, you should base your tree on Linus's tree and don't have ANY
> conflicts in your subsystem, between ANY subsystems and especially
> Linus, so we will be able to develop and test.
> 
> For me, this merge conflict puts a large sign, that your tree is not ready for 4.14.
> 
> Please base your tree on Linus's tree.

And if these commits are destined for v4.14, then they should not have
been in linux-next yet.

-- 
Cheers,
Stephen Rothwell

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

[Leon Romanovsky]

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

On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote:
> On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> > Hi Doug,
> >
> > Today's linux-next merge of the rdma tree got conflicts in:
> >
> >   drivers/infiniband/core/uverbs_cmd.c
> >   drivers/infiniband/core/verbs.c
> >
> > between commit:
> >
> >   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> >
> > from Linus' tree and commits:
> >
> >   c7c0fb974caa ("IB/core: Introduce modify QP operation with udata")
> >   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to avoid
> > resolving DMAC")
> >
> > from the rdma tree.
> >
> > I fixed it up (I used the latter version of uverbs_cmd.c and 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.
>
> This was expected.  The SELinux changes went through the SELinux tree
> and the referenced patches touch the same code.  Your fix is correct.

Sorry Doug, but it is not expected at all for the code which will go to 4.14.

Both patches in question were targeted for 4.13 and you was expected to
see the merge conflicts during last month or so, prior to merge window of 4.13.

In 4.14, you should base your tree on Linus's tree and don't have ANY
conflicts in your subsystem, between ANY subsystems and especially
Linus, so we will be able to develop and test.

For me, this merge conflict puts a large sign, that your tree is not ready for 4.14.

Please base your tree on Linus's tree.

Thanks

> 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 Linus' tree

[Doug Ledford]

On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> Hi Doug,
> 
> Today's linux-next merge of the rdma tree got conflicts in:
> 
>   drivers/infiniband/core/uverbs_cmd.c
>   drivers/infiniband/core/verbs.c
> 
> between commit:
> 
>   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> 
> from Linus' tree and commits:
> 
>   c7c0fb974caa ("IB/core: Introduce modify QP operation with udata")
>   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to avoid
> resolving DMAC")
> 
> from the rdma tree.
> 
> I fixed it up (I used the latter version of uverbs_cmd.c and 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.

This was expected.  The SELinux changes went through the SELinux tree
and the referenced patches touch the same code.  Your fix is correct. 
Thanks.

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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/infiniband/core/uverbs_cmd.c
  drivers/infiniband/core/verbs.c

between commit:

  d291f1a65232 ("IB/core: Enforce PKey security on QPs")

from Linus' tree and commits:

  c7c0fb974caa ("IB/core: Introduce modify QP operation with udata")
  5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to avoid resolving DMAC")

from the rdma tree.

I fixed it up (I used the latter version of uverbs_cmd.c and 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/verbs.c
index c973a83c898b,8ece2aae033d..000000000000
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@@ -1280,8 -1283,15 +1298,15 @@@ int ib_modify_qp_with_udata(struct ib_q
  		if (ret)
  			return ret;
  	}
 -	return qp->device->modify_qp(qp->real_qp, attr, attr_mask, udata);
++	return ib_security_modify_qp(qp->real_qp, attr, attr_mask, udata);
+ }
+ EXPORT_SYMBOL(ib_modify_qp_with_udata);
  
- 	return ib_security_modify_qp(qp->real_qp, qp_attr, qp_attr_mask, NULL);
+ int ib_modify_qp(struct ib_qp *qp,
+ 		 struct ib_qp_attr *qp_attr,
+ 		 int qp_attr_mask)
+ {
+ 	return ib_modify_qp_with_udata(qp, qp_attr, qp_attr_mask, NULL);
  }
  EXPORT_SYMBOL(ib_modify_qp);
  

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/infiniband/sw/rxe/rxe_req.c

between commit:

  002e062e13db ("IB/rxe: Fix handling of erroneous WR")

from Linus' tree and commit:

  37f69f43fb5a ("IB/rxe: Hold refs when running tasklets")

from the rdma tree.

I fixed it up (I think - see below - thanks for the heads up, Doug) 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_req.c
index 22bd9630dcd9,b246653cf713..000000000000
--- a/drivers/infiniband/sw/rxe/rxe_req.c
+++ b/drivers/infiniband/sw/rxe/rxe_req.c
@@@ -696,8 -698,7 +698,9 @@@ next_wqe
  						       qp->req.wqe_index);
  			wqe->state = wqe_state_done;
  			wqe->status = IB_WC_SUCCESS;
 -			goto complete;
 +			__rxe_do_task(&qp->comp.task);
++			rxe_drop_ref(qp);
 +			return 0;
  		}
  		payload = mtu;
  	}
@@@ -746,18 -747,15 +749,20 @@@ err
  	wqe->status = IB_WC_LOC_PROT_ERR;
  	wqe->state = wqe_state_error;
  
 -complete:
 -	if (qp_type(qp) != IB_QPT_RC) {
 -		while (rxe_completer(qp) == 0)
 -			;
 -	}
 +	/*
 +	 * IBA Spec. Section 10.7.3.1 SIGNALED COMPLETIONS
 +	 * ---------8<---------8<-------------
 +	 * ...Note that if a completion error occurs, a Work Completion
 +	 * will always be generated, even if the signaling
 +	 * indicator requests an Unsignaled Completion.
 +	 * ---------8<---------8<-------------
 +	 */
 +	wqe->wr.send_flags |= IB_SEND_SIGNALED;
 +	__rxe_do_task(&qp->comp.task);
+ 	rxe_drop_ref(qp);
 -	return 0;
 +	return -EAGAIN;
  
  exit:
+ 	rxe_drop_ref(qp);
  	return -EAGAIN;
  }

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/mellanox/mlx4/fw.c
  include/linux/mlx4/device.h

between commit:

  7c3d21c8153c ("net/mlx4_core: Preparation for VF vlan protocol 802.1ad")

from Linus' tree and commit:

  fd10ed8e6f42 ("IB/mlx4: Fix possible vl/sl field mismatch in LRH header in QP1 packets")

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/net/ethernet/mellanox/mlx4/fw.c
index f9cbc67f1694,d87bbe65c2b0..000000000000
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@@ -159,7 -159,7 +159,8 @@@ static void dump_dev_cap_flags2(struct 
  		[32] = "Loopback source checks support",
  		[33] = "RoCEv2 support",
  		[34] = "DMFS Sniffer support (UC & MC)",
 +		[35] = "QinQ VST mode support",
+ 		[36] = "sl to vl mapping table change event support"
  	};
  	int i;
  
diff --cc include/linux/mlx4/device.h
index 59b50d3eedb4,062d10aaf5cb..000000000000
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@@ -221,7 -222,7 +222,8 @@@ enum 
  	MLX4_DEV_CAP_FLAG2_ROCE_V1_V2		= 1ULL <<  33,
  	MLX4_DEV_CAP_FLAG2_DMFS_UC_MC_SNIFFER   = 1ULL <<  34,
  	MLX4_DEV_CAP_FLAG2_DIAG_PER_PORT	= 1ULL <<  35,
 -	MLX4_DEV_CAP_FLAG2_SL_TO_VL_CHANGE_EVENT = 1ULL << 36,
 +	MLX4_DEV_CAP_FLAG2_SVLAN_BY_QP          = 1ULL <<  36,
++	MLX4_DEV_CAP_FLAG2_SL_TO_VL_CHANGE_EVENT = 1ULL << 37,
  };
  
  enum {

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c

between commit:

  0fbc81b3ad51 ("chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's")

from Linus' tree and commit:

  086de575c142 ("cxgb4: advertise support for FR_NSMR_TPTE_WR")

from the rdma tree.

I fixed it up (the former removed the code modified by the latter) 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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h

between commit:

  8ae7b8a59938 ("net: hns: fix sbm default parameters config error")

from Linus' tree and commit:

  c80815c0b214 ("net: hns: Add reset function support for RoCE driver")

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/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 235f74444b1d,750ab4b4d154..000000000000
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@@ -796,18 -800,10 +805,22 @@@
  #define DSAFV2_SBM_CFG4_RESET_BUF_NUM_NO_PFC_S 9
  #define DSAFV2_SBM_CFG4_RESET_BUF_NUM_NO_PFC_M (((1ULL << 9) - 1) << 9)
  
 +#define DSAFV2_SBM_CFG2_ROCEE_SET_BUF_NUM_S 0
 +#define DSAFV2_SBM_CFG2_ROCEE_SET_BUF_NUM_M (((1ULL << 8) - 1) << 0)
 +#define DSAFV2_SBM_CFG2_ROCEE_RESET_BUF_NUM_S 8
 +#define DSAFV2_SBM_CFG2_ROCEE_RESET_BUF_NUM_M (((1ULL << 8) - 1) << 8)
 +
 +#define DSAFV2_SBM_CFG2_PPE_SET_BUF_NUM_S (0)
 +#define DSAFV2_SBM_CFG2_PPE_SET_BUF_NUM_M (((1ULL << 6) - 1) << 0)
 +#define DSAFV2_SBM_CFG2_PPE_RESET_BUF_NUM_S (6)
 +#define DSAFV2_SBM_CFG2_PPE_RESET_BUF_NUM_M (((1ULL << 6) - 1) << 6)
 +#define DSAFV2_SBM_CFG2_PPE_CFG_USEFUL_NUM_S (12)
 +#define DSAFV2_SBM_CFG2_PPE_CFG_USEFUL_NUM_M (((1ULL << 6) - 1) << 12)
 +
+ #define DSAF_CHNS_MASK			0x3f000
+ #define DSAF_SBM_ROCEE_CFG_CRD_EN_B	2
+ #define SRST_TIME_INTERVAL		20
+ 
  #define DSAF_TBL_TCAM_ADDR_S 0
  #define DSAF_TBL_TCAM_ADDR_M ((1ULL << 9) - 1)
  

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c

between commits:

  a24274aa5c23 ("net: hns: add dsaf misc operation method")
  f00ef863da2b ("net: hns: implement the miscellaneous operation by asl")

from Linus' tree and commit:

  c80815c0b214 ("net: hns: Add reset function support for RoCE driver")

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/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 611b67b6f450,da3061cf5070..000000000000
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@@ -231,16 -165,43 +231,52 @@@ static void hns_dsaf_xge_core_srst_by_p
  	dsaf_write_sub(dsaf_dev, reg_addr, reg_val);
  }
  
+ /**
+  * hns_dsaf_srst_chns - reset dsaf channels
+  * @dsaf_dev: dsaf device struct pointer
+  * @msk: xbar channels mask value:
+  * bit0-5 for xge0-5
+  * bit6-11 for ppe0-5
+  * bit12-17 for roce0-5
+  * bit18-19 for com/dfx
+  * @enable: false - request reset , true - drop reset
+  */
+ void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
+ {
+ 	u32 reg_addr;
+ 
+ 	if (!enable)
+ 		reg_addr = DSAF_SUB_SC_DSAF_RESET_REQ_REG;
+ 	else
+ 		reg_addr = DSAF_SUB_SC_DSAF_RESET_DREQ_REG;
+ 
+ 	dsaf_write_sub(dsaf_dev, reg_addr, msk);
+ }
+ 
+ void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
+ {
+ 	if (!enable) {
+ 		dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_RESET_REQ_REG, 1);
+ 	} else {
+ 		dsaf_write_sub(dsaf_dev,
+ 			       DSAF_SUB_SC_ROCEE_CLK_DIS_REG, 1);
+ 		dsaf_write_sub(dsaf_dev,
+ 			       DSAF_SUB_SC_ROCEE_RESET_DREQ_REG, 1);
+ 		msleep(20);
+ 		dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_CLK_EN_REG, 1);
+ 	}
+ }
+ 
 -void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port, u32 val)
 +static void
 +hns_dsaf_xge_core_srst_by_port_acpi(struct dsaf_device *dsaf_dev,
 +				    u32 port, bool dereset)
 +{
 +	hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
 +				   HNS_XGE_CORE_RESET_FUNC, port, dereset);
 +}
 +
 +static void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port,
 +				     bool dereset)
  {
  	u32 reg_val_1;
  	u32 reg_val_2;

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  MAINTAINERS

between commit:

  b30d74e42d78 ("MAINTAINERS: add maintainers for hns driver")

from Linus' tree and commit:

  dd778a9920a6 ("MAINTAINERS: Add maintainers for Hisilicon RoCE driver")

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 MAINTAINERS
index 5a8cb5bd1f64,9d97badd2e09..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -5548,15 -5421,14 +5548,23 @@@ F:	include/uapi/linux/if_hippi.
  F:	net/802/hippi.c
  F:	drivers/net/hippi/
  
 +HISILICON NETWORK SUBSYSTEM DRIVER
 +M:	Yisen Zhuang <yisen.zhuang@huawei.com>
 +M:	Salil Mehta <salil.mehta@huawei.com>
 +L:	netdev@vger.kernel.org
 +W:	http://www.hisilicon.com
 +S:	Maintained
 +F:	drivers/net/ethernet/hisilicon/
 +F:	Documentation/devicetree/bindings/net/hisilicon*.txt
 +
+ HISILICON ROCE DRIVER
+ M:	Lijun Ou <oulijun@huawei.com>
+ M:	Wei Hu(Xavier) <xavier.huwei@huawei.com>
+ L:	linux-rdma@vger.kernel.org
+ S:	Maintained
+ F:	drivers/infiniband/hw/hns/
+ F:	Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
+ 
  HISILICON SAS Controller
  M:	John Garry <john.garry@huawei.com>
  W:	http://www.hisilicon.com

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  include/linux/mlx5/driver.h

between commit:

  43a335e055bb ("net/mlx5_core: Flow counters infrastructure")

from Linus' tree and commit:

  94c6825e0ff7 ("net/mlx5_core: Use tasklet for user-space CQ completion events")

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 include/linux/mlx5/driver.h
index 07b504f7eb84,5a41f9003941..000000000000
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@@ -41,7 -41,7 +41,8 @@@
  #include <linux/slab.h>
  #include <linux/vmalloc.h>
  #include <linux/radix-tree.h>
 +#include <linux/workqueue.h>
+ #include <linux/interrupt.h>
  
  #include <linux/mlx5/device.h>
  #include <linux/mlx5/doorbell.h>

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/staging/rdma/hfi1/verbs.c

between commit:

  e1af35bc7942 ("staging: rdma: hfi1: Use setup_timer")

from Linus' tree and commit:

  045277cf1548 ("IB/qib,staging/rdma/hfi1: use setup_timer api")

from the rdma tree.

I fixed it up (I just used the latter version) 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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/staging/rdma/hfi1/user_pages.c

between commit:

  7e43d4d25558 ("staging: rdma: hfi1: Compress return logic")

from Linus' tree and commit:

  0b091fb32c5a ("staging/hfi1: Enable TID caching feature")

from the rdma tree.

I fixed it up (the latter removed the function that was updated in the
former) 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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/staging/rdma/hfi1/keys.c
  drivers/staging/rdma/hfi1/mr.c

between commits:

  809487c70388 ("staging: rdma: hfi1: Use DIV_ROUND_UP")
  037f741673e0 ("staging: rdma: hfi1: Do not use | with a variable with value 0")

from Linus' tree and commit:

  895420ddc8b3 ("staging/rdma/hfi1: Remove hfi1 MR and hfi1 specific qp type")

from the rdma tree.

I fixed it up (I just removed the 2 files - the changes from Linus'
tree may need to be applied to some other files, now) 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

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  drivers/staging/rdma/hfi1/mad.c

between commits:

  a4fe1bc16411 ("staging: rdma: hfi1: Remove casts of pointer to same type")
  acc17d671c62 ("staging: rdma: hfi1: Remove unnecessary parantheses")

from Linus' tree and commit:

  58721b8f8c71 ("staging/rdma/hfi1: Remove unnecessary parentheses")

from the rdma tree.

I fixed it up (the result was like the former) 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

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

[Sagi Grimberg]

> Hi Doug,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
>    net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>
> between commit:
>
>    c91aed989694 ("svcrdma: handle rdma read with a non-zero initial page offset")
>
> from Linus' tree and commit:
>
>    412a15c0fe53 ("svcrdma: Port to new memory registration API")
>
> from the rdma tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
>

Hi Stephen,

The fix looks correct to me.

Cheers,
Sagi.

linux-next: manual merge of the rdma tree with Linus' tree

[Stephen Rothwell]

Hi Doug,

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

  net/sunrpc/xprtrdma/svc_rdma_recvfrom.c

between commit:

  c91aed989694 ("svcrdma: handle rdma read with a non-zero initial page offset")

from Linus' tree and commit:

  412a15c0fe53 ("svcrdma: Port to new memory registration API")

from the rdma tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
index f0c3ff67ca98,cb0991345816..000000000000
--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@@ -235,17 -234,14 +235,14 @@@ int rdma_read_chunk_frmr(struct svcxprt
  
  	ctxt->direction = DMA_FROM_DEVICE;
  	ctxt->frmr = frmr;
- 	pages_needed = min_t(int, pages_needed, xprt->sc_frmr_pg_list_len);
- 	read = min_t(int, (pages_needed << PAGE_SHIFT) - *page_offset,
- 		     rs_length);
+ 	nents = min_t(unsigned int, nents, xprt->sc_frmr_pg_list_len);
 -	read = min_t(int, nents << PAGE_SHIFT, rs_length);
++	read = min_t(int, (nents << PAGE_SHIFT) - *page_offset, rs_length);
  
- 	frmr->kva = page_address(rqstp->rq_arg.pages[pg_no]);
  	frmr->direction = DMA_FROM_DEVICE;
  	frmr->access_flags = (IB_ACCESS_LOCAL_WRITE|IB_ACCESS_REMOTE_WRITE);
- 	frmr->map_len = pages_needed << PAGE_SHIFT;
- 	frmr->page_list_len = pages_needed;
+ 	frmr->sg_nents = nents;
  
- 	for (pno = 0; pno < pages_needed; pno++) {
+ 	for (pno = 0; pno < nents; pno++) {
  		int len = min_t(int, rs_length, PAGE_SIZE - pg_off);
  
  		head->arg.pages[pg_no] = rqstp->rq_arg.pages[pg_no];