Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the rdma tree with Linus' tree
@ 2019-11-05  1:17 Stephen Rothwell
  2019-11-05  2:21 ` Jason Gunthorpe
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2019-11-05  1:17 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-11-05  1:17 linux-next: manual merge of the rdma tree with Linus' tree Stephen Rothwell
@ 2019-11-05  2:21 ` Jason Gunthorpe
  2019-11-05  2:28   ` Stephen Rothwell
  0 siblings, 1 reply; 41+ messages in thread
From: Jason Gunthorpe @ 2019-11-05  2:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-11-05  2:21 ` Jason Gunthorpe
@ 2019-11-05  2:28   ` Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2019-11-05  2:28 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Doug Ledford, Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-10-24  0:01 Stephen Rothwell
@ 2019-10-28 19:30 ` Jason Gunthorpe
  0 siblings, 0 replies; 41+ messages in thread
From: Jason Gunthorpe @ 2019-10-28 19:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux Next Mailing List, Linux Kernel Mailing List,
	Erez Alfasi

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2019-10-24  0:01 Stephen Rothwell
  2019-10-28 19:30 ` Jason Gunthorpe
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2019-10-24  0:01 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Erez Alfasi

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-06-20  2:10 Stephen Rothwell
@ 2019-06-20  3:25 ` Doug Ledford
  0 siblings, 0 replies; 41+ messages in thread
From: Doug Ledford @ 2019-06-20  3:25 UTC (permalink / raw)
  To: Stephen Rothwell, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Thomas Gleixner, Greg Kroah-Hartman

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-06-20  2:06 Stephen Rothwell
@ 2019-06-20  3:24 ` Doug Ledford
  0 siblings, 0 replies; 41+ messages in thread
From: Doug Ledford @ 2019-06-20  3:24 UTC (permalink / raw)
  To: Stephen Rothwell, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Leon Romanovsky

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2019-06-20  2:10 Stephen Rothwell
  2019-06-20  3:25 ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2019-06-20  2:10 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Thomas Gleixner, Greg Kroah-Hartman

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2019-06-20  2:06 Stephen Rothwell
  2019-06-20  3:24 ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2019-06-20  2:06 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Leon Romanovsky

[-- Attachment #1: Type: text/plain, Size: 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 --]

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2019-06-14  3:00 Stephen Rothwell
@ 2019-06-14 13:11 ` Doug Ledford
  0 siblings, 0 replies; 41+ messages in thread
From: Doug Ledford @ 2019-06-14 13:11 UTC (permalink / raw)
  To: Stephen Rothwell, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Leon Romanovsky, Gal Pressman

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2019-06-14  3:00 Stephen Rothwell
  2019-06-14 13:11 ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2019-06-14  3:00 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Leon Romanovsky, Gal Pressman

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

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

* RE: linux-next: manual merge of the rdma tree with Linus' tree
  2018-09-28  0:01 Stephen Rothwell
@ 2018-09-29  2:57 ` Parav Pandit
  0 siblings, 0 replies; 41+ messages in thread
From: Parav Pandit @ 2018-09-29  2:57 UTC (permalink / raw)
  To: Stephen Rothwell, Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2018-09-28  0:01 Stephen Rothwell
  2018-09-29  2:57 ` Parav Pandit
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2018-09-28  0:01 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Parav Pandit

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2018-08-06 19:41 ` Jason Gunthorpe
@ 2018-08-06 21:49   ` Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2018-08-06 21:49 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2018-08-06  2:01 Stephen Rothwell
@ 2018-08-06 19:41 ` Jason Gunthorpe
  2018-08-06 21:49   ` Stephen Rothwell
  0 siblings, 1 reply; 41+ messages in thread
From: Jason Gunthorpe @ 2018-08-06 19:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2018-08-06  2:01 Stephen Rothwell
  2018-08-06 19:41 ` Jason Gunthorpe
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2018-08-06  2:01 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2017-08-08  2:11 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2017-08-08  2:11 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huy Nguyen,
	Saeed Mahameed

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14 14:33         ` Doug Ledford
@ 2017-07-14 15:10           ` Leon Romanovsky
  0 siblings, 0 replies; 41+ messages in thread
From: Leon Romanovsky @ 2017-07-14 15:10 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  4:54       ` Leon Romanovsky
@ 2017-07-14 14:33         ` Doug Ledford
  2017-07-14 15:10           ` Leon Romanovsky
  0 siblings, 1 reply; 41+ messages in thread
From: Doug Ledford @ 2017-07-14 14:33 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14 12:03         ` Doug Ledford
@ 2017-07-14 13:46           ` Leon Romanovsky
  0 siblings, 0 replies; 41+ messages in thread
From: Leon Romanovsky @ 2017-07-14 13:46 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  4:55       ` Leon Romanovsky
@ 2017-07-14 12:03         ` Doug Ledford
  2017-07-14 13:46           ` Leon Romanovsky
  0 siblings, 1 reply; 41+ messages in thread
From: Doug Ledford @ 2017-07-14 12:03 UTC (permalink / raw)
  To: Leon Romanovsky, Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Paul Moore, Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  3:50     ` Stephen Rothwell
@ 2017-07-14  4:55       ` Leon Romanovsky
  2017-07-14 12:03         ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Leon Romanovsky @ 2017-07-14  4:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Paul Moore, Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  4:12     ` Doug Ledford
@ 2017-07-14  4:54       ` Leon Romanovsky
  2017-07-14 14:33         ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Leon Romanovsky @ 2017-07-14  4:54 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  3:34   ` Leon Romanovsky
  2017-07-14  3:50     ` Stephen Rothwell
@ 2017-07-14  4:12     ` Doug Ledford
  2017-07-14  4:54       ` Leon Romanovsky
  1 sibling, 1 reply; 41+ messages in thread
From: Doug Ledford @ 2017-07-14  4:12 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  3:34   ` Leon Romanovsky
@ 2017-07-14  3:50     ` Stephen Rothwell
  2017-07-14  4:55       ` Leon Romanovsky
  2017-07-14  4:12     ` Doug Ledford
  1 sibling, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2017-07-14  3:50 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Paul Moore, Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  1:17 ` Doug Ledford
@ 2017-07-14  3:34   ` Leon Romanovsky
  2017-07-14  3:50     ` Stephen Rothwell
  2017-07-14  4:12     ` Doug Ledford
  0 siblings, 2 replies; 41+ messages in thread
From: Leon Romanovsky @ 2017-07-14  3:34 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Jurgens, Paul Moore,
	Parav Pandit, Eli Cohen

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2017-07-14  1:14 Stephen Rothwell
@ 2017-07-14  1:17 ` Doug Ledford
  2017-07-14  3:34   ` Leon Romanovsky
  0 siblings, 1 reply; 41+ messages in thread
From: Doug Ledford @ 2017-07-14  1:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Paul Moore, Parav Pandit, Leon Romanovsky,
	Eli Cohen

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2017-07-14  1:14 Stephen Rothwell
  2017-07-14  1:17 ` Doug Ledford
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2017-07-14  1:14 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Jurgens, Paul Moore, Parav Pandit, Leon Romanovsky,
	Eli Cohen

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-12-15  0:47 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-12-15  0:47 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-next, linux-kernel, Yonatan Cohen, Andrew Boyer, Linus

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-10-10  0:59 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-10-10  0:59 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Jack Morgenstein, Moshe Shemesh,
	David S. Miller

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 {

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-10-10  0:54 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-10-10  0:54 UTC (permalink / raw)
  To: Doug Ledford; +Cc: linux-next, linux-kernel, Hariprasad Shenai, David S. Miller

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-08-05  1:05 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-08-05  1:05 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Wei Hu, Nenglong Zhao, Lijun Ou,
	Sheng Li, Daode Huang, Yisen Zhuang, David S. Miller

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)
  

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-08-05  1:01 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-08-05  1:01 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, oulijun, Wei Hu, Nenglong Zhao,
	Sheng Li, Kejian Yan, Yisen Zhuang, David S. Miller

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;

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-08-05  0:52 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-08-05  0:52 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Daode Huang, David S. Miller, Wei Hu, Lijun Ou

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-05-19  1:45 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-05-19  1:45 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Matan Barak, Amir Vadai, David S. Miller

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>

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-03-22  0:33 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-03-22  0:33 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Bhaktipriya Shridhar,
	Greg Kroah-Hartman, Hari Prasath Gujulan Elango

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-03-22  0:29 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-03-22  0:29 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Bhaktipriya Shridhar,
	Greg Kroah-Hartman, Mitko Haralanov

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-03-22  0:24 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-03-22  0:24 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Dennis Dalessandro,
	Janani Ravichandran, Amitoj Kaur Chawla, Greg Kroah-Hartman

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2016-03-22  0:17 Stephen Rothwell
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Rothwell @ 2016-03-22  0:17 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Bhaktipriya Shridhar,
	Greg Kroah-Hartman, Jubin John

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

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

* Re: linux-next: manual merge of the rdma tree with Linus' tree
  2015-11-01  7:48 Stephen Rothwell
@ 2015-11-02 10:40 ` Sagi Grimberg
  0 siblings, 0 replies; 41+ messages in thread
From: Sagi Grimberg @ 2015-11-02 10:40 UTC (permalink / raw)
  To: Stephen Rothwell, Doug Ledford
  Cc: linux-next, linux-kernel, Steve Wise, J. Bruce Fields

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

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

* linux-next: manual merge of the rdma tree with Linus' tree
@ 2015-11-01  7:48 Stephen Rothwell
  2015-11-02 10:40 ` Sagi Grimberg
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Rothwell @ 2015-11-01  7:48 UTC (permalink / raw)
  To: Doug Ledford
  Cc: linux-next, linux-kernel, Sagi Grimberg, Steve Wise, J. Bruce Fields

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

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

end of thread, back to index

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-05  1:17 linux-next: manual merge of the rdma tree with Linus' tree Stephen Rothwell
2019-11-05  2:21 ` Jason Gunthorpe
2019-11-05  2:28   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2019-10-24  0:01 Stephen Rothwell
2019-10-28 19:30 ` Jason Gunthorpe
2019-06-20  2:10 Stephen Rothwell
2019-06-20  3:25 ` Doug Ledford
2019-06-20  2:06 Stephen Rothwell
2019-06-20  3:24 ` Doug Ledford
2019-06-14  3:00 Stephen Rothwell
2019-06-14 13:11 ` Doug Ledford
2018-09-28  0:01 Stephen Rothwell
2018-09-29  2:57 ` Parav Pandit
2018-08-06  2:01 Stephen Rothwell
2018-08-06 19:41 ` Jason Gunthorpe
2018-08-06 21:49   ` Stephen Rothwell
2017-08-08  2:11 Stephen Rothwell
2017-07-14  1:14 Stephen Rothwell
2017-07-14  1:17 ` Doug Ledford
2017-07-14  3:34   ` Leon Romanovsky
2017-07-14  3:50     ` Stephen Rothwell
2017-07-14  4:55       ` Leon Romanovsky
2017-07-14 12:03         ` Doug Ledford
2017-07-14 13:46           ` Leon Romanovsky
2017-07-14  4:12     ` Doug Ledford
2017-07-14  4:54       ` Leon Romanovsky
2017-07-14 14:33         ` Doug Ledford
2017-07-14 15:10           ` Leon Romanovsky
2016-12-15  0:47 Stephen Rothwell
2016-10-10  0:59 Stephen Rothwell
2016-10-10  0:54 Stephen Rothwell
2016-08-05  1:05 Stephen Rothwell
2016-08-05  1:01 Stephen Rothwell
2016-08-05  0:52 Stephen Rothwell
2016-05-19  1:45 Stephen Rothwell
2016-03-22  0:33 Stephen Rothwell
2016-03-22  0:29 Stephen Rothwell
2016-03-22  0:24 Stephen Rothwell
2016-03-22  0:17 Stephen Rothwell
2015-11-01  7:48 Stephen Rothwell
2015-11-02 10:40 ` Sagi Grimberg

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git