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

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

[Stephen Rothwell]

Hi Doug,

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

  net/core/dev.c

between commit:

  0e4ead9d7b36 ("net: introduce change upper device notifier change info")

from the net-next tree and commit:

  133b5b93c734 ("net: Add info for NETDEV_CHANGEUPPER event")

from the rdma tree.

They are doing very similar things, but not identical.

I fixed it up (see bottom of email and the below extra patch) and can
carry the fix as necessary (no action is required unless something more
correct is supplied, of course).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 28 Aug 2015 11:14:38 +1000
Subject: [PATCH] net: merge change upper notifier changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/infiniband/core/roce_gid_mgmt.c | 12 ++++++------
 include/linux/netdevice.h               | 23 +++++++++--------------
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/infiniband/core/roce_gid_mgmt.c b/drivers/infiniband/core/roce_gid_mgmt.c
index 6eecdfbf3aef..69e2ffa35d91 100644
--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@ -529,7 +529,7 @@ static const struct netdev_event_work_cmd add_cmd = {
 static const struct netdev_event_work_cmd add_cmd_upper_ips = {
 	.cb = add_netdev_upper_ips, .filter = is_eth_port_of_netdev};
 
-static void netdevice_event_changeupper(struct netdev_changeupper_info *changeupper_info,
+static void netdevice_event_changeupper(struct netdev_notifier_changeupper_info *changeupper_info,
 					struct netdev_event_work_cmd *cmds)
 {
 	static const struct netdev_event_work_cmd upper_ips_del_cmd = {
@@ -540,15 +540,15 @@ static void netdevice_event_changeupper(struct netdev_changeupper_info *changeup
 	if (changeupper_info->event ==
 	    NETDEV_CHANGEUPPER_UNLINK) {
 		cmds[0] = upper_ips_del_cmd;
-		cmds[0].ndev = changeupper_info->upper;
+		cmds[0].ndev = changeupper_info->upper_dev;
 		cmds[1] = add_cmd;
 	} else if (changeupper_info->event ==
 		   NETDEV_CHANGEUPPER_LINK) {
 		cmds[0] = bonding_default_del_cmd;
-		cmds[0].ndev = changeupper_info->upper;
+		cmds[0].ndev = changeupper_info->upper_dev;
 		cmds[1] = add_cmd_upper_ips;
-		cmds[1].ndev = changeupper_info->upper;
-		cmds[1].filter_ndev = changeupper_info->upper;
+		cmds[1].ndev = changeupper_info->upper_dev;
+		cmds[1].filter_ndev = changeupper_info->upper_dev;
 	}
 }
 
@@ -590,7 +590,7 @@ static int netdevice_event(struct notifier_block *this, unsigned long event,
 
 	case NETDEV_CHANGEUPPER:
 		netdevice_event_changeupper(
-			container_of(ptr, struct netdev_changeupper_info, info),
+			container_of(ptr, struct netdev_notifier_changeupper_info, info),
 			cmds);
 		break;
 
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0aa7d19ac85e..4ce420487d07 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2115,13 +2115,22 @@ struct netdev_notifier_change_info {
 	unsigned int flags_changed;
 };
 
+enum netdev_changeupper_event {
+	NETDEV_CHANGEUPPER_LINK,
+	NETDEV_CHANGEUPPER_UNLINK,
+};
+
 struct netdev_notifier_changeupper_info {
 	struct netdev_notifier_info info; /* must be first */
+	enum netdev_changeupper_event event;
 	struct net_device *upper_dev; /* new upper dev */
 	bool master; /* is upper dev master */
 	bool linking; /* is the nofication for link or unlink */
 };
 
+void netdev_changeupper_info_change(struct net_device *dev,
+				    struct netdev_notifier_changeupper_info *info);
+
 static inline void netdev_notifier_info_init(struct netdev_notifier_info *info,
 					     struct net_device *dev)
 {
@@ -3606,20 +3615,6 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
 struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
 				    netdev_features_t features);
 
-enum netdev_changeupper_event {
-	NETDEV_CHANGEUPPER_LINK,
-	NETDEV_CHANGEUPPER_UNLINK,
-};
-
-struct netdev_changeupper_info {
-	struct netdev_notifier_info	info; /* must be first */
-	enum netdev_changeupper_event	event;
-	struct net_device		*upper;
-};
-
-void netdev_changeupper_info_change(struct net_device *dev,
-				    struct netdev_changeupper_info *info);
-
 struct netdev_bonding_info {
 	ifslave	slave;
 	ifbond	master;
-- 
2.5.0



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

diff --cc net/core/dev.c
index a8e6cf4298d3,6e6f14e5d44f..000000000000
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@@ -5330,10 -5320,6 +5330,11 @@@ static int __netdev_upper_dev_link(stru
  	if (master && netdev_master_upper_dev_get(dev))
  		return -EBUSY;
  
++	changeupper_info.event = NETDEV_CHANGEUPPER_LINK;
 +	changeupper_info.upper_dev = upper_dev;
 +	changeupper_info.master = master;
 +	changeupper_info.linking = true;
 +
  	ret = __netdev_adjacent_dev_link_neighbour(dev, upper_dev, private,
  						   master);
  	if (ret)
@@@ -5468,14 -5456,10 +5469,15 @@@ EXPORT_SYMBOL(netdev_master_upper_dev_l
  void netdev_upper_dev_unlink(struct net_device *dev,
  			     struct net_device *upper_dev)
  {
 +	struct netdev_notifier_changeupper_info changeupper_info;
  	struct netdev_adjacent *i, *j;
 -	struct netdev_changeupper_info changeupper_info;
  	ASSERT_RTNL();
  
++	changeupper_info.event = NETDEV_CHANGEUPPER_UNLINK;
 +	changeupper_info.upper_dev = upper_dev;
 +	changeupper_info.master = netdev_master_upper_dev_get(dev) == upper_dev;
 +	changeupper_info.linking = false;
 +
  	__netdev_adjacent_dev_unlink_neighbour(dev, upper_dev);
  
  	/* Here is the tricky part. We must remove all dev's lower

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

[Jiri Pirko]

Fri, Aug 28, 2015 at 03:26:50AM CEST, sfr@canb.auug.org.au wrote:
>Hi Doug,
>
>Today's linux-next merge of the rdma tree got a conflict in:
>
>  net/core/dev.c
>
>between commit:
>
>  0e4ead9d7b36 ("net: introduce change upper device notifier change info")
>
>from the net-next tree and commit:
>
>  133b5b93c734 ("net: Add info for NETDEV_CHANGEUPPER event")
>
>from the rdma tree.
>
>They are doing very similar things, but not identical.
>
>I fixed it up (see bottom of email and the below extra patch) and can
>carry the fix as necessary (no action is required unless something more
>correct is supplied, of course).
>
>From: Stephen Rothwell <sfr@canb.auug.org.au>
>Date: Fri, 28 Aug 2015 11:14:38 +1000
>Subject: [PATCH] net: merge change upper notifier changes
>
>Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>---

<snip>

>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>index 0aa7d19ac85e..4ce420487d07 100644
>--- a/include/linux/netdevice.h
>+++ b/include/linux/netdevice.h
>@@ -2115,13 +2115,22 @@ struct netdev_notifier_change_info {
> 	unsigned int flags_changed;
> };
> 
>+enum netdev_changeupper_event {
>+	NETDEV_CHANGEUPPER_LINK,
>+	NETDEV_CHANGEUPPER_UNLINK,
>+};
>+

I have this handled by "bool linking". So this is not needed.


> struct netdev_notifier_changeupper_info {
> 	struct netdev_notifier_info info; /* must be first */
>+	enum netdev_changeupper_event event;

	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



Other than this, looks good. Thanks

> 	struct net_device *upper_dev; /* new upper dev */
> 	bool master; /* is upper dev master */
> 	bool linking; /* is the nofication for link or unlink */
> };
> 

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

[Stephen Rothwell]

Hi Doug,

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

  drivers/net/ethernet/mellanox/mlx5/core/vport.c
  include/linux/mlx5/mlx5_ifc.h
  include/linux/mlx5/vport.h

between commits:

  e1d7d349c69d ("net/mlx5: Update access functions to Query/Modify vport MAC address")
  e75465148b7d ("net/mlx5: Introduce access functions to modify/query vport state")

from the net-next tree and commit:

  e5f6175c5b66 ("net/mlx5_core: Break down the vport mac address query function")

from the rdma tree and maybe some others.

I have no hope of fixing this stuff up, so I have dropped the rdma tree
again for today.  There is similar functionality being introduced in
both trees ... please sort this mess out ...

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

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

[Or Gerlitz]

On 1/5/2016 3:51 AM, Stephen Rothwell wrote:
> Hi Doug,
>
> Today's linux-next merge of the rdma tree got conflicts in:
>
>    drivers/net/ethernet/mellanox/mlx5/core/vport.c
>    include/linux/mlx5/mlx5_ifc.h
>    include/linux/mlx5/vport.h
>
> between commits:
>
>    e1d7d349c69d ("net/mlx5: Update access functions to Query/Modify vport MAC address")
>    e75465148b7d ("net/mlx5: Introduce access functions to modify/query vport state")
>
> from the net-next tree and commit:
>
>    e5f6175c5b66 ("net/mlx5_core: Break down the vport mac address query function")
>
> from the rdma tree and maybe some others.
>
> I have no hope of fixing this stuff up, so I have dropped the rdma tree
> again for today.  There is similar functionality being introduced in
> both trees ... please sort this mess out ...

Hi Stephen,

Saeed/Matan and Co are working here on a fix which would solve the 
conflict.

We have the basic patch and people will be testing it later/tomorrow.

Could you please advice how would it be possible to provide you the
git rerere output -- the pre-image and post-images files from .git/rr-cache?

Or.

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

[Stephen Rothwell]

Hi Or,

On Tue, 5 Jan 2016 19:05:24 +0200 Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> On 1/5/2016 3:51 AM, Stephen Rothwell wrote:
> > Hi Doug,
> >
> > Today's linux-next merge of the rdma tree got conflicts in:
> >
> >    drivers/net/ethernet/mellanox/mlx5/core/vport.c
> >    include/linux/mlx5/mlx5_ifc.h
> >    include/linux/mlx5/vport.h
> >
> > between commits:
> >
> >    e1d7d349c69d ("net/mlx5: Update access functions to Query/Modify vport MAC address")
> >    e75465148b7d ("net/mlx5: Introduce access functions to modify/query vport state")
> >
> > from the net-next tree and commit:
> >
> >    e5f6175c5b66 ("net/mlx5_core: Break down the vport mac address query function")
> >
> > from the rdma tree and maybe some others.
> >
> > I have no hope of fixing this stuff up, so I have dropped the rdma tree
> > again for today.  There is similar functionality being introduced in
> > both trees ... please sort this mess out ...  
> 
> Hi Stephen,
> 
> Saeed/Matan and Co are working here on a fix which would solve the 
> conflict.

Wonderful.

> We have the basic patch and people will be testing it later/tomorrow.
> 
> Could you please advice how would it be possible to provide you the
> git rerere output -- the pre-image and post-images files from .git/rr-cache?

Just send me a (private) email (no need to bother the list) with the
pre and post image files attached, thanks.

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

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

[Stephen Rothwell]

Hi all,

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

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

between commit:

  60ab4584f5bf ("net/mlx5_core: Set flow steering dest only for forward rules")

from the net-next tree and commit:

  b3638e1a7664 ("net/mlx5_core: Introduce forward to next priority action")

from the rdma tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index e848d708d2b7,bf3446794bd5..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@@ -73,10 -73,13 +73,13 @@@
  #define BY_PASS_MIN_LEVEL (KENREL_MIN_LEVEL + MLX5_BY_PASS_NUM_PRIOS +\
  			   LEFTOVERS_MAX_FT)
  
 -#define KERNEL_MAX_FT 2
 -#define KERNEL_NUM_PRIOS 1
 +#define KERNEL_MAX_FT 3
 +#define KERNEL_NUM_PRIOS 2
  #define KENREL_MIN_LEVEL 2
  
+ #define ANCHOR_MAX_FT 1
+ #define ANCHOR_NUM_PRIOS 1
+ #define ANCHOR_MIN_LEVEL (BY_PASS_MIN_LEVEL + 1)
  struct node_caps {
  	size_t	arr_sz;
  	long	*caps;
@@@ -360,8 -367,13 +367,13 @@@ static void del_rule(struct fs_node *no
  	memcpy(match_value, fte->val, sizeof(fte->val));
  	fs_get_obj(ft, fg->node.parent);
  	list_del(&rule->node.list);
+ 	if (rule->sw_action == MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO) {
+ 		mutex_lock(&rule->dest_attr.ft->lock);
+ 		list_del(&rule->next_ft);
+ 		mutex_unlock(&rule->dest_attr.ft->lock);
+ 	}
 -	fte->dests_size--;
 -	if (fte->dests_size) {
 +	if ((fte->action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) &&
 +	    --fte->dests_size) {
  		err = mlx5_cmd_update_fte(dev, ft,
  					  fg->id, fte);
  		if (err)
@@@ -762,9 -835,9 +835,10 @@@ static struct mlx5_flow_rule *alloc_rul
  	if (!rule)
  		return NULL;
  
+ 	INIT_LIST_HEAD(&rule->next_ft);
  	rule->node.type = FS_TYPE_FLOW_DEST;
 -	memcpy(&rule->dest_attr, dest, sizeof(*dest));
 +	if (dest)
 +		memcpy(&rule->dest_attr, dest, sizeof(*dest));
  
  	return rule;
  }
@@@ -783,12 -856,16 +857,17 @@@ static struct mlx5_flow_rule *add_rule_
  		return ERR_PTR(-ENOMEM);
  
  	fs_get_obj(ft, fg->node.parent);
- 	/* Add dest to dests list- added as first element after the head */
+ 	/* Add dest to dests list- we need flow tables to be in the
+ 	 * end of the list for forward to next prio rules.
+ 	 */
  	tree_init_node(&rule->node, 1, del_rule);
- 	list_add_tail(&rule->node.list, &fte->node.children);
+ 	if (dest && dest->type != MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE)
+ 		list_add(&rule->node.list, &fte->node.children);
+ 	else
+ 		list_add_tail(&rule->node.list, &fte->node.children);
 -	fte->dests_size++;
 -	if (fte->dests_size == 1)
 +	if (dest)
 +		fte->dests_size++;
 +	if (fte->dests_size == 1 || !dest)
  		err = mlx5_cmd_create_fte(get_dev(&ft->node),
  					  ft, fg->id, fte);
  	else

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

[Maor Gottlieb]

2016-03-16 2:58 GMT+02:00 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>
> between commit:
>
>   60ab4584f5bf ("net/mlx5_core: Set flow steering dest only for forward rules")
>
> from the net-next tree and commit:
>
>   b3638e1a7664 ("net/mlx5_core: Introduce forward to next priority action")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index e848d708d2b7,bf3446794bd5..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@@ -73,10 -73,13 +73,13 @@@
>   #define BY_PASS_MIN_LEVEL (KENREL_MIN_LEVEL + MLX5_BY_PASS_NUM_PRIOS +\
>                            LEFTOVERS_MAX_FT)
>
>  -#define KERNEL_MAX_FT 2
>  -#define KERNEL_NUM_PRIOS 1
>  +#define KERNEL_MAX_FT 3
>  +#define KERNEL_NUM_PRIOS 2
>   #define KENREL_MIN_LEVEL 2
>
> + #define ANCHOR_MAX_FT 1
> + #define ANCHOR_NUM_PRIOS 1
> + #define ANCHOR_MIN_LEVEL (BY_PASS_MIN_LEVEL + 1)
>   struct node_caps {
>         size_t  arr_sz;
>         long    *caps;
> @@@ -360,8 -367,13 +367,13 @@@ static void del_rule(struct fs_node *no
>         memcpy(match_value, fte->val, sizeof(fte->val));
>         fs_get_obj(ft, fg->node.parent);
>         list_del(&rule->node.list);
> +       if (rule->sw_action == MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO) {
> +               mutex_lock(&rule->dest_attr.ft->lock);
> +               list_del(&rule->next_ft);
> +               mutex_unlock(&rule->dest_attr.ft->lock);
> +       }
>  -      fte->dests_size--;
>  -      if (fte->dests_size) {
>  +      if ((fte->action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) &&
>  +          --fte->dests_size) {
>                 err = mlx5_cmd_update_fte(dev, ft,
>                                           fg->id, fte);
>                 if (err)
> @@@ -762,9 -835,9 +835,10 @@@ static struct mlx5_flow_rule *alloc_rul
>         if (!rule)
>                 return NULL;
>
> +       INIT_LIST_HEAD(&rule->next_ft);
>         rule->node.type = FS_TYPE_FLOW_DEST;
>  -      memcpy(&rule->dest_attr, dest, sizeof(*dest));
>  +      if (dest)
>  +              memcpy(&rule->dest_attr, dest, sizeof(*dest));
>
>         return rule;
>   }
> @@@ -783,12 -856,16 +857,17 @@@ static struct mlx5_flow_rule *add_rule_
>                 return ERR_PTR(-ENOMEM);
>
>         fs_get_obj(ft, fg->node.parent);
> -       /* Add dest to dests list- added as first element after the head */
> +       /* Add dest to dests list- we need flow tables to be in the
> +        * end of the list for forward to next prio rules.
> +        */
>         tree_init_node(&rule->node, 1, del_rule);
> -       list_add_tail(&rule->node.list, &fte->node.children);
> +       if (dest && dest->type != MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE)
> +               list_add(&rule->node.list, &fte->node.children);
> +       else
> +               list_add_tail(&rule->node.list, &fte->node.children);
>  -      fte->dests_size++;
>  -      if (fte->dests_size == 1)
>  +      if (dest)
>  +              fte->dests_size++;
>  +      if (fte->dests_size == 1 || !dest)
>                 err = mlx5_cmd_create_fte(get_dev(&ft->node),
>                                           ft, fg->id, fte);
>         else

Hi Stephen,

I reveiwed your merge and it's fine.

Thanks,
Maor

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

[Linus Torvalds]

On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Side note: can you change this wording for your manual merge script?
Last merge window (or was it the one before it?) we had confusion with
people who thought that "no action is required" means "you can just
ignore this entirely".

I want people who have known merge issues to at the very least
*mention* them to me when they send the pull request, and I also think
that trees that have merge conflicts that aren't just totally trivial
should also make sure that they have communicated with each other
about why the problem happened.

This is *particularly* true for the complete effing disaster that is
mellanox and rdma-vs-networking.

So please don't say "no action is required". Please make it clear that
there may not be any further action needed for linux-next itself, but
that other action may certainly be required.

Because I'm very close to not taking any rdma changes that touch
networking any more. Ever.

The Mellanox people are on my shit-list until they show that they can
actually act like responsible people and not just monkeys throwing
shit at the walls.

"No action required" is simply not true for Mellanox.

                     Linus

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

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 953 bytes --]

On 3/16/2016 1:18 PM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
> 
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".

I certainly didn't take it that way regardless of the wording.  I'm
keenly aware of the short leash you have Mellanox (and by extension
myself) on.  I reviewed the merge in detail, enough to satisfy myself
that it was easy, correct, and that the code itself made the merge
obvious (such as the comment that flow table entries need to be last in
the lists in order to support priority transitions, which fairly handily
explained what needed to happen in the merge).




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

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

[Linus Torvalds]

On Wed, Mar 16, 2016 at 10:35 AM, Doug Ledford <dledford@redhat.com> wrote:
> On 3/16/2016 1:18 PM, Linus Torvalds wrote:
>> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>> is required).
>>
>> Side note: can you change this wording for your manual merge script?
>> Last merge window (or was it the one before it?) we had confusion with
>> people who thought that "no action is required" means "you can just
>> ignore this entirely".
>
> I certainly didn't take it that way regardless of the wording.

It was Or Gerlitz. You were cc'd, since it was the whole rdma Mellanox
mess. I quote from that thread:

 "> However, the fact that it got resolved in linux-next is purely
  > informational. It doesn't "fix" the conflict - it just means that both
  > sides should have gotten informed about it. That doesn't mean that the
  > conflict goes away or becomes better.

  That's news to me. When such things happen and caught by Stephen, we
  are getting an email saying something like

  "Today's linux-next merge of the infiniband tree got a conflict
  between commit X from net-next tree and commit Y from the infiniband
  tree. I fixed it up (see below) and can carry the fix as necessary (no
  action is required)."

  Also asked around a bit and got to learn on Stephen using git rerere,
  so all (no action needed note + seeing git rerere in action...) that
  leaded me to think that indeed no action is required from our side,
  but after reading your email (twice, so far), I realized that this was
  wrong conclusion."

So that whole "no action is required" wording very much has caused
confusion before in the rdma camp.

Let's fix the wording. I'm indeed hopeful that the rdma camp is now
keenly aware of the issues, but that doesn't change the fact that the
wording has been problematic.

                  Linus

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

[Or Gerlitz]

On Wed, Mar 16, 2016 at 7:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Mar 16, 2016 at 10:35 AM, Doug Ledford <dledford@redhat.com> wrote:
>> On 3/16/2016 1:18 PM, Linus Torvalds wrote:
>>> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

>>> Side note: can you change this wording for your manual merge script?
>>> Last merge window (or was it the one before it?) we had confusion with
>>> people who thought that "no action is required" means "you can just
>>> ignore this entirely".

>> I certainly didn't take it that way regardless of the wording.

> It was Or Gerlitz. You were cc'd, since it was the whole rdma Mellanox
> mess. I quote from that thread:
>
>  "> However, the fact that it got resolved in linux-next is purely
>   > informational. It doesn't "fix" the conflict - it just means that both
>   > sides should have gotten informed about it. That doesn't mean that the
>   > conflict goes away or becomes better.
>
>   That's news to me. When such things happen and caught by Stephen, we
>   are getting an email saying something like
>
>   "Today's linux-next merge of the infiniband tree got a conflict
>   between commit X from net-next tree and commit Y from the infiniband
>   tree. I fixed it up (see below) and can carry the fix as necessary (no
>   action is required)."
>
>   Also asked around a bit and got to learn on Stephen using git rerere,
>   so all (no action needed note + seeing git rerere in action...) that
>   leaded me to think that indeed no action is required from our side,
>   but after reading your email (twice, so far), I realized that this was
>   wrong conclusion."

> So that whole "no action is required" wording very much has caused
> confusion before in the rdma camp.

> Let's fix the wording. I'm indeed hopeful that the rdma camp is now
> keenly aware of the issues, but that doesn't change the fact that the
> wording has been problematic.

>> "[...] The Mellanox people are on my xxit-list until they show that they can
>> actually act like responsible people [...]"

Linus,

As I wrote you in that other thread you were quoting from there,
following to the happenings mentioned there, we took responsibility
and made bunch of corrective actions within Mellanox which got us to a
point where there was only one rdma/netdev-next conflict for the 4.6
merge window.

I know there's history here, and in the 4.5 cycle things were much
worse, but I still wanted to put things in their more precise place,
if you don't mind.

Or.

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

[Linus Torvalds]

On Wed, Mar 23, 2016 at 4:04 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> I know there's history here, and in the 4.5 cycle things were much
> worse, but I still wanted to put things in their more precise place,
> if you don't mind.

We'll see how things shape up in the future. Once bitten, twice shy,
as they say.

Please make sure that Mellanox will not be a pain going forward, and
everything will be forgiven/forgotten.

            Linus

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

[Stephen Rothwell]

Hi Linus,

On Wed, 16 Mar 2016 10:18:33 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).  
> 
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".
> 
> I want people who have known merge issues to at the very least
> *mention* them to me when they send the pull request, and I also think
> that trees that have merge conflicts that aren't just totally trivial
> should also make sure that they have communicated with each other
> about why the problem happened.
> 
> This is *particularly* true for the complete effing disaster that is
> mellanox and rdma-vs-networking.
> 
> So please don't say "no action is required". Please make it clear that
> there may not be any further action needed for linux-next itself, but
> that other action may certainly be required.

Yeah, I can see your point.  The "no action required" was a reaction to
people going off and rebasing their tree or dropping patches at any
sign of a conflict at all.

How about "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 want also want to
consider cooperate 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 the net-next tree

[Linus Torvalds]

On Wed, Mar 16, 2016 at 1:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> How about "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 want also want to
> consider cooperate with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts."

Yup, sounds fine.

Maybe you could even say "don't merge this to hide the problem",
because that has been another reaction in the past, but the above
already sounds pretty good.

                Linus

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

[Andrew Lunn]

Hi Stephen

> How about "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 want also want to

Only the second want is required.

> consider cooperate with the maintainer of the conflicting tree to

cooperating

	Andrew

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

[Stephen Rothwell]

Hi Andrew,

On Wed, 16 Mar 2016 22:15:03 +0100 Andrew Lunn <andrew@lunn.ch> wrote:
>
> > How about "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 want also want to  
> 
> Only the second want is required.
> 
> > consider cooperate with the maintainer of the conflicting tree to  
> 
> cooperating

Thanks.  Breakfast is not the best time to compose prose :-)

-- 
Cheers,
Stephen Rothwell