LKML Archive on lore.kernel.org
 help / Atom feed
* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-07  1:39 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-12-07  1:39 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Florian Fainelli, Andrew Lunn

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

Hi all,

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

  net/dsa/master.c

between commit:

  a3d7e01da060 ("net: dsa: Fix tagging attribute location")

from the net tree and commit:

  dc0fe7d47f9f ("net: dsa: Set the master device's MTU to account for DSA overheads")

from the net-next 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 net/dsa/master.c
index 5e8c9bef78bd,42f525bc68e2..000000000000
--- a/net/dsa/master.c
+++ b/net/dsa/master.c
@@@ -158,31 -158,24 +158,47 @@@ static void dsa_master_ethtool_teardown
  	cpu_dp->orig_ethtool_ops = NULL;
  }
  
 +static ssize_t tagging_show(struct device *d, struct device_attribute *attr,
 +			    char *buf)
 +{
 +	struct net_device *dev = to_net_dev(d);
 +	struct dsa_port *cpu_dp = dev->dsa_ptr;
 +
 +	return sprintf(buf, "%s\n",
 +		       dsa_tag_protocol_to_str(cpu_dp->tag_ops));
 +}
 +static DEVICE_ATTR_RO(tagging);
 +
 +static struct attribute *dsa_slave_attrs[] = {
 +	&dev_attr_tagging.attr,
 +	NULL
 +};
 +
 +static const struct attribute_group dsa_group = {
 +	.name	= "dsa",
 +	.attrs	= dsa_slave_attrs,
 +};
 +
+ void dsa_master_set_mtu(struct net_device *dev, struct dsa_port *cpu_dp)
+ {
+ 	unsigned int mtu = ETH_DATA_LEN + cpu_dp->tag_ops->overhead;
+ 	int err;
+ 
+ 	rtnl_lock();
+ 	if (mtu <= dev->max_mtu) {
+ 		err = dev_set_mtu(dev, mtu);
+ 		if (err)
+ 			netdev_dbg(dev, "Unable to set MTU to include for DSA overheads\n");
+ 	}
+ 	rtnl_unlock();
+ }
+ 
  int dsa_master_setup(struct net_device *dev, struct dsa_port *cpu_dp)
  {
 +	int ret;
 +
+ 	dsa_master_set_mtu(dev,  cpu_dp);
+ 
  	/* If we use a tagging format that doesn't have an ethertype
  	 * field, make sure that all packets from this point on get
  	 * sent to the tag format's receive function.

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-10  1:36 Stephen Rothwell
  2018-12-10 11:38 ` Or Gerlitz
@ 2018-12-10 18:38 ` Nambiar, Amritha
  1 sibling, 0 replies; 325+ messages in thread
From: Nambiar, Amritha @ 2018-12-10 18:38 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Or Gerlitz,
	aul Blakey

On 12/9/2018 5:36 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/cls_flower.c
> 
> between commit:
> 
>   35cc3cefc4de ("net/sched: cls_flower: Reject duplicated rules also under skip_sw")
> 
> from the net tree and commit:
> 
>   5c72299fba9d ("net: sched: cls_flower: Classify packets using port ranges")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Looks good to me. Thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-10  1:36 Stephen Rothwell
@ 2018-12-10 11:38 ` Or Gerlitz
  2018-12-10 18:38 ` Nambiar, Amritha
  1 sibling, 0 replies; 325+ messages in thread
From: Or Gerlitz @ 2018-12-10 11:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Linux Netdev List, linux-next, Linux Kernel,
	Amritha Nambiar, Or Gerlitz, Paul Blakey, Jiri Pirko

On Mon, Dec 10, 2018 at 3:38 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/sched/cls_flower.c
>
> between commit:
>
>   35cc3cefc4de ("net/sched: cls_flower: Reject duplicated rules also under skip_sw")
>
> from the net tree and commit:
>
>   5c72299fba9d ("net: sched: cls_flower: Classify packets using port ranges")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This

[..]

The fix LGTM, thanks for addressing this.

Or.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-10  1:36 Stephen Rothwell
  2018-12-10 11:38 ` Or Gerlitz
  2018-12-10 18:38 ` Nambiar, Amritha
  0 siblings, 2 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-12-10  1:36 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Amritha Nambiar, Or Gerlitz, aul Blakey

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

Hi all,

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

  net/sched/cls_flower.c

between commit:

  35cc3cefc4de ("net/sched: cls_flower: Reject duplicated rules also under skip_sw")

from the net tree and commit:

  5c72299fba9d ("net: sched: cls_flower: Classify packets using port ranges")

from the net-next 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 net/sched/cls_flower.c
index 71312d7bd8f4,85e9f8e1da10..000000000000
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@@ -1238,16 -1355,18 +1355,16 @@@ static int fl_change(struct net *net, s
  	if (err)
  		goto errout_idr;
  
- 	if (!fold && fl_lookup(fnew->mask, &fnew->mkey)) {
 -	if (!tc_skip_sw(fnew->flags)) {
 -		if (!fold && __fl_lookup(fnew->mask, &fnew->mkey)) {
 -			err = -EEXIST;
 -			goto errout_mask;
 -		}
 -
 -		err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node,
 -					     fnew->mask->filter_ht_params);
 -		if (err)
 -			goto errout_mask;
++	if (!fold && __fl_lookup(fnew->mask, &fnew->mkey)) {
 +		err = -EEXIST;
 +		goto errout_mask;
  	}
  
 +	err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node,
 +				     fnew->mask->filter_ht_params);
 +	if (err)
 +		goto errout_mask;
 +
  	if (!tc_skip_hw(fnew->flags)) {
  		err = fl_hw_replace_filter(tp, fnew, extack);
  		if (err)

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-10  1:31 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-12-10  1:31 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andrew Lunn,
	Florian Fainelli

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

Hi all,

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

  net/dsa/master.c

between commit:

  a3d7e01da060 ("net: dsa: Fix tagging attribute location")

from the net tree and commits:

  a60956ed72f7 ("net: dsa: Make dsa_master_set_mtu() static")

from the net-next 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 net/dsa/master.c
index 5e8c9bef78bd,d7d5145aa235..000000000000
--- a/net/dsa/master.c
+++ b/net/dsa/master.c
@@@ -158,31 -158,36 +158,59 @@@ static void dsa_master_ethtool_teardown
  	cpu_dp->orig_ethtool_ops = NULL;
  }
  
 +static ssize_t tagging_show(struct device *d, struct device_attribute *attr,
 +			    char *buf)
 +{
 +	struct net_device *dev = to_net_dev(d);
 +	struct dsa_port *cpu_dp = dev->dsa_ptr;
 +
 +	return sprintf(buf, "%s\n",
 +		       dsa_tag_protocol_to_str(cpu_dp->tag_ops));
 +}
 +static DEVICE_ATTR_RO(tagging);
 +
 +static struct attribute *dsa_slave_attrs[] = {
 +	&dev_attr_tagging.attr,
 +	NULL
 +};
 +
 +static const struct attribute_group dsa_group = {
 +	.name	= "dsa",
 +	.attrs	= dsa_slave_attrs,
 +};
 +
+ static void dsa_master_set_mtu(struct net_device *dev, struct dsa_port *cpu_dp)
+ {
+ 	unsigned int mtu = ETH_DATA_LEN + cpu_dp->tag_ops->overhead;
+ 	int err;
+ 
+ 	rtnl_lock();
+ 	if (mtu <= dev->max_mtu) {
+ 		err = dev_set_mtu(dev, mtu);
+ 		if (err)
+ 			netdev_dbg(dev, "Unable to set MTU to include for DSA overheads\n");
+ 	}
+ 	rtnl_unlock();
+ }
+ 
+ static void dsa_master_reset_mtu(struct net_device *dev)
+ {
+ 	int err;
+ 
+ 	rtnl_lock();
+ 	err = dev_set_mtu(dev, ETH_DATA_LEN);
+ 	if (err)
+ 		netdev_dbg(dev,
+ 			   "Unable to reset MTU to exclude DSA overheads\n");
+ 	rtnl_unlock();
+ }
+ 
  int dsa_master_setup(struct net_device *dev, struct dsa_port *cpu_dp)
  {
 +	int ret;
 +
+ 	dsa_master_set_mtu(dev,  cpu_dp);
+ 
  	/* If we use a tagging format that doesn't have an ethertype
  	 * field, make sure that all packets from this point on get
  	 * sent to the tag format's receive function.
@@@ -204,8 -201,8 +232,9 @@@
  
  void dsa_master_teardown(struct net_device *dev)
  {
 +	sysfs_remove_group(&dev->dev.kobj, &dsa_group);
  	dsa_master_ethtool_teardown(dev);
+ 	dsa_master_reset_mtu(dev);
  
  	dev->dsa_ptr = NULL;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-05  0:33 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-12-05  0:33 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Heiner Kallweit, Andrew Lunn

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

Hi all,

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

  drivers/net/phy/phy_device.c

between commit:

  d2a36971ef59 ("net: phy: don't allow __set_phy_supported to add unsupported modes")

from the net tree and commits:

  3c1bcc8614db ("net: ethernet: Convert phydev advertize and supported from u32 to link mode")
  6915bf3b002b ("net: phy: don't allow __set_phy_supported to add unsupported modes")

from the net-next tree.

I fixed it up (I just used the net-next tree 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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-03  1:50 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-12-03  1:50 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, John Hurley

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

Hi all,

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

  drivers/net/ethernet/netronome/nfp/flower/offload.c

between commits:

  b5f0cf083400 ("nfp: flower: prevent offload if rhashtable insert fails")

from the net tree and commit:

  7885b4fc8d8e ("nfp: flower: allow non repr netdev offload")

from the net-next 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/netronome/nfp/flower/offload.c
index 2f49eb75f3cc,545d94168874..000000000000
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@@ -480,14 -469,10 +464,15 @@@ nfp_flower_add_offload(struct nfp_app *
  	err = rhashtable_insert_fast(&priv->flow_table, &flow_pay->fl_node,
  				     nfp_flower_table_params);
  	if (err)
 -		goto err_destroy_flow;
 +		goto err_release_metadata;
 +
- 	err = nfp_flower_xmit_flow(netdev, flow_pay,
++	err = nfp_flower_xmit_flow(app, flow_pay,
 +				   NFP_FLOWER_CMSG_TYPE_FLOW_ADD);
 +	if (err)
 +		goto err_remove_rhash;
  
- 	port->tc_offload_cnt++;
+ 	if (port)
+ 		port->tc_offload_cnt++;
  
  	/* Deallocate flow payload when flower rule has been destroyed. */
  	kfree(key_layer);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-18 23:56 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-18 23:56 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Nikolay Aleksandrov, David Ahern

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

Hi all,

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

  net/ipv4/ipmr_base.c

between commit:

  eddf016b9104 ("net: ipmr: fix unresolved entry dumps")

from the net tree and commit:

  e1cedae1ba6b ("ipmr: Refactor mr_rtm_dumproute")

from the net-next 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 net/ipv4/ipmr_base.c
index eab8cd5ec2f5,844806120f44..000000000000
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@@ -268,6 -268,83 +268,81 @@@ int mr_fill_mroute(struct mr_table *mrt
  }
  EXPORT_SYMBOL(mr_fill_mroute);
  
+ static bool mr_mfc_uses_dev(const struct mr_table *mrt,
+ 			    const struct mr_mfc *c,
+ 			    const struct net_device *dev)
+ {
+ 	int ct;
+ 
+ 	for (ct = c->mfc_un.res.minvif; ct < c->mfc_un.res.maxvif; ct++) {
+ 		if (VIF_EXISTS(mrt, ct) && c->mfc_un.res.ttls[ct] < 255) {
+ 			const struct vif_device *vif;
+ 
+ 			vif = &mrt->vif_table[ct];
+ 			if (vif->dev == dev)
+ 				return true;
+ 		}
+ 	}
+ 	return false;
+ }
+ 
+ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
+ 		  struct netlink_callback *cb,
+ 		  int (*fill)(struct mr_table *mrt, struct sk_buff *skb,
+ 			      u32 portid, u32 seq, struct mr_mfc *c,
+ 			      int cmd, int flags),
+ 		  spinlock_t *lock, struct fib_dump_filter *filter)
+ {
+ 	unsigned int e = 0, s_e = cb->args[1];
+ 	unsigned int flags = NLM_F_MULTI;
+ 	struct mr_mfc *mfc;
+ 	int err;
+ 
+ 	if (filter->filter_set)
+ 		flags |= NLM_F_DUMP_FILTERED;
+ 
+ 	list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list) {
+ 		if (e < s_e)
+ 			goto next_entry;
+ 		if (filter->dev &&
+ 		    !mr_mfc_uses_dev(mrt, mfc, filter->dev))
+ 			goto next_entry;
+ 
+ 		err = fill(mrt, skb, NETLINK_CB(cb->skb).portid,
+ 			   cb->nlh->nlmsg_seq, mfc, RTM_NEWROUTE, flags);
+ 		if (err < 0)
+ 			goto out;
+ next_entry:
+ 		e++;
+ 	}
 -	e = 0;
 -	s_e = 0;
+ 
+ 	spin_lock_bh(lock);
+ 	list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
+ 		if (e < s_e)
+ 			goto next_entry2;
+ 		if (filter->dev &&
+ 		    !mr_mfc_uses_dev(mrt, mfc, filter->dev))
+ 			goto next_entry2;
+ 
+ 		err = fill(mrt, skb, NETLINK_CB(cb->skb).portid,
+ 			   cb->nlh->nlmsg_seq, mfc, RTM_NEWROUTE, flags);
+ 		if (err < 0) {
+ 			spin_unlock_bh(lock);
+ 			goto out;
+ 		}
+ next_entry2:
+ 		e++;
+ 	}
+ 	spin_unlock_bh(lock);
+ 	err = 0;
+ 	e = 0;
+ 
+ out:
+ 	cb->args[1] = e;
+ 	return err;
+ }
+ EXPORT_SYMBOL(mr_table_dump);
+ 
  int mr_rtm_dumproute(struct sk_buff *skb, struct netlink_callback *cb,
  		     struct mr_table *(*iter)(struct net *net,
  					      struct mr_table *mrt),

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-16 23:46 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-16 23:46 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Davide Caratti, David Ahern

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

Hi all,

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

  net/sched/cls_api.c

between commit:

  e331473fee3d ("net/sched: cls_api: add missing validation of netlink attributes")

from the net tree and commit:

  dac9c9790e54 ("net: Add extack to nlmsg_parse")

from the net-next 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 net/sched/cls_api.c
index 70f144ac5e1d,43c8559aca56..000000000000
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@@ -1951,8 -2055,8 +2057,8 @@@ static int tc_dump_chain(struct sk_buf
  	if (nlmsg_len(cb->nlh) < sizeof(*tcm))
  		return skb->len;
  
 -	err = nlmsg_parse(cb->nlh, sizeof(*tcm), tca, TCA_MAX, NULL,
 +	err = nlmsg_parse(cb->nlh, sizeof(*tcm), tca, TCA_MAX, rtm_tca_policy,
- 			  NULL);
+ 			  cb->extack);
  	if (err)
  		return err;
  

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

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

* RE: linux-next: manual merge of the net-next tree with the net tree
  2018-10-11 23:45 Stephen Rothwell
@ 2018-10-14  7:58 ` Kiyanovski, Arthur
  0 siblings, 0 replies; 325+ messages in thread
From: Kiyanovski, Arthur @ 2018-10-14  7:58 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Friday, October 12, 2018 2:45 AM
> To: David Miller <davem@davemloft.net>; Networking
> <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Kiyanovski, Arthur
> <akiyano@amazon.com>
> Subject: linux-next: manual merge of the net-next tree with the net tree
> 
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/amazon/ena/ena_eth_com.c
> 
> between commit:
> 
>   248ab77342d0 ("net: ena: fix auto casting to boolean")
> 
> from the net tree and commit:
> 
>   cb36bb36e1f1 ("net: ena: use CSUM_CHECKED device indication to report
> skb's checksum status")
> 
> from the net-next 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/amazon/ena/ena_eth_com.c
> index 2b3ff0c20155,6f8e15b9b3cf..000000000000
> --- a/drivers/net/ethernet/amazon/ena/ena_eth_com.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_eth_com.c
> @@@ -245,11 -349,14 +349,14 @@@ static inline void ena_com_rx_set_flags
>   		(cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_MASK) >>
>   		ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_SHIFT;
>   	ena_rx_ctx->l3_csum_err =
>  -		(cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
>  -		ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT;
>  +		!!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
>  +		ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT);
>   	ena_rx_ctx->l4_csum_err =
>  -		(cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
>  -		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT;
>  +		!!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
>  +		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT);
> + 	ena_rx_ctx->l4_csum_checked =
> + 		!!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_MASK) >>
> + 		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_SHIFT);
>   	ena_rx_ctx->hash = cdesc->hash;
>   	ena_rx_ctx->frag =
>   		(cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_IPV4_FRAG_MASK) >>

Hi Stephen, 

The merge looks good.
I will know to mention conflicts in my future upstream releases.
Sorry for the trouble caused.

Thanks,
Arthur


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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-10-11 23:53 Stephen Rothwell
@ 2018-10-12  0:10 ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-12  0:10 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

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

Hi all,

On Fri, 12 Oct 2018 10:53:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/rxrpc/input.c
> 
> between commit:
> 
>   5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
> 
> from the net tree and commit:
> 
>   d2944b1c66a5 ("rxrpc: Use rxrpc_free_skb() rather than rxrpc_lose_skb()")
> 
> from the net-next tree.
> 
> I fixed it up (I used the net tree version) and can carry the fix as

Just to be clear, I did not use the whole file from the net tree, just
the net tree version of the conflicting hunks.  There are other non
conflicting changes on both sides.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-11 23:53 Stephen Rothwell
  2018-10-12  0:10 ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-11 23:53 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

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

Hi all,

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

  net/rxrpc/input.c

between commit:

  5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")

from the net tree and commit:

  d2944b1c66a5 ("rxrpc: Use rxrpc_free_skb() rather than rxrpc_lose_skb()")

from the net-next tree.

I fixed it up (I used the net tree 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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-11 23:45 Stephen Rothwell
  2018-10-14  7:58 ` Kiyanovski, Arthur
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-11 23:45 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Arthur Kiyanovski

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

Hi all,

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

  drivers/net/ethernet/amazon/ena/ena_eth_com.c

between commit:

  248ab77342d0 ("net: ena: fix auto casting to boolean")

from the net tree and commit:

  cb36bb36e1f1 ("net: ena: use CSUM_CHECKED device indication to report skb's checksum status")

from the net-next 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/amazon/ena/ena_eth_com.c
index 2b3ff0c20155,6f8e15b9b3cf..000000000000
--- a/drivers/net/ethernet/amazon/ena/ena_eth_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_eth_com.c
@@@ -245,11 -349,14 +349,14 @@@ static inline void ena_com_rx_set_flags
  		(cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_MASK) >>
  		ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_SHIFT;
  	ena_rx_ctx->l3_csum_err =
 -		(cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
 -		ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT;
 +		!!((cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
 +		ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT);
  	ena_rx_ctx->l4_csum_err =
 -		(cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
 -		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT;
 +		!!((cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
 +		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT);
+ 	ena_rx_ctx->l4_csum_checked =
+ 		!!((cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_MASK) >>
+ 		ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_SHIFT);
  	ena_rx_ctx->hash = cdesc->hash;
  	ena_rx_ctx->frag =
  		(cdesc->status & ENA_ETH_IO_RX_CDESC_BASE_IPV4_FRAG_MASK) >>

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-10-09 10:02 ` Jamal Hadi Salim
@ 2018-10-09 20:58   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-09 20:58 UTC (permalink / raw)
  To: Jamal Hadi Salim
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Al Viro

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

Hi Jamal,

On Tue, 9 Oct 2018 06:02:25 -0400 Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> Attached should fix it. Al, please double check.

OK, I will use that resolution from today.

Thanks.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-10-09  1:21 Stephen Rothwell
@ 2018-10-09 10:02 ` Jamal Hadi Salim
  2018-10-09 20:58   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Jamal Hadi Salim @ 2018-10-09 10:02 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Al Viro

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

On 2018-10-08 9:21 p.m., Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>    net/sched/cls_u32.c
> 
> between commit:
> 
>    6d4c407744dd ("net: sched: cls_u32: fix hnode refcounting")
> 
> from the net tree and commit:
> 
>    a030598690c6 ("net: sched: cls_u32: simplify the hell out u32_delete() emptiness check")
> 
> from the net-next tree.
> 
> I fixed it up (I reverted the net tree commit as I could not tell
> wich parts of it, if any, are still needed) 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.
> 

Attached should fix it. Al, please double check.

cheers,
jamal

[-- Attachment #2: al-merge-diff-net-next --]
[-- Type: text/plain, Size: 1165 bytes --]

--- a/net-next/net/sched/cls_u32.c	2018-10-09 05:18:04.046642676 -0400
+++ b/net/sched/cls_u32.c	2018-10-09 05:29:51.965528032 -0400
@@ -391,6 +391,7 @@
 	RCU_INIT_POINTER(root_ht->next, tp_c->hlist);
 	rcu_assign_pointer(tp_c->hlist, root_ht);
 
+	root_ht->refcnt++;
 	rcu_assign_pointer(tp->root, root_ht);
 	tp->data = tp_c;
 	return 0;
@@ -606,7 +607,7 @@
 	struct tc_u_hnode __rcu **hn;
 	struct tc_u_hnode *phn;
 
-	WARN_ON(ht->refcnt);
+	WARN_ON(--ht->refcnt);
 
 	u32_clear_hnode(tp, ht, extack);
 
@@ -634,7 +635,7 @@
 
 	WARN_ON(root_ht == NULL);
 
-	if (root_ht && --root_ht->refcnt == 0)
+	if (root_ht && --root_ht->refcnt == 1)
 		u32_destroy_hnode(tp, root_ht, extack);
 
 	if (--tp_c->refcnt == 0) {
@@ -679,7 +680,6 @@
 	}
 
 	if (ht->refcnt == 1) {
-		ht->refcnt--;
 		u32_destroy_hnode(tp, ht, extack);
 	} else {
 		NL_SET_ERR_MSG_MOD(extack, "Can not delete in-use filter");
@@ -1079,8 +1079,7 @@
 	}
 #endif
 
-	err = u32_set_parms(net, tp, base, n, tb, tca[TCA_RATE], ovr,
-			    extack);
+	err = u32_set_parms(net, tp, base, n, tb, tca[TCA_RATE], ovr, extack);
 	if (err == 0) {
 		struct tc_u_knode __rcu **ins;
 		struct tc_u_knode *pins;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-09  1:21 Stephen Rothwell
  2018-10-09 10:02 ` Jamal Hadi Salim
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-09  1:21 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Al Viro,
	Jamal Hadi Salim

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

Hi all,

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

  net/sched/cls_u32.c

between commit:

  6d4c407744dd ("net: sched: cls_u32: fix hnode refcounting")

from the net tree and commit:

  a030598690c6 ("net: sched: cls_u32: simplify the hell out u32_delete() emptiness check")

from the net-next tree.

I fixed it up (I reverted the net tree commit as I could not tell
wich parts of it, if any, are still needed) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-10-03  2:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-10-03  2:18 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Ahern,
	Christian Brauner

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

Hi all,

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

  net/core/rtnetlink.c

between commit:

  893626d6a353 ("rtnetlink: Fail dump if target netnsid is invalid")

from the net tree and commits:

  c383edc42403 ("rtnetlink: add rtnl_get_net_ns_capable()")
  7e4a8d5a93f6 ("rtnetlink: s/IFLA_IF_NETNSID/IFLA_TARGET_NETNSID/g")

from the net-next 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 net/core/rtnetlink.c
index 7f37fe9c65a5,35162e1b06ad..000000000000
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@@ -1895,11 -1910,13 +1910,11 @@@ static int rtnl_dump_ifinfo(struct sk_b
  
  	if (nlmsg_parse(cb->nlh, hdrlen, tb, IFLA_MAX,
  			ifla_policy, NULL) >= 0) {
- 		if (tb[IFLA_IF_NETNSID]) {
- 			netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
- 			tgt_net = get_target_net(skb->sk, netnsid);
+ 		if (tb[IFLA_TARGET_NETNSID]) {
+ 			netnsid = nla_get_s32(tb[IFLA_TARGET_NETNSID]);
+ 			tgt_net = rtnl_get_net_ns_capable(skb->sk, netnsid);
 -			if (IS_ERR(tgt_net)) {
 -				tgt_net = net;
 -				netnsid = -1;
 -			}
 +			if (IS_ERR(tgt_net))
 +				return PTR_ERR(tgt_net);
  		}
  
  		if (tb[IFLA_EXT_MASK])

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-09-21  0:24 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-09-21  0:24 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Sven Eckelmann, Simon Wunderlich

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

Hi all,

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

  net/batman-adv/main.h

between commit:

  dabeb13eee81 ("batman-adv: Increase version number to 2018.3")

from the net tree and commit:

  138c72efbd5d ("batman-adv: Start new development cycle")

from the net-next tree.

I fixed it up (I used the net-next tree 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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  9:53         ` Daniel Borkmann
  2018-09-18 10:15           ` Daniel Borkmann
@ 2018-09-18 16:32           ` David Miller
  1 sibling, 0 replies; 325+ messages in thread
From: David Miller @ 2018-09-18 16:32 UTC (permalink / raw)
  To: daniel
  Cc: vakul.garg, sfr, netdev, linux-next, linux-kernel, davejwatson, doronrk

From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 18 Sep 2018 11:53:17 +0200

> Ok, I think usually tests assert current kernel behavior to make sure any changes
> coming in don't accidentally break expectations from applications as opposed to
> future tests that still need fixing, but I guess I'm fine either way how to resolve
> the conflict; leaving it up to DaveM. Thanks for clarifying!

I'm doing the merge right now and will leave both tests in.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18 11:48               ` Stephen Rothwell
@ 2018-09-18 12:08                 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2018-09-18 12:08 UTC (permalink / raw)
  To: Stephen Rothwell, Vakul Garg
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, davejwatson, doronrk

On 09/18/2018 01:48 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 18 Sep 2018 10:17:03 +0000 Vakul Garg <vakul.garg@nxp.com> wrote:
>>
>> Got it. 
>> Thanks for the guidance.
> 
> So, what should I remove? ;-)

My (very own personal) preference in general would be that we test / assert
the kernel behavior that exists /today/, meaning once we implement support
for multi-record peek we add the corresponding test case along with that
code. Fwiw, this practice would be consistent with the rest of the kernel
selftests development model we have under net (& bpf).

Thanks,
Daniel

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18 10:17             ` Vakul Garg
@ 2018-09-18 11:48               ` Stephen Rothwell
  2018-09-18 12:08                 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-09-18 11:48 UTC (permalink / raw)
  To: Vakul Garg
  Cc: Daniel Borkmann, David Miller, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List, davejwatson,
	doronrk

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

Hi all,

On Tue, 18 Sep 2018 10:17:03 +0000 Vakul Garg <vakul.garg@nxp.com> wrote:
>
> Got it. 
> Thanks for the guidance.

So, what should I remove? ;-)

-- 
Cheers,
Stephen Rothwell

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

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

* RE: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18 10:15           ` Daniel Borkmann
@ 2018-09-18 10:17             ` Vakul Garg
  2018-09-18 11:48               ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Vakul Garg @ 2018-09-18 10:17 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, davejwatson, doronrk



> -----Original Message-----
> From: Daniel Borkmann <daniel@iogearbox.net>
> Sent: Tuesday, September 18, 2018 3:46 PM
> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
> Networking <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; davejwatson@fb.com;
> doronrk@fb.com
> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
> 
> On 09/18/2018 11:53 AM, Daniel Borkmann wrote:
> > On 09/18/2018 11:32 AM, Vakul Garg wrote:
> >>> -----Original Message-----
> >>> From: Daniel Borkmann <daniel@iogearbox.net>
> >>> Sent: Tuesday, September 18, 2018 2:57 PM
> >>> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
> >>> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
> >>> Networking <netdev@vger.kernel.org>
> >>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
> >>> Kernel Mailing List <linux-kernel@vger.kernel.org>
> >>> Subject: Re: linux-next: manual merge of the net-next tree with the
> >>> net tree
> >>>
> >>> On 09/18/2018 11:10 AM, Vakul Garg wrote:
> >>>>> -----Original Message-----
> >>>>> From: Daniel Borkmann <daniel@iogearbox.net>
> >>>>> Sent: Tuesday, September 18, 2018 2:14 PM
> >>>>> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
> >>>>> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
> >>>>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
> >>>>> Kernel Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
> >>>>> <vakul.garg@nxp.com>
> >>>>> Subject: Re: linux-next: manual merge of the net-next tree with
> >>>>> the net tree
> >>>>>
> >>>>> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Today's linux-next merge of the net-next tree got a conflict in:
> >>>>>>
> >>>>>>   tools/testing/selftests/net/tls.c
> >>>>>>
> >>>>>> between commit:
> >>>>>>
> >>>>>>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> >>>>>>
> >>>>>> from the net tree and commit:
> >>>>>>
> >>>>>>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
> >>>>>> across multiple records")
> >>>>>>
> >>>>>> from the net-next 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.
> >>>>>
> >>>>> The test from 50c6b58a814d supersedes the one from c2ad647c6442
> so
> >>>>> the recv_peek_large_buf_mult_recs could be removed; latter was
> >>>>> also not working correctly due to this bug.
> >>>>
> >>>> Why remove recv_peek_large_buf_mult_recs if its correct?
> >>>> Why not the newly added one which achieves the same thing?
> >>>
> >>> Hmm, not quite, on net-next kernel, the
> >>> recv_peek_large_buf_mult_recs fails every time I invoke the tls test
> suite:
> >>>
> >>> # ./tls
> >>> [==========] Running 28 tests from 2 test cases.
> >>> [ RUN      ] tls.sendfile
> >>> [       OK ] tls.sendfile
> >>> [ RUN      ] tls.send_then_sendfile
> >>> [       OK ] tls.send_then_sendfile
> >>> [ RUN      ] tls.recv_max
> >>> [       OK ] tls.recv_max
> >>> [ RUN      ] tls.recv_small
> >>> [       OK ] tls.recv_small
> >>> [ RUN      ] tls.msg_more
> >>> [       OK ] tls.msg_more
> >>> [ RUN      ] tls.sendmsg_single
> >>> [       OK ] tls.sendmsg_single
> >>> [ RUN      ] tls.sendmsg_large
> >>> [       OK ] tls.sendmsg_large
> >>> [ RUN      ] tls.sendmsg_multiple
> >>> [       OK ] tls.sendmsg_multiple
> >>> [ RUN      ] tls.sendmsg_multiple_stress
> >>> [       OK ] tls.sendmsg_multiple_stress
> >>> [ RUN      ] tls.splice_from_pipe
> >>> [       OK ] tls.splice_from_pipe
> >>> [ RUN      ] tls.splice_from_pipe2
> >>> [       OK ] tls.splice_from_pipe2
> >>> [ RUN      ] tls.send_and_splice
> >>> [       OK ] tls.send_and_splice
> >>> [ RUN      ] tls.splice_to_pipe
> >>> [       OK ] tls.splice_to_pipe
> >>> [ RUN      ] tls.recvmsg_single
> >>> [       OK ] tls.recvmsg_single
> >>> [ RUN      ] tls.recvmsg_single_max
> >>> [       OK ] tls.recvmsg_single_max
> >>> [ RUN      ] tls.recvmsg_multiple
> >>> [       OK ] tls.recvmsg_multiple
> >>> [ RUN      ] tls.single_send_multiple_recv
> >>> [       OK ] tls.single_send_multiple_recv
> >>> [ RUN      ] tls.multiple_send_single_recv
> >>> [       OK ] tls.multiple_send_single_recv
> >>> [ RUN      ] tls.recv_partial
> >>> [       OK ] tls.recv_partial
> >>> [ RUN      ] tls.recv_nonblock
> >>> [       OK ] tls.recv_nonblock
> >>> [ RUN      ] tls.recv_peek
> >>> [       OK ] tls.recv_peek
> >>> [ RUN      ] tls.recv_peek_multiple
> >>> [       OK ] tls.recv_peek_multiple
> >>> [ RUN      ] tls.recv_peek_large_buf_mult_recs
> >>> tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected
> >>> memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
> >>> tls.recv_peek_large_buf_mult_recs: Test failed at step #8
> >>> [     FAIL ] tls.recv_peek_large_buf_mult_recs
> >>> [ RUN      ] tls.pollin
> >>> [       OK ] tls.pollin
> >>> [ RUN      ] tls.poll_wait
> >>> [       OK ] tls.poll_wait
> >>> [ RUN      ] tls.blocking
> >>> [       OK ] tls.blocking
> >>> [ RUN      ] tls.nonblocking
> >>> [       OK ] tls.nonblocking
> >>> [ RUN      ] tls.control_msg
> >>> [       OK ] tls.control_msg
> >>> [==========] 27 / 28 tests passed.
> >>> [  FAILED  ]
> >>>
> >>> Here's what the recvfrom() with MSG_PEEK sees:
> >>>
> >>> [pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid  2602]
> >>> socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid  2602] bind(4,
> >>> {sa_family=AF_INET, sin_port=htons(0),
> >>> sin_addr=inet_addr("0.0.0.0")}, 16) =
> >>> 0
> >>> [pid  2602] listen(4, 10)               = 0
> >>> [pid  2602] getsockname(4, {sa_family=AF_INET,
> >>> sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> >>> [pid  2602] connect(3, {sa_family=AF_INET, sin_port=htons(41483),
> >>> sin_addr=inet_addr("0.0.0.0")},
> >>> 16) = 0 [pid  2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */,
> >>> [7564404], 4) = 0 [pid  2602] setsockopt(3, 0x11a /* SOL_?? */, 1,
> >>>
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".
> >>> ..,
> >>> 40) = 0 [pid  2602] accept(4, {sa_family=AF_INET,
> >>> sin_port=htons(46290), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
> >>> [pid  2602] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4)
> >>> = 0 [pid  2602] setsockopt(5, 0x11a /* SOL_?? */, 2,
> >>>
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".
> >>> ..,
> >>> 40) = 0
> >>> [pid  2602] close(4)                    = 0
> >>> [pid  2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid
> >>> 2602] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid  2602]
> >>> recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK,
> >>> NULL, NULL) = 64 [pid  2602] write(2,
> >>> "tls.c:526:tls.recv_peek_large_bu"...,
> >>> 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected
> >>> memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
> >>> ) = 112
> >>> [pid  2602] close(3)                    = 0
> >>> [pid  2602] close(5)                    = 0
> >>> [pid  2602] exit_group(8)               = ?
> >>>
> >>> Reason for the "test_read_peektest_read_peektest[...]" is because
> >>> MSG_PEEK cannot call tls_sw_advance_skb(), since the skb is sitting
> >>> there that needs to be consumed for non-MSG_PEEK case, and only then
> >>> we can advance it.
> >>
> >> I general, my plan was to modify the tls_sw_recvmsg() to trigger as
> >> many decryption as possible as required by requested user space PEEK
> size.
> >> This would have required creating a pending list of decrypted records in
> tls_tx context.
> >
> > Right, had been thinking the same though for a fix in -net it would
> > have been way too intrusive, hence the 50c6b58a814d ("tls: fix
> > currently broken MSG_PEEK
> > behavior") to avoid looping the same record which is clearly a bug.
> > Wondering if DaveW's original rationale was to avoid accumulating too
> > many records in the kernel since we would need to unpause strparser
> > and keep processing the deeper we peek.
> >
> >>> Could you elaborate on where you ever had this test succeeding? With
> >>> nxp accelerator?
> >>
> >> I never had this test succeeding. I pointed the problem to Dave
> >> Watson sometime back (found during code reading).
> >>
> >> To make sure that this bug does not slip out, I simply submitted a
> >> test case to keep reminding ourselves that we need to fix it sometime.
> >
> > Ok, I think usually tests assert current kernel behavior to make sure
> > any changes coming in don't accidentally break expectations from
> > applications as opposed to future tests that still need fixing, but I
> > guess I'm fine either way how to resolve the conflict; leaving it up to
> DaveM. Thanks for clarifying!
> 
> By the way, full commit message from c2ad647c6442 said:
> 
>   selftests/tls: Add test for recv(PEEK) spanning across multiple records
> 
>   Added test case to receive multiple records with a single recvmsg()
>   operation with a MSG_PEEK set.
> 
> From reading it, the expectation would normally be that the test case would
> succeed for the author, I think in future such things definitely need to be
> better clarified in the commit log to avoid confusion for others.
> 

Got it. 
Thanks for the guidance.
 

> Thanks,
> Daniel

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  9:53         ` Daniel Borkmann
@ 2018-09-18 10:15           ` Daniel Borkmann
  2018-09-18 10:17             ` Vakul Garg
  2018-09-18 16:32           ` David Miller
  1 sibling, 1 reply; 325+ messages in thread
From: Daniel Borkmann @ 2018-09-18 10:15 UTC (permalink / raw)
  To: Vakul Garg, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, davejwatson, doronrk

On 09/18/2018 11:53 AM, Daniel Borkmann wrote:
> On 09/18/2018 11:32 AM, Vakul Garg wrote:
>>> -----Original Message-----
>>> From: Daniel Borkmann <daniel@iogearbox.net>
>>> Sent: Tuesday, September 18, 2018 2:57 PM
>>> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
>>> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
>>> Networking <netdev@vger.kernel.org>
>>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
>>> Mailing List <linux-kernel@vger.kernel.org>
>>> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>>>
>>> On 09/18/2018 11:10 AM, Vakul Garg wrote:
>>>>> -----Original Message-----
>>>>> From: Daniel Borkmann <daniel@iogearbox.net>
>>>>> Sent: Tuesday, September 18, 2018 2:14 PM
>>>>> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
>>>>> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
>>>>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
>>>>> Kernel Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
>>>>> <vakul.garg@nxp.com>
>>>>> Subject: Re: linux-next: manual merge of the net-next tree with the
>>>>> net tree
>>>>>
>>>>> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Today's linux-next merge of the net-next tree got a conflict in:
>>>>>>
>>>>>>   tools/testing/selftests/net/tls.c
>>>>>>
>>>>>> between commit:
>>>>>>
>>>>>>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
>>>>>>
>>>>>> from the net tree and commit:
>>>>>>
>>>>>>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
>>>>>> across multiple records")
>>>>>>
>>>>>> from the net-next 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.
>>>>>
>>>>> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so
>>>>> the recv_peek_large_buf_mult_recs could be removed; latter was also
>>>>> not working correctly due to this bug.
>>>>
>>>> Why remove recv_peek_large_buf_mult_recs if its correct?
>>>> Why not the newly added one which achieves the same thing?
>>>
>>> Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
>>> every time I invoke the tls test suite:
>>>
>>> # ./tls
>>> [==========] Running 28 tests from 2 test cases.
>>> [ RUN      ] tls.sendfile
>>> [       OK ] tls.sendfile
>>> [ RUN      ] tls.send_then_sendfile
>>> [       OK ] tls.send_then_sendfile
>>> [ RUN      ] tls.recv_max
>>> [       OK ] tls.recv_max
>>> [ RUN      ] tls.recv_small
>>> [       OK ] tls.recv_small
>>> [ RUN      ] tls.msg_more
>>> [       OK ] tls.msg_more
>>> [ RUN      ] tls.sendmsg_single
>>> [       OK ] tls.sendmsg_single
>>> [ RUN      ] tls.sendmsg_large
>>> [       OK ] tls.sendmsg_large
>>> [ RUN      ] tls.sendmsg_multiple
>>> [       OK ] tls.sendmsg_multiple
>>> [ RUN      ] tls.sendmsg_multiple_stress
>>> [       OK ] tls.sendmsg_multiple_stress
>>> [ RUN      ] tls.splice_from_pipe
>>> [       OK ] tls.splice_from_pipe
>>> [ RUN      ] tls.splice_from_pipe2
>>> [       OK ] tls.splice_from_pipe2
>>> [ RUN      ] tls.send_and_splice
>>> [       OK ] tls.send_and_splice
>>> [ RUN      ] tls.splice_to_pipe
>>> [       OK ] tls.splice_to_pipe
>>> [ RUN      ] tls.recvmsg_single
>>> [       OK ] tls.recvmsg_single
>>> [ RUN      ] tls.recvmsg_single_max
>>> [       OK ] tls.recvmsg_single_max
>>> [ RUN      ] tls.recvmsg_multiple
>>> [       OK ] tls.recvmsg_multiple
>>> [ RUN      ] tls.single_send_multiple_recv
>>> [       OK ] tls.single_send_multiple_recv
>>> [ RUN      ] tls.multiple_send_single_recv
>>> [       OK ] tls.multiple_send_single_recv
>>> [ RUN      ] tls.recv_partial
>>> [       OK ] tls.recv_partial
>>> [ RUN      ] tls.recv_nonblock
>>> [       OK ] tls.recv_nonblock
>>> [ RUN      ] tls.recv_peek
>>> [       OK ] tls.recv_peek
>>> [ RUN      ] tls.recv_peek_multiple
>>> [       OK ] tls.recv_peek_multiple
>>> [ RUN      ] tls.recv_peek_large_buf_mult_recs
>>> tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
>>> buf, len) (18446744073709551595) == 0 (0)
>>> tls.recv_peek_large_buf_mult_recs: Test failed at step #8
>>> [     FAIL ] tls.recv_peek_large_buf_mult_recs
>>> [ RUN      ] tls.pollin
>>> [       OK ] tls.pollin
>>> [ RUN      ] tls.poll_wait
>>> [       OK ] tls.poll_wait
>>> [ RUN      ] tls.blocking
>>> [       OK ] tls.blocking
>>> [ RUN      ] tls.nonblocking
>>> [       OK ] tls.nonblocking
>>> [ RUN      ] tls.control_msg
>>> [       OK ] tls.control_msg
>>> [==========] 27 / 28 tests passed.
>>> [  FAILED  ]
>>>
>>> Here's what the recvfrom() with MSG_PEEK sees:
>>>
>>> [pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid  2602]
>>> socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid  2602] bind(4,
>>> {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) =
>>> 0
>>> [pid  2602] listen(4, 10)               = 0
>>> [pid  2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483),
>>> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid  2602] connect(3,
>>> {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")},
>>> 16) = 0 [pid  2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4)
>>> = 0 [pid  2602] setsockopt(3, 0x11a /* SOL_?? */, 1,
>>> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
>>> 40) = 0 [pid  2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290),
>>> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid  2602] setsockopt(5,
>>> SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid  2602] setsockopt(5,
>>> 0x11a /* SOL_?? */, 2,
>>> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
>>> 40) = 0
>>> [pid  2602] close(4)                    = 0
>>> [pid  2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid  2602]
>>> sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid  2602] recvfrom(5,
>>> "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
>>> [pid  2602] write(2, "tls.c:526:tls.recv_peek_large_bu"...,
>>> 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
>>> buf, len) (18446744073709551595) == 0 (0)
>>> ) = 112
>>> [pid  2602] close(3)                    = 0
>>> [pid  2602] close(5)                    = 0
>>> [pid  2602] exit_group(8)               = ?
>>>
>>> Reason for the "test_read_peektest_read_peektest[...]" is because
>>> MSG_PEEK cannot call tls_sw_advance_skb(), since the skb is sitting there
>>> that needs to be consumed for non-MSG_PEEK case, and only then we can
>>> advance it.
>>
>> I general, my plan was to modify the tls_sw_recvmsg() to trigger as many 
>> decryption as possible as required by requested user space PEEK size.
>> This would have required creating a pending list of decrypted records in tls_tx context.
> 
> Right, had been thinking the same though for a fix in -net it would have been
> way too intrusive, hence the 50c6b58a814d ("tls: fix currently broken MSG_PEEK
> behavior") to avoid looping the same record which is clearly a bug. Wondering
> if DaveW's original rationale was to avoid accumulating too many records in the
> kernel since we would need to unpause strparser and keep processing the deeper
> we peek.
> 
>>> Could you elaborate on where you ever had this test succeeding? With nxp
>>> accelerator?
>>  
>> I never had this test succeeding. I pointed the problem to Dave Watson sometime
>> back (found during code reading). 
>>
>> To make sure that this bug does not slip out, I simply submitted a test case to keep
>> reminding ourselves that we need to fix it sometime.
> 
> Ok, I think usually tests assert current kernel behavior to make sure any changes
> coming in don't accidentally break expectations from applications as opposed to
> future tests that still need fixing, but I guess I'm fine either way how to resolve
> the conflict; leaving it up to DaveM. Thanks for clarifying!

By the way, full commit message from c2ad647c6442 said:

  selftests/tls: Add test for recv(PEEK) spanning across multiple records

  Added test case to receive multiple records with a single recvmsg()
  operation with a MSG_PEEK set.

From reading it, the expectation would normally be that the test case would
succeed for the author, I think in future such things definitely need to be
better clarified in the commit log to avoid confusion for others.

Thanks,
Daniel

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  9:32       ` Vakul Garg
@ 2018-09-18  9:53         ` Daniel Borkmann
  2018-09-18 10:15           ` Daniel Borkmann
  2018-09-18 16:32           ` David Miller
  0 siblings, 2 replies; 325+ messages in thread
From: Daniel Borkmann @ 2018-09-18  9:53 UTC (permalink / raw)
  To: Vakul Garg, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, davejwatson, doronrk

On 09/18/2018 11:32 AM, Vakul Garg wrote:
>> -----Original Message-----
>> From: Daniel Borkmann <daniel@iogearbox.net>
>> Sent: Tuesday, September 18, 2018 2:57 PM
>> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
>> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
>> Networking <netdev@vger.kernel.org>
>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
>> Mailing List <linux-kernel@vger.kernel.org>
>> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>>
>> On 09/18/2018 11:10 AM, Vakul Garg wrote:
>>>> -----Original Message-----
>>>> From: Daniel Borkmann <daniel@iogearbox.net>
>>>> Sent: Tuesday, September 18, 2018 2:14 PM
>>>> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
>>>> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
>>>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
>>>> Kernel Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
>>>> <vakul.garg@nxp.com>
>>>> Subject: Re: linux-next: manual merge of the net-next tree with the
>>>> net tree
>>>>
>>>> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the net-next tree got a conflict in:
>>>>>
>>>>>   tools/testing/selftests/net/tls.c
>>>>>
>>>>> between commit:
>>>>>
>>>>>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
>>>>>
>>>>> from the net tree and commit:
>>>>>
>>>>>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
>>>>> across multiple records")
>>>>>
>>>>> from the net-next 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.
>>>>
>>>> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so
>>>> the recv_peek_large_buf_mult_recs could be removed; latter was also
>>>> not working correctly due to this bug.
>>>
>>> Why remove recv_peek_large_buf_mult_recs if its correct?
>>> Why not the newly added one which achieves the same thing?
>>
>> Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
>> every time I invoke the tls test suite:
>>
>> # ./tls
>> [==========] Running 28 tests from 2 test cases.
>> [ RUN      ] tls.sendfile
>> [       OK ] tls.sendfile
>> [ RUN      ] tls.send_then_sendfile
>> [       OK ] tls.send_then_sendfile
>> [ RUN      ] tls.recv_max
>> [       OK ] tls.recv_max
>> [ RUN      ] tls.recv_small
>> [       OK ] tls.recv_small
>> [ RUN      ] tls.msg_more
>> [       OK ] tls.msg_more
>> [ RUN      ] tls.sendmsg_single
>> [       OK ] tls.sendmsg_single
>> [ RUN      ] tls.sendmsg_large
>> [       OK ] tls.sendmsg_large
>> [ RUN      ] tls.sendmsg_multiple
>> [       OK ] tls.sendmsg_multiple
>> [ RUN      ] tls.sendmsg_multiple_stress
>> [       OK ] tls.sendmsg_multiple_stress
>> [ RUN      ] tls.splice_from_pipe
>> [       OK ] tls.splice_from_pipe
>> [ RUN      ] tls.splice_from_pipe2
>> [       OK ] tls.splice_from_pipe2
>> [ RUN      ] tls.send_and_splice
>> [       OK ] tls.send_and_splice
>> [ RUN      ] tls.splice_to_pipe
>> [       OK ] tls.splice_to_pipe
>> [ RUN      ] tls.recvmsg_single
>> [       OK ] tls.recvmsg_single
>> [ RUN      ] tls.recvmsg_single_max
>> [       OK ] tls.recvmsg_single_max
>> [ RUN      ] tls.recvmsg_multiple
>> [       OK ] tls.recvmsg_multiple
>> [ RUN      ] tls.single_send_multiple_recv
>> [       OK ] tls.single_send_multiple_recv
>> [ RUN      ] tls.multiple_send_single_recv
>> [       OK ] tls.multiple_send_single_recv
>> [ RUN      ] tls.recv_partial
>> [       OK ] tls.recv_partial
>> [ RUN      ] tls.recv_nonblock
>> [       OK ] tls.recv_nonblock
>> [ RUN      ] tls.recv_peek
>> [       OK ] tls.recv_peek
>> [ RUN      ] tls.recv_peek_multiple
>> [       OK ] tls.recv_peek_multiple
>> [ RUN      ] tls.recv_peek_large_buf_mult_recs
>> tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
>> buf, len) (18446744073709551595) == 0 (0)
>> tls.recv_peek_large_buf_mult_recs: Test failed at step #8
>> [     FAIL ] tls.recv_peek_large_buf_mult_recs
>> [ RUN      ] tls.pollin
>> [       OK ] tls.pollin
>> [ RUN      ] tls.poll_wait
>> [       OK ] tls.poll_wait
>> [ RUN      ] tls.blocking
>> [       OK ] tls.blocking
>> [ RUN      ] tls.nonblocking
>> [       OK ] tls.nonblocking
>> [ RUN      ] tls.control_msg
>> [       OK ] tls.control_msg
>> [==========] 27 / 28 tests passed.
>> [  FAILED  ]
>>
>> Here's what the recvfrom() with MSG_PEEK sees:
>>
>> [pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid  2602]
>> socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid  2602] bind(4,
>> {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) =
>> 0
>> [pid  2602] listen(4, 10)               = 0
>> [pid  2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483),
>> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid  2602] connect(3,
>> {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")},
>> 16) = 0 [pid  2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4)
>> = 0 [pid  2602] setsockopt(3, 0x11a /* SOL_?? */, 1,
>> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
>> 40) = 0 [pid  2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290),
>> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid  2602] setsockopt(5,
>> SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid  2602] setsockopt(5,
>> 0x11a /* SOL_?? */, 2,
>> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
>> 40) = 0
>> [pid  2602] close(4)                    = 0
>> [pid  2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid  2602]
>> sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid  2602] recvfrom(5,
>> "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
>> [pid  2602] write(2, "tls.c:526:tls.recv_peek_large_bu"...,
>> 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
>> buf, len) (18446744073709551595) == 0 (0)
>> ) = 112
>> [pid  2602] close(3)                    = 0
>> [pid  2602] close(5)                    = 0
>> [pid  2602] exit_group(8)               = ?
>>
>> Reason for the "test_read_peektest_read_peektest[...]" is because
>> MSG_PEEK cannot call tls_sw_advance_skb(), since the skb is sitting there
>> that needs to be consumed for non-MSG_PEEK case, and only then we can
>> advance it.
> 
> I general, my plan was to modify the tls_sw_recvmsg() to trigger as many 
> decryption as possible as required by requested user space PEEK size.
> This would have required creating a pending list of decrypted records in tls_tx context.

Right, had been thinking the same though for a fix in -net it would have been
way too intrusive, hence the 50c6b58a814d ("tls: fix currently broken MSG_PEEK
behavior") to avoid looping the same record which is clearly a bug. Wondering
if DaveW's original rationale was to avoid accumulating too many records in the
kernel since we would need to unpause strparser and keep processing the deeper
we peek.

>> Could you elaborate on where you ever had this test succeeding? With nxp
>> accelerator?
>  
> I never had this test succeeding. I pointed the problem to Dave Watson sometime
> back (found during code reading). 
> 
> To make sure that this bug does not slip out, I simply submitted a test case to keep
> reminding ourselves that we need to fix it sometime.

Ok, I think usually tests assert current kernel behavior to make sure any changes
coming in don't accidentally break expectations from applications as opposed to
future tests that still need fixing, but I guess I'm fine either way how to resolve
the conflict; leaving it up to DaveM. Thanks for clarifying!

Cheers,
Daniel

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

* RE: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  9:26     ` Daniel Borkmann
@ 2018-09-18  9:32       ` Vakul Garg
  2018-09-18  9:53         ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Vakul Garg @ 2018-09-18  9:32 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List



> -----Original Message-----
> From: Daniel Borkmann <daniel@iogearbox.net>
> Sent: Tuesday, September 18, 2018 2:57 PM
> To: Vakul Garg <vakul.garg@nxp.com>; Stephen Rothwell
> <sfr@canb.auug.org.au>; David Miller <davem@davemloft.net>;
> Networking <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
> 
> On 09/18/2018 11:10 AM, Vakul Garg wrote:
> >> -----Original Message-----
> >> From: Daniel Borkmann <daniel@iogearbox.net>
> >> Sent: Tuesday, September 18, 2018 2:14 PM
> >> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
> >> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
> >> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux
> >> Kernel Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
> >> <vakul.garg@nxp.com>
> >> Subject: Re: linux-next: manual merge of the net-next tree with the
> >> net tree
> >>
> >> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the net-next tree got a conflict in:
> >>>
> >>>   tools/testing/selftests/net/tls.c
> >>>
> >>> between commit:
> >>>
> >>>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> >>>
> >>> from the net tree and commit:
> >>>
> >>>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
> >>> across multiple records")
> >>>
> >>> from the net-next 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.
> >>
> >> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so
> >> the recv_peek_large_buf_mult_recs could be removed; latter was also
> >> not working correctly due to this bug.
> >
> > Why remove recv_peek_large_buf_mult_recs if its correct?
> > Why not the newly added one which achieves the same thing?
> 
> Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
> every time I invoke the tls test suite:
> 
> # ./tls
> [==========] Running 28 tests from 2 test cases.
> [ RUN      ] tls.sendfile
> [       OK ] tls.sendfile
> [ RUN      ] tls.send_then_sendfile
> [       OK ] tls.send_then_sendfile
> [ RUN      ] tls.recv_max
> [       OK ] tls.recv_max
> [ RUN      ] tls.recv_small
> [       OK ] tls.recv_small
> [ RUN      ] tls.msg_more
> [       OK ] tls.msg_more
> [ RUN      ] tls.sendmsg_single
> [       OK ] tls.sendmsg_single
> [ RUN      ] tls.sendmsg_large
> [       OK ] tls.sendmsg_large
> [ RUN      ] tls.sendmsg_multiple
> [       OK ] tls.sendmsg_multiple
> [ RUN      ] tls.sendmsg_multiple_stress
> [       OK ] tls.sendmsg_multiple_stress
> [ RUN      ] tls.splice_from_pipe
> [       OK ] tls.splice_from_pipe
> [ RUN      ] tls.splice_from_pipe2
> [       OK ] tls.splice_from_pipe2
> [ RUN      ] tls.send_and_splice
> [       OK ] tls.send_and_splice
> [ RUN      ] tls.splice_to_pipe
> [       OK ] tls.splice_to_pipe
> [ RUN      ] tls.recvmsg_single
> [       OK ] tls.recvmsg_single
> [ RUN      ] tls.recvmsg_single_max
> [       OK ] tls.recvmsg_single_max
> [ RUN      ] tls.recvmsg_multiple
> [       OK ] tls.recvmsg_multiple
> [ RUN      ] tls.single_send_multiple_recv
> [       OK ] tls.single_send_multiple_recv
> [ RUN      ] tls.multiple_send_single_recv
> [       OK ] tls.multiple_send_single_recv
> [ RUN      ] tls.recv_partial
> [       OK ] tls.recv_partial
> [ RUN      ] tls.recv_nonblock
> [       OK ] tls.recv_nonblock
> [ RUN      ] tls.recv_peek
> [       OK ] tls.recv_peek
> [ RUN      ] tls.recv_peek_multiple
> [       OK ] tls.recv_peek_multiple
> [ RUN      ] tls.recv_peek_large_buf_mult_recs
> tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
> buf, len) (18446744073709551595) == 0 (0)
> tls.recv_peek_large_buf_mult_recs: Test failed at step #8
> [     FAIL ] tls.recv_peek_large_buf_mult_recs
> [ RUN      ] tls.pollin
> [       OK ] tls.pollin
> [ RUN      ] tls.poll_wait
> [       OK ] tls.poll_wait
> [ RUN      ] tls.blocking
> [       OK ] tls.blocking
> [ RUN      ] tls.nonblocking
> [       OK ] tls.nonblocking
> [ RUN      ] tls.control_msg
> [       OK ] tls.control_msg
> [==========] 27 / 28 tests passed.
> [  FAILED  ]
> 
> Here's what the recvfrom() with MSG_PEEK sees:
> 
> [pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid  2602]
> socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid  2602] bind(4,
> {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) =
> 0
> [pid  2602] listen(4, 10)               = 0
> [pid  2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid  2602] connect(3,
> {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")},
> 16) = 0 [pid  2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4)
> = 0 [pid  2602] setsockopt(3, 0x11a /* SOL_?? */, 1,
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 40) = 0 [pid  2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290),
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid  2602] setsockopt(5,
> SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid  2602] setsockopt(5,
> 0x11a /* SOL_?? */, 2,
> "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 40) = 0
> [pid  2602] close(4)                    = 0
> [pid  2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid  2602]
> sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid  2602] recvfrom(5,
> "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
> [pid  2602] write(2, "tls.c:526:tls.recv_peek_large_bu"...,
> 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str,
> buf, len) (18446744073709551595) == 0 (0)
> ) = 112
> [pid  2602] close(3)                    = 0
> [pid  2602] close(5)                    = 0
> [pid  2602] exit_group(8)               = ?
> 
> Reason for the "test_read_peektest_read_peektest[...]" is because
> MSG_PEEK cannot call tls_sw_advance_skb(), since the skb is sitting there
> that needs to be consumed for non-MSG_PEEK case, and only then we can
> advance it.
> 

I general, my plan was to modify the tls_sw_recvmsg() to trigger as many 
decryption as possible as required by requested user space PEEK size.
This would have required creating a pending list of decrypted records in tls_tx context.

> Could you elaborate on where you ever had this test succeeding? With nxp
> accelerator?
 
I never had this test succeeding. I pointed the problem to Dave Watson sometime
back (found during code reading). 

To make sure that this bug does not slip out, I simply submitted a test case to keep
reminding ourselves that we need to fix it sometime.

> 
> Thanks,
> Daniel

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  9:10   ` Vakul Garg
@ 2018-09-18  9:26     ` Daniel Borkmann
  2018-09-18  9:32       ` Vakul Garg
  0 siblings, 1 reply; 325+ messages in thread
From: Daniel Borkmann @ 2018-09-18  9:26 UTC (permalink / raw)
  To: Vakul Garg, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

On 09/18/2018 11:10 AM, Vakul Garg wrote:
>> -----Original Message-----
>> From: Daniel Borkmann <daniel@iogearbox.net>
>> Sent: Tuesday, September 18, 2018 2:14 PM
>> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
>> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
>> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
>> Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
>> <vakul.garg@nxp.com>
>> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
>>
>> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the net-next tree got a conflict in:
>>>
>>>   tools/testing/selftests/net/tls.c
>>>
>>> between commit:
>>>
>>>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
>>>
>>> from the net tree and commit:
>>>
>>>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
>>> across multiple records")
>>>
>>> from the net-next 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.
>>
>> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
>> recv_peek_large_buf_mult_recs could be removed; latter was also not
>> working correctly due to this bug.
> 
> Why remove recv_peek_large_buf_mult_recs if its correct?
> Why not the newly added one which achieves the same thing?

Hmm, not quite, on net-next kernel, the recv_peek_large_buf_mult_recs fails
every time I invoke the tls test suite:

# ./tls
[==========] Running 28 tests from 2 test cases.
[ RUN      ] tls.sendfile
[       OK ] tls.sendfile
[ RUN      ] tls.send_then_sendfile
[       OK ] tls.send_then_sendfile
[ RUN      ] tls.recv_max
[       OK ] tls.recv_max
[ RUN      ] tls.recv_small
[       OK ] tls.recv_small
[ RUN      ] tls.msg_more
[       OK ] tls.msg_more
[ RUN      ] tls.sendmsg_single
[       OK ] tls.sendmsg_single
[ RUN      ] tls.sendmsg_large
[       OK ] tls.sendmsg_large
[ RUN      ] tls.sendmsg_multiple
[       OK ] tls.sendmsg_multiple
[ RUN      ] tls.sendmsg_multiple_stress
[       OK ] tls.sendmsg_multiple_stress
[ RUN      ] tls.splice_from_pipe
[       OK ] tls.splice_from_pipe
[ RUN      ] tls.splice_from_pipe2
[       OK ] tls.splice_from_pipe2
[ RUN      ] tls.send_and_splice
[       OK ] tls.send_and_splice
[ RUN      ] tls.splice_to_pipe
[       OK ] tls.splice_to_pipe
[ RUN      ] tls.recvmsg_single
[       OK ] tls.recvmsg_single
[ RUN      ] tls.recvmsg_single_max
[       OK ] tls.recvmsg_single_max
[ RUN      ] tls.recvmsg_multiple
[       OK ] tls.recvmsg_multiple
[ RUN      ] tls.single_send_multiple_recv
[       OK ] tls.single_send_multiple_recv
[ RUN      ] tls.multiple_send_single_recv
[       OK ] tls.multiple_send_single_recv
[ RUN      ] tls.recv_partial
[       OK ] tls.recv_partial
[ RUN      ] tls.recv_nonblock
[       OK ] tls.recv_nonblock
[ RUN      ] tls.recv_peek
[       OK ] tls.recv_peek
[ RUN      ] tls.recv_peek_multiple
[       OK ] tls.recv_peek_multiple
[ RUN      ] tls.recv_peek_large_buf_mult_recs
tls.c:524:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
tls.recv_peek_large_buf_mult_recs: Test failed at step #8
[     FAIL ] tls.recv_peek_large_buf_mult_recs
[ RUN      ] tls.pollin
[       OK ] tls.pollin
[ RUN      ] tls.poll_wait
[       OK ] tls.poll_wait
[ RUN      ] tls.blocking
[       OK ] tls.blocking
[ RUN      ] tls.nonblocking
[       OK ] tls.nonblocking
[ RUN      ] tls.control_msg
[       OK ] tls.control_msg
[==========] 27 / 28 tests passed.
[  FAILED  ]

Here's what the recvfrom() with MSG_PEEK sees:

[pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid  2602] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
[pid  2602] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid  2602] listen(4, 10)               = 0
[pid  2602] getsockname(4, {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
[pid  2602] connect(3, {sa_family=AF_INET, sin_port=htons(41483), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid  2602] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
[pid  2602] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
[pid  2602] accept(4, {sa_family=AF_INET, sin_port=htons(46290), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
[pid  2602] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
[pid  2602] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
[pid  2602] close(4)                    = 0
[pid  2602] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
[pid  2602] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
[pid  2602] recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
[pid  2602] write(2, "tls.c:526:tls.recv_peek_large_bu"..., 112tls.c:526:tls.recv_peek_large_buf_mult_recs:Expected memcmp(test_str, buf, len) (18446744073709551595) == 0 (0)
) = 112
[pid  2602] close(3)                    = 0
[pid  2602] close(5)                    = 0
[pid  2602] exit_group(8)               = ?

Reason for the "test_read_peektest_read_peektest[...]" is because MSG_PEEK
cannot call tls_sw_advance_skb(), since the skb is sitting there that needs
to be consumed for non-MSG_PEEK case, and only then we can advance it.

Could you elaborate on where you ever had this test succeeding? With nxp
accelerator?

Thanks,
Daniel

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

* RE: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  8:44 ` Daniel Borkmann
@ 2018-09-18  9:10   ` Vakul Garg
  2018-09-18  9:26     ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Vakul Garg @ 2018-09-18  9:10 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List



> -----Original Message-----
> From: Daniel Borkmann <daniel@iogearbox.net>
> Sent: Tuesday, September 18, 2018 2:14 PM
> To: Stephen Rothwell <sfr@canb.auug.org.au>; David Miller
> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Vakul Garg
> <vakul.garg@nxp.com>
> Subject: Re: linux-next: manual merge of the net-next tree with the net tree
> 
> On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> >   tools/testing/selftests/net/tls.c
> >
> > between commit:
> >
> >   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> >
> > from the net tree and commit:
> >
> >   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning
> > across multiple records")
> >
> > from the net-next 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.
> 
> The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
> recv_peek_large_buf_mult_recs could be removed; latter was also not
> working correctly due to this bug.

Why remove recv_peek_large_buf_mult_recs if its correct?
Why not the newly added one which achieves the same thing?

Regards, Vakul

> 
> Thanks,
> Daniel

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-09-18  0:11 Stephen Rothwell
@ 2018-09-18  8:44 ` Daniel Borkmann
  2018-09-18  9:10   ` Vakul Garg
  0 siblings, 1 reply; 325+ messages in thread
From: Daniel Borkmann @ 2018-09-18  8:44 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Vakul Garg

On 09/18/2018 02:11 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/net/tls.c
> 
> between commit:
> 
>   50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
> 
> from the net tree and commit:
> 
>   c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning across multiple records")
> 
> from the net-next 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.

The test from 50c6b58a814d supersedes the one from c2ad647c6442 so the
recv_peek_large_buf_mult_recs could be removed; latter was also not working
correctly due to this bug.

Thanks,
Daniel

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-09-18  0:11 Stephen Rothwell
  2018-09-18  8:44 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-09-18  0:11 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Vakul Garg

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

Hi all,

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

  tools/testing/selftests/net/tls.c

between commit:

  50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")

from the net tree and commit:

  c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning across multiple records")

from the net-next 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 tools/testing/selftests/net/tls.c
index 8fdfeafaf8c0,96fc6fe70293..000000000000
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@@ -502,55 -502,28 +502,77 @@@ TEST_F(tls, recv_peek_multiple
  	EXPECT_EQ(memcmp(test_str, buf, send_len), 0);
  }
  
 +TEST_F(tls, recv_peek_multiple_records)
 +{
 +	char const *test_str = "test_read_peek_mult_recs";
 +	char const *test_str_first = "test_read_peek";
 +	char const *test_str_second = "_mult_recs";
 +	int len;
 +	char buf[64];
 +
 +	len = strlen(test_str_first);
 +	EXPECT_EQ(send(self->fd, test_str_first, len, 0), len);
 +
 +	len = strlen(test_str_second) + 1;
 +	EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
 +
 +	len = sizeof(buf);
 +	memset(buf, 0, len);
 +	EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
 +
 +	/* MSG_PEEK can only peek into the current record. */
 +	len = strlen(test_str_first) + 1;
 +	EXPECT_EQ(memcmp(test_str_first, buf, len), 0);
 +
 +	len = sizeof(buf);
 +	memset(buf, 0, len);
 +	EXPECT_NE(recv(self->cfd, buf, len, 0), -1);
 +
 +	/* Non-MSG_PEEK will advance strparser (and therefore record)
 +	 * however.
 +	 */
 +	len = strlen(test_str) + 1;
 +	EXPECT_EQ(memcmp(test_str, buf, len), 0);
 +
 +	/* MSG_MORE will hold current record open, so later MSG_PEEK
 +	 * will see everything.
 +	 */
 +	len = strlen(test_str_first);
 +	EXPECT_EQ(send(self->fd, test_str_first, len, MSG_MORE), len);
 +
 +	len = strlen(test_str_second) + 1;
 +	EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
 +
 +	len = sizeof(buf);
 +	memset(buf, 0, len);
 +	EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
 +
 +	len = strlen(test_str) + 1;
 +	EXPECT_EQ(memcmp(test_str, buf, len), 0);
 +}
 +
+ TEST_F(tls, recv_peek_large_buf_mult_recs)
+ {
+ 	char const *test_str = "test_read_peek_mult_recs";
+ 	char const *test_str_first = "test_read_peek";
+ 	char const *test_str_second = "_mult_recs";
+ 	int len;
+ 	char buf[64];
+ 
+ 	len = strlen(test_str_first);
+ 	EXPECT_EQ(send(self->fd, test_str_first, len, 0), len);
+ 
+ 	len = strlen(test_str_second) + 1;
+ 	EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
+ 
+ 	len = sizeof(buf);
+ 	memset(buf, 0, len);
+ 	EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
+ 
+ 	len = strlen(test_str) + 1;
+ 	EXPECT_EQ(memcmp(test_str, buf, len), 0);
+ }
+ 
  TEST_F(tls, pollin)
  {
  	char const *test_str = "test_poll";

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-19  1:25 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-19  1:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Stefano Brivio, Boris Pismenny, Ilya Lesokhin

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

Hi all,

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

  include/linux/skbuff.h

between commit:

  8b7008620b84 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")

from the net tree and commits:

  784abe24c903 ("net: Add decrypted field to skb")
  a48d189ef531 ("net: Move skb decrypted field, avoid explicity copy")

from the net-next tree.

The conflict only occurs because a48d189ef531 didn't put the comment
back on the __unused field that was there before 784abe24c903.

I fixed it up (I used the former 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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-07-17  2:33 Stephen Rothwell
@ 2018-07-17  5:47 ` Stefano Brivio
  0 siblings, 0 replies; 325+ messages in thread
From: Stefano Brivio @ 2018-07-17  5:47 UTC (permalink / raw)
  To: Boris Pismenny
  Cc: Stephen Rothwell, David Miller, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Tue, 17 Jul 2018 12:33:06 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   include/linux/skbuff.h
> 
> between commit:
> 
>   8b7008620b84 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")
> 
> from the net tree and commit:
> 
>   784abe24c903 ("net: Add decrypted field to skb")
> 
> from the net-next tree.
>
> [...]
>
> @@@ -736,7 -737,11 +738,11 @@@ struct sk_buff 
>   				peeked:1,
>   				head_frag:1,
>   				xmit_more:1,
>  +				pfmemalloc:1;
> + #ifdef CONFIG_TLS_DEVICE
>  -				decrypted:1;
>  -#else
>  -				__unused:1;
> ++	__u8			decrypted:1,
> ++				__unused:7;
> + #endif
>   
>   	/* fields enclosed in headers_start/headers_end are copied
>   	 * using a single memcpy() in __copy_skb_header()

I checked the layout of sk_buff after this, we already had a 1-byte
hole there, that now becomes a 7-bits hole (or disappears with
__unused). That's fine.

Boris, I read your commit 784abe24c903 ("net: Add decrypted field to
skb") just now.

I think 'decrypted' shouldn't go there, because you then copy it on
copy and clone: if you move if after headers_start[0] you don't need to
explicitly copy it in __copy_skb_header().

While at it, the copy you added in __skb_clone() is redundant (no
matter the position of 'decrypted').

I can send a clean-up patch against net-next. I guess this might cause
again a linux-next merge conflict, but it's again trivial (the __unused
field above would go away).

-- 
Stefano

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-17  2:33 Stephen Rothwell
  2018-07-17  5:47 ` Stefano Brivio
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-17  2:33 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Stefano Brivio, Boris Pismenny

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

Hi all,

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

  include/linux/skbuff.h

between commit:

  8b7008620b84 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")

from the net tree and commit:

  784abe24c903 ("net: Add decrypted field to skb")

from the net-next tree.

I fixed it up (see below - maybe not the best resolution) 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/skbuff.h
index 610a201126ee,3ceb8dcc54da..000000000000
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@@ -630,7 -630,7 +630,8 @@@ typedef unsigned char *sk_buff_data_t
   *	@hash: the packet hash
   *	@queue_mapping: Queue mapping for multiqueue devices
   *	@xmit_more: More SKBs are pending for this queue
 + *	@pfmemalloc: skbuff was allocated from PFMEMALLOC reserves
+  *	@decrypted: Decrypted SKB
   *	@ndisc_nodetype: router type (from link layer)
   *	@ooo_okay: allow the mapping of a socket to a queue to be changed
   *	@l4_hash: indicate hash is a canonical 4-tuple hash over transport
@@@ -736,7 -737,11 +738,11 @@@ struct sk_buff 
  				peeked:1,
  				head_frag:1,
  				xmit_more:1,
 +				pfmemalloc:1;
+ #ifdef CONFIG_TLS_DEVICE
 -				decrypted:1;
 -#else
 -				__unused:1;
++	__u8			decrypted:1,
++				__unused:7;
+ #endif
  
  	/* fields enclosed in headers_start/headers_end are copied
  	 * using a single memcpy() in __copy_skb_header()

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-13  0:47 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-13  0:47 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Stefan Baranoff, Arnd Bergmann, Eric Dumazet

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

Hi all,

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

  net/ipv4/tcp_ipv4.c

between commit:

  21684dc46c59 ("tcp: fix sequence numbers for repaired sockets re-using TIME-WAIT sockets")

from the net tree and commit:

  cca9bab1b72c ("tcp: use monotonic timestamps for PAWS")

from the net-next 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 net/ipv4/tcp_ipv4.c
index 3b2711e33e4c,dc415c66a33a..000000000000
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@@ -155,25 -155,13 +155,26 @@@ int tcp_twsk_unique(struct sock *sk, st
  	   and use initial timestamp retrieved from peer table.
  	 */
  	if (tcptw->tw_ts_recent_stamp &&
- 	    (!twp || (reuse && get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
+ 	    (!twp || (reuse && time_after32(ktime_get_seconds(),
+ 					    tcptw->tw_ts_recent_stamp)))) {
 -		tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2;
 -		if (tp->write_seq == 0)
 -			tp->write_seq = 1;
 -		tp->rx_opt.ts_recent	   = tcptw->tw_ts_recent;
 -		tp->rx_opt.ts_recent_stamp = tcptw->tw_ts_recent_stamp;
 +		/* In case of repair and re-using TIME-WAIT sockets we still
 +		 * want to be sure that it is safe as above but honor the
 +		 * sequence numbers and time stamps set as part of the repair
 +		 * process.
 +		 *
 +		 * Without this check re-using a TIME-WAIT socket with TCP
 +		 * repair would accumulate a -1 on the repair assigned
 +		 * sequence number. The first time it is reused the sequence
 +		 * is -1, the second time -2, etc. This fixes that issue
 +		 * without appearing to create any others.
 +		 */
 +		if (likely(!tp->repair)) {
 +			tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2;
 +			if (tp->write_seq == 0)
 +				tp->write_seq = 1;
 +			tp->rx_opt.ts_recent	   = tcptw->tw_ts_recent;
 +			tp->rx_opt.ts_recent_stamp = tcptw->tw_ts_recent_stamp;
 +		}
  		sock_hold(sktw);
  		return 1;
  	}

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-09  1:03 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-09  1:03 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Davide Caratti, Vlad Buslov, Jiri Pirko

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

Hi all,

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

  net/sched/act_tunnel_key.c

between commit:

  38230a3e0e09 ("net/sched: act_tunnel_key: fix NULL dereference when 'goto chain' is used")

from the net tree and commit:

  036bb44327f5 ("net: sched: change type of reference and bind counters")

from the net-next 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 net/sched/act_tunnel_key.c
index 9bc6c2ae98a5,3ec585d58762..000000000000
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@@ -252,9 -477,8 +477,9 @@@ static int tunnel_key_dump(struct sk_bu
  	struct tcf_tunnel_key_params *params;
  	struct tc_tunnel_key opt = {
  		.index    = t->tcf_index,
- 		.refcnt   = t->tcf_refcnt - ref,
- 		.bindcnt  = t->tcf_bindcnt - bind,
+ 		.refcnt   = refcount_read(&t->tcf_refcnt) - ref,
+ 		.bindcnt  = atomic_read(&t->tcf_bindcnt) - bind,
 +		.action   = t->tcf_action,
  	};
  	struct tcf_t tm;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-09  0:46 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-09  0:46 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Davide Caratti, Vlad Buslov, Jiri Pirko

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

Hi all,

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

  net/sched/act_csum.c

between commit:

  11a245e2f7bf ("net/sched: act_csum: fix NULL dereference when 'goto chain' is used")

from the net tree and commit:

  036bb44327f5 ("net: sched: change type of reference and bind counters")

from the net-next 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 net/sched/act_csum.c
index 6e7124e57918,bd232d3bd022..000000000000
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@@ -597,9 -603,8 +603,9 @@@ static int tcf_csum_dump(struct sk_buf
  	struct tcf_csum_params *params;
  	struct tc_csum opt = {
  		.index   = p->tcf_index,
- 		.refcnt  = p->tcf_refcnt - ref,
- 		.bindcnt = p->tcf_bindcnt - bind,
+ 		.refcnt  = refcount_read(&p->tcf_refcnt) - ref,
+ 		.bindcnt = atomic_read(&p->tcf_bindcnt) - bind,
 +		.action  = p->tcf_action,
  	};
  	struct tcf_t t;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-09  0:28 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-09  0:28 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anton Mikaev,
	Igor Russkikh

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

Hi all,

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

  drivers/net/ethernet/aquantia/atlantic/aq_hw.h

between commit:

  94b3b542303f ("net: aquantia: vlan unicast address list correct handling")

from the net tree and commit:

  c1af5427954b ("net: aquantia: Ethtool based ring size configuration")

from the net-next 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/aquantia/atlantic/aq_hw.h
index 2c6ebd91a9f2,1a51152029c3..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
@@@ -98,8 -100,9 +100,11 @@@ struct aq_stats_s 
  #define AQ_HW_MEDIA_TYPE_TP    1U
  #define AQ_HW_MEDIA_TYPE_FIBRE 2U
  
 +#define AQ_HW_MULTICAST_ADDRESS_MAX     32U
 +
+ #define AQ_HW_TXD_MULTIPLE 8U
+ #define AQ_HW_RXD_MULTIPLE 8U
+ 
  struct aq_hw_s {
  	atomic_t flags;
  	u8 rbl_enabled:1;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-07-02  0:15 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-07-02  0:15 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jose Abreu

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

Hi all,

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

  drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
  drivers/net/ethernet/stmicro/stmmac/hwif.h

between commit:

  4205c88eaf17 ("net: stmmac: Set DMA buffer size in HW")

from the net tree and commit:

  1f705bc61aee ("net: stmmac: Add support for CBS QDISC")

from the net-next 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/stmicro/stmmac/dwmac4_dma.c
index 65bc3556bd8f,6e32f8a3710b..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@@ -407,16 -407,19 +407,29 @@@ static void dwmac4_enable_tso(void __io
  	}
  }
  
 +static void dwmac4_set_bfsize(void __iomem *ioaddr, int bfsize, u32 chan)
 +{
 +	u32 value = readl(ioaddr + DMA_CHAN_RX_CONTROL(chan));
 +
 +	value &= ~DMA_RBSZ_MASK;
 +	value |= (bfsize << DMA_RBSZ_SHIFT) & DMA_RBSZ_MASK;
 +
 +	writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
 +}
 +
+ static void dwmac4_qmode(void __iomem *ioaddr, u32 channel, u8 qmode)
+ {
+ 	u32 mtl_tx_op = readl(ioaddr + MTL_CHAN_TX_OP_MODE(channel));
+ 
+ 	mtl_tx_op &= ~MTL_OP_MODE_TXQEN_MASK;
+ 	if (qmode != MTL_QUEUE_AVB)
+ 		mtl_tx_op |= MTL_OP_MODE_TXQEN;
+ 	else
+ 		mtl_tx_op |= MTL_OP_MODE_TXQEN_AV;
+ 
+ 	writel(mtl_tx_op, ioaddr +  MTL_CHAN_TX_OP_MODE(channel));
+ }
+ 
  const struct stmmac_dma_ops dwmac4_dma_ops = {
  	.reset = dwmac4_dma_reset,
  	.init = dwmac4_dma_init,
@@@ -441,7 -444,7 +454,8 @@@
  	.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
  	.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
  	.enable_tso = dwmac4_enable_tso,
 +	.set_bfsize = dwmac4_set_bfsize,
+ 	.qmode = dwmac4_qmode,
  };
  
  const struct stmmac_dma_ops dwmac410_dma_ops = {
@@@ -468,5 -471,5 +482,6 @@@
  	.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
  	.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
  	.enable_tso = dwmac4_enable_tso,
 +	.set_bfsize = dwmac4_set_bfsize,
+ 	.qmode = dwmac4_qmode,
  };
diff --cc drivers/net/ethernet/stmicro/stmmac/hwif.h
index fe8b536b13f8,e2a965790648..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@@ -183,7 -183,7 +183,8 @@@ struct stmmac_dma_ops 
  	void (*set_rx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
  	void (*set_tx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
  	void (*enable_tso)(void __iomem *ioaddr, bool en, u32 chan);
 +	void (*set_bfsize)(void __iomem *ioaddr, int bfsize, u32 chan);
+ 	void (*qmode)(void __iomem *ioaddr, u32 channel, u8 qmode);
  };
  
  #define stmmac_reset(__priv, __args...) \
@@@ -236,8 -236,8 +237,10 @@@
  	stmmac_do_void_callback(__priv, dma, set_tx_tail_ptr, __args)
  #define stmmac_enable_tso(__priv, __args...) \
  	stmmac_do_void_callback(__priv, dma, enable_tso, __args)
 +#define stmmac_set_dma_bfsize(__priv, __args...) \
 +	stmmac_do_void_callback(__priv, dma, set_bfsize, __args)
+ #define stmmac_dma_qmode(__priv, __args...) \
+ 	stmmac_do_void_callback(__priv, dma, qmode, __args)
  
  struct mac_device_info;
  struct net_device;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-24 14:35 Mark Brown
  0 siblings, 0 replies; 325+ messages in thread
From: Mark Brown @ 2018-05-24 14:35 UTC (permalink / raw)
  To: David Miller, Networking, Roopa Prabhu
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  net/ipv4/fib_frontend.c

between commit:

  2eabd764cb5512f1338 ("net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy")

from the net tree and commit:

  404eb77ea766260c45c ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE")

from the net-next 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.

diff --cc net/ipv4/fib_frontend.c
index e66172aaf241,897ae92dff0f..000000000000
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@@ -649,7 -649,9 +649,10 @@@ const struct nla_policy rtm_ipv4_policy
  	[RTA_ENCAP]		= { .type = NLA_NESTED },
  	[RTA_UID]		= { .type = NLA_U32 },
  	[RTA_MARK]		= { .type = NLA_U32 },
 +	[RTA_TABLE]		= { .type = NLA_U32 },
+ 	[RTA_IP_PROTO]		= { .type = NLA_U8 },
+ 	[RTA_SPORT]		= { .type = NLA_U16 },
+ 	[RTA_DPORT]		= { .type = NLA_U16 },
  };
  
  static int rtm_to_fib_config(struct net *net, struct sk_buff *skb,

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-10  2:13 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-10  2:13 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Heiner Kallweit

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

Hi all,

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

  drivers/net/ethernet/realtek/r8169.c

between commit:

  3148dedfe79e ("r8169: fix powering up RTL8168h")

from the net tree and commit:

  4f447d296982 ("r8169: drop member pll_power_ops from struct rtl8169_private")

from the net-next 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/realtek/r8169.c
index c7aac1fc99e8,6d99b141a7aa..000000000000
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@@ -4980,72 -4767,13 +4767,16 @@@ static void rtl_pll_power_down(struct r
  
  static void rtl_pll_power_up(struct rtl8169_private *tp)
  {
- 	rtl_generic_op(tp, tp->pll_power_ops.up);
- 
- 	/* give MAC/PHY some time to resume */
- 	msleep(20);
- }
- 
- static void rtl_init_pll_power_ops(struct rtl8169_private *tp)
- {
- 	struct pll_power_ops *ops = &tp->pll_power_ops;
- 
  	switch (tp->mac_version) {
- 	case RTL_GIGA_MAC_VER_07:
- 	case RTL_GIGA_MAC_VER_08:
- 	case RTL_GIGA_MAC_VER_09:
- 	case RTL_GIGA_MAC_VER_10:
- 	case RTL_GIGA_MAC_VER_16:
- 	case RTL_GIGA_MAC_VER_29:
- 	case RTL_GIGA_MAC_VER_30:
- 	case RTL_GIGA_MAC_VER_37:
- 	case RTL_GIGA_MAC_VER_39:
- 	case RTL_GIGA_MAC_VER_43:
- 	case RTL_GIGA_MAC_VER_47:
- 	case RTL_GIGA_MAC_VER_48:
- 		ops->down	= r810x_pll_power_down;
- 		ops->up		= r810x_pll_power_up;
- 		break;
- 
- 	case RTL_GIGA_MAC_VER_11:
- 	case RTL_GIGA_MAC_VER_12:
- 	case RTL_GIGA_MAC_VER_17:
- 	case RTL_GIGA_MAC_VER_18:
- 	case RTL_GIGA_MAC_VER_19:
- 	case RTL_GIGA_MAC_VER_20:
- 	case RTL_GIGA_MAC_VER_21:
- 	case RTL_GIGA_MAC_VER_22:
- 	case RTL_GIGA_MAC_VER_23:
- 	case RTL_GIGA_MAC_VER_24:
- 	case RTL_GIGA_MAC_VER_25:
- 	case RTL_GIGA_MAC_VER_26:
- 	case RTL_GIGA_MAC_VER_27:
- 	case RTL_GIGA_MAC_VER_28:
- 	case RTL_GIGA_MAC_VER_31:
- 	case RTL_GIGA_MAC_VER_32:
- 	case RTL_GIGA_MAC_VER_33:
- 	case RTL_GIGA_MAC_VER_34:
- 	case RTL_GIGA_MAC_VER_35:
- 	case RTL_GIGA_MAC_VER_36:
- 	case RTL_GIGA_MAC_VER_38:
- 	case RTL_GIGA_MAC_VER_40:
- 	case RTL_GIGA_MAC_VER_41:
- 	case RTL_GIGA_MAC_VER_42:
- 	case RTL_GIGA_MAC_VER_44:
- 	case RTL_GIGA_MAC_VER_45:
- 	case RTL_GIGA_MAC_VER_46:
- 	case RTL_GIGA_MAC_VER_49:
- 	case RTL_GIGA_MAC_VER_50:
- 	case RTL_GIGA_MAC_VER_51:
- 		ops->down	= r8168_pll_power_down;
- 		ops->up		= r8168_pll_power_up;
+ 	case RTL_GIGA_MAC_VER_01 ... RTL_GIGA_MAC_VER_06:
+ 	case RTL_GIGA_MAC_VER_13 ... RTL_GIGA_MAC_VER_15:
  		break;
- 
  	default:
- 		ops->down	= NULL;
- 		ops->up		= NULL;
- 		break;
+ 		r8168_pll_power_up(tp);
  	}
++
++	/* give MAC/PHY some time to resume */
++	msleep(20);
  }
  
  static void rtl_init_rxcfg(struct rtl8169_private *tp)

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-05-09  8:24 ` Anders Roxell
@ 2018-05-09 10:44   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-09 10:44 UTC (permalink / raw)
  To: Anders Roxell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List

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

Hi Anders,

On Wed, 9 May 2018 10:24:49 +0200 Anders Roxell <anders.roxell@linaro.org> wrote:
>
> On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >   TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> > - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> > + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh  
> 
> in_netns.sh shouldn't be in the above list, its already in the
> TEST_PROGS_EXTENDED below.

Thanks for that, I have fixed up my merge resolution for tomorrow.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-05-09  4:19 Stephen Rothwell
@ 2018-05-09  8:24 ` Anders Roxell
  2018-05-09 10:44   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Anders Roxell @ 2018-05-09  8:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List

On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   tools/testing/selftests/net/Makefile
>
> between commit:
>
>   1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")
>
> from the net tree and commits:
>
>   a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next 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 tools/testing/selftests/net/Makefile
> index 3ff81a478dbe,73af45773938..000000000000
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@@ -5,10 -5,13 +5,13 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2
>   CFLAGS += -I../../../../usr/include/
>
>   TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh

in_netns.sh shouldn't be in the above list, its already in the
TEST_PROGS_EXTENDED below.

Cheers,
Anders

> + TEST_PROGS += udpgso_bench.sh
>  -TEST_GEN_PROGS_EXTENDED := in_netns.sh
>  +TEST_PROGS_EXTENDED := in_netns.sh
>   TEST_GEN_FILES =  socket
>   TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
> + TEST_GEN_FILES += tcp_mmap tcp_inq
> + TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
>   TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
>   TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
>

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-09  4:19 Stephen Rothwell
  2018-05-09  8:24 ` Anders Roxell
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-09  4:19 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anders Roxell

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

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")

from the net tree and commits:

  a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next 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 tools/testing/selftests/net/Makefile
index 3ff81a478dbe,73af45773938..000000000000
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,10 -5,13 +5,13 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
+ TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 -TEST_GEN_PROGS_EXTENDED := in_netns.sh
 +TEST_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap tcp_inq
+ TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-09  4:12 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-09  4:12 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Eric Dumazet,
	Boris Pismenny

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

Hi all,

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

  net/tls/tls_main.c

between commit:

  98f0a39529e5 ("tls: fix use after free in tls_sk_proto_close")

from the net tree and commit:

  f66de3ee2c16 ("net/tls: Split conf to rx + tx")

from the net-next 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 net/tls/tls_main.c
index 20cd93be6236,4b57ddd72f34..000000000000
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@@ -254,8 -252,12 +254,9 @@@ static void tls_sk_proto_close(struct s
  	lock_sock(sk);
  	sk_proto_close = ctx->sk_proto_close;
  
- 	if (ctx->conf == TLS_BASE || ctx->conf == TLS_HW_RECORD) {
 -	if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
 -		goto skip_tx_cleanup;
 -
 -	if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) {
 -		kfree(ctx);
 -		ctx = NULL;
++	if ((ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) ||
++	    (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)) {
 +		free_ctx = true;
  		goto skip_tx_cleanup;
  	}
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-06 23:52 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-06 23:52 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Rutland,
	Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau

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

Hi all,

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

  kernel/bpf/syscall.c

between commit:

  9ef09e35e521 ("bpf: fix possible spectre-v1 in find_and_alloc_map()")

from the net tree and commit:

  a26ca7c982cb ("bpf: btf: Add pretty print support to the basic arraymap")

from the net-next tree.

I fixed it up (I removed the conflicting addition of an include of
linux/btf.h in the latter commit as it had already been included
earlier in the file by a previous commit) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-05-02  1:52 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-05-02  1:52 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Thomas Winter, David Ahern

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

Hi all,

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

  include/net/ip6_route.h

between commit:

  edd7ceb78296 ("ipv6: Allow non-gateway ECMP for IPv6")

from the net tree and commit:

  93c2fb253d17 ("net/ipv6: Rename fib6_info struct elements")

from the net-next 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/net/ip6_route.h
index abceb5864d99,8df4ff798b04..000000000000
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@@ -66,9 -66,10 +66,9 @@@ static inline bool rt6_need_strict(cons
  		(IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
  }
  
- static inline bool rt6_qualify_for_ecmp(const struct rt6_info *rt)
+ static inline bool rt6_qualify_for_ecmp(const struct fib6_info *f6i)
  {
- 	return (rt->rt6i_flags & (RTF_ADDRCONF | RTF_DYNAMIC)) == 0;
 -	return (f6i->fib6_flags & (RTF_GATEWAY|RTF_ADDRCONF|RTF_DYNAMIC)) ==
 -	       RTF_GATEWAY;
++	return (f6i->fib6_flags & (RTF_ADDRCONF | RTF_DYNAMIC)) == 0;
  }
  
  void ip6_route_input(struct sk_buff *skb);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-04-30  0:10 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-04-30  0:10 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Anders Roxell, Willem de Bruijn

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

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  9faedd643fd9 ("selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED")

from the net tree and commit:

  a160725780e3 ("selftests: udp gso")

from the net-next 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 tools/testing/selftests/net/Makefile
index daf5effec3f0,df9102ec7b7a..000000000000
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,12 -5,14 +5,15 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
 -TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
++TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 +TEST_GEN_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
+ TEST_GEN_PROGS += udpgso udpgso_bench_tx udpgso_bench_rx
  
  include ../lib.mk
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-03-15  1:55 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-03-15  1:55 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Sabrina Dubroca, David Ahern

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

Hi all,

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

  net/ipv4/xfrm4_policy.c

between commit:

  d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu")

from the net tree and commit:

  68e813aa4307 ("net/ipv4: Remove fib table id from rtable")

from the net-next 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 net/ipv4/xfrm4_policy.c
index fbebda67ac1b,0c752dc3f93b..000000000000
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@@ -100,10 -100,7 +100,9 @@@ static int xfrm4_fill_dst(struct xfrm_d
  	xdst->u.rt.rt_gateway = rt->rt_gateway;
  	xdst->u.rt.rt_uses_gateway = rt->rt_uses_gateway;
  	xdst->u.rt.rt_pmtu = rt->rt_pmtu;
 +	xdst->u.rt.rt_mtu_locked = rt->rt_mtu_locked;
- 	xdst->u.rt.rt_table_id = rt->rt_table_id;
  	INIT_LIST_HEAD(&xdst->u.rt.rt_uncached);
 +	rt_add_uncached_list(&xdst->u.rt);
  
  	return 0;
  }

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-03-13  0:29 Stephen Rothwell
@ 2018-03-13 10:41 ` Petr Machata
  0 siblings, 0 replies; 325+ messages in thread
From: Petr Machata @ 2018-03-13 10:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Jiri Pirko, Ido Schimmel

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Today's linux-next merge of the net-next tree got conflicts in:
>
>   drivers/net/ethernet/mellanox/mlxsw/spectrum.h
>   drivers/net/ethernet/mellanox/mlxsw/spectrum.c
>
> between commit:
>
>   663f1b26f9c1 ("mlxsw: spectrum: Prevent duplicate mirrors")
>
> from the net tree and commit:
>
>   a629ef210d89 ("mlxsw: spectrum: Move SPAN code to separate module")
>
> from the net-next tree.
>
> I fixed it up

Looks good.

Thanks,
Petr

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-03-13  0:29 Stephen Rothwell
  2018-03-13 10:41 ` Petr Machata
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-03-13  0:29 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Petr Machata,
	Jiri Pirko, Ido Schimmel

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlxsw/spectrum.h
  drivers/net/ethernet/mellanox/mlxsw/spectrum.c

between commit:

  663f1b26f9c1 ("mlxsw: spectrum: Prevent duplicate mirrors")

from the net tree and commit:

  a629ef210d89 ("mlxsw: spectrum: Move SPAN code to separate module")

from the net-next tree.

I fixed it up (the code changed in the former was moved in the latter -
I applied the below merge fix patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Mar 2018 11:25:13 +1100
Subject: [PATCH] mlxsw: merge fix for move of SPAN code

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 .../net/ethernet/mellanox/mlxsw/spectrum_span.c    | 28 ++++++++++++++++++----
 .../net/ethernet/mellanox/mlxsw/spectrum_span.h    |  3 +++
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index ae22a3daffbf..4d6ed207b4af 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -600,13 +600,17 @@ int mlxsw_sp_span_port_mtu_update(struct mlxsw_sp_port *port, u16 mtu)
 }
 
 static struct mlxsw_sp_span_inspected_port *
-mlxsw_sp_span_entry_bound_port_find(struct mlxsw_sp_port *port,
-				    struct mlxsw_sp_span_entry *span_entry)
+mlxsw_sp_span_entry_bound_port_find(struct mlxsw_sp_span_entry *span_entry,
+				    enum mlxsw_sp_span_type type,
+				    struct mlxsw_sp_port *port,
+				    bool bind)
 {
 	struct mlxsw_sp_span_inspected_port *p;
 
 	list_for_each_entry(p, &span_entry->bound_ports_list, list)
-		if (port->local_port == p->local_port)
+		if (type == p->type &&
+		    port->local_port == p->local_port &&
+		    bind == p->bound)
 			return p;
 	return NULL;
 }
@@ -636,8 +640,22 @@ mlxsw_sp_span_inspected_port_add(struct mlxsw_sp_port *port,
 	struct mlxsw_sp_span_inspected_port *inspected_port;
 	struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
 	char sbib_pl[MLXSW_REG_SBIB_LEN];
+	int i;
 	int err;
 
+	/* A given (source port, direction) can only be bound to one analyzer,
+	 * so if a binding is requested, check for conflicts.
+	 */
+	if (bind)
+		for (i = 0; i < mlxsw_sp->span.entries_count; i++) {
+			struct mlxsw_sp_span_entry *curr =
+				&mlxsw_sp->span.entries[i];
+
+			if (mlxsw_sp_span_entry_bound_port_find(curr, type,
+								port, bind))
+				return -EEXIST;
+		}
+
 	/* if it is an egress SPAN, bind a shared buffer to it */
 	if (type == MLXSW_SP_SPAN_EGRESS) {
 		u32 buffsize = mlxsw_sp_span_mtu_to_buffsize(mlxsw_sp,
@@ -665,6 +683,7 @@ mlxsw_sp_span_inspected_port_add(struct mlxsw_sp_port *port,
 	}
 	inspected_port->local_port = port->local_port;
 	inspected_port->type = type;
+	inspected_port->bound = bind;
 	list_add_tail(&inspected_port->list, &span_entry->bound_ports_list);
 
 	return 0;
@@ -691,7 +710,8 @@ mlxsw_sp_span_inspected_port_del(struct mlxsw_sp_port *port,
 	struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
 	char sbib_pl[MLXSW_REG_SBIB_LEN];
 
-	inspected_port = mlxsw_sp_span_entry_bound_port_find(port, span_entry);
+	inspected_port = mlxsw_sp_span_entry_bound_port_find(span_entry, type,
+							     port, bind);
 	if (!inspected_port)
 		return;
 
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
index 948aceb512c5..4b87ec20e658 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
@@ -51,6 +51,9 @@ struct mlxsw_sp_span_inspected_port {
 	struct list_head list;
 	enum mlxsw_sp_span_type type;
 	u8 local_port;
+
+	/* Whether this is a directly bound mirror (port-to-port) or an ACL. */
+	bool bound;
 };
 
 struct mlxsw_sp_span_parms {
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-03-13  0:04 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-03-13  0:04 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Brad Mouring,
	Heiner Kallweit

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

Hi all,

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

  drivers/net/phy/phy.c

between commit:

  a2c054a896b8 ("net: phy: Tell caller result of phy_change()")

from the net tree and commit:

  4fff2d33c707 ("net: phy: remove phy_error from phy_disable_interrupts")

from the net-next 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/phy/phy.c
index 9aabfa1a455a,c2d9027be863..000000000000
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@@ -617,77 -617,6 +617,68 @@@ static void phy_error(struct phy_devic
  	phy_trigger_machine(phydev, false);
  }
  
 +/**
 + * phy_disable_interrupts - Disable the PHY interrupts from the PHY side
 + * @phydev: target phy_device struct
 + */
 +static int phy_disable_interrupts(struct phy_device *phydev)
 +{
 +	int err;
 +
 +	/* Disable PHY interrupts */
 +	err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
 +	if (err)
- 		goto phy_err;
++		return err;
 +
 +	/* Clear the interrupt */
- 	err = phy_clear_interrupt(phydev);
- 	if (err)
- 		goto phy_err;
- 
- 	return 0;
- 
- phy_err:
- 	phy_error(phydev);
- 
- 	return err;
++	return phy_clear_interrupt(phydev);
 +}
 +
 +/**
 + * phy_change - Called by the phy_interrupt to handle PHY changes
 + * @phydev: phy_device struct that interrupted
 + */
 +static irqreturn_t phy_change(struct phy_device *phydev)
 +{
 +	if (phy_interrupt_is_valid(phydev)) {
 +		if (phydev->drv->did_interrupt &&
 +		    !phydev->drv->did_interrupt(phydev))
 +			return IRQ_NONE;
 +
 +		if (phydev->state == PHY_HALTED)
 +			if (phy_disable_interrupts(phydev))
 +				goto phy_err;
 +	}
 +
 +	mutex_lock(&phydev->lock);
 +	if ((PHY_RUNNING == phydev->state) || (PHY_NOLINK == phydev->state))
 +		phydev->state = PHY_CHANGELINK;
 +	mutex_unlock(&phydev->lock);
 +
 +	/* reschedule state queue work to run as soon as possible */
 +	phy_trigger_machine(phydev, true);
 +
 +	if (phy_interrupt_is_valid(phydev) && phy_clear_interrupt(phydev))
 +		goto phy_err;
 +	return IRQ_HANDLED;
 +
 +phy_err:
 +	phy_error(phydev);
 +	return IRQ_NONE;
 +}
 +
 +/**
 + * phy_change_work - Scheduled by the phy_mac_interrupt to handle PHY changes
 + * @work: work_struct that describes the work to be done
 + */
 +void phy_change_work(struct work_struct *work)
 +{
 +	struct phy_device *phydev =
 +		container_of(work, struct phy_device, phy_queue);
 +
 +	phy_change(phydev);
 +}
 +
  /**
   * phy_interrupt - PHY interrupt handler
   * @irq: interrupt line

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-03-04 23:00 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-03-04 23:00 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Florian Westphal, Pablo Neira Ayuso, David Ahern

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

Hi all,

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

  net/ipv6/netfilter/nft_fib_ipv6.c

between commit:

  47b7e7f82802 ("netfilter: don't set F_IFACE on ipv6 fib lookups")

from the net tree and commit:

  b75cc8f90f07 ("net/ipv6: Pass skb to route lookup")

from the net-next 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 net/ipv6/netfilter/nft_fib_ipv6.c
index 62fc84d7bdff,3230b3d7b11b..000000000000
--- a/net/ipv6/netfilter/nft_fib_ipv6.c
+++ b/net/ipv6/netfilter/nft_fib_ipv6.c
@@@ -180,7 -180,9 +180,8 @@@ void nft_fib6_eval(const struct nft_exp
  	}
  
  	*dest = 0;
- 	rt = (void *)ip6_route_lookup(nft_net(pkt), &fl6, lookup_flags);
 - again:
+ 	rt = (void *)ip6_route_lookup(nft_net(pkt), &fl6, pkt->skb,
+ 				      lookup_flags);
  	if (rt->dst.error)
  		goto put_rt_err;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-03-01 23:09 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-03-01 23:09 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Karsten Graul, Ursula Braun

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

Hi all,

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

  net/smc/smc_core.c

between commit:

  2be922f31606 ("net/smc: use link_id of server in confirm link reply")

from the net tree and commit:

  52bedf37bafe ("net/smc: process add/delete link messages")

from the net-next 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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-02-28 22:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-02-28 22:51 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jiri Pirko,
	Arkadi Sharshevsky

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlxsw/spectrum.c

between commit:

  77d270967c5f ("mlxsw: spectrum: Fix handling of resource_size_param")

from the net tree and commit:

  4f4bbf7c4e3d ("devlink: Perform cleanup of resource_set cb")

from the net-next 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/mlxsw/spectrum.c
index c7e941aecc2a,7c6204f701ae..000000000000
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@@ -4204,21 -3816,13 +3822,12 @@@ static struct devlink_resource_ops mlxs
  	.occ_get = mlxsw_sp_resource_kvd_linear_occ_get,
  };
  
- static struct devlink_resource_ops mlxsw_sp_resource_kvd_hash_single_ops = {
- 	.size_validate = mlxsw_sp_resource_kvd_hash_single_size_validate,
- };
- 
- static struct devlink_resource_ops mlxsw_sp_resource_kvd_hash_double_ops = {
- 	.size_validate = mlxsw_sp_resource_kvd_hash_double_size_validate,
- };
 -static struct devlink_resource_size_params mlxsw_sp_kvd_size_params;
 -static struct devlink_resource_size_params mlxsw_sp_linear_size_params;
 -static struct devlink_resource_size_params mlxsw_sp_hash_single_size_params;
 -static struct devlink_resource_size_params mlxsw_sp_hash_double_size_params;
--
  static void
 -mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core)
 +mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core,
 +				      struct devlink_resource_size_params *kvd_size_params,
 +				      struct devlink_resource_size_params *linear_size_params,
 +				      struct devlink_resource_size_params *hash_double_size_params,
 +				      struct devlink_resource_size_params *hash_single_size_params)
  {
  	u32 single_size_min = MLXSW_CORE_RES_GET(mlxsw_core,
  						 KVD_SINGLE_MIN_SIZE);
@@@ -4274,8 -3876,8 +3883,8 @@@ static int mlxsw_sp_resources_register(
  					true, kvd_size,
  					MLXSW_SP_RESOURCE_KVD,
  					DEVLINK_RESOURCE_ID_PARENT_TOP,
 -					&mlxsw_sp_kvd_size_params,
 +					&kvd_size_params,
- 					&mlxsw_sp_resource_kvd_ops);
+ 					NULL);
  	if (err)
  		return err;
  
@@@ -4298,8 -3904,8 +3911,8 @@@
  					false, double_size,
  					MLXSW_SP_RESOURCE_KVD_HASH_DOUBLE,
  					MLXSW_SP_RESOURCE_KVD,
 -					&mlxsw_sp_hash_double_size_params,
 +					&hash_double_size_params,
- 					&mlxsw_sp_resource_kvd_hash_double_ops);
+ 					NULL);
  	if (err)
  		return err;
  
@@@ -4308,8 -3914,8 +3921,8 @@@
  					false, single_size,
  					MLXSW_SP_RESOURCE_KVD_HASH_SINGLE,
  					MLXSW_SP_RESOURCE_KVD,
 -					&mlxsw_sp_hash_single_size_params,
 +					&hash_single_size_params,
- 					&mlxsw_sp_resource_kvd_hash_single_ops);
+ 					NULL);
  	if (err)
  		return err;
  

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-02-27 22:56 Stephen Rothwell
@ 2018-02-28  9:46 ` Petr Machata
  0 siblings, 0 replies; 325+ messages in thread
From: Petr Machata @ 2018-02-28  9:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Thomas Winter, Jiri Pirko,
	Ido Schimmel

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/ipv4/ip_tunnel.c
>
> between commit:
>
>   4e994776e7bd ("ip_tunnel: Do not use mark in skb by default")
>
> from the net tree and commit:
>
>   b0066da52ea5 ("ip_tunnel: Rename & publish init_tunnel_flow")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary.

Looks good, thanks!

Petr

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-02-27 22:56 Stephen Rothwell
  2018-02-28  9:46 ` Petr Machata
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-02-27 22:56 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Thomas Winter, Petr Machata, Jiri Pirko, Ido Schimmel

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

Hi all,

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

  net/ipv4/ip_tunnel.c

between commit:

  4e994776e7bd ("ip_tunnel: Do not use mark in skb by default")

from the net tree and commit:

  b0066da52ea5 ("ip_tunnel: Rename & publish init_tunnel_flow")

from the net-next 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 net/ipv4/ip_tunnel.c
index 6d21068f9b55,b2117d89bc83..000000000000
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@@ -710,9 -694,16 +694,9 @@@ void ip_tunnel_xmit(struct sk_buff *skb
  		}
  	}
  
- 	init_tunnel_flow(&fl4, protocol, dst, tnl_params->saddr,
- 			 tunnel->parms.o_key, RT_TOS(tos), tunnel->parms.link,
- 			 tunnel->fwmark);
 -	if (tunnel->fwmark) {
 -		ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
 -				    tunnel->parms.o_key, RT_TOS(tos),
 -				    tunnel->parms.link, tunnel->fwmark);
 -	}
 -	else {
 -		ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
 -				    tunnel->parms.o_key, RT_TOS(tos),
 -				    tunnel->parms.link, skb->mark);
 -	}
++	ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
++			    tunnel->parms.o_key, RT_TOS(tos),
++			    tunnel->parms.link, tunnel->fwmark);
  
  	if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0)
  		goto tx_error;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-19  1:00 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-19  1:00 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Alexei Starovoitov

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  6f16101e6a8b ("bpf: mark dst unknown on inconsistent {s, u}bounds adjustments")

from the net tree and commit:

  f4d7e40a5b71 ("bpf: introduce function calls (verification)")

from the net-next tree.

I fixed it up (I just used the former 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-18  1:09 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-18  1:09 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Cong Wang,
	Jason Wang, Jesper Dangaard Brouer, Alexei Starovoitov

Hi all,

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

  drivers/net/tun.c

between commit:

  4df0bfc79904 ("tun: fix a memory leak for tfile->tx_array")

from the net tree and commits:

  8bf5c4ee1889 ("tun: setup xdp_rxq_info")
  5990a30510ed ("tun/tap: use ptr_ring instead of skb_array")
  fc72d1d54dd9 ("tuntap: XDP transmission")

from the net-next tree.

I have no idea how to clean this up, so I effectively reverted the net
tree commit.

I fixed it up (see above) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-17  1:09 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-17  1:09 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Alexander Aring

Hi all,

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

  net/sched/sch_ingress.c
  net/sched/sch_api.c
  include/net/sch_generic.h

between commit:

  81d947e2b8dd ("net, sched: fix panic when updating miniq {b,q}stats")

from the net tree and commits:

  54160ef6ec64 ("net: sched: sch_api: rearrange init handling")
  8d1a77f974ca ("net: sch: api: add extack support in tcf_block_get")
  d0bd684dddab ("net: sch: api: add extack support in qdisc_alloc")

from the net-next 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 include/net/sch_generic.h
index becf86aa4ac6,ac029d5d88e4..000000000000
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@@ -444,10 -471,11 +471,12 @@@ void qdisc_destroy(struct Qdisc *qdisc)
  void qdisc_tree_reduce_backlog(struct Qdisc *qdisc, unsigned int n,
  			       unsigned int len);
  struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
- 			  const struct Qdisc_ops *ops);
+ 			  const struct Qdisc_ops *ops,
+ 			  struct netlink_ext_ack *extack);
 +void qdisc_free(struct Qdisc *qdisc);
  struct Qdisc *qdisc_create_dflt(struct netdev_queue *dev_queue,
- 				const struct Qdisc_ops *ops, u32 parentid);
+ 				const struct Qdisc_ops *ops, u32 parentid,
+ 				struct netlink_ext_ack *extack);
  void __qdisc_calculate_pkt_len(struct sk_buff *skb,
  			       const struct qdisc_size_table *stab);
  int skb_do_redirect(struct sk_buff *);
diff --cc net/sched/sch_api.c
index 52529b7f8d96,0038a1c44ee9..000000000000
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@@ -1062,43 -1088,64 +1088,53 @@@ static struct Qdisc *qdisc_create(struc
  		netdev_info(dev, "Caught tx_queue_len zero misconfig\n");
  	}
  
- 	if (!ops->init || (err = ops->init(sch, tca[TCA_OPTIONS])) == 0) {
- 		if (tca[TCA_STAB]) {
- 			stab = qdisc_get_stab(tca[TCA_STAB]);
- 			if (IS_ERR(stab)) {
- 				err = PTR_ERR(stab);
- 				goto err_out4;
- 			}
- 			rcu_assign_pointer(sch->stab, stab);
- 		}
- 		if (tca[TCA_RATE]) {
- 			seqcount_t *running;
- 
- 			err = -EOPNOTSUPP;
- 			if (sch->flags & TCQ_F_MQROOT)
- 				goto err_out4;
- 
- 			if ((sch->parent != TC_H_ROOT) &&
- 			    !(sch->flags & TCQ_F_INGRESS) &&
- 			    (!p || !(p->flags & TCQ_F_MQROOT)))
- 				running = qdisc_root_sleeping_running(sch);
- 			else
- 				running = &sch->running;
- 
- 			err = gen_new_estimator(&sch->bstats,
- 						sch->cpu_bstats,
- 						&sch->rate_est,
- 						NULL,
- 						running,
- 						tca[TCA_RATE]);
- 			if (err)
- 				goto err_out4;
+ 	if (ops->init) {
+ 		err = ops->init(sch, tca[TCA_OPTIONS], extack);
+ 		if (err != 0)
+ 			goto err_out5;
+ 	}
+ 
 -	if (qdisc_is_percpu_stats(sch)) {
 -		sch->cpu_bstats =
 -			netdev_alloc_pcpu_stats(struct gnet_stats_basic_cpu);
 -		if (!sch->cpu_bstats)
 -			goto err_out4;
 -
 -		sch->cpu_qstats = alloc_percpu(struct gnet_stats_queue);
 -		if (!sch->cpu_qstats)
 -			goto err_out4;
 -	}
 -
+ 	if (tca[TCA_STAB]) {
+ 		stab = qdisc_get_stab(tca[TCA_STAB], extack);
+ 		if (IS_ERR(stab)) {
+ 			err = PTR_ERR(stab);
+ 			goto err_out4;
  		}
+ 		rcu_assign_pointer(sch->stab, stab);
+ 	}
+ 	if (tca[TCA_RATE]) {
+ 		seqcount_t *running;
  
- 		qdisc_hash_add(sch, false);
+ 		err = -EOPNOTSUPP;
+ 		if (sch->flags & TCQ_F_MQROOT) {
+ 			NL_SET_ERR_MSG(extack, "Cannot attach rate estimator to a multi-queue root qdisc");
+ 			goto err_out4;
+ 		}
  
- 		return sch;
+ 		if (sch->parent != TC_H_ROOT &&
+ 		    !(sch->flags & TCQ_F_INGRESS) &&
+ 		    (!p || !(p->flags & TCQ_F_MQROOT)))
+ 			running = qdisc_root_sleeping_running(sch);
+ 		else
+ 			running = &sch->running;
+ 
+ 		err = gen_new_estimator(&sch->bstats,
+ 					sch->cpu_bstats,
+ 					&sch->rate_est,
+ 					NULL,
+ 					running,
+ 					tca[TCA_RATE]);
+ 		if (err) {
+ 			NL_SET_ERR_MSG(extack, "Failed to generate new estimator");
+ 			goto err_out4;
+ 		}
  	}
+ 
+ 	qdisc_hash_add(sch, false);
+ 
+ 	return sch;
+ 
+ err_out5:
  	/* ops->init() failed, we call ->destroy() like qdisc_create_dflt() */
  	if (ops->destroy)
  		ops->destroy(sch);
diff --cc net/sched/sch_ingress.c
index 003e1b063447,7ca2be20dd6f..000000000000
--- a/net/sched/sch_ingress.c
+++ b/net/sched/sch_ingress.c
@@@ -75,7 -78,13 +77,7 @@@ static int ingress_init(struct Qdisc *s
  	q->block_info.chain_head_change = clsact_chain_head_change;
  	q->block_info.chain_head_change_priv = &q->miniqp;
  
- 	return tcf_block_get_ext(&q->block, sch, &q->block_info);
 -	err = tcf_block_get_ext(&q->block, sch, &q->block_info, extack);
 -	if (err)
 -		return err;
 -
 -	sch->flags |= TCQ_F_CPUSTATS;
 -
 -	return 0;
++	return tcf_block_get_ext(&q->block, sch, &q->block_info, extack);
  }
  
  static void ingress_destroy(struct Qdisc *sch)
@@@ -186,7 -197,14 +191,8 @@@ static int clsact_init(struct Qdisc *sc
  	q->egress_block_info.chain_head_change = clsact_chain_head_change;
  	q->egress_block_info.chain_head_change_priv = &q->miniqp_egress;
  
- 	return tcf_block_get_ext(&q->egress_block, sch, &q->egress_block_info);
 -	err = tcf_block_get_ext(&q->egress_block, sch, &q->egress_block_info,
++	return tcf_block_get_ext(&q->egress_block, sch, &q->egress_block_info,
+ 				extack);
 -	if (err)
 -		return err;
 -
 -	sch->flags |= TCQ_F_CPUSTATS;
 -
 -	return 0;
  }
  
  static void clsact_destroy(struct Qdisc *sch)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-15 23:36 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-15 23:36 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mike Maloney

Hi all,

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

  net/ipv6/ip6_output.c

between commit:

  749439bfac6e ("ipv6: fix udpv6 sendmsg crash caused by too small MTU")

from the net tree and commit:

  0f6c480f23f4 ("xfrm: Move dst->path into struct xfrm_dst")

from the net-next 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 net/ipv6/ip6_output.c
index 4f7d8de56611,18547a44bdaf..000000000000
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@@ -1206,18 -1215,16 +1215,18 @@@ static int ip6_setup_cork(struct sock *
  	v6_cork->tclass = ipc6->tclass;
  	if (rt->dst.flags & DST_XFRM_TUNNEL)
  		mtu = np->pmtudisc >= IPV6_PMTUDISC_PROBE ?
 -		      rt->dst.dev->mtu : dst_mtu(&rt->dst);
 +		      READ_ONCE(rt->dst.dev->mtu) : dst_mtu(&rt->dst);
  	else
  		mtu = np->pmtudisc >= IPV6_PMTUDISC_PROBE ?
- 		      READ_ONCE(rt->dst.dev->mtu) : dst_mtu(rt->dst.path);
 -		      rt->dst.dev->mtu : dst_mtu(xfrm_dst_path(&rt->dst));
++		      READ_ONCE(rt->dst.dev->mtu) : dst_mtu(xfrm_dst_path(&rt->dst));
  	if (np->frag_size < mtu) {
  		if (np->frag_size)
  			mtu = np->frag_size;
  	}
 +	if (mtu < IPV6_MIN_MTU)
 +		return -EINVAL;
  	cork->base.fragsize = mtu;
- 	if (dst_allfrag(rt->dst.path))
+ 	if (dst_allfrag(xfrm_dst_path(&rt->dst)))
  		cork->base.flags |= IPCORK_ALLFRAG;
  	cork->base.length = 0;
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-15 23:31 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-15 23:31 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, William Tu

Hi all,

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

  net/openvswitch/flow_netlink.c

between commit:

  95a332088ecb ("Revert "openvswitch: Add erspan tunnel support."")

from the net tree and commit:

  1d7e2ed22f8d ("net: erspan: refactor existing erspan code")

from the net-next tree.

I fixed it up (I removed the bits of code rmeoved by the former that
were updated in 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] 325+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-01-14 23:52 Stephen Rothwell
@ 2018-01-15  7:53 ` Eran Ben Elisha
  0 siblings, 0 replies; 325+ messages in thread
From: Eran Ben Elisha @ 2018-01-15  7:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Eran Ben Elisha, Saeed Mahameed,
	Or Gerlitz

On Mon, Jan 15, 2018 at 1:52 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   include/linux/mlx5/mlx5_ifc.h
>
> between commit:
>
>   8978cc921fc7 ("{net,ib}/mlx5: Don't disable local loopback multicast traffic when needed")
>
> from the net tree and commit:
>
>   40817cdbb695 ("net/mlx5: Add hairpin definitions to the FW API")
>
> from the net-next 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.

sure, https://patchwork.ozlabs.org/patch/859425/

>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc include/linux/mlx5/mlx5_ifc.h
> index 1391a82da98e,78e36fc2609e..000000000000
> --- a/include/linux/mlx5/mlx5_ifc.h
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@@ -1027,9 -1035,10 +1035,10 @@@ struct mlx5_ifc_cmd_hca_cap_bits
>         u8         log_max_wq_sz[0x5];
>
>         u8         nic_vport_change_event[0x1];
>  -      u8         disable_local_lb[0x1];
>  -      u8         reserved_at_3e2[0x1];
>  +      u8         disable_local_lb_uc[0x1];
>  +      u8         disable_local_lb_mc[0x1];
> -       u8         reserved_at_3e3[0x8];
> +       u8         log_min_hairpin_wq_data_sz[0x5];
> +       u8         reserved_at_3e8[0x3];

Conflict fix looks good as proposed.

thanks for the fix,
Eran.

>         u8         log_max_vlan_list[0x5];
>         u8         reserved_at_3f0[0x3];
>         u8         log_max_current_mc_list[0x5];

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-01-14 23:52 Stephen Rothwell
  2018-01-15  7:53 ` Eran Ben Elisha
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2018-01-14 23:52 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Eran Ben Elisha, Saeed Mahameed, Or Gerlitz

Hi all,

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

  include/linux/mlx5/mlx5_ifc.h

between commit:

  8978cc921fc7 ("{net,ib}/mlx5: Don't disable local loopback multicast traffic when needed")

from the net tree and commit:

  40817cdbb695 ("net/mlx5: Add hairpin definitions to the FW API")

from the net-next 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/mlx5_ifc.h
index 1391a82da98e,78e36fc2609e..000000000000
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@@ -1027,9 -1035,10 +1035,10 @@@ struct mlx5_ifc_cmd_hca_cap_bits 
  	u8         log_max_wq_sz[0x5];
  
  	u8         nic_vport_change_event[0x1];
 -	u8         disable_local_lb[0x1];
 -	u8         reserved_at_3e2[0x1];
 +	u8         disable_local_lb_uc[0x1];
 +	u8         disable_local_lb_mc[0x1];
- 	u8         reserved_at_3e3[0x8];
+ 	u8         log_min_hairpin_wq_data_sz[0x5];
+ 	u8         reserved_at_3e8[0x3];
  	u8         log_max_vlan_list[0x5];
  	u8         reserved_at_3f0[0x3];
  	u8         log_max_current_mc_list[0x5];

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-12-22  0:11 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-12-22  0:11 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jann Horn,
	Daniel Borkmann, Alexei Starovoitov

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  0c17d1d2c619 ("bpf: fix incorrect tracking of register size truncation")

from the net tree and commits:

  f4d7e40a5b71 ("bpf: introduce function calls (verification)")
  1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")

from the net-next 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 kernel/bpf/verifier.c
index 04b24876cd23,48b2901cf483..000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -1072,29 -1425,54 +1430,77 @@@ static int check_ptr_alignment(struct b
  					   strict);
  }
  
 +/* truncate register to smaller size (in bytes)
 + * must be called with size < BPF_REG_SIZE
 + */
 +static void coerce_reg_to_size(struct bpf_reg_state *reg, int size)
 +{
 +	u64 mask;
 +
 +	/* clear high bits in bit representation */
 +	reg->var_off = tnum_cast(reg->var_off, size);
 +
 +	/* fix arithmetic bounds */
 +	mask = ((u64)1 << (size * 8)) - 1;
 +	if ((reg->umin_value & ~mask) == (reg->umax_value & ~mask)) {
 +		reg->umin_value &= mask;
 +		reg->umax_value &= mask;
 +	} else {
 +		reg->umin_value = 0;
 +		reg->umax_value = mask;
 +	}
 +	reg->smin_value = reg->umin_value;
 +	reg->smax_value = reg->umax_value;
 +}
 +
+ static int update_stack_depth(struct bpf_verifier_env *env,
+ 			      const struct bpf_func_state *func,
+ 			      int off)
+ {
+ 	u16 stack = env->subprog_stack_depth[func->subprogno], total = 0;
+ 	struct bpf_verifier_state *cur = env->cur_state;
+ 	int i;
+ 
+ 	if (stack >= -off)
+ 		return 0;
+ 
+ 	/* update known max for given subprogram */
+ 	env->subprog_stack_depth[func->subprogno] = -off;
+ 
+ 	/* compute the total for current call chain */
+ 	for (i = 0; i <= cur->curframe; i++) {
+ 		u32 depth = env->subprog_stack_depth[cur->frame[i]->subprogno];
+ 
+ 		/* round up to 32-bytes, since this is granularity
+ 		 * of interpreter stack sizes
+ 		 */
+ 		depth = round_up(depth, 32);
+ 		total += depth;
+ 	}
+ 
+ 	if (total > MAX_BPF_STACK) {
+ 		verbose(env, "combined stack size of %d calls is %d. Too large\n",
+ 			cur->curframe, total);
+ 		return -EACCES;
+ 	}
+ 	return 0;
+ }
+ 
+ static int get_callee_stack_depth(struct bpf_verifier_env *env,
+ 				  const struct bpf_insn *insn, int idx)
+ {
+ 	int start = idx + insn->imm + 1, subprog;
+ 
+ 	subprog = find_subprog(env, start);
+ 	if (subprog < 0) {
+ 		WARN_ONCE(1, "verifier bug. No program starts at insn %d\n",
+ 			  start);
+ 		return -EFAULT;
+ 	}
+ 	subprog++;
+ 	return env->subprog_stack_depth[subprog];
+ }
+ 
  /* check whether memory at (regno + off) is accessible for t = (read | write)
   * if t==write, value_regno is a register which value is stored into memory
   * if t==read, value_regno is a register which will receive the value from memory
@@@ -1302,15 -1678,14 +1704,15 @@@ static int check_stack_boundary(struct 
  	}
  
  	/* Only allow fixed-offset stack reads */
- 	if (!tnum_is_const(regs[regno].var_off)) {
+ 	if (!tnum_is_const(reg->var_off)) {
  		char tn_buf[48];
  
- 		tnum_strn(tn_buf, sizeof(tn_buf), regs[regno].var_off);
+ 		tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
  		verbose(env, "invalid variable stack read R%d var_off=%s\n",
  			regno, tn_buf);
 +		return -EACCES;
  	}
- 	off = regs[regno].off + regs[regno].var_off.value;
+ 	off = reg->off + reg->var_off.value;
  	if (off >= 0 || off < -MAX_BPF_STACK || off + access_size > 0 ||
  	    access_size < 0 || (access_size == 0 && !zero_size_allowed)) {
  		verbose(env, "invalid stack type R%d off=%d access_size=%d\n",
@@@ -2294,9 -2758,12 +2828,11 @@@ static int adjust_scalar_min_max_vals(s
  static int adjust_reg_min_max_vals(struct bpf_verifier_env *env,
  				   struct bpf_insn *insn)
  {
- 	struct bpf_reg_state *regs = cur_regs(env), *dst_reg, *src_reg;
+ 	struct bpf_verifier_state *vstate = env->cur_state;
+ 	struct bpf_func_state *state = vstate->frame[vstate->curframe];
+ 	struct bpf_reg_state *regs = state->regs, *dst_reg, *src_reg;
  	struct bpf_reg_state *ptr_reg = NULL, off_reg = {0};
  	u8 opcode = BPF_OP(insn->code);
 -	int rc;
  
  	dst_reg = &regs[insn->dst_reg];
  	src_reg = NULL;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-12-20 22:59 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-12-20 22:59 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jakub Kicinski

Hi all,

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

  drivers/net/ethernet/netronome/nfp/bpf/main.c

between commit:

  d3f89b98e391 ("nfp: bpf: keep track of the offloaded program")

from the net tree and commit:

  bd0b2e7fe611 ("net: xdp: make the stack take care of the tear down")

from the net-next tree.

I fixed it up (the latter seems to be a fix for the same problem as the
former, so I just reverted the former by hand) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-12-19  0:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-12-19  0:51 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Zhao Qiang,
	Heiner Kallweit

Hi all,

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

  drivers/net/phy/marvell.c

between commit:

  c505873eaece ("net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.")

from the net tree and commit:

  80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg and read_status from drivers")

from the net-next 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/phy/marvell.c
index 82104edca393,2fc026dc170a..000000000000
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@@ -2085,8 -2070,7 +2082,7 @@@ static struct phy_driver marvell_driver
  		.flags = PHY_HAS_INTERRUPT,
  		.probe = marvell_probe,
  		.config_init = &m88e1145_config_init,
 -		.config_aneg = &marvell_config_aneg,
 +		.config_aneg = &m88e1101_config_aneg,
- 		.read_status = &genphy_read_status,
  		.ack_interrupt = &marvell_ack_interrupt,
  		.config_intr = &marvell_config_intr,
  		.resume = &genphy_resume,

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-12-12  1:07 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-12-12  1:07 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jerome Brunet, Heiner Kallweit

Hi all,

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

  drivers/net/phy/meson-gxl.c

between commit:

  f1e2400a80ff ("net: phy: meson-gxl: detect LPA corruption")

from the net tree and commit:

  80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg and read_status from drivers")

from the net-next tree.

I fixed it up (I just used 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

diff --cc drivers/net/phy/meson-gxl.c
index 700007dd4be5,401e3234be58..000000000000
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@@ -130,9 -58,7 +130,8 @@@ static struct phy_driver meson_gxl_phy[
  		.features	= PHY_BASIC_FEATURES,
  		.flags		= PHY_IS_INTERNAL,
  		.config_init	= meson_gxl_config_init,
- 		.config_aneg	= genphy_config_aneg,
  		.aneg_done      = genphy_aneg_done,
 +		.read_status	= meson_gxl_read_status,
  		.suspend        = genphy_suspend,
  		.resume         = genphy_resume,
  	},

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-11-01  0:58 Stephen Rothwell
@ 2017-11-01  4:17 ` Cong Wang
  0 siblings, 0 replies; 325+ messages in thread
From: Cong Wang @ 2017-11-01  4:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Jiri Pirko

On Tue, Oct 31, 2017 at 5:58 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/sched/cls_api.c
>
> between commit:
>
>   822e86d997e4 ("net_sched: remove tcf_block_put_deferred()")
>
> from the net tree and commit:
>
>   8c4083b30e56 ("net: sched: add block bind/unbind notif. and extended block_get/put")
>
> from the net-next tree.

Seems good.

Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-11-01  0:58 Stephen Rothwell
  2017-11-01  4:17 ` Cong Wang
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-11-01  0:58 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Cong Wang,
	Jiri Pirko

Hi all,

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

  net/sched/cls_api.c

between commit:

  822e86d997e4 ("net_sched: remove tcf_block_put_deferred()")

from the net tree and commit:

  8c4083b30e56 ("net: sched: add block bind/unbind notif. and extended block_get/put")

from the net-next 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 net/sched/cls_api.c
index b2d310745487,d9d54b367d23..000000000000
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@@ -289,22 -331,47 +331,26 @@@ static void tcf_block_put_final(struct 
  }
  
  /* XXX: Standalone actions are not allowed to jump to any chain, and bound
 - * actions should be all removed after flushing. However, filters are destroyed
 - * in RCU callbacks, we have to hold the chains first, otherwise we would
 - * always race with RCU callbacks on this list without proper locking.
 + * actions should be all removed after flushing. However, filters are now
 + * destroyed in tc filter workqueue with RTNL lock, they can not race here.
   */
- void tcf_block_put(struct tcf_block *block)
 -static void tcf_block_put_deferred(struct work_struct *work)
 -{
 -	struct tcf_block *block = container_of(work, struct tcf_block, work);
 -	struct tcf_chain *chain;
 -
 -	rtnl_lock();
 -	/* Hold a refcnt for all chains, except 0, in case they are gone. */
 -	list_for_each_entry(chain, &block->chain_list, list)
 -		if (chain->index)
 -			tcf_chain_hold(chain);
 -
 -	/* No race on the list, because no chain could be destroyed. */
 -	list_for_each_entry(chain, &block->chain_list, list)
 -		tcf_chain_flush(chain);
 -
 -	INIT_WORK(&block->work, tcf_block_put_final);
 -	/* Wait for RCU callbacks to release the reference count and make
 -	 * sure their works have been queued before this.
 -	 */
 -	rcu_barrier();
 -	tcf_queue_work(&block->work);
 -	rtnl_unlock();
 -}
 -
+ void tcf_block_put_ext(struct tcf_block *block,
+ 		       struct tcf_proto __rcu **p_filter_chain, struct Qdisc *q,
+ 		       struct tcf_block_ext_info *ei)
  {
 +	struct tcf_chain *chain, *tmp;
 +
  	if (!block)
  		return;
  
+ 	tcf_block_offload_unbind(block, q, ei);
+ 
 -	INIT_WORK(&block->work, tcf_block_put_deferred);
 -	/* Wait for existing RCU callbacks to cool down, make sure their works
 -	 * have been queued before this. We can not flush pending works here
 -	 * because we are holding the RTNL lock.
 +	list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
 +		tcf_chain_flush(chain);
 +
 +	INIT_WORK(&block->work, tcf_block_put_final);
 +	/* Wait for RCU callbacks to release the reference count and make
 +	 * sure their works have been queued before this.
  	 */
  	rcu_barrier();
  	tcf_queue_work(&block->work);

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-10-19 13:05 Mark Brown
@ 2017-10-19 13:08 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2017-10-19 13:08 UTC (permalink / raw)
  To: Mark Brown, David Miller, Networking, Alexei Starovoitov,
	John Fastabend, Jakub Kicinski, Edward Cree
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

On 10/19/2017 03:05 PM, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    tools/testing/selftests/bpf/test_verifier.c
>
> between commit:
>
>    28e33f9d78eef ("bpf: disallow arithmetic operations on context pointer")
>
> from the net tree and commit:
>
>    22c8852624fc9 ("bpf: improve selftests and add tests for meta pointer")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This

LGTM, thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-10-19 13:05 Mark Brown
  2017-10-19 13:08 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Mark Brown @ 2017-10-19 13:05 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov,
	John Fastabend, Jakub Kicinski, Edward Cree
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  tools/testing/selftests/bpf/test_verifier.c

between commit:

  28e33f9d78eef ("bpf: disallow arithmetic operations on context pointer")

from the net tree and commit:

  22c8852624fc9 ("bpf: improve selftests and add tests for meta pointer")

from the net-next 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.

diff --cc tools/testing/selftests/bpf/test_verifier.c
index 3c7d3a45a3c5,cc91d0159f43..000000000000
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@@ -6645,20 -6645,325 +6645,339 @@@ static struct bpf_test tests[] = 
  		.errstr = "BPF_END uses reserved fields",
  		.result = REJECT,
  	},
 +	{
 +		"arithmetic ops make PTR_TO_CTX unusable",
 +		.insns = {
 +			BPF_ALU64_IMM(BPF_ADD, BPF_REG_1,
 +				      offsetof(struct __sk_buff, data) -
 +				      offsetof(struct __sk_buff, mark)),
 +			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
 +				    offsetof(struct __sk_buff, mark)),
 +			BPF_EXIT_INSN(),
 +		},
 +		.errstr = "dereference of modified ctx ptr R1 off=68+8, ctx+const is allowed, ctx+const+const is not",
 +		.result = REJECT,
 +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
 +	},
+ 	{
+ 		"meta access, test1",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test2",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_SUB, BPF_REG_0, 8),
+ 			BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_0, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet, off=-8",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test3",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_end)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test4",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_end)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_4),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test5",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_3),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_4, 3),
+ 			BPF_MOV64_IMM(BPF_REG_2, -8),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_xdp_adjust_meta),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_3, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "R3 !read_ok",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test6",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_3),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_0, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test7",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_3),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+ 			BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test8",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 0xFFFF),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test9",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 0xFFFF),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 1),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test10",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_end)),
+ 			BPF_MOV64_IMM(BPF_REG_5, 42),
+ 			BPF_MOV64_IMM(BPF_REG_6, 24),
+ 			BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_5, -8),
+ 			BPF_STX_XADD(BPF_DW, BPF_REG_10, BPF_REG_6, -8),
+ 			BPF_LDX_MEM(BPF_DW, BPF_REG_5, BPF_REG_10, -8),
+ 			BPF_JMP_IMM(BPF_JGT, BPF_REG_5, 100, 6),
+ 			BPF_ALU64_REG(BPF_ADD, BPF_REG_3, BPF_REG_5),
+ 			BPF_MOV64_REG(BPF_REG_5, BPF_REG_3),
+ 			BPF_MOV64_REG(BPF_REG_6, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_6, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_6, BPF_REG_5, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_2, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = REJECT,
+ 		.errstr = "invalid access to packet",
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test11",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_MOV64_IMM(BPF_REG_5, 42),
+ 			BPF_MOV64_IMM(BPF_REG_6, 24),
+ 			BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_5, -8),
+ 			BPF_STX_XADD(BPF_DW, BPF_REG_10, BPF_REG_6, -8),
+ 			BPF_LDX_MEM(BPF_DW, BPF_REG_5, BPF_REG_10, -8),
+ 			BPF_JMP_IMM(BPF_JGT, BPF_REG_5, 100, 6),
+ 			BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_5),
+ 			BPF_MOV64_REG(BPF_REG_5, BPF_REG_2),
+ 			BPF_MOV64_REG(BPF_REG_6, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_6, 8),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_6, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_5, BPF_REG_5, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"meta access, test12",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_meta)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data)),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1,
+ 				    offsetof(struct xdp_md, data_end)),
+ 			BPF_MOV64_REG(BPF_REG_5, BPF_REG_3),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_5, 16),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_5, BPF_REG_4, 5),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_3, 0),
+ 			BPF_MOV64_REG(BPF_REG_5, BPF_REG_2),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_5, 16),
+ 			BPF_JMP_REG(BPF_JGT, BPF_REG_5, BPF_REG_3, 1),
+ 			BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+ 			BPF_MOV64_IMM(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_XDP,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test1",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "R0 has value (0x0; 0xffffffff)",
+ 		.result = REJECT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test2",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1, 0),
+ 			BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test3",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1, 0),
+ 			BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 3),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "R0 has value (0x0; 0x3)",
+ 		.result = REJECT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test4",
+ 		.insns = {
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test5",
+ 		.insns = {
+ 			BPF_MOV64_IMM(BPF_REG_0, 2),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "R0 has value (0x2; 0x0)",
+ 		.result = REJECT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test6",
+ 		.insns = {
+ 			BPF_MOV64_REG(BPF_REG_0, BPF_REG_1),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "R0 is not a known value (ctx)",
+ 		.result = REJECT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
+ 	{
+ 		"bpf_exit with invalid return code. test7",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1, 0),
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1, 4),
+ 			BPF_ALU64_REG(BPF_MUL, BPF_REG_0, BPF_REG_2),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "R0 has unknown scalar value",
+ 		.result = REJECT,
+ 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+ 	},
  };
  
  static int probe_filter_length(const struct bpf_insn *fp)

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-10-17 11:30 ` Sergei Shtylyov
@ 2017-10-17 13:01   ` Mark Brown
  0 siblings, 0 replies; 325+ messages in thread
From: Mark Brown @ 2017-10-17 13:01 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: David Miller, Networking, Vivien Didelot,
	Linux-Next Mailing List, Linux Kernel Mailing List

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

On Tue, Oct 17, 2017 at 02:30:29PM +0300, Sergei Shtylyov wrote:

> > diff --cc drivers/net/dsa/mv88e6060.c
> > index f123ed57630d,6173be889d95..000000000000
> > --- a/drivers/net/dsa/mv88e6060.c
> > +++ b/drivers/net/dsa/mv88e6060.c

>    Your mail ends here.

Yes, that's the resulting diff.

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-10-16  9:36 Mark Brown
@ 2017-10-17 11:30 ` Sergei Shtylyov
  2017-10-17 13:01   ` Mark Brown
  0 siblings, 1 reply; 325+ messages in thread
From: Sergei Shtylyov @ 2017-10-17 11:30 UTC (permalink / raw)
  To: Mark Brown, David Miller, Networking, Vivien Didelot
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hello!

On 10/16/2017 12:36 PM, Mark Brown wrote:

> Today's linux-next merge of the net-next tree got a conflict in:
> 
>    drivers/net/dsa/mv88e6060.c
> 
> between commit:
> 
>    3efc93c2bc243 ("net: dsa: mv88e6060: fix switch MAC address")
> 
> from the net tree and commit:
> 
>    56c3ff9bf23e1 ("net: dsa: mv88e6060: setup random mac address")
> 
> from the net-next tree.
> 
> I fixed it up (see below, the relevant code was deleted in net-next) 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/net/dsa/mv88e6060.c
> index f123ed57630d,6173be889d95..000000000000
> --- a/drivers/net/dsa/mv88e6060.c
> +++ b/drivers/net/dsa/mv88e6060.c

    Your mail ends here.

MBR, Sergei

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-10-16  9:36 Mark Brown
  2017-10-17 11:30 ` Sergei Shtylyov
  0 siblings, 1 reply; 325+ messages in thread
From: Mark Brown @ 2017-10-16  9:36 UTC (permalink / raw)
  To: David Miller, Networking, Vivien Didelot
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  drivers/net/dsa/mv88e6060.c

between commit:

  3efc93c2bc243 ("net: dsa: mv88e6060: fix switch MAC address")

from the net tree and commit:

  56c3ff9bf23e1 ("net: dsa: mv88e6060: setup random mac address")

from the net-next tree.

I fixed it up (see below, the relevant code was deleted in net-next) 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/net/dsa/mv88e6060.c
index f123ed57630d,6173be889d95..000000000000
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-08-29  2:25 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-08-29  2:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Antoine Tenart, Thomas Petazzoni

Hi all,

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

  drivers/net/ethernet/marvell/mvpp2.c

between commit:

  4c2286826451 ("net: mvpp2: fix the mac address used when using PPv2.2")

from the net tree and commits:

  09f8397553a2 ("net: mvpp2: introduce per-port nrxqs/ntxqs variables")
  213f428f5056 ("net: mvpp2: add support for TX interrupts and RX queue distribution modes")

from the net-next 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/marvell/mvpp2.c
index 4d598ca8503a,fea9ae5b70ba..000000000000
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@@ -6504,7 -7248,9 +7248,9 @@@ static int mvpp2_port_probe(struct plat
  	struct resource *res;
  	const char *dt_mac_addr;
  	const char *mac_from;
 -	char hw_mac_addr[ETH_ALEN];
 +	char hw_mac_addr[ETH_ALEN] = {0};
+ 	unsigned int ntxqs, nrxqs;
+ 	bool has_tx_irqs;
  	u32 id;
  	int features;
  	int phy_mode;

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-08-23  1:31 Stephen Rothwell
@ 2017-08-23  5:41 ` Ido Schimmel
  0 siblings, 0 replies; 325+ messages in thread
From: Ido Schimmel @ 2017-08-23  5:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Wei Wang, Ido Schimmel, iri Pirko

On Wed, Aug 23, 2017 at 11:31:05AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv6/ip6_fib.c
> 
> between commit:
> 
>   c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")
> 
> from the net tree and commit:
> 
>   a460aa83963b ("ipv6: fib: Add helpers to hold / drop a reference on rt6_info")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good to me.

Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-08-23  1:31 Stephen Rothwell
  2017-08-23  5:41 ` Ido Schimmel
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-08-23  1:31 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Wei Wang,
	Ido Schimmel, iri Pirko

Hi all,

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

  net/ipv6/ip6_fib.c

between commit:

  c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")

from the net tree and commit:

  a460aa83963b ("ipv6: fib: Add helpers to hold / drop a reference on rt6_info")

from the net-next 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 net/ipv6/ip6_fib.c
index a5ebf86f6be8,549aacc3cb2c..000000000000
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@@ -160,12 -154,7 +161,12 @@@ static void node_free_rcu(struct rcu_he
  	kmem_cache_free(fib6_node_kmem, fn);
  }
  
 +static void node_free(struct fib6_node *fn)
 +{
 +	call_rcu(&fn->rcu, node_free_rcu);
 +}
 +
- static void rt6_free_pcpu(struct rt6_info *non_pcpu_rt)
+ void rt6_free_pcpu(struct rt6_info *non_pcpu_rt)
  {
  	int cpu;
  

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-08-07  2:21 ` Neal Cardwell
@ 2017-08-07  4:59   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-08-07  4:59 UTC (permalink / raw)
  To: Neal Cardwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Yuchung Cheng

Hi Neal,

On Sun, 6 Aug 2017 22:21:43 -0400 Neal Cardwell <ncardwell@google.com> wrote:
>
> > 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 about that. Will try to follow that procedure in the future.

The above is a generic statement I add to all these emails.  It is
aimed more at the maintainers if the trees involved, no the developers
of patches.  I don't think you need to do anything different in these
cases with the "net" and "net-next" tree.  Dave Miller will fix up any
conflicts when he next merges the net tree into the net-next tree.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-08-07  2:01 Stephen Rothwell
@ 2017-08-07  2:21 ` Neal Cardwell
  2017-08-07  4:59   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Neal Cardwell @ 2017-08-07  2:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Yuchung Cheng

On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/ipv4/tcp_output.c
>
> between commit:
>
>   a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO should fire")
>
> from the net tree and commit:
>
>   bb4d991a28cc ("tcp: adjust tail loss probe timeout")
>
> from the net-next 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 about that. Will try to follow that procedure in the future.

thanks,
neal

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-08-07  2:01 Stephen Rothwell
  2017-08-07  2:21 ` Neal Cardwell
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-08-07  2:01 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Neal Cardwell, Yuchung Cheng

Hi all,

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

  net/ipv4/tcp_output.c

between commit:

  a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO should fire")

from the net tree and commit:

  bb4d991a28cc ("tcp: adjust tail loss probe timeout")

from the net-next 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 net/ipv4/tcp_output.c
index 276406a83a37,d49bff51bdb7..000000000000
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@@ -2377,9 -2375,13 +2375,8 @@@ bool tcp_schedule_loss_probe(struct soc
  {
  	struct inet_connection_sock *icsk = inet_csk(sk);
  	struct tcp_sock *tp = tcp_sk(sk);
- 	u32 rtt = usecs_to_jiffies(tp->srtt_us >> 3);
 -	u32 timeout, tlp_time_stamp, rto_time_stamp;
 +	u32 timeout, rto_delta_us;
  
 -	/* No consecutive loss probes. */
 -	if (WARN_ON(icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)) {
 -		tcp_rearm_rto(sk);
 -		return false;
 -	}
  	/* Don't do any loss probe on a Fast Open connection before 3WHS
  	 * finishes.
  	 */
@@@ -2402,16 -2408,24 +2399,20 @@@
  	 * for delayed ack when there's one outstanding packet. If no RTT
  	 * sample is available then probe after TCP_TIMEOUT_INIT.
  	 */
- 	timeout = rtt << 1 ? : TCP_TIMEOUT_INIT;
- 	if (tp->packets_out == 1)
- 		timeout = max_t(u32, timeout,
- 				(rtt + (rtt >> 1) + TCP_DELACK_MAX));
- 	timeout = max_t(u32, timeout, msecs_to_jiffies(10));
+ 	if (tp->srtt_us) {
+ 		timeout = usecs_to_jiffies(tp->srtt_us >> 2);
+ 		if (tp->packets_out == 1)
+ 			timeout += TCP_RTO_MIN;
+ 		else
+ 			timeout += TCP_TIMEOUT_MIN;
+ 	} else {
+ 		timeout = TCP_TIMEOUT_INIT;
+ 	}
  
 -	/* If RTO is shorter, just schedule TLP in its place. */
 -	tlp_time_stamp = tcp_jiffies32 + timeout;
 -	rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
 -	if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
 -		s32 delta = rto_time_stamp - tcp_jiffies32;
 -		if (delta > 0)
 -			timeout = delta;
 -	}
 +	/* If the RTO formula yields an earlier time, then use that time. */
 +	rto_delta_us = tcp_rto_delta_us(sk);  /* How far in future is RTO? */
 +	if (rto_delta_us > 0)
 +		timeout = min_t(u32, timeout, usecs_to_jiffies(rto_delta_us));
  
  	inet_csk_reset_xmit_timer(sk, ICSK_TIME_LOSS_PROBE, timeout,
  				  TCP_RTO_MAX);

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-08-03  2:01 Stephen Rothwell
@ 2017-08-03  2:42 ` Stephen Hemminger
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Hemminger @ 2017-08-03  2:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Stephen Hemminger, Florian Fainelli

On Thu, 3 Aug 2017 12:01:37 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/hyperv/netvsc.c
> 
> between commit:
> 
>   4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")
> 
> from the net tree and commit:
> 
>   35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel table")
> 
> from the net-next 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, that looks right.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-08-03  2:01 Stephen Rothwell
  2017-08-03  2:42 ` Stephen Hemminger
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-08-03  2:01 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Stephen Hemminger, Florian Fainelli

Hi all,

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

  drivers/net/hyperv/netvsc.c

between commit:

  4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")

from the net tree and commit:

  35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel table")

from the net-next 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/hyperv/netvsc.c
index 96f90c75d1b7,9598220b3bcc..000000000000
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@@ -1302,8 -1269,7 +1269,9 @@@ struct netvsc_device *netvsc_device_add
  		struct netvsc_channel *nvchan = &net_device->chan_table[i];
  
  		nvchan->channel = device->channel;
+ 		nvchan->net_device = net_device;
 +		u64_stats_init(&nvchan->tx_stats.syncp);
 +		u64_stats_init(&nvchan->rx_stats.syncp);
  	}
  
  	/* Enable NAPI handler before init callbacks */

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-07-03  1:43 Stephen Rothwell
@ 2017-07-03  7:59 ` Saeed Mahameed
  0 siblings, 0 replies; 325+ messages in thread
From: Saeed Mahameed @ 2017-07-03  7:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Mohamad Haj Yahia, Saeed Mahameed,
	Moshe Shemesh, Ilan Tayari

On Mon, Jul 3, 2017 at 4:43 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/health.c
>   include/linux/mlx5/driver.h
>
> between commit:
>
>   2a0165a034ac ("net/mlx5: Cancel delayed recovery work when unloading the driver")
>
> from the net tree and commit:
>
>   0179720d6be2 ("Introduce new function for entering bad-health state.")
>
> from the net-next 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/health.c
> index 8a8b5f0e497c,0648a659b21d..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@@ -193,8 -193,8 +194,8 @@@ static void health_care(struct work_str
>         mlx5_core_warn(dev, "handling bad device here\n");
>         mlx5_handle_bad_state(dev);
>
> -       spin_lock(&health->wq_lock);
> +       spin_lock_irqsave(&health->wq_lock, flags);
>  -      if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags))
>  +      if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags))
>                 schedule_delayed_work(&health->recover_work, recover_delay);
>         else
>                 dev_err(&dev->pdev->dev,
> @@@ -334,11 -341,11 +343,12 @@@ void mlx5_stop_health_poll(struct mlx5_
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev)
>   {
>         struct mlx5_core_health *health = &dev->priv.health;
> +       unsigned long flags;
>
> -       spin_lock(&health->wq_lock);
> +       spin_lock_irqsave(&health->wq_lock, flags);
>         set_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
>  +      set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
> -       spin_unlock(&health->wq_lock);
> +       spin_unlock_irqrestore(&health->wq_lock, flags);
>         cancel_delayed_work_sync(&health->recover_work);
>         cancel_work_sync(&health->work);
>   }
> diff --cc include/linux/mlx5/driver.h
> index ba260330ce5e,2ab4ae3e3a1a..000000000000
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@@ -925,7 -945,7 +945,8 @@@ int mlx5_health_init(struct mlx5_core_d
>   void mlx5_start_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
>  +void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
> + void mlx5_trigger_health_work(struct mlx5_core_dev *dev);
>   int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,
>                         struct mlx5_buf *buf, int node);
>   int mlx5_buf_alloc(struct mlx5_core_dev *dev, int size, struct mlx5_buf *buf);

Hi Stephen,

The fix up looks good, I already notified Dave about this on net
submission and he approved.

Thanks,
Saeed.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-07-03  1:43 Stephen Rothwell
  2017-07-03  7:59 ` Saeed Mahameed
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-07-03  1:43 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Mohamad Haj Yahia, Saeed Mahameed, Moshe Shemesh, Ilan Tayari

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/health.c
  include/linux/mlx5/driver.h

between commit:

  2a0165a034ac ("net/mlx5: Cancel delayed recovery work when unloading the driver")

from the net tree and commit:

  0179720d6be2 ("Introduce new function for entering bad-health state.")

from the net-next 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/health.c
index 8a8b5f0e497c,0648a659b21d..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@@ -193,8 -193,8 +194,8 @@@ static void health_care(struct work_str
  	mlx5_core_warn(dev, "handling bad device here\n");
  	mlx5_handle_bad_state(dev);
  
- 	spin_lock(&health->wq_lock);
+ 	spin_lock_irqsave(&health->wq_lock, flags);
 -	if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags))
 +	if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags))
  		schedule_delayed_work(&health->recover_work, recover_delay);
  	else
  		dev_err(&dev->pdev->dev,
@@@ -334,11 -341,11 +343,12 @@@ void mlx5_stop_health_poll(struct mlx5_
  void mlx5_drain_health_wq(struct mlx5_core_dev *dev)
  {
  	struct mlx5_core_health *health = &dev->priv.health;
+ 	unsigned long flags;
  
- 	spin_lock(&health->wq_lock);
+ 	spin_lock_irqsave(&health->wq_lock, flags);
  	set_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
 +	set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
- 	spin_unlock(&health->wq_lock);
+ 	spin_unlock_irqrestore(&health->wq_lock, flags);
  	cancel_delayed_work_sync(&health->recover_work);
  	cancel_work_sync(&health->work);
  }
diff --cc include/linux/mlx5/driver.h
index ba260330ce5e,2ab4ae3e3a1a..000000000000
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@@ -925,7 -945,7 +945,8 @@@ int mlx5_health_init(struct mlx5_core_d
  void mlx5_start_health_poll(struct mlx5_core_dev *dev);
  void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
  void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
 +void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
+ void mlx5_trigger_health_work(struct mlx5_core_dev *dev);
  int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,
  			struct mlx5_buf *buf, int node);
  int mlx5_buf_alloc(struct mlx5_core_dev *dev, int size, struct mlx5_buf *buf);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-23  1:12 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-23  1:12 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Vlad Yasevich, Zhang Shengju

Hi all,

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

  drivers/net/macvlan.c

between commits:

  e26f43faa0d7 ("macvlan: Do not return error when setting the same mac address")
  18c8c54de9a6 ("macvlan: Let passthru macvlan correctly restore lower mac address")

from the net tree and commit:

  a88e2676a6cd ("macvlan: propagate the mac address change status for lowerdev")

from the net-next 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/macvlan.c
index 72b801803aa4,8ca274c6df3d..000000000000
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@@ -743,15 -703,8 +743,14 @@@ static int macvlan_set_mac_address(stru
  	if (!is_valid_ether_addr(addr->sa_data))
  		return -EADDRNOTAVAIL;
  
 -	if (vlan->mode == MACVLAN_MODE_PASSTHRU)
 +	/* If the addresses are the same, this is a no-op */
 +	if (ether_addr_equal(dev->dev_addr, addr->sa_data))
 +		return 0;
 +
 +	if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
 +		macvlan_set_addr_change(vlan->port);
- 		dev_set_mac_address(vlan->lowerdev, addr);
- 		return 0;
+ 		return dev_set_mac_address(vlan->lowerdev, addr);
 +	}
  
  	return macvlan_sync_address(dev, addr->sa_data);
  }

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-21  1:47 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-21  1:47 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Serhey Popovych, Vlad Yasevich

Hi all,

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

  net/core/rtnetlink.c

between commit:

  db833d40ad32 ("rtnetlink: add IFLA_GROUP to ifla_policy")

from the net tree and commit:

  3d3ea5af5c0b ("rtnl: Add support for netdev event to link messages")

from the net-next 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 net/core/rtnetlink.c
index 467a2f4510a7,3aa57848a895..000000000000
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@@ -1469,7 -1519,7 +1520,8 @@@ static const struct nla_policy ifla_pol
  	[IFLA_LINK_NETNSID]	= { .type = NLA_S32 },
  	[IFLA_PROTO_DOWN]	= { .type = NLA_U8 },
  	[IFLA_XDP]		= { .type = NLA_NESTED },
 +	[IFLA_GROUP]		= { .type = NLA_U32 },
+ 	[IFLA_EVENT]		= { .type = NLA_U32 },
  };
  
  static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-14  0:25 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-14  0:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andreas Pape,
	Simon Wunderlich, Sven Eckelmann

Hi all,

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

  net/batman-adv/routing.c

between commit:

  a1a745ef980a ("batman-adv: fix memory leak when dropping packet from other gateway")

from the net tree and commit:

  22f0502ed9f3 ("batman-adv: Print correct function names in dbg messages")

from the net-next 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 net/batman-adv/routing.c
index ae9f4d37d34f,1338b9221613..000000000000
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@@ -985,9 -985,9 +985,9 @@@ int batadv_recv_unicast_packet(struct s
  			batadv_orig_node_put(orig_node_gw);
  			if (is_gw) {
  				batadv_dbg(BATADV_DBG_BLA, bat_priv,
- 					   "recv_unicast_packet(): Dropped unicast pkt received from another backbone gw %pM.\n",
- 					   orig_addr_gw);
+ 					   "%s(): Dropped unicast pkt received from another backbone gw %pM.\n",
+ 					   __func__, orig_addr_gw);
 -				return NET_RX_DROP;
 +				goto free_skb;
  			}
  		}
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-14  0:20 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-14  0:20 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tomer Tayar,
	Yuval Mintz

Hi all,

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

  drivers/net/ethernet/qlogic/qed/qed_debug.c

between commit:

  ace17c369295 ("qed: fix dump of context data")

from the net tree and commit:

  7b6859fbdcc4 ("qed: Utilize FW 8.20.0.0")

from the net-next tree.

I fixed it up (the latter incorporated 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-06  1:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-06  1:49 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Florian Fainelli, Vivien Didelot

Hi all,

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

  net/dsa/dsa2.c

between commit:

  b07ac9894644 ("net: dsa: Fix stale cpu_switch reference after unbind then bind")

from the net tree and commits:

  8b0d3ea55587 ("net: dsa: store CPU port pointer in the tree")
  937c7df85ce7 ("net: dsa: Pass dsa_port reference to ethtool setup/restore")

from the net-next tree.

I fixed it up (I think (maybe it should be "dst->cpu_dp.ds = NULL"?) -
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 net/dsa/dsa2.c
index 7796580e99ee,cd13bb54a30c..000000000000
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@@ -484,10 -474,8 +474,10 @@@ static void dsa_dst_unapply(struct dsa_
  		dsa_ds_unapply(dst, ds);
  	}
  
- 	if (dst->cpu_switch) {
- 		dsa_cpu_port_ethtool_restore(dst->cpu_switch);
- 		dst->cpu_switch = NULL;
 -	if (dst->cpu_dp)
++	if (dst->cpu_dp) {
+ 		dsa_cpu_port_ethtool_restore(dst->cpu_dp);
++		dst->cpu_dp = NULL;
 +	}
  
  	pr_info("DSA: tree %d unapplied\n", dst->tree);
  	dst->applied = false;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-06-01  1:30 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-06-01  1:30 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Russell King,
	Andrew Lunn

Hi all,

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

  drivers/net/phy/marvell.c

between commit:

  898805e0cdf7 ("net: phy: fix marvell phy status reading")

from the net tree and commit:

  e1dde8dc5b27 ("net: phy: marvell: Refactor some bigger functions")

from the net-next 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/phy/marvell.c
index 57297ba23987,1a72bebc588a..000000000000
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@@ -1082,119 -1133,106 +1133,104 @@@ static int marvell_update_link(struct p
  	return 0;
  }
  
- /* marvell_read_status_page
-  *
-  * Description:
-  *   Check the link, then figure out the current state
-  *   by comparing what we advertise with what the link partner
-  *   advertises.  Start by checking the gigabit possibilities,
-  *   then move on to 10/100.
-  */
- static int marvell_read_status_page(struct phy_device *phydev, int page)
+ static int marvell_read_status_page_an(struct phy_device *phydev,
+ 				       int fiber)
  {
- 	int adv;
- 	int err;
+ 	int status;
  	int lpa;
  	int lpagb;
- 	int status = 0;
- 	int fiber;
+ 	int adv;
  
- 	/* Detect and update the link, but return if there
- 	 * was an error */
- 	if (page == MII_M1111_FIBER)
- 		fiber = 1;
- 	else
- 		fiber = 0;
+ 	status = phy_read(phydev, MII_M1011_PHY_STATUS);
+ 	if (status < 0)
+ 		return status;
  
- 	err = marvell_update_link(phydev, fiber);
- 	if (err)
- 		return err;
+ 	lpa = phy_read(phydev, MII_LPA);
+ 	if (lpa < 0)
+ 		return lpa;
  
- 	if (AUTONEG_ENABLE == phydev->autoneg) {
- 		status = phy_read(phydev, MII_M1011_PHY_STATUS);
- 		if (status < 0)
- 			return status;
+ 	lpagb = phy_read(phydev, MII_STAT1000);
+ 	if (lpagb < 0)
+ 		return lpagb;
  
- 		lpa = phy_read(phydev, MII_LPA);
- 		if (lpa < 0)
- 			return lpa;
+ 	adv = phy_read(phydev, MII_ADVERTISE);
+ 	if (adv < 0)
+ 		return adv;
  
- 		lpagb = phy_read(phydev, MII_STAT1000);
- 		if (lpagb < 0)
- 			return lpagb;
 -	lpa &= adv;
 -
+ 	if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+ 		phydev->duplex = DUPLEX_FULL;
+ 	else
+ 		phydev->duplex = DUPLEX_HALF;
  
- 		adv = phy_read(phydev, MII_ADVERTISE);
- 		if (adv < 0)
- 			return adv;
+ 	status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+ 	phydev->pause = 0;
+ 	phydev->asym_pause = 0;
  
- 		if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
- 			phydev->duplex = DUPLEX_FULL;
- 		else
- 			phydev->duplex = DUPLEX_HALF;
+ 	switch (status) {
+ 	case MII_M1011_PHY_STATUS_1000:
+ 		phydev->speed = SPEED_1000;
+ 		break;
  
- 		status = status & MII_M1011_PHY_STATUS_SPD_MASK;
- 		phydev->pause = phydev->asym_pause = 0;
+ 	case MII_M1011_PHY_STATUS_100:
+ 		phydev->speed = SPEED_100;
+ 		break;
  
- 		switch (status) {
- 		case MII_M1011_PHY_STATUS_1000:
- 			phydev->speed = SPEED_1000;
- 			break;
+ 	default:
+ 		phydev->speed = SPEED_10;
+ 		break;
+ 	}
  
- 		case MII_M1011_PHY_STATUS_100:
- 			phydev->speed = SPEED_100;
- 			break;
+ 	if (!fiber) {
+ 		phydev->lp_advertising =
+ 			mii_stat1000_to_ethtool_lpa_t(lpagb) |
+ 			mii_lpa_to_ethtool_lpa_t(lpa);
  
- 		default:
- 			phydev->speed = SPEED_10;
- 			break;
+ 		if (phydev->duplex == DUPLEX_FULL) {
+ 			phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+ 			phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
  		}
- 
- 		if (!fiber) {
- 			phydev->lp_advertising = mii_stat1000_to_ethtool_lpa_t(lpagb) |
- 					 mii_lpa_to_ethtool_lpa_t(lpa);
- 
- 			if (phydev->duplex == DUPLEX_FULL) {
- 				phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
- 				phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
- 			}
- 		} else {
- 			/* The fiber link is only 1000M capable */
- 			phydev->lp_advertising = fiber_lpa_to_ethtool_lpa_t(lpa);
- 
- 			if (phydev->duplex == DUPLEX_FULL) {
- 				if (!(lpa & LPA_PAUSE_FIBER)) {
- 					phydev->pause = 0;
- 					phydev->asym_pause = 0;
- 				} else if ((lpa & LPA_PAUSE_ASYM_FIBER)) {
- 					phydev->pause = 1;
- 					phydev->asym_pause = 1;
- 				} else {
- 					phydev->pause = 1;
- 					phydev->asym_pause = 0;
- 				}
+ 	} else {
+ 		/* The fiber link is only 1000M capable */
+ 		phydev->lp_advertising = fiber_lpa_to_ethtool_lpa_t(lpa);
+ 
+ 		if (phydev->duplex == DUPLEX_FULL) {
+ 			if (!(lpa & LPA_PAUSE_FIBER)) {
+ 				phydev->pause = 0;
+ 				phydev->asym_pause = 0;
+ 			} else if ((lpa & LPA_PAUSE_ASYM_FIBER)) {
+ 				phydev->pause = 1;
+ 				phydev->asym_pause = 1;
+ 			} else {
+ 				phydev->pause = 1;
+ 				phydev->asym_pause = 0;
  			}
  		}
- 	} else {
- 		int bmcr = phy_read(phydev, MII_BMCR);
+ 	}
+ 	return 0;
+ }
  
- 		if (bmcr < 0)
- 			return bmcr;
+ static int marvell_read_status_page_fixed(struct phy_device *phydev)
+ {
+ 	int bmcr = phy_read(phydev, MII_BMCR);
  
- 		if (bmcr & BMCR_FULLDPLX)
- 			phydev->duplex = DUPLEX_FULL;
- 		else
- 			phydev->duplex = DUPLEX_HALF;
+ 	if (bmcr < 0)
+ 		return bmcr;
  
- 		if (bmcr & BMCR_SPEED1000)
- 			phydev->speed = SPEED_1000;
- 		else if (bmcr & BMCR_SPEED100)
- 			phydev->speed = SPEED_100;
- 		else
- 			phydev->speed = SPEED_10;
+ 	if (bmcr & BMCR_FULLDPLX)
+ 		phydev->duplex = DUPLEX_FULL;
+ 	else
+ 		phydev->duplex = DUPLEX_HALF;
  
- 		phydev->pause = phydev->asym_pause = 0;
- 		phydev->lp_advertising = 0;
- 	}
+ 	if (bmcr & BMCR_SPEED1000)
+ 		phydev->speed = SPEED_1000;
+ 	else if (bmcr & BMCR_SPEED100)
+ 		phydev->speed = SPEED_100;
+ 	else
+ 		phydev->speed = SPEED_10;
+ 
+ 	phydev->pause = 0;
+ 	phydev->asym_pause = 0;
+ 	phydev->lp_advertising = 0;
  
  	return 0;
  }

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-05-24 23:34 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-05-24 23:34 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Lunn

Hi all,

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

  drivers/net/phy/marvell.c

between commit:

  f2899788353c ("net: phy: marvell: Limit errata to 88m1101")

from the net tree and commit:

  0c3439bc7773 ("net: phy: Marvell: checkpatch - Comments")

from the net-next tree.

I fixed it up (I just used the former 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] 325+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-04-18  0:18 Stephen Rothwell
@ 2017-04-18  0:39 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2017-04-18  0:39 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Alexei Starovoitov

On 04/18/2017 02:18 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    kernel/bpf/syscall.c
>
> between commits:
>
>    6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls")
>    c2002f983767 ("bpf: fix checking xdp_adjust_head on tail calls")
>
> from the net tree and commit:
>
>    e245c5c6a565 ("bpf: move fixup_bpf_calls() function")
>    79741b3bdec0 ("bpf: refactor fixup_bpf_calls()")
>
> from the net-next tree.
>
> I fixed it up (the latter moved and changed teh code modified by the
> former  - I added the following fix up patch) 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.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Apr 2017 10:16:03 +1000
> Subject: [PATCH] bpf: merge fix for move of fixup_bpf_calls()
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   kernel/bpf/verifier.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 62e1e447ded9..5939b4c81fe1 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3349,6 +3349,14 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
>   		if (insn->imm == BPF_FUNC_xdp_adjust_head)
>   			prog->xdp_adjust_head = 1;
>   		if (insn->imm == BPF_FUNC_tail_call) {
> +			/* If we tail call into other programs, we
> +			 * cannot make any assumptions since they
> +			 * can be replaced dynamically during runtime
> +			 * in the program array.
> +			 */
> +			prog->cb_access = 1;
> +			prog->xdp_adjust_head = 1;
> +
>   			/* mark bpf_tail_call as different opcode to avoid
>   			 * conditional branch in the interpeter for every normal
>   			 * call and to prevent accidental JITing by JIT compiler
>

Looks good, thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-04-18  0:18 Stephen Rothwell
  2017-04-18  0:39 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-04-18  0:18 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Alexei Starovoitov

Hi all,

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

  kernel/bpf/syscall.c

between commits:

  6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls")
  c2002f983767 ("bpf: fix checking xdp_adjust_head on tail calls")

from the net tree and commit:

  e245c5c6a565 ("bpf: move fixup_bpf_calls() function")
  79741b3bdec0 ("bpf: refactor fixup_bpf_calls()")

from the net-next tree.

I fixed it up (the latter moved and changed teh code modified by the
former  - I added the following fix up patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Apr 2017 10:16:03 +1000
Subject: [PATCH] bpf: merge fix for move of fixup_bpf_calls()

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/bpf/verifier.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 62e1e447ded9..5939b4c81fe1 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3349,6 +3349,14 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
 		if (insn->imm == BPF_FUNC_xdp_adjust_head)
 			prog->xdp_adjust_head = 1;
 		if (insn->imm == BPF_FUNC_tail_call) {
+			/* If we tail call into other programs, we
+			 * cannot make any assumptions since they
+			 * can be replaced dynamically during runtime
+			 * in the program array.
+			 */
+			prog->cb_access = 1;
+			prog->xdp_adjust_head = 1;
+
 			/* mark bpf_tail_call as different opcode to avoid
 			 * conditional branch in the interpeter for every normal
 			 * call and to prevent accidental JITing by JIT compiler
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-04-07  0:12 Stephen Rothwell
@ 2017-04-07 15:46 ` Cong Wang
  0 siblings, 0 replies; 325+ messages in thread
From: Cong Wang @ 2017-04-07 15:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Jiri Kosina

On Thu, Apr 6, 2017 at 5:12 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> diff --cc net/sched/sch_generic.c
> index 1a2f9e964330,3e64d23e098c..000000000000
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@@ -794,8 -794,8 +794,8 @@@ static void attach_default_qdiscs(struc
>                 }
>         }
>   #ifdef CONFIG_NET_SCHED
>  -      if (dev->qdisc)
>  +      if (dev->qdisc != &noop_qdisc)
> -               qdisc_hash_add(dev->qdisc);
> +               qdisc_hash_add(dev->qdisc, false);
>   #endif
>   }


Looks good to me.

Thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-04-07  0:12 Stephen Rothwell
  2017-04-07 15:46 ` Cong Wang
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-04-07  0:12 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Cong Wang,
	Jiri Kosina

Hi all,

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

  net/sched/sch_generic.c

between commit:

  92f9170621a1 ("net_sched: check noop_qdisc before qdisc_hash_add()")

from the net tree and commit:

  49b499718fa1 ("net: sched: make default fifo qdiscs appear in the dump")

from the net-next 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 net/sched/sch_generic.c
index 1a2f9e964330,3e64d23e098c..000000000000
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@@ -794,8 -794,8 +794,8 @@@ static void attach_default_qdiscs(struc
  		}
  	}
  #ifdef CONFIG_NET_SCHED
 -	if (dev->qdisc)
 +	if (dev->qdisc != &noop_qdisc)
- 		qdisc_hash_add(dev->qdisc);
+ 		qdisc_hash_add(dev->qdisc, false);
  #endif
  }
  

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-04-04  1:13 Stephen Rothwell
@ 2017-04-04 14:48 ` Simon Horman
  0 siblings, 0 replies; 325+ messages in thread
From: Simon Horman @ 2017-04-04 14:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Jiri Pirko

On Tue, Apr 04, 2017 at 11:13:57AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/core/flow_dissector.c
> 
> between commit:
> 
>   ac6a3722fed6 ("flow dissector: correct size of storage for ARP")
> 
> from the net tree and commit:
> 
>   9bf881ffc5c0 ("flow_dissector: Move ARP dissection into a separate function")
> 
> from the net-next 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, the fix looks correct to me.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-04-04  1:13 Stephen Rothwell
  2017-04-04 14:48 ` Simon Horman
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-04-04  1:13 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Simon Horman,
	Jiri Pirko

Hi all,

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

  net/core/flow_dissector.c

between commit:

  ac6a3722fed6 ("flow dissector: correct size of storage for ARP")

from the net tree and commit:

  9bf881ffc5c0 ("flow_dissector: Move ARP dissection into a separate function")

from the net-next 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 net/core/flow_dissector.c
index d98d4998213d,5f3ae922fcd1..000000000000
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@@ -113,6 -113,216 +113,216 @@@ __be32 __skb_flow_get_ports(const struc
  }
  EXPORT_SYMBOL(__skb_flow_get_ports);
  
+ enum flow_dissect_ret {
+ 	FLOW_DISSECT_RET_OUT_GOOD,
+ 	FLOW_DISSECT_RET_OUT_BAD,
+ 	FLOW_DISSECT_RET_OUT_PROTO_AGAIN,
+ };
+ 
+ static enum flow_dissect_ret
+ __skb_flow_dissect_mpls(const struct sk_buff *skb,
+ 			struct flow_dissector *flow_dissector,
+ 			void *target_container, void *data, int nhoff, int hlen)
+ {
+ 	struct flow_dissector_key_keyid *key_keyid;
+ 	struct mpls_label *hdr, _hdr[2];
+ 
+ 	if (!dissector_uses_key(flow_dissector,
+ 				FLOW_DISSECTOR_KEY_MPLS_ENTROPY))
+ 		return FLOW_DISSECT_RET_OUT_GOOD;
+ 
+ 	hdr = __skb_header_pointer(skb, nhoff, sizeof(_hdr), data,
+ 				   hlen, &_hdr);
+ 	if (!hdr)
+ 		return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 	if ((ntohl(hdr[0].entry) & MPLS_LS_LABEL_MASK) >>
+ 	    MPLS_LS_LABEL_SHIFT == MPLS_LABEL_ENTROPY) {
+ 		key_keyid = skb_flow_dissector_target(flow_dissector,
+ 						      FLOW_DISSECTOR_KEY_MPLS_ENTROPY,
+ 						      target_container);
+ 		key_keyid->keyid = hdr[1].entry & htonl(MPLS_LS_LABEL_MASK);
+ 	}
+ 	return FLOW_DISSECT_RET_OUT_GOOD;
+ }
+ 
+ static enum flow_dissect_ret
+ __skb_flow_dissect_arp(const struct sk_buff *skb,
+ 		       struct flow_dissector *flow_dissector,
+ 		       void *target_container, void *data, int nhoff, int hlen)
+ {
+ 	struct flow_dissector_key_arp *key_arp;
+ 	struct {
+ 		unsigned char ar_sha[ETH_ALEN];
+ 		unsigned char ar_sip[4];
+ 		unsigned char ar_tha[ETH_ALEN];
+ 		unsigned char ar_tip[4];
+ 	} *arp_eth, _arp_eth;
+ 	const struct arphdr *arp;
 -	struct arphdr *_arp;
++	struct arphdr _arp;
+ 
+ 	if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_ARP))
+ 		return FLOW_DISSECT_RET_OUT_GOOD;
+ 
+ 	arp = __skb_header_pointer(skb, nhoff, sizeof(_arp), data,
+ 				   hlen, &_arp);
+ 	if (!arp)
+ 		return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 	if (arp->ar_hrd != htons(ARPHRD_ETHER) ||
+ 	    arp->ar_pro != htons(ETH_P_IP) ||
+ 	    arp->ar_hln != ETH_ALEN ||
+ 	    arp->ar_pln != 4 ||
+ 	    (arp->ar_op != htons(ARPOP_REPLY) &&
+ 	     arp->ar_op != htons(ARPOP_REQUEST)))
+ 		return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 	arp_eth = __skb_header_pointer(skb, nhoff + sizeof(_arp),
+ 				       sizeof(_arp_eth), data,
+ 				       hlen, &_arp_eth);
+ 	if (!arp_eth)
+ 		return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 	key_arp = skb_flow_dissector_target(flow_dissector,
+ 					    FLOW_DISSECTOR_KEY_ARP,
+ 					    target_container);
+ 
+ 	memcpy(&key_arp->sip, arp_eth->ar_sip, sizeof(key_arp->sip));
+ 	memcpy(&key_arp->tip, arp_eth->ar_tip, sizeof(key_arp->tip));
+ 
+ 	/* Only store the lower byte of the opcode;
+ 	 * this covers ARPOP_REPLY and ARPOP_REQUEST.
+ 	 */
+ 	key_arp->op = ntohs(arp->ar_op) & 0xff;
+ 
+ 	ether_addr_copy(key_arp->sha, arp_eth->ar_sha);
+ 	ether_addr_copy(key_arp->tha, arp_eth->ar_tha);
+ 
+ 	return FLOW_DISSECT_RET_OUT_GOOD;
+ }
+ 
+ static enum flow_dissect_ret
+ __skb_flow_dissect_gre(const struct sk_buff *skb,
+ 		       struct flow_dissector_key_control *key_control,
+ 		       struct flow_dissector *flow_dissector,
+ 		       void *target_container, void *data,
+ 		       __be16 *p_proto, int *p_nhoff, int *p_hlen,
+ 		       unsigned int flags)
+ {
+ 	struct flow_dissector_key_keyid *key_keyid;
+ 	struct gre_base_hdr *hdr, _hdr;
+ 	int offset = 0;
+ 	u16 gre_ver;
+ 
+ 	hdr = __skb_header_pointer(skb, *p_nhoff, sizeof(_hdr),
+ 				   data, *p_hlen, &_hdr);
+ 	if (!hdr)
+ 		return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 	/* Only look inside GRE without routing */
+ 	if (hdr->flags & GRE_ROUTING)
+ 		return FLOW_DISSECT_RET_OUT_GOOD;
+ 
+ 	/* Only look inside GRE for version 0 and 1 */
+ 	gre_ver = ntohs(hdr->flags & GRE_VERSION);
+ 	if (gre_ver > 1)
+ 		return FLOW_DISSECT_RET_OUT_GOOD;
+ 
+ 	*p_proto = hdr->protocol;
+ 	if (gre_ver) {
+ 		/* Version1 must be PPTP, and check the flags */
+ 		if (!(*p_proto == GRE_PROTO_PPP && (hdr->flags & GRE_KEY)))
+ 			return FLOW_DISSECT_RET_OUT_GOOD;
+ 	}
+ 
+ 	offset += sizeof(struct gre_base_hdr);
+ 
+ 	if (hdr->flags & GRE_CSUM)
+ 		offset += sizeof(((struct gre_full_hdr *) 0)->csum) +
+ 			  sizeof(((struct gre_full_hdr *) 0)->reserved1);
+ 
+ 	if (hdr->flags & GRE_KEY) {
+ 		const __be32 *keyid;
+ 		__be32 _keyid;
+ 
+ 		keyid = __skb_header_pointer(skb, *p_nhoff + offset,
+ 					     sizeof(_keyid),
+ 					     data, *p_hlen, &_keyid);
+ 		if (!keyid)
+ 			return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 		if (dissector_uses_key(flow_dissector,
+ 				       FLOW_DISSECTOR_KEY_GRE_KEYID)) {
+ 			key_keyid = skb_flow_dissector_target(flow_dissector,
+ 							      FLOW_DISSECTOR_KEY_GRE_KEYID,
+ 							      target_container);
+ 			if (gre_ver == 0)
+ 				key_keyid->keyid = *keyid;
+ 			else
+ 				key_keyid->keyid = *keyid & GRE_PPTP_KEY_MASK;
+ 		}
+ 		offset += sizeof(((struct gre_full_hdr *) 0)->key);
+ 	}
+ 
+ 	if (hdr->flags & GRE_SEQ)
+ 		offset += sizeof(((struct pptp_gre_header *) 0)->seq);
+ 
+ 	if (gre_ver == 0) {
+ 		if (*p_proto == htons(ETH_P_TEB)) {
+ 			const struct ethhdr *eth;
+ 			struct ethhdr _eth;
+ 
+ 			eth = __skb_header_pointer(skb, *p_nhoff + offset,
+ 						   sizeof(_eth),
+ 						   data, *p_hlen, &_eth);
+ 			if (!eth)
+ 				return FLOW_DISSECT_RET_OUT_BAD;
+ 			*p_proto = eth->h_proto;
+ 			offset += sizeof(*eth);
+ 
+ 			/* Cap headers that we access via pointers at the
+ 			 * end of the Ethernet header as our maximum alignment
+ 			 * at that point is only 2 bytes.
+ 			 */
+ 			if (NET_IP_ALIGN)
+ 				*p_hlen = *p_nhoff + offset;
+ 		}
+ 	} else { /* version 1, must be PPTP */
+ 		u8 _ppp_hdr[PPP_HDRLEN];
+ 		u8 *ppp_hdr;
+ 
+ 		if (hdr->flags & GRE_ACK)
+ 			offset += sizeof(((struct pptp_gre_header *) 0)->ack);
+ 
+ 		ppp_hdr = __skb_header_pointer(skb, *p_nhoff + offset,
+ 					       sizeof(_ppp_hdr),
+ 					       data, *p_hlen, _ppp_hdr);
+ 		if (!ppp_hdr)
+ 			return FLOW_DISSECT_RET_OUT_BAD;
+ 
+ 		switch (PPP_PROTOCOL(ppp_hdr)) {
+ 		case PPP_IP:
+ 			*p_proto = htons(ETH_P_IP);
+ 			break;
+ 		case PPP_IPV6:
+ 			*p_proto = htons(ETH_P_IPV6);
+ 			break;
+ 		default:
+ 			/* Could probably catch some more like MPLS */
+ 			break;
+ 		}
+ 
+ 		offset += PPP_HDRLEN;
+ 	}
+ 
+ 	*p_nhoff += offset;
+ 	key_control->flags |= FLOW_DIS_ENCAPSULATION;
+ 	if (flags & FLOW_DISSECTOR_F_STOP_AT_ENCAP)
+ 		return FLOW_DISSECT_RET_OUT_GOOD;
+ 
+ 	return FLOW_DISSECT_RET_OUT_PROTO_AGAIN;
+ }
+ 
  /**
   * __skb_flow_dissect - extract the flow_keys struct and return it
   * @skb: sk_buff to extract the flow from, can be NULL if the rest are specified

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2017-04-03  2:07 Stephen Rothwell
@ 2017-04-03 13:14 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2017-04-03 13:14 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexei Starovoitov, Martin KaFai Lau

On 04/03/2017 04:07 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>    tools/testing/selftests/bpf/Makefile
>    tools/testing/selftests/bpf/test_verifier.c
>
> between commit:
>
>    02ea80b1850e ("bpf: add various verifier test cases for self-tests")
>
> from the net tree and commits:
>
>    6882804c916b ("selftests/bpf: add a test for overlapping packet range checks")
>    fb30d4b71214 ("bpf: Add tests for map-in-map")
>
> from the net-next tree.
>
> I fixed it up (see below - though there are probably more fixups needed)
> and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.

Looks fine, thanks Stephen!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-04-03  2:07 Stephen Rothwell
  2017-04-03 13:14 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2017-04-03  2:07 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau

Hi all,

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

  tools/testing/selftests/bpf/Makefile
  tools/testing/selftests/bpf/test_verifier.c

between commit:

  02ea80b1850e ("bpf: add various verifier test cases for self-tests")

from the net tree and commits:

  6882804c916b ("selftests/bpf: add a test for overlapping packet range checks")
  fb30d4b71214 ("bpf: Add tests for map-in-map")

from the net-next tree.

I fixed it up (see below - though there are probably more fixups needed)
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 tools/testing/selftests/bpf/Makefile
index 9af09e8099c0,32fb7a294f0f..000000000000
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@@ -1,17 -1,12 +1,19 @@@
  LIBDIR := ../../../lib
  BPFDIR := $(LIBDIR)/bpf
 +APIDIR := ../../../include/uapi
 +GENDIR := ../../../../include/generated
 +GENHDR := $(GENDIR)/autoconf.h
  
 -CFLAGS += -Wall -O2 -I../../../include/uapi -I$(LIBDIR) -I../../../include
 +ifneq ($(wildcard $(GENHDR)),)
 +  GENFLAGS := -DHAVE_GENHDR
 +endif
 +
- CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS)
- LDLIBS += -lcap
++CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) -I../../../include $(GENFLAGS)
+ LDLIBS += -lcap -lelf
  
- TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map
+ TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs
+ 
+ TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o
  
  TEST_PROGS := test_kmod.sh
  
diff --cc tools/testing/selftests/bpf/test_verifier.c
index c848e90b6421,f4f43c98cf7f..000000000000
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@@ -46,9 -38,8 +46,10 @@@
  
  #define MAX_INSNS	512
  #define MAX_FIXUPS	8
+ #define MAX_NR_MAPS	4
  
 +#define F_NEEDS_EFFICIENT_UNALIGNED_ACCESS	(1 << 0)
 +
  struct bpf_test {
  	const char *descr;
  	struct bpf_insn	insns[MAX_INSNS];
@@@ -4719,8 -4454,76 +4721,77 @@@ static struct bpf_test tests[] = 
  		.errstr = "R0 min value is negative, either use unsigned index or do a if (index >=0) check.",
  		.result = REJECT,
  		.result_unpriv = REJECT,
 +		.flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,
- 	}
+ 	},
+ 	{
+ 		"map in map access",
+ 		.insns = {
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_LD_MAP_FD(BPF_REG_1, 0),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 5),
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_MOV64_REG(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.fixup_map_in_map = { 3 },
+ 		.result = ACCEPT,
+ 	},
+ 	{
+ 		"invalid inner map pointer",
+ 		.insns = {
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_LD_MAP_FD(BPF_REG_1, 0),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 6),
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 8),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_MOV64_REG(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.fixup_map_in_map = { 3 },
+ 		.errstr = "R1 type=inv expected=map_ptr",
+ 		.errstr_unpriv = "R1 pointer arithmetic prohibited",
+ 		.result = REJECT,
+ 	},
+ 	{
+ 		"forgot null checking on the inner map pointer",
+ 		.insns = {
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_LD_MAP_FD(BPF_REG_1, 0),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_ST_MEM(0, BPF_REG_10, -4, 0),
+ 			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ 			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
+ 			BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
+ 			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ 				     BPF_FUNC_map_lookup_elem),
+ 			BPF_MOV64_REG(BPF_REG_0, 0),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.fixup_map_in_map = { 3 },
+ 		.errstr = "R1 type=map_value_or_null expected=map_ptr",
+ 		.result = REJECT,
+ 	},
  };
  
  static int probe_filter_length(const struct bpf_insn *fp)
@@@ -4802,10 -4635,15 +4904,14 @@@ static void do_test_single(struct bpf_t
  	struct bpf_insn *prog = test->insns;
  	int prog_len = probe_filter_length(prog);
  	int prog_type = test->prog_type;
- 	int fd_f1 = -1, fd_f2 = -1, fd_f3 = -1;
+ 	int map_fds[MAX_NR_MAPS];
 -	int fd_prog, expected_ret;
  	const char *expected_err;
+ 	int i;
+ 
+ 	for (i = 0; i < MAX_NR_MAPS; i++)
+ 		map_fds[i] = -1;
  
- 	do_test_fixup(test, prog, &fd_f1, &fd_f2, &fd_f3);
+ 	do_test_fixup(test, prog, map_fds);
  
  	fd_prog = bpf_load_program(prog_type ? : BPF_PROG_TYPE_SOCKET_FILTER,
  				   prog, prog_len, "GPL", 0, bpf_vlog,
@@@ -4844,13 -4671,11 +4950,12 @@@
  	}
  
  	(*passes)++;
 -	printf("OK\n");
 +	printf("OK%s\n", reject_from_alignment ?
 +	       " (NOTE: reject due to unknown alignment)" : "");
  close_fds:
  	close(fd_prog);
- 	close(fd_f1);
- 	close(fd_f2);
- 	close(fd_f3);
+ 	for (i = 0; i < MAX_NR_MAPS; i++)
+ 		close(map_fds[i]);
  	sched_yield();
  	return;
  fail_log:

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-03-23  0:00 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-03-23  0:00 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Doug Berger, Florian Fainelli

Hi all,

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

  drivers/net/ethernet/broadcom/genet/bcmmii.c

between commit:

  31739eae738c ("net: bcmgenet: remove bcmgenet_internal_phy_setup()")

from the net tree and commit:

  421380856d9c ("net: bcmgenet: add support for the GENETv5 hardware")

from the net-next tree.

I fixed it up (I just removed the bcmgenet_internal_phy_setup() function)
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/broadcom/genet/bcmmii.c
index 2f9281936f0e,8df47c90cfc5..000000000000
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@@ -195,31 -195,49 +195,33 @@@ void bcmgenet_phy_power_set(struct net_
  	u32 reg = 0;
  
  	/* EXT_GPHY_CTRL is only valid for GENETv4 and onward */
- 	if (!GENET_IS_V4(priv))
- 		return;
- 
- 	reg = bcmgenet_ext_readl(priv, EXT_GPHY_CTRL);
- 	if (enable) {
- 		reg &= ~EXT_CK25_DIS;
- 		bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
- 		mdelay(1);
- 
- 		reg &= ~(EXT_CFG_IDDQ_BIAS | EXT_CFG_PWR_DOWN);
- 		reg |= EXT_GPHY_RESET;
+ 	if (GENET_IS_V4(priv)) {
+ 		reg = bcmgenet_ext_readl(priv, EXT_GPHY_CTRL);
+ 		if (enable) {
+ 			reg &= ~EXT_CK25_DIS;
+ 			bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
+ 			mdelay(1);
+ 
+ 			reg &= ~(EXT_CFG_IDDQ_BIAS | EXT_CFG_PWR_DOWN);
+ 			reg |= EXT_GPHY_RESET;
+ 			bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
+ 			mdelay(1);
+ 
+ 			reg &= ~EXT_GPHY_RESET;
+ 		} else {
+ 			reg |= EXT_CFG_IDDQ_BIAS | EXT_CFG_PWR_DOWN |
+ 			       EXT_GPHY_RESET;
+ 			bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
+ 			mdelay(1);
+ 			reg |= EXT_CK25_DIS;
+ 		}
  		bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
- 		mdelay(1);
- 
- 		reg &= ~EXT_GPHY_RESET;
+ 		udelay(60);
  	} else {
- 		reg |= EXT_CFG_IDDQ_BIAS | EXT_CFG_PWR_DOWN | EXT_GPHY_RESET;
- 		bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
  		mdelay(1);
- 		reg |= EXT_CK25_DIS;
  	}
- 	bcmgenet_ext_writel(priv, reg, EXT_GPHY_CTRL);
- 	udelay(60);
  }
  
 -static void bcmgenet_internal_phy_setup(struct net_device *dev)
 -{
 -	struct bcmgenet_priv *priv = netdev_priv(dev);
 -	u32 reg;
 -
 -	/* Power up PHY */
 -	bcmgenet_phy_power_set(dev, true);
 -	if (!GENET_IS_V5(priv)) {
 -		/* enable APD */
 -		reg = bcmgenet_ext_readl(priv, EXT_EXT_PWR_MGMT);
 -		reg |= EXT_PWR_DN_EN_LD;
 -		bcmgenet_ext_writel(priv, reg, EXT_EXT_PWR_MGMT);
 -	}
 -	bcmgenet_mii_reset(dev);
 -}
 -
  static void bcmgenet_moca_phy_setup(struct bcmgenet_priv *priv)
  {
  	u32 reg;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-03-20  0:02 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-03-20  0:02 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, stephen hemminger, Stephen Hemminger

Hi all,

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

  drivers/net/hyperv/netvsc.c

between commit:

  e14b4db7a567 ("netvsc: fix race during initialization")

from the net tree and commits:

  0d6dd35784e7 ("netvsc: need napi scheduled during removal")
  6de38af611ca ("netvsc: avoid race with callback")

from the net-next tree.

I fixed it up (I just used the net-next 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.

P.S. the Signed-off-bys do not match the Author email addresses.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-01-31  1:23 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-01-31  1:23 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Hadar Hen Zion, Saeed Mahameed, Or Gerlitz

Hi all,

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

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

between commit:

  3e621b19b0bb ("net/mlx5e: Support TC encapsulation offloads with upper devices")

from the net tree and commits:

  75c33da82736 ("net/mlx5e: TC ipv4 tunnel encap offload cosmetic changes")
  9a941117fb76 ("net/mlx5e: Maximize ip tunnel key usage on the TC offloading path")

from the net-next 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/en_tc.c
index c5282b6aba8b,640f10f2e994..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -660,13 -684,10 +684,11 @@@ static int mlx5e_route_lookup_ipv4(stru
  				   struct net_device **out_dev,
  				   struct flowi4 *fl4,
  				   struct neighbour **out_n,
- 				   __be32 *saddr,
  				   int *out_ttl)
  {
 +	struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
  	struct rtable *rt;
  	struct neighbour *n = NULL;
- 	int ttl;
  
  #if IS_ENABLED(CONFIG_INET)
  	int ret;
@@@ -678,21 -699,21 +700,19 @@@
  #else
  	return -EOPNOTSUPP;
  #endif
 -
 -	if (!switchdev_port_same_parent_id(priv->netdev, rt->dst.dev)) {
 -		pr_warn("%s: can't offload, devices not on same HW e-switch\n", __func__);
 -		ip_rt_put(rt);
 -		return -EOPNOTSUPP;
 -	}
 +	/* if the egress device isn't on the same HW e-switch, we use the uplink */
 +	if (!switchdev_port_same_parent_id(priv->netdev, rt->dst.dev))
 +		*out_dev = mlx5_eswitch_get_uplink_netdev(esw);
 +	else
 +		*out_dev = rt->dst.dev;
  
- 	ttl = ip4_dst_hoplimit(&rt->dst);
+ 	*out_ttl = ip4_dst_hoplimit(&rt->dst);
  	n = dst_neigh_lookup(&rt->dst, &fl4->daddr);
  	ip_rt_put(rt);
  	if (!n)
  		return -ENOMEM;
  
  	*out_n = n;
- 	*saddr = fl4->saddr;
- 	*out_ttl = ttl;
 -	*out_dev = rt->dst.dev;
  
  	return 0;
  }

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-01-31  1:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-01-31  1:18 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Rafal Ozieblo, Andrei Pistirica

Hi all,

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

  drivers/net/ethernet/cadence/macb.h

between commit:

  dc97a89e726c ("net: macb: Fix 64 bit addressing support for GEM")

from the net tree and commit:

  c2594d804d5c ("macb: Common code to enable ptp support for MACB/GEM")

from the net-next 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/cadence/macb.h
index fc8550a5d47f,94ddedd2d83e..000000000000
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@@ -385,9 -426,18 +426,20 @@@
  /* Bitfields in DCFG6. */
  #define GEM_PBUF_LSO_OFFSET			27
  #define GEM_PBUF_LSO_SIZE			1
 +#define GEM_DAW64_OFFSET			23
 +#define GEM_DAW64_SIZE				1
  
+ /* Bitfields in TISUBN */
+ #define GEM_SUBNSINCR_OFFSET			0
+ #define GEM_SUBNSINCR_SIZE			16
+ 
+ /* Bitfields in TI */
+ #define GEM_NSINCR_OFFSET			0
+ #define GEM_NSINCR_SIZE				8
+ 
+ /* Bitfields in ADJ */
+ #define GEM_ADDSUB_OFFSET			31
+ #define GEM_ADDSUB_SIZE				1
  /* Constants for CLK */
  #define MACB_CLK_DIV8				0
  #define MACB_CLK_DIV16				1
@@@ -885,9 -942,7 +952,11 @@@ struct macb 
  
  	u32			wol;
  
 +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
 +	enum macb_hw_dma_cap hw_dma_cap;
 +#endif
++
+ 	struct macb_ptp_info	*ptp_info;	/* macb-ptp interface */
  };
  
  static inline bool macb_is_gem(struct macb *bp)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2017-01-24  0:38 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2017-01-24  0:38 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, David Ahern, Robert Shearman

Hi all,

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

  net/mpls/af_mpls.c

between commit:

  9f427a0e474a ("net: mpls: Fix multipath selection for LSR use case")

from the net tree and commit:

  27d691056bde ("mpls: Packet stats")

from the net-next 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 net/mpls/af_mpls.c
index 5b77377e5a15,4dc81963af8f..000000000000
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@@ -98,10 -94,35 +94,35 @@@ bool mpls_pkt_too_big(const struct sk_b
  }
  EXPORT_SYMBOL_GPL(mpls_pkt_too_big);
  
+ void mpls_stats_inc_outucastpkts(struct net_device *dev,
+ 				 const struct sk_buff *skb)
+ {
+ 	struct mpls_dev *mdev;
+ 
+ 	if (skb->protocol == htons(ETH_P_MPLS_UC)) {
+ 		mdev = mpls_dev_get(dev);
+ 		if (mdev)
+ 			MPLS_INC_STATS_LEN(mdev, skb->len,
+ 					   tx_packets,
+ 					   tx_bytes);
+ 	} else if (skb->protocol == htons(ETH_P_IP)) {
+ 		IP_UPD_PO_STATS(dev_net(dev), IPSTATS_MIB_OUT, skb->len);
+ #if IS_ENABLED(CONFIG_IPV6)
+ 	} else if (skb->protocol == htons(ETH_P_IPV6)) {
+ 		struct inet6_dev *in6dev = __in6_dev_get(dev);
+ 
+ 		if (in6dev)
+ 			IP6_UPD_PO_STATS(dev_net(dev), in6dev,
+ 					 IPSTATS_MIB_OUT, skb->len);
+ #endif
+ 	}
+ }
+ EXPORT_SYMBOL_GPL(mpls_stats_inc_outucastpkts);
+ 
 -static u32 mpls_multipath_hash(struct mpls_route *rt,
 -			       struct sk_buff *skb, bool bos)
 +static u32 mpls_multipath_hash(struct mpls_route *rt, struct sk_buff *skb)
  {
  	struct mpls_entry_decoded dec;
 +	unsigned int mpls_hdr_len = 0;
  	struct mpls_shim_hdr *hdr;
  	bool eli_seen = false;
  	int label_index;
@@@ -280,27 -308,24 +310,24 @@@ static int mpls_forward(struct sk_buff 
  	hdr = mpls_hdr(skb);
  	dec = mpls_entry_decode(hdr);
  
 -	/* Pop the label */
 -	skb_pull(skb, sizeof(*hdr));
 -	skb_reset_network_header(skb);
 -
 -	skb_orphan(skb);
 -
  	rt = mpls_route_input_rcu(net, dec.label);
- 	if (!rt)
+ 	if (!rt) {
+ 		MPLS_INC_STATS(mdev, rx_noroute);
  		goto drop;
+ 	}
  
 -	nh = mpls_select_multipath(rt, skb, dec.bos);
 +	nh = mpls_select_multipath(rt, skb);
  	if (!nh)
- 		goto drop;
- 
- 	/* Find the output device */
- 	out_dev = rcu_dereference(nh->nh_dev);
- 	if (!mpls_output_possible(out_dev))
- 		goto drop;
+ 		goto err;
  
 +	/* Pop the label */
 +	skb_pull(skb, sizeof(*hdr));
 +	skb_reset_network_header(skb);
 +
 +	skb_orphan(skb);
 +
  	if (skb_warn_if_lro(skb))
- 		goto drop;
+ 		goto err;
  
  	skb_forward_csum(skb);
  

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-12-01  1:41 Stephen Rothwell
@ 2016-12-01  7:56 ` Jiri Pirko
  0 siblings, 0 replies; 325+ messages in thread
From: Jiri Pirko @ 2016-12-01  7:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, linux-next, linux-kernel, Jiri Pirko,
	Roi Dayan

Thu, Dec 01, 2016 at 02:41:59AM CET, sfr@canb.auug.org.au wrote:
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/sched/cls_flower.c
>
>between commit:
>
>  725cbb62e7ad ("sched: cls_flower: remove from hashtable only in case skip sw flag is not set")
>
>from the net tree and commit:
>
>  13fa876ebd03 ("net/sched: cls_flower: merge filter delete/destroy common code")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your tree
>is submitted for merging.  You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any particularly
>complex conflicts.

Looks fine to me. Thanks.

>
>-- 
>Cheers,
>Stephen Rothwell
>
>diff --cc net/sched/cls_flower.c
>index 904442421db3,e8dd09af0d0c..000000000000
>--- a/net/sched/cls_flower.c
>+++ b/net/sched/cls_flower.c
>@@@ -273,24 -272,14 +276,32 @@@ static void fl_hw_update_stats(struct t
>  	dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol, &tc);
>  }
>  
> +static void fl_destroy_sleepable(struct work_struct *work)
> +{
> +	struct cls_fl_head *head = container_of(work, struct cls_fl_head,
> +						work);
> +	if (head->mask_assigned)
> +		rhashtable_destroy(&head->ht);
> +	kfree(head);
> +	module_put(THIS_MODULE);
> +}
> +
> +static void fl_destroy_rcu(struct rcu_head *rcu)
> +{
> +	struct cls_fl_head *head = container_of(rcu, struct cls_fl_head, rcu);
> +
> +	INIT_WORK(&head->work, fl_destroy_sleepable);
> +	schedule_work(&head->work);
> +}
> +
>+ static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
>+ {
>+ 	list_del_rcu(&f->list);
>+ 	fl_hw_destroy_filter(tp, (unsigned long)f);
>+ 	tcf_unbind_filter(tp, &f->res);
>+ 	call_rcu(&f->rcu, fl_destroy_filter);
>+ }
>+ 
>  static bool fl_destroy(struct tcf_proto *tp, bool force)
>  {
>  	struct cls_fl_head *head = rtnl_dereference(tp->root);
>@@@ -299,14 -288,12 +310,11 @@@
>  	if (!force && !list_empty(&head->filters))
>  		return false;
>  
>- 	list_for_each_entry_safe(f, next, &head->filters, list) {
>- 		fl_hw_destroy_filter(tp, (unsigned long)f);
>- 		list_del_rcu(&f->list);
>- 		call_rcu(&f->rcu, fl_destroy_filter);
>- 	}
>+ 	list_for_each_entry_safe(f, next, &head->filters, list)
>+ 		__fl_delete(tp, f);
> -	RCU_INIT_POINTER(tp->root, NULL);
> -	if (head->mask_assigned)
> -		rhashtable_destroy(&head->ht);
> -	kfree_rcu(head, rcu);
> +
> +	__module_get(THIS_MODULE);
> +	call_rcu(&head->rcu, fl_destroy_rcu);
>  	return true;
>  }
>  
>@@@ -761,13 -782,9 +804,10 @@@ static int fl_delete(struct tcf_proto *
>  	struct cls_fl_head *head = rtnl_dereference(tp->root);
>  	struct cls_fl_filter *f = (struct cls_fl_filter *) arg;
>  
> -	rhashtable_remove_fast(&head->ht, &f->ht_node,
> -			       head->ht_params);
> +	if (!tc_skip_sw(f->flags))
> +		rhashtable_remove_fast(&head->ht, &f->ht_node,
> +				       head->ht_params);
>- 	list_del_rcu(&f->list);
>- 	fl_hw_destroy_filter(tp, (unsigned long)f);
>- 	tcf_unbind_filter(tp, &f->res);
>- 	call_rcu(&f->rcu, fl_destroy_filter);
>+ 	__fl_delete(tp, f);
>  	return 0;
>  }
>  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-12-01  1:41 Stephen Rothwell
  2016-12-01  7:56 ` Jiri Pirko
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-12-01  1:41 UTC (permalink / raw)
  To: David Miller, Networking; +Cc: linux-next, linux-kernel, Jiri Pirko, Roi Dayan

Hi all,

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

  net/sched/cls_flower.c

between commit:

  725cbb62e7ad ("sched: cls_flower: remove from hashtable only in case skip sw flag is not set")

from the net tree and commit:

  13fa876ebd03 ("net/sched: cls_flower: merge filter delete/destroy common code")

from the net-next 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 net/sched/cls_flower.c
index 904442421db3,e8dd09af0d0c..000000000000
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@@ -273,24 -272,14 +276,32 @@@ static void fl_hw_update_stats(struct t
  	dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol, &tc);
  }
  
 +static void fl_destroy_sleepable(struct work_struct *work)
 +{
 +	struct cls_fl_head *head = container_of(work, struct cls_fl_head,
 +						work);
 +	if (head->mask_assigned)
 +		rhashtable_destroy(&head->ht);
 +	kfree(head);
 +	module_put(THIS_MODULE);
 +}
 +
 +static void fl_destroy_rcu(struct rcu_head *rcu)
 +{
 +	struct cls_fl_head *head = container_of(rcu, struct cls_fl_head, rcu);
 +
 +	INIT_WORK(&head->work, fl_destroy_sleepable);
 +	schedule_work(&head->work);
 +}
 +
+ static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
+ {
+ 	list_del_rcu(&f->list);
+ 	fl_hw_destroy_filter(tp, (unsigned long)f);
+ 	tcf_unbind_filter(tp, &f->res);
+ 	call_rcu(&f->rcu, fl_destroy_filter);
+ }
+ 
  static bool fl_destroy(struct tcf_proto *tp, bool force)
  {
  	struct cls_fl_head *head = rtnl_dereference(tp->root);
@@@ -299,14 -288,12 +310,11 @@@
  	if (!force && !list_empty(&head->filters))
  		return false;
  
- 	list_for_each_entry_safe(f, next, &head->filters, list) {
- 		fl_hw_destroy_filter(tp, (unsigned long)f);
- 		list_del_rcu(&f->list);
- 		call_rcu(&f->rcu, fl_destroy_filter);
- 	}
+ 	list_for_each_entry_safe(f, next, &head->filters, list)
+ 		__fl_delete(tp, f);
 -	RCU_INIT_POINTER(tp->root, NULL);
 -	if (head->mask_assigned)
 -		rhashtable_destroy(&head->ht);
 -	kfree_rcu(head, rcu);
 +
 +	__module_get(THIS_MODULE);
 +	call_rcu(&head->rcu, fl_destroy_rcu);
  	return true;
  }
  
@@@ -761,13 -782,9 +804,10 @@@ static int fl_delete(struct tcf_proto *
  	struct cls_fl_head *head = rtnl_dereference(tp->root);
  	struct cls_fl_filter *f = (struct cls_fl_filter *) arg;
  
 -	rhashtable_remove_fast(&head->ht, &f->ht_node,
 -			       head->ht_params);
 +	if (!tc_skip_sw(f->flags))
 +		rhashtable_remove_fast(&head->ht, &f->ht_node,
 +				       head->ht_params);
- 	list_del_rcu(&f->list);
- 	fl_hw_destroy_filter(tp, (unsigned long)f);
- 	tcf_unbind_filter(tp, &f->res);
- 	call_rcu(&f->rcu, fl_destroy_filter);
+ 	__fl_delete(tp, f);
  	return 0;
  }
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-12-01  1:36 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-12-01  1:36 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Cyrille Pitchen, Zach Brown

Hi all,

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

  drivers/net/ethernet/cadence/macb.c

between commit:

  a0b44eea372b ("net: macb: fix the RX queue reset in macb_rx()")

from the net tree and commit:

  b410d13e10db ("net: macb: Use variables with defaults for tx/rx ring sizes instead of hardcoded values")

from the net-next 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/cadence/macb.c
index ec09fcece711,0e489bb82456..000000000000
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@@ -974,8 -990,7 +990,8 @@@ static inline void macb_init_rx_ring(st
  		bp->rx_ring[i].ctrl = 0;
  		addr += bp->rx_buffer_size;
  	}
- 	bp->rx_ring[RX_RING_SIZE - 1].addr |= MACB_BIT(RX_WRAP);
+ 	bp->rx_ring[bp->rx_ring_size - 1].addr |= MACB_BIT(RX_WRAP);
 +	bp->rx_tail = 0;
  }
  
  static int macb_rx(struct macb *bp, int budget)
@@@ -1617,7 -1735,9 +1737,7 @@@ static void macb_init_rings(struct mac
  	}
  	bp->queues[0].tx_head = 0;
  	bp->queues[0].tx_tail = 0;
- 	bp->queues[0].tx_ring[TX_RING_SIZE - 1].ctrl |= MACB_BIT(TX_WRAP);
+ 	bp->queues[0].tx_ring[bp->tx_ring_size - 1].ctrl |= MACB_BIT(TX_WRAP);
 -
 -	bp->rx_tail = 0;
  }
  
  static void macb_reset_hw(struct macb *bp)

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-11-29  0:22 Stephen Rothwell
@ 2016-11-29  9:01 ` Borislav Petkov
  0 siblings, 0 replies; 325+ messages in thread
From: Borislav Petkov @ 2016-11-29  9:01 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller
  Cc: Networking, linux-next, linux-kernel, Tom Lendacky

On Tue, Nov 29, 2016 at 11:22:32AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/amd/xgbe/xgbe-main.c
> 
> between commit:
> 
>   91eefaabf102 ("amd-xgbe: Fix unused suspend handlers build warning")
> 
> from the net tree and commit:
> 
>   bd8255d8ba35 ("amd-xgbe: Prepare for supporting PCI devices")
> 
> from the net-next tree.
> 
> I fixed it up (the latter removed the code modified by the former)

... except that +#ifdef CONFIG_PM is present in the new
drivers/net/ethernet/amd/xgbe/xgbe-platform.c now.

So actually the proper fix is, IMO, to convert:

+#ifdef CONFIG_PM
+static int xgbe_platform_suspend(struct device *dev)

to

+#ifdef CONFIG_PM_SLEEP
+static int xgbe_platform_suspend(struct device *dev)

so that it doesn't fire again.

David, would you prefer a patch against linux-next?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-11-29  0:31 Stephen Rothwell
@ 2016-11-29  6:32 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2016-11-29  6:32 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking; +Cc: linux-next, linux-kernel

On 11/29/2016 01:31 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    net/sched/cls_flower.c
>
> between commit:
>
>    d936377414fa ("net, sched: respect rcu grace period on cls destruction")
>
> from the net tree and commit:
>
>    13fa876ebd03 ("net/sched: cls_flower: merge filter delete/destroy common code")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good to me, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-29  0:31 Stephen Rothwell
  2016-11-29  6:32 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-29  0:31 UTC (permalink / raw)
  To: David Miller, Networking; +Cc: linux-next, linux-kernel, Daniel Borkmann

Hi all,

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

  net/sched/cls_flower.c

between commit:

  d936377414fa ("net, sched: respect rcu grace period on cls destruction")

from the net tree and commit:

  13fa876ebd03 ("net/sched: cls_flower: merge filter delete/destroy common code")

from the net-next 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 net/sched/cls_flower.c
index b296f3991ab2,e8dd09af0d0c..000000000000
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@@ -273,24 -272,14 +276,32 @@@ static void fl_hw_update_stats(struct t
  	dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol, &tc);
  }
  
 +static void fl_destroy_sleepable(struct work_struct *work)
 +{
 +	struct cls_fl_head *head = container_of(work, struct cls_fl_head,
 +						work);
 +	if (head->mask_assigned)
 +		rhashtable_destroy(&head->ht);
 +	kfree(head);
 +	module_put(THIS_MODULE);
 +}
 +
 +static void fl_destroy_rcu(struct rcu_head *rcu)
 +{
 +	struct cls_fl_head *head = container_of(rcu, struct cls_fl_head, rcu);
 +
 +	INIT_WORK(&head->work, fl_destroy_sleepable);
 +	schedule_work(&head->work);
 +}
 +
+ static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
+ {
+ 	list_del_rcu(&f->list);
+ 	fl_hw_destroy_filter(tp, (unsigned long)f);
+ 	tcf_unbind_filter(tp, &f->res);
+ 	call_rcu(&f->rcu, fl_destroy_filter);
+ }
+ 
  static bool fl_destroy(struct tcf_proto *tp, bool force)
  {
  	struct cls_fl_head *head = rtnl_dereference(tp->root);
@@@ -299,14 -288,12 +310,11 @@@
  	if (!force && !list_empty(&head->filters))
  		return false;
  
- 	list_for_each_entry_safe(f, next, &head->filters, list) {
- 		fl_hw_destroy_filter(tp, (unsigned long)f);
- 		list_del_rcu(&f->list);
- 		call_rcu(&f->rcu, fl_destroy_filter);
- 	}
+ 	list_for_each_entry_safe(f, next, &head->filters, list)
+ 		__fl_delete(tp, f);
 -	RCU_INIT_POINTER(tp->root, NULL);
 -	if (head->mask_assigned)
 -		rhashtable_destroy(&head->ht);
 -	kfree_rcu(head, rcu);
 +
 +	__module_get(THIS_MODULE);
 +	call_rcu(&head->rcu, fl_destroy_rcu);
  	return true;
  }
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-29  0:25 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-29  0:25 UTC (permalink / raw)
  To: David Miller, Networking; +Cc: linux-next, linux-kernel, Tariq Toukan

Hi all,

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

  drivers/net/ethernet/mellanox/mlx4/en_netdev.c

between commit:

  b4353708f5a1 ("Revert "net/mlx4_en: Avoid unregister_netdev at shutdown flow"")

from the net tree and commit:

  67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")

from the net-next 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/mlx4/en_netdev.c
index fb8bb027b69c,ea76b28b728b..000000000000
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@@ -2155,6 -2209,9 +2202,7 @@@ void mlx4_en_destroy_netdev(struct net_
  {
  	struct mlx4_en_priv *priv = netdev_priv(dev);
  	struct mlx4_en_dev *mdev = priv->mdev;
 -	bool shutdown = mdev->dev->persist->interface_state &
 -					    MLX4_INTERFACE_STATE_SHUTDOWN;
+ 	int t;
  
  	en_dbg(DRV, priv, "Destroying netdev on port:%d\n", priv->port);
  
@@@ -2188,10 -2248,13 +2236,12 @@@
  	mlx4_en_free_resources(priv);
  	mutex_unlock(&mdev->state_lock);
  
- 	kfree(priv->tx_ring);
- 	kfree(priv->tx_cq);
+ 	for (t = 0; t < MLX4_EN_NUM_TX_TYPES; t++) {
+ 		kfree(priv->tx_ring[t]);
+ 		kfree(priv->tx_cq[t]);
+ 	}
  
 -	if (!shutdown)
 -		free_netdev(dev);
 +	free_netdev(dev);
  }
  
  static int mlx4_en_change_mtu(struct net_device *dev, int new_mtu)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-29  0:22 Stephen Rothwell
  2016-11-29  9:01 ` Borislav Petkov
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-29  0:22 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Borislav Petkov, Tom Lendacky

Hi all,

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

  drivers/net/ethernet/amd/xgbe/xgbe-main.c

between commit:

  91eefaabf102 ("amd-xgbe: Fix unused suspend handlers build warning")

from the net tree and commit:

  bd8255d8ba35 ("amd-xgbe: Prepare for supporting PCI devices")

from the net-next tree.

I fixed it up (the latter removed the code modified by 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-22  0:58 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-22  0:58 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Giuseppe CAVALLARO, LABBE Corentin

Hi all,

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

  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

between commit:

  ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")

from the net tree and commit:

  38ddc59d65b6 ("net: stmmac: replace all pr_xxx by their netdev_xxx counterpart")

from the net-next 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/stmicro/stmmac/stmmac_main.c
index 1f9ec02fa7f8,fbd1cd79233d..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -2484,7 -2493,7 +2493,7 @@@ static int stmmac_rx(struct stmmac_pri
  	if (netif_msg_rx_status(priv)) {
  		void *rx_head;
  
- 		pr_info(">>>>>> %s: descriptor ring:\n", __func__);
 -		netdev_dbg(priv->dev, "%s: descriptor ring:\n", __func__);
++		netdev_info(priv->dev, ">>>>>> %s: descriptor ring:\n", __func__);
  		if (priv->extend_desc)
  			rx_head = (void *)priv->dma_erx;
  		else
@@@ -2571,11 -2577,11 +2580,11 @@@
  				frame_len -= ETH_FCS_LEN;
  
  			if (netif_msg_rx_status(priv)) {
- 				pr_info("\tdesc: %p [entry %d] buff=0x%x\n",
- 					p, entry, des);
 -				netdev_dbg(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
 -					   p, entry, des);
++				netdev_info(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
++					    p, entry, des);
  				if (frame_len > ETH_FRAME_LEN)
- 					pr_debug("\tframe size %d, COE: %d\n",
- 						 frame_len, status);
+ 					netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
+ 						   frame_len, status);
  			}
  
  			/* The zero-copy is always used for all the sizes
@@@ -2628,8 -2635,11 +2638,9 @@@
  						 DMA_FROM_DEVICE);
  			}
  
 -			stmmac_get_rx_hwtstamp(priv, entry, skb);
 -
  			if (netif_msg_pktdata(priv)) {
- 				pr_debug("frame received (%dbytes)", frame_len);
+ 				netdev_dbg(priv->dev, "frame received (%dbytes)",
+ 					   frame_len);
  				print_pkt(skb->data, frame_len);
  			}
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-16 23:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-16 23:51 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Josef Bacik, Tobias Klauser

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  f23cc643f9ba ("bpf: fix range arithmetic for bpf map access")

from the net tree and commit:

  de464375daf0 ("bpf: Remove unused but set variables")

from the net-next 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 kernel/bpf/verifier.c
index 6a936159c6e0,89f787ca47ef..000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -212,12 -229,13 +229,13 @@@ static void print_verifier_state(struc
  		else if (t == CONST_PTR_TO_MAP || t == PTR_TO_MAP_VALUE ||
  			 t == PTR_TO_MAP_VALUE_OR_NULL ||
  			 t == PTR_TO_MAP_VALUE_ADJ)
- 			verbose("(ks=%d,vs=%d)",
+ 			verbose("(ks=%d,vs=%d,id=%u)",
  				reg->map_ptr->key_size,
- 				reg->map_ptr->value_size);
+ 				reg->map_ptr->value_size,
+ 				reg->id);
  		if (reg->min_value != BPF_REGISTER_MIN_RANGE)
 -			verbose(",min_value=%llu",
 -				(unsigned long long)reg->min_value);
 +			verbose(",min_value=%lld",
 +				(long long)reg->min_value);
  		if (reg->max_value != BPF_REGISTER_MAX_RANGE)
  			verbose(",max_value=%llu",
  				(unsigned long long)reg->max_value);
@@@ -1477,9 -1498,7 +1499,8 @@@ static void adjust_reg_min_max_vals(str
  				    struct bpf_insn *insn)
  {
  	struct bpf_reg_state *regs = env->cur_state.regs, *dst_reg;
 -	u64 min_val = BPF_REGISTER_MIN_RANGE, max_val = BPF_REGISTER_MAX_RANGE;
 +	s64 min_val = BPF_REGISTER_MIN_RANGE;
 +	u64 max_val = BPF_REGISTER_MAX_RANGE;
- 	bool min_set = false, max_set = false;
  	u8 opcode = BPF_OP(insn->code);
  
  	dst_reg = &regs[insn->dst_reg];

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-16 23:48 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-16 23:48 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Josef Bacik, Thomas Graf

Hi all,

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

  include/linux/bpf_verifier.h

between commit:

  f23cc643f9ba ("bpf: fix range arithmetic for bpf map access")

from the net tree and commit:

  57a09bf0a416 ("bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers")

from the net-next 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/bpf_verifier.h
index 6aaf425cebc3,ac5b393ee6b2..000000000000
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@@ -22,8 -22,8 +22,9 @@@ struct bpf_reg_state 
  	 * Used to determine if any memory access using this register will
  	 * result in a bad access.
  	 */
 -	u64 min_value, max_value;
 +	s64 min_value;
 +	u64 max_value;
+ 	u32 id;
  	union {
  		/* valid when type == CONST_IMM | PTR_TO_STACK | UNKNOWN_VALUE */
  		s64 imm;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-16 23:46 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-16 23:46 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Michael Weiser, Giuseppe CAVALLARO

Hi all,

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

  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c

between commit:

  ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")

from the net tree and commit:

  f8be0d78be6e ("net: ethernet: stmmac: change dma descriptors to __le32")

from the net-next 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/stmicro/stmmac/dwmac4_descs.c
index a601f8d43b75,bec72d3103a1..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@@ -211,18 -205,14 +212,18 @@@ static void dwmac4_rd_enable_tx_timesta
  
  static int dwmac4_wrback_get_tx_timestamp_status(struct dma_desc *p)
  {
 -	return (le32_to_cpu(p->des3) & TDES3_TIMESTAMP_STATUS)
 -		>> TDES3_TIMESTAMP_STATUS_SHIFT;
 +	/* Context type from W/B descriptor must be zero */
- 	if (p->des3 & TDES3_CONTEXT_TYPE)
++	if (le32_to_cpu(p->des3) & TDES3_CONTEXT_TYPE)
 +		return -EINVAL;
 +
 +	/* Tx Timestamp Status is 1 so des0 and des1'll have valid values */
- 	if (p->des3 & TDES3_TIMESTAMP_STATUS)
++	if (le32_to_cpu(p->des3) & TDES3_TIMESTAMP_STATUS)
 +		return 0;
 +
 +	return 1;
  }
  
 -/*  NOTE: For RX CTX bit has to be checked before
 - *  HAVE a specific function for TX and another one for RX
 - */
 -static u64 dwmac4_wrback_get_timestamp(void *desc, u32 ats)
 +static inline u64 dwmac4_get_timestamp(void *desc, u32 ats)
  {
  	struct dma_desc *p = (struct dma_desc *)desc;
  	u64 ns;
@@@ -234,54 -224,12 +235,54 @@@
  	return ns;
  }
  
 -static int dwmac4_context_get_rx_timestamp_status(void *desc, u32 ats)
 +static int dwmac4_rx_check_timestamp(void *desc)
 +{
 +	struct dma_desc *p = (struct dma_desc *)desc;
 +	u32 own, ctxt;
 +	int ret = 1;
 +
- 	own = p->des3 & RDES3_OWN;
- 	ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
++	own = le32_to_cpu(p->des3) & RDES3_OWN;
++	ctxt = ((le32_to_cpu(p->des3) & RDES3_CONTEXT_DESCRIPTOR)
 +		>> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
 +
 +	if (likely(!own && ctxt)) {
 +		if ((p->des0 == 0xffffffff) && (p->des1 == 0xffffffff))
 +			/* Corrupted value */
 +			ret = -EINVAL;
 +		else
 +			/* A valid Timestamp is ready to be read */
 +			ret = 0;
 +	}
 +
 +	/* Timestamp not ready */
 +	return ret;
 +}
 +
 +static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
  {
  	struct dma_desc *p = (struct dma_desc *)desc;
 +	int ret = -EINVAL;
 +
 +	/* Get the status from normal w/b descriptor */
- 	if (likely(p->des3 & TDES3_RS1V)) {
- 		if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
++	if (likely(le32_to_cpu(p->des3) & TDES3_RS1V)) {
++		if (likely(le32_to_cpu(p->des1) & RDES1_TIMESTAMP_AVAILABLE)) {
 +			int i = 0;
 +
 +			/* Check if timestamp is OK from context descriptor */
 +			do {
 +				ret = dwmac4_rx_check_timestamp(desc);
 +				if (ret < 0)
 +					goto exit;
 +				i++;
  
 -	return (le32_to_cpu(p->des1) & RDES1_TIMESTAMP_AVAILABLE)
 -		>> RDES1_TIMESTAMP_AVAILABLE_SHIFT;
 +			} while ((ret == 1) || (i < 10));
 +
 +			if (i == 10)
 +				ret = -EBUSY;
 +		}
 +	}
 +exit:
 +	return ret;
  }
  
  static void dwmac4_rd_init_rx_desc(struct dma_desc *p, int disable_rx_ic,

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-16 23:36 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-16 23:36 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Jarod Wilson, Sunil Goutham

Hi all,

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

  drivers/net/ethernet/cavium/thunder/nicvf_main.c

between commit:

  712c31853440 ("net: thunderx: Program LMAC credits based on MTU")

from the net tree and commit:

  109cc16526c6 ("ethernet/cavium: use core min/max MTU checking")

from the net-next 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/cavium/thunder/nicvf_main.c
index 8a37012c9c89,b192712c93b7..000000000000
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@@ -1292,19 -1312,10 +1292,13 @@@ static int nicvf_change_mtu(struct net_
  {
  	struct nicvf *nic = netdev_priv(netdev);
  
- 	if (new_mtu > NIC_HW_MAX_FRS)
- 		return -EINVAL;
- 
- 	if (new_mtu < NIC_HW_MIN_FRS)
- 		return -EINVAL;
- 
 +	netdev->mtu = new_mtu;
 +
 +	if (!netif_running(netdev))
 +		return 0;
 +
  	if (nicvf_update_hw_max_frs(nic, new_mtu))
  		return -EINVAL;
 -	netdev->mtu = new_mtu;
 -	nic->mtu = new_mtu;
  
  	return 0;
  }

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-11-09 23:50 Stephen Rothwell
@ 2016-11-13 12:27 ` Or Gerlitz
  0 siblings, 0 replies; 325+ messages in thread
From: Or Gerlitz @ 2016-11-13 12:27 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller
  Cc: Networking, linux-next, Linux Kernel, Or Gerlitz, Saeed Mahameed,
	Hadar Hen Zion

On Thu, Nov 10, 2016 at 1:50 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>
> between commit:
>   ee39fbc4447d ("net/mlx5: E-Switch, Set the actions for offloaded rules properly")
> from the net tree and commit:
>   66958ed906b8 ("net/mlx5: Support encap id when setting new steering entry")
> from the net-next tree.

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

Thanks Stephen, the fix is correct. Dave will hit the conflict the
next time he rebases
net-next on net and will solve it there. Hence the conflict will not
show up in linux-next
once you re-peek net-next.

Or.

> diff --cc drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> index d239f5d0ea36,50fe8e8861bb..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> @@@ -57,14 -58,14 +58,15 @@@ mlx5_eswitch_add_offloaded_rule(struct
>         if (esw->mode != SRIOV_OFFLOADS)
>                 return ERR_PTR(-EOPNOTSUPP);
>
>  -      flow_act.action = attr->action;
>  +      /* per flow vlan pop/push is emulated, don't set that into the firmware */
> -       action = attr->action & ~(MLX5_FLOW_CONTEXT_ACTION_VLAN_PUSH | MLX5_FLOW_CONTEXT_ACTION_VLAN_POP);
> ++      flow_act.action = attr->action & ~(MLX5_FLOW_CONTEXT_ACTION_VLAN_PUSH | MLX5_FLOW_CONTEXT_ACTION_VLAN_POP);
>
> -       if (action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
> -               dest.type = MLX5_FLOW_DESTINATION_TYPE_VPORT;
> -               dest.vport_num = attr->out_rep->vport;
> -               action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
> -       } else if (action & MLX5_FLOW_CONTEXT_ACTION_COUNT) {
> +       if (flow_act.action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
> +               dest[i].type = MLX5_FLOW_DESTINATION_TYPE_VPORT;
> +               dest[i].vport_num = attr->out_rep->vport;
> +               i++;
> +       }
> +       if (flow_act.action & MLX5_FLOW_CONTEXT_ACTION_COUNT) {
>                 counter = mlx5_fc_create(esw->dev, true);
>                 if (IS_ERR(counter))
>                         return ERR_CAST(counter);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-09 23:50 Stephen Rothwell
  2016-11-13 12:27 ` Or Gerlitz
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-09 23:50 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Or Gerlitz, Saeed Mahameed, Hadar Hen Zion

Hi all,

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

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

between commit:

  ee39fbc4447d ("net/mlx5: E-Switch, Set the actions for offloaded rules properly")

from the net tree and commit:

  66958ed906b8 ("net/mlx5: Support encap id when setting new steering entry")

from the net-next 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/eswitch_offloads.c
index d239f5d0ea36,50fe8e8861bb..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@@ -57,14 -58,14 +58,15 @@@ mlx5_eswitch_add_offloaded_rule(struct 
  	if (esw->mode != SRIOV_OFFLOADS)
  		return ERR_PTR(-EOPNOTSUPP);
  
 -	flow_act.action = attr->action;
 +	/* per flow vlan pop/push is emulated, don't set that into the firmware */
- 	action = attr->action & ~(MLX5_FLOW_CONTEXT_ACTION_VLAN_PUSH | MLX5_FLOW_CONTEXT_ACTION_VLAN_POP);
++	flow_act.action = attr->action & ~(MLX5_FLOW_CONTEXT_ACTION_VLAN_PUSH | MLX5_FLOW_CONTEXT_ACTION_VLAN_POP);
  
- 	if (action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
- 		dest.type = MLX5_FLOW_DESTINATION_TYPE_VPORT;
- 		dest.vport_num = attr->out_rep->vport;
- 		action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
- 	} else if (action & MLX5_FLOW_CONTEXT_ACTION_COUNT) {
+ 	if (flow_act.action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
+ 		dest[i].type = MLX5_FLOW_DESTINATION_TYPE_VPORT;
+ 		dest[i].vport_num = attr->out_rep->vport;
+ 		i++;
+ 	}
+ 	if (flow_act.action & MLX5_FLOW_CONTEXT_ACTION_COUNT) {
  		counter = mlx5_fc_create(esw->dev, true);
  		if (IS_ERR(counter))
  			return ERR_CAST(counter);

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-11-08  1:25 Stephen Rothwell
@ 2016-11-08  6:34 ` Cong Wang
  0 siblings, 0 replies; 325+ messages in thread
From: Cong Wang @ 2016-11-08  6:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, linux-next, LKML, Johannes Berg

On Mon, Nov 7, 2016 at 5:25 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/netlink/genetlink.c
>
> between commit:
>
>   00ffc1ba02d8 ("genetlink: fix a memory leak on error path")
>
> from the net tree and commit:
>
>   2ae0f17df1cd ("genetlink: use idr to track families")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good to me.

Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-11-08  1:25 Stephen Rothwell
  2016-11-08  6:34 ` Cong Wang
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-11-08  1:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, WANG Cong, Johannes Berg

Hi all,

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

  net/netlink/genetlink.c

between commit:

  00ffc1ba02d8 ("genetlink: fix a memory leak on error path")

from the net tree and commit:

  2ae0f17df1cd ("genetlink: use idr to track families")

from the net-next 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 net/netlink/genetlink.c
index 49c28e8ef01b,bbd3bff885a1..000000000000
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@@ -402,11 -360,17 +360,17 @@@ int genl_register_family(struct genl_fa
  	} else
  		family->attrbuf = NULL;
  
+ 	family->id = idr_alloc(&genl_fam_idr, family,
+ 			       start, end + 1, GFP_KERNEL);
+ 	if (family->id < 0) {
+ 		err = family->id;
 -		goto errout_locked;
++		goto errout_free;
+ 	}
+ 
  	err = genl_validate_assign_mc_groups(family);
  	if (err)
- 		goto errout_free;
+ 		goto errout_remove;
  
- 	list_add_tail(&family->family_list, genl_family_chain(family->id));
  	genl_unlock_all();
  
  	/* send all events */
@@@ -417,14 -381,13 +381,15 @@@
  
  	return 0;
  
+ errout_remove:
+ 	idr_remove(&genl_fam_idr, family->id);
 +errout_free:
 +	kfree(family->attrbuf);
  errout_locked:
  	genl_unlock_all();
- errout:
  	return err;
  }
- EXPORT_SYMBOL(__genl_register_family);
+ EXPORT_SYMBOL(genl_register_family);
  
  /**
   * genl_unregister_family - unregister generic netlink family

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-10-23 23:34 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-10-23 23:34 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Eric Dumazet, Paolo Abeni

Hi all,

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

  include/net/udp.h

between commit:

  286c72deabaa ("udp: must lock the socket in udp_disconnect()")

from the net tree and commit:

  f970bd9e3a06 ("udp: implement memory accounting helpers")

from the net-next 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/net/udp.h
index 4948790d393d,18f1e6b91927..000000000000
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@@ -258,7 -261,7 +261,8 @@@ void udp_flush_pending_frames(struct so
  void udp4_hwcsum(struct sk_buff *skb, __be32 src, __be32 dst);
  int udp_rcv(struct sk_buff *skb);
  int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ int udp_init_sock(struct sock *sk);
 +int __udp_disconnect(struct sock *sk, int flags);
  int udp_disconnect(struct sock *sk, int flags);
  unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait);
  struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-10-20 23:40 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-10-20 23:40 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Jarod Wilson, Thomas Falcon

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  87737f8810db ("ibmvnic: Update MTU after device initialization")

from the net tree and commit:

  d894be57ca92 ("ethernet: use net core MTU range checking in more drivers")

from the net-next 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/ibm/ibmvnic.c
index 213162df1a9b,657206be7ba9..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -3654,7 -3644,8 +3644,9 @@@ static void handle_crq_init_rsp(struct 
  		goto task_failed;
  
  	netdev->real_num_tx_queues = adapter->req_tx_queues;
 +	netdev->mtu = adapter->req_mtu;
+ 	netdev->min_mtu = adapter->min_mtu;
+ 	netdev->max_mtu = adapter->max_mtu;
  
  	if (adapter->failover) {
  		adapter->failover = false;

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-10-20  0:01 Stephen Rothwell
@ 2016-10-20  6:37 ` Ido Schimmel
  0 siblings, 0 replies; 325+ messages in thread
From: Ido Schimmel @ 2016-10-20  6:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, linux-next, linux-kernel, Ido Schimmel,
	David Ahern

On Thu, Oct 20, 2016 at 11:01:42AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   include/linux/netdevice.h
>   net/core/dev.c
> 
> between commit:
> 
>   e4961b076885 ("net: core: Correctly iterate over lower adjacency list")
> 
> from the net tree and commit:
> 
>   1a3f060c1a47 ("net: Introduce new api for walking upper and lower devices")
>   f1170fd462c6 ("net: Remove all_adj_list and its references")
> 
> from the net-next tree.
> 
> I fixed it up (I just used the net-next tree version) and can carry the
> fix as necessary.

Yes, net-next is correct. Thanks Stephen!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-10-20  0:01 Stephen Rothwell
  2016-10-20  6:37 ` Ido Schimmel
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-10-20  0:01 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Ido Schimmel, David Ahern

Hi all,

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

  include/linux/netdevice.h
  net/core/dev.c

between commit:

  e4961b076885 ("net: core: Correctly iterate over lower adjacency list")

from the net tree and commit:

  1a3f060c1a47 ("net: Introduce new api for walking upper and lower devices")
  f1170fd462c6 ("net: Remove all_adj_list and its references")

from the net-next tree.

I fixed it up (I just used the net-next tree 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-09-12  0:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-09-12  0:49 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Jean Delvare, Andrew Lunn

Hi all,

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

  drivers/net/phy/Kconfig

between commit:

  c2f57fb97da5 ("drivers: net: phy: mdio-xgene: Add hardware dependency")

from the net tree and commit:

  d75b4a22b255 ("net: phy: Sort Makefile and Kconfig")

from the net-next 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.

These "sort the Kconfig/Makefile" patches are much better done just
before or after -rc1 so that the conflicting changes are already merged
and new development can be based on top of them.
-- 
Cheers,
Stephen Rothwell

138c337cf0c2436790877f87e91154b3c3294346
diff --cc drivers/net/phy/Kconfig
index b4863e4e522b,87b566f54cc1..2651c8d8de2f
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@@ -15,88 -15,156 +15,157 @@@ if PHYLI
  config SWPHY
  	bool
  
- comment "MII PHY device drivers"
- 
- config AQUANTIA_PHY
-         tristate "Drivers for the Aquantia PHYs"
-         ---help---
-           Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
+ comment "MDIO bus device drivers"
  
- config AT803X_PHY
- 	tristate "Drivers for Atheros AT803X PHYs"
- 	---help---
- 	  Currently supports the AT8030 and AT8035 model
+ config MDIO_BCM_IPROC
+ 	tristate "Broadcom iProc MDIO bus controller"
+ 	depends on ARCH_BCM_IPROC || COMPILE_TEST
+ 	depends on HAS_IOMEM && OF_MDIO
+ 	help
+ 	  This module provides a driver for the MDIO busses found in the
+ 	  Broadcom iProc SoC's.
  
- config AMD_PHY
- 	tristate "Drivers for the AMD PHYs"
- 	---help---
- 	  Currently supports the am79c874
+ config MDIO_BCM_UNIMAC
+ 	tristate "Broadcom UniMAC MDIO bus controller"
+ 	depends on HAS_IOMEM
+ 	help
+ 	  This module provides a driver for the Broadcom UniMAC MDIO busses.
+ 	  This hardware can be found in the Broadcom GENET Ethernet MAC
+ 	  controllers as well as some Broadcom Ethernet switches such as the
+ 	  Starfighter 2 switches.
  
- config MARVELL_PHY
- 	tristate "Drivers for Marvell PHYs"
- 	---help---
- 	  Currently has a driver for the 88E1011S
- 	
- config DAVICOM_PHY
- 	tristate "Drivers for Davicom PHYs"
- 	---help---
- 	  Currently supports dm9161e and dm9131
+ config MDIO_BITBANG
+ 	tristate "Bitbanged MDIO buses"
+ 	help
+ 	  This module implements the MDIO bus protocol in software,
+ 	  for use by low level drivers that export the ability to
+ 	  drive the relevant pins.
  
- config QSEMI_PHY
- 	tristate "Drivers for Quality Semiconductor PHYs"
- 	---help---
- 	  Currently supports the qs6612
+ 	  If in doubt, say N.
  
- config LXT_PHY
- 	tristate "Drivers for the Intel LXT PHYs"
- 	---help---
- 	  Currently supports the lxt970, lxt971
+ config MDIO_BUS_MUX
+ 	tristate
+ 	depends on OF_MDIO
+ 	help
+ 	  This module provides a driver framework for MDIO bus
+ 	  multiplexers which connect one of several child MDIO busses
+ 	  to a parent bus.  Switching between child busses is done by
+ 	  device specific drivers.
  
- config CICADA_PHY
- 	tristate "Drivers for the Cicada PHYs"
- 	---help---
- 	  Currently supports the cis8204
+ config MDIO_BUS_MUX_BCM_IPROC
+ 	tristate "Broadcom iProc based MDIO bus multiplexers"
+ 	depends on OF && OF_MDIO && (ARCH_BCM_IPROC || COMPILE_TEST)
+ 	select MDIO_BUS_MUX
+ 	default ARCH_BCM_IPROC
+ 	help
+ 	  This module provides a driver for MDIO bus multiplexers found in
+ 	  iProc based Broadcom SoCs. This multiplexer connects one of several
+ 	  child MDIO bus to a parent bus. Buses could be internal as well as
+ 	  external and selection logic lies inside the same multiplexer.
  
- config VITESSE_PHY
-         tristate "Drivers for the Vitesse PHYs"
-         ---help---
-           Currently supports the vsc8244
+ config MDIO_BUS_MUX_GPIO
+ 	tristate "GPIO controlled MDIO bus multiplexers"
+ 	depends on OF_GPIO && OF_MDIO
+ 	select MDIO_BUS_MUX
+ 	help
+ 	  This module provides a driver for MDIO bus multiplexers that
+ 	  are controlled via GPIO lines.  The multiplexer connects one of
+ 	  several child MDIO busses to a parent bus.  Child bus
+ 	  selection is under the control of GPIO lines.
  
- config TERANETICS_PHY
-         tristate "Drivers for the Teranetics PHYs"
-         ---help---
-           Currently supports the Teranetics TN2020
+ config MDIO_BUS_MUX_MMIOREG
+ 	tristate "MMIO device-controlled MDIO bus multiplexers"
+ 	depends on OF_MDIO && HAS_IOMEM
+ 	select MDIO_BUS_MUX
+ 	help
+ 	  This module provides a driver for MDIO bus multiplexers that
+ 	  are controlled via a simple memory-mapped device, like an FPGA.
+ 	  The multiplexer connects one of several child MDIO busses to a
+ 	  parent bus.  Child bus selection is under the control of one of
+ 	  the FPGA's registers.
  
- config SMSC_PHY
- 	tristate "Drivers for SMSC PHYs"
- 	---help---
- 	  Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
+ 	  Currently, only 8-bit registers are supported.
  
- config BCM_NET_PHYLIB
+ config MDIO_CAVIUM
  	tristate
  
- config BROADCOM_PHY
- 	tristate "Drivers for Broadcom PHYs"
- 	select BCM_NET_PHYLIB
+ config MDIO_GPIO
+ 	tristate "GPIO lib-based bitbanged MDIO buses"
+ 	depends on MDIO_BITBANG && GPIOLIB
  	---help---
- 	  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- 	  BCM5481 and BCM5482 PHYs.
+ 	  Supports GPIO lib-based MDIO busses.
  
- config BCM_CYGNUS_PHY
- 	tristate "Drivers for Broadcom Cygnus SoC internal PHY"
- 	depends on ARCH_BCM_CYGNUS || COMPILE_TEST
- 	depends on MDIO_BCM_IPROC
- 	select BCM_NET_PHYLIB
+ 	  To compile this driver as a module, choose M here: the module
+ 	  will be called mdio-gpio.
+ 
+ config MDIO_HISI_FEMAC
+ 	tristate "Hisilicon FEMAC MDIO bus controller"
+ 	depends on HAS_IOMEM && OF_MDIO
+ 	help
+ 	  This module provides a driver for the MDIO busses found in the
+ 	  Hisilicon SoC that have an Fast Ethernet MAC.
+ 
+ config MDIO_MOXART
+         tristate "MOXA ART MDIO interface support"
+         depends on ARCH_MOXART
+         help
+           This driver supports the MDIO interface found in the network
+           interface units of the MOXA ART SoC
+ 
+ config MDIO_OCTEON
+ 	tristate "Octeon and some ThunderX SOCs MDIO buses"
+ 	depends on 64BIT
+ 	depends on HAS_IOMEM
+ 	select MDIO_CAVIUM
+ 	help
+ 	  This module provides a driver for the Octeon and ThunderX MDIO
+ 	  buses. It is required by the Octeon and ThunderX ethernet device
+ 	  drivers on some systems.
+ 
+ config MDIO_SUN4I
+ 	tristate "Allwinner sun4i MDIO interface support"
+ 	depends on ARCH_SUNXI
+ 	help
+ 	  This driver supports the MDIO interface found in the network
+ 	  interface units of the Allwinner SoC that have an EMAC (A10,
+ 	  A12, A10s, etc.)
+ 
+ config MDIO_THUNDER
+ 	tristate "ThunderX SOCs MDIO buses"
+ 	depends on 64BIT
+ 	depends on PCI
+ 	select MDIO_CAVIUM
+ 	help
+ 	  This driver supports the MDIO interfaces found on Cavium
+ 	  ThunderX SoCs when the MDIO bus device appears as a PCI
+ 	  device.
+ 
+ config MDIO_XGENE
+ 	tristate "APM X-Gene SoC MDIO bus controller"
++	depends on ARCH_XGENE || COMPILE_TEST
+ 	help
+ 	  This module provides a driver for the MDIO busses found in the
+ 	  APM X-Gene SoC's.
+ 
+ comment "MII PHY device drivers"
+ 
+ config AMD_PHY
+ 	tristate "AMD PHYs"
  	---help---
- 	  This PHY driver is for the 1G internal PHYs of the Broadcom
- 	  Cygnus Family SoC.
+ 	  Currently supports the am79c874
  
- 	  Currently supports internal PHY's used in the BCM11300,
- 	  BCM11320, BCM11350, BCM11360, BCM58300, BCM58302,
- 	  BCM58303 & BCM58305 Broadcom Cygnus SoCs.
+ config AQUANTIA_PHY
+         tristate "Aquantia PHYs"
+         ---help---
+           Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
+ 
+ config AT803X_PHY
+ 	tristate "AT803X PHYs"
+ 	---help---
+ 	  Currently supports the AT8030 and AT8035 model
  
  config BCM63XX_PHY
- 	tristate "Drivers for Broadcom 63xx SOCs internal PHY"
+ 	tristate "Broadcom 63xx SOCs internal PHY"
  	depends on BCM63XX
  	select BCM_NET_PHYLIB
  	---help---

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-09-07  3:16 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-09-07  3:16 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Joe Perches, Wu Fengguang

Hi all,

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

  drivers/net/ethernet/qlogic/qed/qed_dcbx.c

between commit:

  561ed23331df ("qed: fix kzalloc-simple.cocci warnings")

from the net tree and commit:

  2591c280c375 ("qed: Remove OOM messages")

from the net-next 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/qlogic/qed/qed_dcbx.c
index 3656d2fd673d,be7b3dc7c9a7..000000000000
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@@ -1189,11 -1172,9 +1186,9 @@@ int qed_dcbx_get_config_params(struct q
  		return 0;
  	}
  
 -	dcbx_info = kmalloc(sizeof(*dcbx_info), GFP_KERNEL);
 +	dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
- 	if (!dcbx_info) {
- 		DP_ERR(p_hwfn, "Failed to allocate struct qed_dcbx_info\n");
+ 	if (!dcbx_info)
  		return -ENOMEM;
- 	}
  
  	rc = qed_dcbx_query_params(p_hwfn, dcbx_info, QED_DCBX_OPERATIONAL_MIB);
  	if (rc) {
@@@ -1226,11 -1207,9 +1221,9 @@@ static struct qed_dcbx_get *qed_dcbnl_g
  {
  	struct qed_dcbx_get *dcbx_info;
  
 -	dcbx_info = kmalloc(sizeof(*dcbx_info), GFP_KERNEL);
 +	dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
- 	if (!dcbx_info) {
- 		DP_ERR(hwfn->cdev, "Failed to allocate memory for dcbx_info\n");
+ 	if (!dcbx_info)
  		return NULL;
- 	}
  
  	if (qed_dcbx_query_params(hwfn, dcbx_info, type)) {
  		kfree(dcbx_info);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-09-05  3:10 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-09-05  3:10 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Sean Wang, Nelson Chang, Wei Yongjun

Hi all,

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

  drivers/net/ethernet/mediatek/mtk_eth_soc.c

between commits:

  d3bd1ce4db8e ("net: ethernet: mediatek: remove redundant free_irq for devm_request_irq allocated irq")
  7c6b0d76fa02 ("net: ethernet: mediatek: fix logic unbalance between probe and remove")

from the net tree and commits:

  45d339309f49 ("net: mediatek: remove unnecessary platform_set_drvdata()")
  bacfd110e059 ("net: ethernet: mediatek: modify to use the PDMA instead of the QDMA for Ethernet RX")

from the net-next 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/mediatek/mtk_eth_soc.c
index d9199151a83e,2dadfa961898..000000000000
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@@ -334,9 -338,12 +334,10 @@@ static void mtk_mdio_cleanup(struct mtk
  		return;
  
  	mdiobus_unregister(eth->mii_bus);
 -	of_node_put(eth->mii_bus->dev.of_node);
 -	mdiobus_free(eth->mii_bus);
  }
  
- static inline void mtk_irq_disable(struct mtk_eth *eth, u32 mask)
+ static inline void mtk_irq_disable(struct mtk_eth *eth,
+ 				   unsigned reg, u32 mask)
  {
  	unsigned long flags;
  	u32 val;
@@@ -1501,7 -1513,11 +1508,8 @@@ static void mtk_uninit(struct net_devic
  	struct mtk_eth *eth = mac->hw;
  
  	phy_disconnect(mac->phy_dev);
- 	mtk_irq_disable(eth, ~0);
 -	mtk_mdio_cleanup(eth);
+ 	mtk_irq_disable(eth, MTK_QDMA_INT_MASK, ~0);
+ 	mtk_irq_disable(eth, MTK_PDMA_INT_MASK, ~0);
 -	free_irq(eth->irq[1], dev);
 -	free_irq(eth->irq[2], dev);
  }
  
  static int mtk_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@@ -1913,8 -1920,6 +1921,7 @@@ static int mtk_remove(struct platform_d
  	netif_napi_del(&eth->tx_napi);
  	netif_napi_del(&eth->rx_napi);
  	mtk_cleanup(eth);
 +	mtk_mdio_cleanup(eth);
- 	platform_set_drvdata(pdev, NULL);
  
  	return 0;
  }

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-08-22  1:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-08-22  1:51 UTC (permalink / raw)
  To: David Miller, Networking; +Cc: linux-next, linux-kernel, Hariprasad Shenai

Hi all,

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

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

between commit:

  e0d8b2908696 ("cxgb4: Fixes resource allocation for ULD's in kdump kernel")

from the net tree and commit:

  94cdb8bb993a ("cxgb4: Add support for dynamic allocation of resources for ULD")

from the net-next tree.

I fixed it up (I just used the version form the net-next tree) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-08-17  1:05 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-08-17  1:05 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Arnd Bergmann, Vivien Didelot

Hi all,

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

  drivers/net/dsa/mv88e6xxx/chip.c

between commit:

  601bbae0bc10 ("dsa: mv88e6xxx: hide unused functions")

from the net tree and commit:

  9c93829c014f ("net: dsa: mv88e6xxx: use the new PHY API")

from the net-next 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/dsa/mv88e6xxx/chip.c
index d1d9d3cf9139,a230fcba5b64..000000000000
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@@ -3187,48 -3250,13 +3250,20 @@@ static int mv88e6xxx_set_addr(struct ds
  	return err;
  }
  
- #ifdef CONFIG_NET_DSA_HWMON
- static int mv88e6xxx_mdio_page_read(struct dsa_switch *ds, int port, int page,
- 				    int reg)
- {
- 	struct mv88e6xxx_chip *chip = ds_to_priv(ds);
- 	int ret;
- 
- 	mutex_lock(&chip->reg_lock);
- 	ret = _mv88e6xxx_mdio_page_read(chip, port, page, reg);
- 	mutex_unlock(&chip->reg_lock);
- 
- 	return ret;
- }
- 
- static int mv88e6xxx_mdio_page_write(struct dsa_switch *ds, int port, int page,
- 				     int reg, int val)
- {
- 	struct mv88e6xxx_chip *chip = ds_to_priv(ds);
- 	int ret;
- 
- 	mutex_lock(&chip->reg_lock);
- 	ret = _mv88e6xxx_mdio_page_write(chip, port, page, reg, val);
- 	mutex_unlock(&chip->reg_lock);
- 
- 	return ret;
- }
- #endif
- 
 +static int mv88e6xxx_port_to_mdio_addr(struct mv88e6xxx_chip *chip, int port)
 +{
 +	if (port >= 0 && port < chip->info->num_ports)
 +		return port;
 +	return -EINVAL;
 +}
 +
- static int mv88e6xxx_mdio_read(struct mii_bus *bus, int port, int regnum)
+ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
  {
  	struct mv88e6xxx_chip *chip = bus->priv;
- 	int addr = mv88e6xxx_port_to_mdio_addr(chip, port);
- 	int ret;
+ 	u16 val;
+ 	int err;
  
- 	if (addr < 0)
+ 	if (phy >= chip->info->num_ports)
  		return 0xffff;
  
  	mutex_lock(&chip->reg_lock);

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-08-15  0:35 Stephen Rothwell
@ 2016-08-15  7:51 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2016-08-15  7:51 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: linux-next, linux-kernel, Sargun Dhillon

On 08/15/2016 02:35 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    kernel/bpf/verifier.c
>
> between commit:
>
>    747ea55e4f78 ("bpf: fix bpf_skb_in_cgroup helper naming")
>
> from the net tree and commit:
>
>    60d20f9195b2 ("bpf: Add bpf_current_task_under_cgroup helper")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary.

Looks good to me, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-08-15  0:35 Stephen Rothwell
  2016-08-15  7:51 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-08-15  0:35 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: linux-next, linux-kernel, Daniel Borkmann, Sargun Dhillon

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  747ea55e4f78 ("bpf: fix bpf_skb_in_cgroup helper naming")

from the net tree and commit:

  60d20f9195b2 ("bpf: Add bpf_current_task_under_cgroup helper")

from the net-next 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 kernel/bpf/verifier.c
index daea765d72e6,0cc46f1df358..000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -1053,7 -1078,8 +1078,8 @@@ static int check_map_func_compatibility
  			goto error;
  		break;
  	case BPF_MAP_TYPE_CGROUP_ARRAY:
- 		if (func_id != BPF_FUNC_skb_under_cgroup)
 -		if (func_id != BPF_FUNC_skb_in_cgroup &&
++		if (func_id != BPF_FUNC_skb_under_cgroup &&
+ 		    func_id != BPF_FUNC_current_task_under_cgroup)
  			goto error;
  		break;
  	default:
@@@ -1075,7 -1101,8 +1101,8 @@@
  		if (map->map_type != BPF_MAP_TYPE_STACK_TRACE)
  			goto error;
  		break;
+ 	case BPF_FUNC_current_task_under_cgroup:
 -	case BPF_FUNC_skb_in_cgroup:
 +	case BPF_FUNC_skb_under_cgroup:
  		if (map->map_type != BPF_MAP_TYPE_CGROUP_ARRAY)
  			goto error;
  		break;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-21  1:41 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-21  1:41 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eugenia Emantayev, Tariq Toukan,
	Brenden Blanco

Hi all,

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

  drivers/net/ethernet/mellanox/mlx4/en_ethtool.c

between commit:

  ec25bc04ed8e ("net/mlx4_en: Add resilience in low memory systems")

from the net tree and commit:

  9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")

from the net-next 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/mlx4/en_ethtool.c
index 44cf16d01f42,f32e272c83dd..000000000000
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@@ -1730,28 -1722,32 +1729,35 @@@ static int mlx4_en_set_channels(struct 
  	    !channel->tx_count || !channel->rx_count)
  		return -EINVAL;
  
+ 	if (channel->tx_count * MLX4_EN_NUM_UP <= priv->xdp_ring_num) {
+ 		en_err(priv, "Minimum %d tx channels required with XDP on\n",
+ 		       priv->xdp_ring_num / MLX4_EN_NUM_UP + 1);
+ 		return -EINVAL;
+ 	}
+ 
 +	tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
 +	if (!tmp)
 +		return -ENOMEM;
 +
  	mutex_lock(&mdev->state_lock);
 +	memcpy(&new_prof, priv->prof, sizeof(struct mlx4_en_port_profile));
 +	new_prof.num_tx_rings_p_up = channel->tx_count;
 +	new_prof.tx_ring_num = channel->tx_count * MLX4_EN_NUM_UP;
 +	new_prof.rx_ring_num = channel->rx_count;
 +
 +	err = mlx4_en_try_alloc_resources(priv, tmp, &new_prof);
 +	if (err)
 +		goto out;
 +
  	if (priv->port_up) {
  		port_up = 1;
  		mlx4_en_stop_port(dev, 1);
  	}
  
 -	mlx4_en_free_resources(priv);
 -
 -	priv->num_tx_rings_p_up = channel->tx_count;
 -	priv->tx_ring_num = channel->tx_count * MLX4_EN_NUM_UP;
 -	priv->rx_ring_num = channel->rx_count;
 -
 -	err = mlx4_en_alloc_resources(priv);
 -	if (err) {
 -		en_err(priv, "Failed reallocating port resources\n");
 -		goto out;
 -	}
 +	mlx4_en_safe_replace_resources(priv, tmp);
  
- 	netif_set_real_num_tx_queues(dev, priv->tx_ring_num);
+ 	netif_set_real_num_tx_queues(dev, priv->tx_ring_num -
+ 							priv->xdp_ring_num);
  	netif_set_real_num_rx_queues(dev, priv->rx_ring_num);
  
  	if (dev->num_tc)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-20  2:10 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-20  2:10 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Willem de Bruijn, Marcelo Ricardo Leitner

Hi all,

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

  net/sctp/input.c

between commit:

  c74bfbdba0e8 ("sctp: load transport header after sk_filter")

from the net tree and commit:

  3acb50c18d8d ("sctp: delay as much as possible skb_linearize")

from the net-next tree.

I fixed it up (I just used the net-next 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-20  2:05 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-20  2:05 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Konstantin Khlebnikov, Eric Dumazet

Hi all,

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

  net/sched/sch_htb.c

between commit:

  338ed9b4de57 ("net_sched: sch_htb: export class backlog in dumps")

from the net tree and commit:

  0564bf0afae4 ("net/sched/sch_htb: clamp xstats tokens to fit into 32-bit int")

from the net-next 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 net/sched/sch_htb.c
index 052f84d6cc23,91982d9784b3..000000000000
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@@ -1136,18 -1113,22 +1113,24 @@@ static in
  htb_dump_class_stats(struct Qdisc *sch, unsigned long arg, struct gnet_dump *d)
  {
  	struct htb_class *cl = (struct htb_class *)arg;
+ 	struct gnet_stats_queue qs = {
+ 		.drops = cl->drops,
+ 	};
  	__u32 qlen = 0;
  
- 	if (!cl->level && cl->un.leaf.q)
+ 	if (!cl->level && cl->un.leaf.q) {
  		qlen = cl->un.leaf.q->q.qlen;
+ 		qs.backlog = cl->un.leaf.q->qstats.backlog;
+ 	}
 -	cl->xstats.tokens = PSCHED_NS2TICKS(cl->tokens);
 -	cl->xstats.ctokens = PSCHED_NS2TICKS(cl->ctokens);
 +	cl->xstats.tokens = clamp_t(s64, PSCHED_NS2TICKS(cl->tokens),
 +				    INT_MIN, INT_MAX);
 +	cl->xstats.ctokens = clamp_t(s64, PSCHED_NS2TICKS(cl->ctokens),
 +				     INT_MIN, INT_MAX);
  
- 	if (gnet_stats_copy_basic(d, NULL, &cl->bstats) < 0 ||
+ 	if (gnet_stats_copy_basic(qdisc_root_sleeping_running(sch),
+ 				  d, NULL, &cl->bstats) < 0 ||
  	    gnet_stats_copy_rate_est(d, NULL, &cl->rate_est) < 0 ||
- 	    gnet_stats_copy_queue(d, NULL, &cl->qstats, qlen) < 0)
+ 	    gnet_stats_copy_queue(d, NULL, &qs, qlen) < 0)
  		return -1;
  
  	return gnet_stats_copy_app(d, &cl->xstats, sizeof(cl->xstats));

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-18  1:59 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-18  1:59 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Kiran Patil, Jeff Kirsher, Mitch Williams

Hi all,

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

  drivers/net/ethernet/intel/i40e/i40e_main.c

between commit:

  f6bd09625ba6 ("i40e: enable VSI broadcast promiscuous mode instead of adding broadcast filter")

from the net tree and commit:

  3e25a8f31af1 ("i40e: add hw struct local variable")

from the net-next 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/intel/i40e/i40e_main.c
index eb09f60b4984,2b1140563a64..000000000000
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@@ -2152,12 -2165,27 +2172,15 @@@ int i40e_sync_vsi_filters(struct i40e_v
  			if (aq_ret) {
  				retval =
  				i40e_aq_rc_to_posix(aq_ret,
- 						    pf->hw.aq.asq_last_status);
+ 						    hw->aq.asq_last_status);
  				dev_info(&pf->pdev->dev,
- 					 "set multicast promisc failed, err %d, aq_err %d\n",
- 					 aq_ret, pf->hw.aq.asq_last_status);
+ 					 "set multicast promisc failed on %s, err %s, aq_err %s\n",
+ 					 vsi_name,
+ 					 i40e_stat_str(hw, aq_ret),
+ 					 i40e_aq_str(hw,
+ 						     hw->aq.asq_last_status));
  			}
  		}
 -		aq_ret = i40e_aq_set_vsi_broadcast(&vsi->back->hw,
 -						   vsi->seid,
 -						   cur_promisc, NULL);
 -		if (aq_ret) {
 -			retval = i40e_aq_rc_to_posix(aq_ret,
 -						     pf->hw.aq.asq_last_status);
 -			dev_info(&pf->pdev->dev,
 -				 "set brdcast promisc failed, err %s, aq_err %s\n",
 -					 i40e_stat_str(hw, aq_ret),
 -					 i40e_aq_str(hw,
 -						     hw->aq.asq_last_status));
 -		}
  	}
  out:
  	/* if something went wrong then set the changed flag so we try again */

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-18  1:52 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-18  1:52 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Florian Fainelli, Raghu Vatsavayi,
	Derek Chickles, Satanand Burla, Felix Manlunas

Hi all,

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

  drivers/net/ethernet/cavium/liquidio/lio_main.c

between commit:

  8e6ce7ebeb34 ("net: cavium: liquidio: Avoid dma_unmap_single on uninitialized ndata")

from the net tree and commit:

  6a885b60dad2 ("liquidio: Introduce new octeon2/3 header")

from the net-next tree.

I am not sure how to fix this up, so I effectively reverted the net
tree commit.  Please let me know if something else should be done.

I fixed it up (see above) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-06  1:32 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-06  1:32 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, hayeswang

Hi all,

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

  drivers/net/usb/r8152.c

between commit:

  2609af19362d ("r8152: fix runtime function for RTL8152")

from the net tree and commit:

  a028a9e003f2 ("r8152: move the settings of PHY to a work queue")

from the net-next 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/usb/r8152.c
index 0da72d39b4f9,24d367280ecf..000000000000
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -624,7 -624,7 +624,8 @@@ struct r8152 
  		int (*eee_get)(struct r8152 *, struct ethtool_eee *);
  		int (*eee_set)(struct r8152 *, struct ethtool_eee *);
  		bool (*in_nway)(struct r8152 *);
 +		void (*autosuspend_en)(struct r8152 *tp, bool enable);
+ 		void (*hw_phy_cfg)(struct r8152 *);
  	} rtl_ops;
  
  	int intr_interval;
@@@ -4156,7 -4157,7 +4176,8 @@@ static int rtl_ops_init(struct r8152 *t
  		ops->eee_get		= r8152_get_eee;
  		ops->eee_set		= r8152_set_eee;
  		ops->in_nway		= rtl8152_in_nway;
 +		ops->autosuspend_en	= rtl_runtime_suspend_enable;
+ 		ops->hw_phy_cfg		= r8152b_hw_phy_cfg;
  		break;
  
  	case RTL_VER_03:
@@@ -4172,7 -4173,7 +4193,8 @@@
  		ops->eee_get		= r8153_get_eee;
  		ops->eee_set		= r8153_set_eee;
  		ops->in_nway		= rtl8153_in_nway;
 +		ops->autosuspend_en	= rtl8153_runtime_enable;
+ 		ops->hw_phy_cfg		= r8153_hw_phy_cfg;
  		break;
  
  	default:

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-07-04  3:07 Stephen Rothwell
@ 2016-07-04 11:34 ` Saeed Mahameed
  0 siblings, 0 replies; 325+ messages in thread
From: Saeed Mahameed @ 2016-07-04 11:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Linux Netdev List, linux-next, linux-kernel,
	Daniel Jurgens, Saeed Mahameed, Yevgeny Petrilin

On Mon, Jul 4, 2016 at 6:07 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>
> between commit:
>
>   29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")
>
> from the net tree and commit:
>
>   507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")
>
> from the net-next 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/en_main.c
> index 7a0dca29c642,96ec53a6a595..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -39,16 -39,10 +39,17 @@@
>   #include "eswitch.h"
>   #include "vxlan.h"
>
>  +enum {
>  +      MLX5_EN_QP_FLUSH_TIMEOUT_MS     = 5000,
>  +      MLX5_EN_QP_FLUSH_MSLEEP_QUANT   = 20,
>  +      MLX5_EN_QP_FLUSH_MAX_ITER       = MLX5_EN_QP_FLUSH_TIMEOUT_MS /
>  +                                        MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
>  +};
>  +
>   struct mlx5e_rq_param {
> -       u32                        rqc[MLX5_ST_SZ_DW(rqc)];
> -       struct mlx5_wq_param       wq;
> +       u32                     rqc[MLX5_ST_SZ_DW(rqc)];
> +       struct mlx5_wq_param    wq;
> +       bool                    am_enabled;
>   };
>
>   struct mlx5e_sq_param {
> @@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
>         /* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
>         napi_synchronize(&rq->channel->napi);
>
> +       cancel_work_sync(&rq->am.work);
> +
>         mlx5e_disable_rq(rq);
>  +      mlx5e_free_rx_descs(rq);
>         mlx5e_destroy_rq(rq);
>   }
>
> @@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
>                 if (mlx5e_sq_has_room_for(sq, 1))
>                         mlx5e_send_nop(sq, true);
>
>  -              mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
>  -                              false, 0);
>  +              err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
> -                                     MLX5_SQC_STATE_ERR);
> ++                                    MLX5_SQC_STATE_ERR, false, 0);
>  +              if (err)
>  +                      set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state);
>         }


Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-07-04  3:02 Stephen Rothwell
@ 2016-07-04 11:33 ` Saeed Mahameed
  0 siblings, 0 replies; 325+ messages in thread
From: Saeed Mahameed @ 2016-07-04 11:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Linux Netdev List, linux-next, linux-kernel,
	Daniel Jurgens, Gil Rockah, Achiad Shochat, Saeed Mahameed

On Mon, Jul 4, 2016 at 6:02 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/en.h
>
> between commit:
>
>   6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")
>
> from the net tree and commit:
>
>   cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
>
> from the net-next 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/en.h
> index 943b1bd434bf,00643a116492..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe
>         struct mlx5_wqe_data_seg       data;
>   };
>
> + static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
> +       "rx_cqe_moder",
> + };
> +
> + enum mlx5e_priv_flag {
> +       MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
> + };
> +
> + #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)    \
> +       do {                                        \
> +               if (enable)                         \
> +                       priv->pflags |= pflag;      \
> +               else                                \
> +                       priv->pflags &= ~pflag;     \
> +       } while (0)
> +
>   #ifdef CONFIG_MLX5_CORE_EN_DCB
>   #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
>  -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
>   #endif
>
> + struct mlx5e_cq_moder {
> +       u16 usec;
> +       u16 pkts;
> + };
> +
>   struct mlx5e_params {
>         u8  log_sq_size;
>         u8  rq_wq_type;
> @@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp
>   enum {
>         MLX5E_RQ_STATE_POST_WQES_ENABLE,
>         MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
>  +      MLX5E_RQ_STATE_FLUSH_TIMEOUT,
> +       MLX5E_RQ_STATE_AM,
>   };
>

Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-04  3:07 Stephen Rothwell
  2016-07-04 11:34 ` Saeed Mahameed
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-04  3:07 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Daniel Jurgens, Saeed Mahameed,
	Yevgeny Petrilin

Hi all,

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

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

between commit:

  29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")

from the net tree and commit:

  507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")

from the net-next 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/en_main.c
index 7a0dca29c642,96ec53a6a595..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -39,16 -39,10 +39,17 @@@
  #include "eswitch.h"
  #include "vxlan.h"
  
 +enum {
 +	MLX5_EN_QP_FLUSH_TIMEOUT_MS	= 5000,
 +	MLX5_EN_QP_FLUSH_MSLEEP_QUANT	= 20,
 +	MLX5_EN_QP_FLUSH_MAX_ITER	= MLX5_EN_QP_FLUSH_TIMEOUT_MS /
 +					  MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
 +};
 +
  struct mlx5e_rq_param {
- 	u32                        rqc[MLX5_ST_SZ_DW(rqc)];
- 	struct mlx5_wq_param       wq;
+ 	u32			rqc[MLX5_ST_SZ_DW(rqc)];
+ 	struct mlx5_wq_param	wq;
+ 	bool			am_enabled;
  };
  
  struct mlx5e_sq_param {
@@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
  	/* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
  	napi_synchronize(&rq->channel->napi);
  
+ 	cancel_work_sync(&rq->am.work);
+ 
  	mlx5e_disable_rq(rq);
 +	mlx5e_free_rx_descs(rq);
  	mlx5e_destroy_rq(rq);
  }
  
@@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
  		if (mlx5e_sq_has_room_for(sq, 1))
  			mlx5e_send_nop(sq, true);
  
 -		mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
 -				false, 0);
 +		err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
- 				      MLX5_SQC_STATE_ERR);
++				      MLX5_SQC_STATE_ERR, false, 0);
 +		if (err)
 +			set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state);
  	}
  
 -	while (sq->cc != sq->pc) /* wait till sq is empty */
 -		msleep(20);
 +	/* wait till sq is empty, unless a TX timeout occurred on this SQ */
 +	while (sq->cc != sq->pc &&
 +	       !test_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state)) {
 +		msleep(MLX5_EN_QP_FLUSH_MSLEEP_QUANT);
 +		if (tout++ > MLX5_EN_QP_FLUSH_MAX_ITER)
 +			set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state);
 +	}
  
  	/* avoid destroying sq before mlx5e_poll_tx_cq() is done with it */
  	napi_synchronize(&sq->channel->napi);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-07-04  3:02 Stephen Rothwell
  2016-07-04 11:33 ` Saeed Mahameed
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-07-04  3:02 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Daniel Jurgens, Gil Rockah,
	Achiad Shochat, Saeed Mahameed

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en.h

between commit:

  6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")

from the net tree and commit:

  cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")

from the net-next 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/en.h
index 943b1bd434bf,00643a116492..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe 
  	struct mlx5_wqe_data_seg       data;
  };
  
+ static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
+ 	"rx_cqe_moder",
+ };
+ 
+ enum mlx5e_priv_flag {
+ 	MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
+ };
+ 
+ #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)    \
+ 	do {                                        \
+ 		if (enable)                         \
+ 			priv->pflags |= pflag;      \
+ 		else                                \
+ 			priv->pflags &= ~pflag;     \
+ 	} while (0)
+ 
  #ifdef CONFIG_MLX5_CORE_EN_DCB
  #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
 -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
  #endif
  
+ struct mlx5e_cq_moder {
+ 	u16 usec;
+ 	u16 pkts;
+ };
+ 
  struct mlx5e_params {
  	u8  log_sq_size;
  	u8  rq_wq_type;
@@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp 
  enum {
  	MLX5E_RQ_STATE_POST_WQES_ENABLE,
  	MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
 +	MLX5E_RQ_STATE_FLUSH_TIMEOUT,
+ 	MLX5E_RQ_STATE_AM,
  };
  
  struct mlx5e_cq {
@@@ -542,9 -610,9 +614,10 @@@ struct mlx5e_priv 
  	struct workqueue_struct    *wq;
  	struct work_struct         update_carrier_work;
  	struct work_struct         set_rx_mode_work;
 +	struct work_struct         tx_timeout_work;
  	struct delayed_work        update_stats_work;
  
+ 	u32                        pflags;
  	struct mlx5_core_dev      *mdev;
  	struct net_device         *netdev;
  	struct mlx5e_stats         stats;

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-06-27  1:46 Stephen Rothwell
@ 2016-06-27  4:52 ` Eric Dumazet
  0 siblings, 0 replies; 325+ messages in thread
From: Eric Dumazet @ 2016-06-27  4:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Eric Dumazet

On Mon, 2016-06-27 at 11:46 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/sch_netem.c
> 
> between commit:
> 
>   21de12ee5568 ("netem: fix a use after free")
> 
> from the net tree and commit:
> 
>   520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Looks good, although the 'use after free' does not happen anymore on
net-next since we defer skb freeing.

I spotted the bug in stable tree when cooking the net-next patch
actually ;)

Thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-27  1:46 Stephen Rothwell
  2016-06-27  4:52 ` Eric Dumazet
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-27  1:46 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

Hi all,

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

  net/sched/sch_netem.c

between commit:

  21de12ee5568 ("netem: fix a use after free")

from the net tree and commit:

  520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")

from the net-next 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 net/sched/sch_netem.c
index 178f1630a036,ccca8ca4c722..000000000000
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@@ -650,14 -617,17 +617,17 @@@ deliver
  #endif
  
  			if (q->qdisc) {
 +				unsigned int pkt_len = qdisc_pkt_len(skb);
- 				int err = qdisc_enqueue(skb, q->qdisc);
+ 				struct sk_buff *to_free = NULL;
+ 				int err;
  
+ 				err = qdisc_enqueue(skb, q->qdisc, &to_free);
+ 				kfree_skb_list(to_free);
 -				if (unlikely(err != NET_XMIT_SUCCESS)) {
 -					if (net_xmit_drop_count(err)) {
 -						qdisc_qstats_drop(sch);
 -						qdisc_tree_reduce_backlog(sch, 1,
 -									  qdisc_pkt_len(skb));
 -					}
 +				if (err != NET_XMIT_SUCCESS &&
 +				    net_xmit_drop_count(err)) {
 +					qdisc_qstats_drop(sch);
 +					qdisc_tree_reduce_backlog(sch, 1,
 +								  pkt_len);
  				}
  				goto tfifo_dequeue;
  			}

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-24  1:24 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-24  1:24 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Chris Packham, David Ahern

Hi all,

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

  drivers/net/vrf.c

between commit:

  52fe705b493d ("net: vrf: replace hard tab with space in assignment")

from the net tree and commits:

  671cd19ade97 ("net: vrf: ipv4 support for local traffic to local addresses")
  625b47b50732 ("net: vrf: ipv6 support for local traffic to local addresses")

from the net-next 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/vrf.c
index 8bd8c7e1ee87,b3762822b653..000000000000
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@@ -304,8 -437,26 +437,26 @@@ static int vrf_rt6_create(struct net_de
  	dst_hold(&rt6->dst);
  
  	rt6->rt6i_table = rt6i_table;
 -	rt6->dst.output	= vrf_output6;
 +	rt6->dst.output = vrf_output6;
+ 
+ 	/* create a dst for local routing - packets sent locally
+ 	 * to local address via the VRF device as a loopback
+ 	 */
+ 	rt6_local = ip6_dst_alloc(net, dev, flags);
+ 	if (!rt6_local) {
+ 		dst_release(&rt6->dst);
+ 		goto out;
+ 	}
+ 
+ 	dst_hold(&rt6_local->dst);
+ 
+ 	rt6_local->rt6i_idev  = in6_dev_get(dev);
+ 	rt6_local->rt6i_flags = RTF_UP | RTF_NONEXTHOP | RTF_LOCAL;
+ 	rt6_local->rt6i_table = rt6i_table;
+ 	rt6_local->dst.input  = ip6_input;
+ 
  	rcu_assign_pointer(vrf->rt6, rt6);
+ 	rcu_assign_pointer(vrf->rt6_local, rt6_local);
  
  	rc = 0;
  out:
@@@ -403,10 -576,22 +576,22 @@@ static int vrf_rtable_create(struct net
  	if (!rth)
  		return -ENOMEM;
  
+ 	/* create a dst for local ingress routing - packets sent locally
+ 	 * to local address via the VRF device as a loopback
+ 	 */
+ 	rth_local = rt_dst_alloc(dev, RTCF_LOCAL, RTN_LOCAL, 1, 1, 0);
+ 	if (!rth_local) {
+ 		dst_release(&rth->dst);
+ 		return -ENOMEM;
+ 	}
+ 
 -	rth->dst.output	= vrf_output;
 +	rth->dst.output = vrf_output;
  	rth->rt_table_id = vrf->tb_id;
  
+ 	rth_local->rt_table_id = vrf->tb_id;
+ 
  	rcu_assign_pointer(vrf->rth, rth);
+ 	rcu_assign_pointer(vrf->rth_local, rth_local);
  
  	return 0;
  }

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-20  1:28 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-20  1:28 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Sowmini Varadhan

Hi all,

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

  net/rds/tcp_listen.c

between commit:

  3bb549ae4c51 ("RDS: TCP: rds_tcp_accept_one() should transition socket from RESETTING to UP")

from the net tree and commit:

  0cb43965d42a ("RDS: split out connection specific state from rds_connection to rds_conn_path")

from the net-next 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 net/rds/tcp_listen.c
index 245542ca4718,22d9bb15f731..000000000000
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@@ -136,9 -137,10 +137,10 @@@ int rds_tcp_accept_one(struct socket *s
  			goto rst_nsk;
  		} else {
  			rds_tcp_reset_callbacks(new_sock, conn);
- 			conn->c_outgoing = 0;
+ 			conn->c_path[0].cp_outgoing = 0;
  			/* rds_connect_path_complete() marks RDS_CONN_UP */
- 			rds_connect_path_complete(conn, RDS_CONN_RESETTING);
+ 			rds_connect_path_complete(&conn->c_path[0],
 -						  RDS_CONN_DISCONNECTING);
++						  RDS_CONN_RESETTING);
  		}
  	} else {
  		rds_tcp_set_callbacks(new_sock, conn);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-20  1:25 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-20  1:25 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Joshua Houghton, Sowmini Varadhan

Hi all,

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

  net/rds/tcp_connect.c

between commit:

  5c3da57d70f1 ("net: rds: fix coding style issues")

from the net tree and commit:

  0cb43965d42a ("RDS: split out connection specific state from rds_connection to rds_conn_path")

from the net-next 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 net/rds/tcp_connect.c
index f6e95d60db54,ba9ec67f4e41..000000000000
--- a/net/rds/tcp_connect.c
+++ b/net/rds/tcp_connect.c
@@@ -54,19 -55,20 +55,20 @@@ void rds_tcp_state_change(struct sock *
  
  	rdsdebug("sock %p state_change to %d\n", tc->t_sock, sk->sk_state);
  
 -	switch(sk->sk_state) {
 -		/* ignore connecting sockets as they make progress */
 -		case TCP_SYN_SENT:
 -		case TCP_SYN_RECV:
 -			break;
 -		case TCP_ESTABLISHED:
 -			rds_connect_path_complete(&conn->c_path[0],
 -						  RDS_CONN_CONNECTING);
 -			break;
 -		case TCP_CLOSE_WAIT:
 -		case TCP_CLOSE:
 -			rds_conn_drop(conn);
 -		default:
 -			break;
 +	switch (sk->sk_state) {
 +	/* ignore connecting sockets as they make progress */
 +	case TCP_SYN_SENT:
 +	case TCP_SYN_RECV:
 +		break;
 +	case TCP_ESTABLISHED:
- 		rds_connect_path_complete(conn, RDS_CONN_CONNECTING);
++		rds_connect_path_complete(&conn->c_path[0],
++					  RDS_CONN_CONNECTING);
 +		break;
 +	case TCP_CLOSE_WAIT:
 +	case TCP_CLOSE:
 +		rds_conn_drop(conn);
 +	default:
 +		break;
  	}
  out:
  	read_unlock_bh(&sk->sk_callback_lock);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-20  1:20 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-20  1:20 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Yuval Mintz

Hi all,

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

  drivers/net/ethernet/qlogic/qed/qed_hsi.h

between commit:

  b639f197210d ("qed: Add missing port-mode")

from the net tree and commit:

  351a4dedb34c ("qed: Utilize FW 8.10.3.0")

from the net-next tree.

I fixed it up (the net-next tree version is a superset of the net tree
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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-06-08  1:17 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-06-08  1:17 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, WANG Cong, Jamal Hadi Salim

Hi all,

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

  net/sched/act_police.c

between commit:

  53eb440f4ada ("net sched actions: introduce timestamp for firsttime use")

from the net tree and commit:

  a03e6fe56971 ("act_police: fix a crash during removal")

from the net-next tree.

I fixed it up (I think that the firstuse zero initialisation has become
redundant, so I just removed it) 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-05-11 23:56 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-05-11 23:56 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jiri Benc

Hi all,

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

  net/ipv4/ip_gre.c

between commit:

  e271c7b4420d ("gre: do not keep the GRE header around in collect medata mode")

from the net tree and commit:

  244a797bdcf1 ("gre: move iptunnel_pull_header down to ipgre_rcv")

from the net-next tree.

I fixed it up (hopefully - 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 net/ipv4/ip_gre.c
index 4cc84212cce1,2b267e71ebf5..4d1030739efa
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@@ -398,10 -272,11 +272,14 @@@ static int __ipgre_rcv(struct sk_buff *
  				  iph->saddr, iph->daddr, tpi->key);
  
  	if (tunnel) {
+ 		if (__iptunnel_pull_header(skb, hdr_len, tpi->proto,
+ 					   raw_proto, false) < 0)
+ 			goto drop;
+ 
 -		skb_pop_mac_header(skb);
 +		if (tunnel->dev->type != ARPHRD_NONE)
 +			skb_pop_mac_header(skb);
 +		else
 +			skb_reset_mac_header(skb);
  		if (tunnel->collect_md) {
  			__be16 flags;
  			__be64 tun_id;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-05-11  0:11 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-05-11  0:11 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Florian Westphal, Pablo Neira Ayuso

Hi all,

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

  net/netfilter/nf_conntrack_core.c

between commit:

  70d72b7e060e ("netfilter: conntrack: init all_locks to avoid debug warning")

from the net tree and commit:

  a3efd81205b1 ("netfilter: conntrack: move generation seqcnt out of netns_ct")
  56d52d4892d0 ("netfilter: conntrack: use a single hashtable for all namespaces")
  0c5366b3a8c7 ("netfilter: conntrack: use single slab cache")

from the net-next 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 net/netfilter/nf_conntrack_core.c
index 895d11dced3c,566c64e3ec50..000000000000
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@@ -66,7 -69,12 +69,12 @@@ EXPORT_SYMBOL_GPL(nf_conntrack_locks)
  __cacheline_aligned_in_smp DEFINE_SPINLOCK(nf_conntrack_expect_lock);
  EXPORT_SYMBOL_GPL(nf_conntrack_expect_lock);
  
+ struct hlist_nulls_head *nf_conntrack_hash __read_mostly;
+ EXPORT_SYMBOL_GPL(nf_conntrack_hash);
+ 
+ static __read_mostly struct kmem_cache *nf_conntrack_cachep;
 -static __read_mostly spinlock_t nf_conntrack_locks_all_lock;
 +static __read_mostly DEFINE_SPINLOCK(nf_conntrack_locks_all_lock);
+ static __read_mostly seqcount_t nf_conntrack_generation;
  static __read_mostly bool nf_conntrack_locks_all;
  
  void nf_conntrack_lock(spinlock_t *lock) __acquires(lock)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-05-09  0:43 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-05-09  0:43 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Jarno Rajahalme, Tom Herbert

Hi all,

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

  include/linux/netdevice.h

between commit:

  229740c63169 ("udp_offload: Set encapsulation before inner completes.")

from the net tree and commit:

  46aa2f30aa7f ("udp: Remove udp_offloads")

from the net-next tree.

I fixed it up (the latter removed the struct that was commented 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-05-05  0:30 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-05-05  0:30 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Kangjie Lu, Nicolas Dichtel

Hi all,

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

  net/core/rtnetlink.c

between commit:

  5f8e44741f9f ("net: fix infoleak in rtnetlink")

from the net tree and commit:

  270cb4d05b29 ("rtnl: align nlattr properly when needed")

from the net-next 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 net/core/rtnetlink.c
index 65763c29f845,d471f097c739..000000000000
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@@ -1180,17 -1173,15 +1173,17 @@@ static noinline_for_stack int rtnl_fill
  
  static int rtnl_fill_link_ifmap(struct sk_buff *skb, struct net_device *dev)
  {
 -	struct rtnl_link_ifmap map = {
 -		.mem_start   = dev->mem_start,
 -		.mem_end     = dev->mem_end,
 -		.base_addr   = dev->base_addr,
 -		.irq         = dev->irq,
 -		.dma         = dev->dma,
 -		.port        = dev->if_port,
 -	};
 +	struct rtnl_link_ifmap map;
 +
 +	memset(&map, 0, sizeof(map));
 +	map.mem_start   = dev->mem_start;
 +	map.mem_end     = dev->mem_end;
 +	map.base_addr   = dev->base_addr;
 +	map.irq         = dev->irq;
 +	map.dma         = dev->dma;
 +	map.port        = dev->if_port;
 +
- 	if (nla_put(skb, IFLA_MAP, sizeof(map), &map))
+ 	if (nla_put_64bit(skb, IFLA_MAP, sizeof(map), &map, IFLA_PAD))
  		return -EMSGSIZE;
  
  	return 0;

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-04-27  2:01 Stephen Rothwell
@ 2016-04-27 13:13 ` Saeed Mahameed
  0 siblings, 0 replies; 325+ messages in thread
From: Saeed Mahameed @ 2016-04-27 13:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Linux Netdev List, linux-next, linux-kernel,
	Saeed Mahameed, Gal Pressman

On Wed, Apr 27, 2016 at 5:01 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>
> between commit:
>
>   d8edd2469ace ("et/mlx5e: Fix minimum MTU")
>
> from the net tree and commit:
>
>   0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")
>
> from the net-next 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/en_main.c
> index 67d548b70e14,5bad17d37d7b..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -2025,9 -2214,49 +2240,52 @@@ static int set_feature_rx_vlan(struct n
>         return err;
>   }
>
> + static int mlx5e_handle_feature(struct net_device *netdev,
> +                               netdev_features_t wanted_features,
> +                               netdev_features_t feature,
> +                               mlx5e_feature_handler feature_handler)
> + {
> +       netdev_features_t changes = wanted_features ^ netdev->features;
> +       bool enable = !!(wanted_features & feature);
> +       int err;
> +
> +       if (!(changes & feature))
> +               return 0;
> +
> +       err = feature_handler(netdev, enable);
> +       if (err) {
> +               netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
> +                          enable ? "Enable" : "Disable", feature, err);
> +               return err;
> +       }
> +
> +       MLX5E_SET_FEATURE(netdev, feature, enable);
> +       return 0;
> + }
> +
> + static int mlx5e_set_features(struct net_device *netdev,
> +                             netdev_features_t features)
> + {
> +       int err;
> +
> +       err  = mlx5e_handle_feature(netdev, features, NETIF_F_LRO,
> +                                   set_feature_lro);
> +       err |= mlx5e_handle_feature(netdev, features,
> +                                   NETIF_F_HW_VLAN_CTAG_FILTER,
> +                                   set_feature_vlan_filter);
> +       err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_TC,
> +                                   set_feature_tc_num_filters);
> +       err |= mlx5e_handle_feature(netdev, features, NETIF_F_RXALL,
> +                                   set_feature_rx_all);
> +       err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_VLAN_CTAG_RX,
> +                                   set_feature_rx_vlan);
> +
> +       return err ? -EINVAL : 0;
> + }
> +
>  +#define MXL5_HW_MIN_MTU 64
>  +#define MXL5E_MIN_MTU (MXL5_HW_MIN_MTU + ETH_FCS_LEN)
>  +
>   static int mlx5e_change_mtu(struct net_device *netdev, int new_mtu)
>   {
>         struct mlx5e_priv *priv = netdev_priv(netdev);
> @@@ -2633,18 -2966,10 +2997,19 @@@ static void mlx5e_destroy_netdev(struc
>         schedule_work(&priv->set_rx_mode_work);
>         mlx5e_disable_async_events(priv);
>         flush_scheduled_work();
>  -      unregister_netdev(netdev);
>  +      if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) {
>  +              netif_device_detach(netdev);
>  +              mutex_lock(&priv->state_lock);
>  +              if (test_bit(MLX5E_STATE_OPENED, &priv->state))
>  +                      mlx5e_close_locked(netdev);
>  +              mutex_unlock(&priv->state_lock);
>  +      } else {
>  +              unregister_netdev(netdev);
>  +      }
>  +
>         mlx5e_tc_cleanup(priv);
>         mlx5e_vxlan_cleanup(priv);
> +       mlx5e_destroy_q_counter(priv);
>         mlx5e_destroy_flow_tables(priv);
>         mlx5e_destroy_tirs(priv);
>         mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);

Looks good, and it is pretty straightforward.
Dave will have to take all hunks from both patches, same as you did.

Thank you Stephen.

Saeed.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-04-27  2:01 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-04-27  2:01 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nicolas Dichtel, Sabrina Dubroca

Hi all,

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

  drivers/net/macsec.c

between commit:

  748164802c1b ("macsec: add missing macsec prefix in uapi")

from the net tree and commit:

  f60d94c00968 ("macsec: use nla_put_u64_64bit()")

from the net-next 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/macsec.c
index c6385617bfb2,a172a1ffa151..000000000000
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@@ -2231,9 -2271,11 +2276,11 @@@ static int nla_put_secy(struct macsec_s
  	if (!secy_nest)
  		return 1;
  
- 	if (nla_put_sci(skb, MACSEC_SECY_ATTR_SCI, secy->sci) ||
- 	    nla_put_u64(skb, MACSEC_SECY_ATTR_CIPHER_SUITE,
- 			MACSEC_DEFAULT_CIPHER_ID) ||
+ 	if (nla_put_sci(skb, MACSEC_SECY_ATTR_SCI, secy->sci,
+ 			MACSEC_SECY_ATTR_PAD) ||
+ 	    nla_put_u64_64bit(skb, MACSEC_SECY_ATTR_CIPHER_SUITE,
 -			      DEFAULT_CIPHER_ID,
++			      MACSEC_DEFAULT_CIPHER_ID,
+ 			      MACSEC_SECY_ATTR_PAD) ||
  	    nla_put_u8(skb, MACSEC_SECY_ATTR_ICV_LEN, secy->icv_len) ||
  	    nla_put_u8(skb, MACSEC_SECY_ATTR_OPER, secy->operational) ||
  	    nla_put_u8(skb, MACSEC_SECY_ATTR_PROTECT, secy->protect_frames) ||
@@@ -3184,10 -3219,11 +3236,11 @@@ static int macsec_fill_info(struct sk_b
  	struct macsec_secy *secy = &macsec_priv(dev)->secy;
  	struct macsec_tx_sc *tx_sc = &secy->tx_sc;
  
- 	if (nla_put_sci(skb, IFLA_MACSEC_SCI, secy->sci) ||
+ 	if (nla_put_sci(skb, IFLA_MACSEC_SCI, secy->sci,
+ 			IFLA_MACSEC_PAD) ||
  	    nla_put_u8(skb, IFLA_MACSEC_ICV_LEN, secy->icv_len) ||
- 	    nla_put_u64(skb, IFLA_MACSEC_CIPHER_SUITE,
- 			MACSEC_DEFAULT_CIPHER_ID) ||
+ 	    nla_put_u64_64bit(skb, IFLA_MACSEC_CIPHER_SUITE,
 -			      DEFAULT_CIPHER_ID, IFLA_MACSEC_PAD) ||
++			      MACSEC_DEFAULT_CIPHER_ID, IFLA_MACSEC_PAD) ||
  	    nla_put_u8(skb, IFLA_MACSEC_ENCODING_SA, tx_sc->encoding_sa) ||
  	    nla_put_u8(skb, IFLA_MACSEC_ENCRYPT, tx_sc->encrypt) ||
  	    nla_put_u8(skb, IFLA_MACSEC_PROTECT, secy->protect_frames) ||

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-04-27  2:01 Stephen Rothwell
  2016-04-27 13:13 ` Saeed Mahameed
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-04-27  2:01 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Saeed Mahameed, Gal Pressman

Hi all,

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

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

between commit:

  d8edd2469ace ("et/mlx5e: Fix minimum MTU")

from the net tree and commit:

  0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")

from the net-next 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/en_main.c
index 67d548b70e14,5bad17d37d7b..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -2025,9 -2214,49 +2240,52 @@@ static int set_feature_rx_vlan(struct n
  	return err;
  }
  
+ static int mlx5e_handle_feature(struct net_device *netdev,
+ 				netdev_features_t wanted_features,
+ 				netdev_features_t feature,
+ 				mlx5e_feature_handler feature_handler)
+ {
+ 	netdev_features_t changes = wanted_features ^ netdev->features;
+ 	bool enable = !!(wanted_features & feature);
+ 	int err;
+ 
+ 	if (!(changes & feature))
+ 		return 0;
+ 
+ 	err = feature_handler(netdev, enable);
+ 	if (err) {
+ 		netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
+ 			   enable ? "Enable" : "Disable", feature, err);
+ 		return err;
+ 	}
+ 
+ 	MLX5E_SET_FEATURE(netdev, feature, enable);
+ 	return 0;
+ }
+ 
+ static int mlx5e_set_features(struct net_device *netdev,
+ 			      netdev_features_t features)
+ {
+ 	int err;
+ 
+ 	err  = mlx5e_handle_feature(netdev, features, NETIF_F_LRO,
+ 				    set_feature_lro);
+ 	err |= mlx5e_handle_feature(netdev, features,
+ 				    NETIF_F_HW_VLAN_CTAG_FILTER,
+ 				    set_feature_vlan_filter);
+ 	err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_TC,
+ 				    set_feature_tc_num_filters);
+ 	err |= mlx5e_handle_feature(netdev, features, NETIF_F_RXALL,
+ 				    set_feature_rx_all);
+ 	err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_VLAN_CTAG_RX,
+ 				    set_feature_rx_vlan);
+ 
+ 	return err ? -EINVAL : 0;
+ }
+ 
 +#define MXL5_HW_MIN_MTU 64
 +#define MXL5E_MIN_MTU (MXL5_HW_MIN_MTU + ETH_FCS_LEN)
 +
  static int mlx5e_change_mtu(struct net_device *netdev, int new_mtu)
  {
  	struct mlx5e_priv *priv = netdev_priv(netdev);
@@@ -2633,18 -2966,10 +2997,19 @@@ static void mlx5e_destroy_netdev(struc
  	schedule_work(&priv->set_rx_mode_work);
  	mlx5e_disable_async_events(priv);
  	flush_scheduled_work();
 -	unregister_netdev(netdev);
 +	if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) {
 +		netif_device_detach(netdev);
 +		mutex_lock(&priv->state_lock);
 +		if (test_bit(MLX5E_STATE_OPENED, &priv->state))
 +			mlx5e_close_locked(netdev);
 +		mutex_unlock(&priv->state_lock);
 +	} else {
 +		unregister_netdev(netdev);
 +	}
 +
  	mlx5e_tc_cleanup(priv);
  	mlx5e_vxlan_cleanup(priv);
+ 	mlx5e_destroy_q_counter(priv);
  	mlx5e_destroy_flow_tables(priv);
  	mlx5e_destroy_tirs(priv);
  	mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-04-26  2:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-04-26  2:18 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Konstantin Khlebnikov

Hi all,

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

  include/linux/ipv6.h
  net/ipv6/addrconf.c

between commit:

  841645b5f2df ("ipv6: Revert optional address flusing on ifdown.")

from the net tree and commits:

  607ea7cda631 ("net/ipv6/addrconf: simplify sysctl registration")
  5df1f77f65e1 ("net/ipv6/addrconf: fix sysctl table indentation")

from the net-next 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/ipv6.h
index 4b2267e1b7c3,58d6e158755f..000000000000
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@@ -62,7 -62,9 +62,8 @@@ struct ipv6_devconf 
  		struct in6_addr secret;
  	} stable_secret;
  	__s32		use_oif_addrs_only;
- 	void		*sysctl;
 -	__s32		keep_addr_on_down;
+ 
+ 	struct ctl_table_header *sysctl_header;
  };
  
  struct ipv6_params {
diff --cc net/ipv6/addrconf.c
index d77ba395d593,f5a77a9dd34e..000000000000
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@@ -5506,323 -5637,322 +5507,314 @@@ int addrconf_sysctl_ignore_routes_with_
  	return ret;
  }
  
- static struct addrconf_sysctl_table
- {
- 	struct ctl_table_header *sysctl_header;
- 	struct ctl_table addrconf_vars[DEVCONF_MAX+1];
- } addrconf_sysctl __read_mostly = {
- 	.sysctl_header = NULL,
- 	.addrconf_vars = {
- 		{
- 			.procname	= "forwarding",
- 			.data		= &ipv6_devconf.forwarding,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_forward,
- 		},
- 		{
- 			.procname	= "hop_limit",
- 			.data		= &ipv6_devconf.hop_limit,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_hop_limit,
- 		},
- 		{
- 			.procname	= "mtu",
- 			.data		= &ipv6_devconf.mtu6,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_mtu,
- 		},
- 		{
- 			.procname	= "accept_ra",
- 			.data		= &ipv6_devconf.accept_ra,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "accept_redirects",
- 			.data		= &ipv6_devconf.accept_redirects,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "autoconf",
- 			.data		= &ipv6_devconf.autoconf,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "dad_transmits",
- 			.data		= &ipv6_devconf.dad_transmits,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "router_solicitations",
- 			.data		= &ipv6_devconf.rtr_solicits,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "router_solicitation_interval",
- 			.data		= &ipv6_devconf.rtr_solicit_interval,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec_jiffies,
- 		},
- 		{
- 			.procname	= "router_solicitation_delay",
- 			.data		= &ipv6_devconf.rtr_solicit_delay,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec_jiffies,
- 		},
- 		{
- 			.procname	= "force_mld_version",
- 			.data		= &ipv6_devconf.force_mld_version,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "mldv1_unsolicited_report_interval",
- 			.data		=
- 				&ipv6_devconf.mldv1_unsolicited_report_interval,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec_ms_jiffies,
- 		},
- 		{
- 			.procname	= "mldv2_unsolicited_report_interval",
- 			.data		=
- 				&ipv6_devconf.mldv2_unsolicited_report_interval,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec_ms_jiffies,
- 		},
- 		{
- 			.procname	= "use_tempaddr",
- 			.data		= &ipv6_devconf.use_tempaddr,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "temp_valid_lft",
- 			.data		= &ipv6_devconf.temp_valid_lft,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "temp_prefered_lft",
- 			.data		= &ipv6_devconf.temp_prefered_lft,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "regen_max_retry",
- 			.data		= &ipv6_devconf.regen_max_retry,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "max_desync_factor",
- 			.data		= &ipv6_devconf.max_desync_factor,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "max_addresses",
- 			.data		= &ipv6_devconf.max_addresses,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "accept_ra_defrtr",
- 			.data		= &ipv6_devconf.accept_ra_defrtr,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "accept_ra_min_hop_limit",
- 			.data		= &ipv6_devconf.accept_ra_min_hop_limit,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "accept_ra_pinfo",
- 			.data		= &ipv6_devconf.accept_ra_pinfo,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
+ static const struct ctl_table addrconf_sysctl[] = {
+ 	{
+ 		.procname	= "forwarding",
+ 		.data		= &ipv6_devconf.forwarding,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_forward,
+ 	},
+ 	{
+ 		.procname	= "hop_limit",
+ 		.data		= &ipv6_devconf.hop_limit,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_hop_limit,
+ 	},
+ 	{
+ 		.procname	= "mtu",
+ 		.data		= &ipv6_devconf.mtu6,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_mtu,
+ 	},
+ 	{
+ 		.procname	= "accept_ra",
+ 		.data		= &ipv6_devconf.accept_ra,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "accept_redirects",
+ 		.data		= &ipv6_devconf.accept_redirects,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "autoconf",
+ 		.data		= &ipv6_devconf.autoconf,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "dad_transmits",
+ 		.data		= &ipv6_devconf.dad_transmits,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "router_solicitations",
+ 		.data		= &ipv6_devconf.rtr_solicits,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "router_solicitation_interval",
+ 		.data		= &ipv6_devconf.rtr_solicit_interval,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec_jiffies,
+ 	},
+ 	{
+ 		.procname	= "router_solicitation_delay",
+ 		.data		= &ipv6_devconf.rtr_solicit_delay,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec_jiffies,
+ 	},
+ 	{
+ 		.procname	= "force_mld_version",
+ 		.data		= &ipv6_devconf.force_mld_version,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "mldv1_unsolicited_report_interval",
+ 		.data		=
+ 			&ipv6_devconf.mldv1_unsolicited_report_interval,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec_ms_jiffies,
+ 	},
+ 	{
+ 		.procname	= "mldv2_unsolicited_report_interval",
+ 		.data		=
+ 			&ipv6_devconf.mldv2_unsolicited_report_interval,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec_ms_jiffies,
+ 	},
+ 	{
+ 		.procname	= "use_tempaddr",
+ 		.data		= &ipv6_devconf.use_tempaddr,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "temp_valid_lft",
+ 		.data		= &ipv6_devconf.temp_valid_lft,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "temp_prefered_lft",
+ 		.data		= &ipv6_devconf.temp_prefered_lft,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "regen_max_retry",
+ 		.data		= &ipv6_devconf.regen_max_retry,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "max_desync_factor",
+ 		.data		= &ipv6_devconf.max_desync_factor,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "max_addresses",
+ 		.data		= &ipv6_devconf.max_addresses,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "accept_ra_defrtr",
+ 		.data		= &ipv6_devconf.accept_ra_defrtr,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "accept_ra_min_hop_limit",
+ 		.data		= &ipv6_devconf.accept_ra_min_hop_limit,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "accept_ra_pinfo",
+ 		.data		= &ipv6_devconf.accept_ra_pinfo,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
  #ifdef CONFIG_IPV6_ROUTER_PREF
- 		{
- 			.procname	= "accept_ra_rtr_pref",
- 			.data		= &ipv6_devconf.accept_ra_rtr_pref,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "router_probe_interval",
- 			.data		= &ipv6_devconf.rtr_probe_interval,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec_jiffies,
- 		},
+ 	{
+ 		.procname	= "accept_ra_rtr_pref",
+ 		.data		= &ipv6_devconf.accept_ra_rtr_pref,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "router_probe_interval",
+ 		.data		= &ipv6_devconf.rtr_probe_interval,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec_jiffies,
+ 	},
  #ifdef CONFIG_IPV6_ROUTE_INFO
- 		{
- 			.procname	= "accept_ra_rt_info_max_plen",
- 			.data		= &ipv6_devconf.accept_ra_rt_info_max_plen,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
+ 	{
+ 		.procname	= "accept_ra_rt_info_max_plen",
+ 		.data		= &ipv6_devconf.accept_ra_rt_info_max_plen,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
  #endif
  #endif
- 		{
- 			.procname	= "proxy_ndp",
- 			.data		= &ipv6_devconf.proxy_ndp,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_proxy_ndp,
- 		},
- 		{
- 			.procname	= "accept_source_route",
- 			.data		= &ipv6_devconf.accept_source_route,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
+ 	{
+ 		.procname	= "proxy_ndp",
+ 		.data		= &ipv6_devconf.proxy_ndp,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_proxy_ndp,
+ 	},
+ 	{
+ 		.procname	= "accept_source_route",
+ 		.data		= &ipv6_devconf.accept_source_route,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
  #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- 		{
- 			.procname       = "optimistic_dad",
- 			.data           = &ipv6_devconf.optimistic_dad,
- 			.maxlen         = sizeof(int),
- 			.mode           = 0644,
- 			.proc_handler   = proc_dointvec,
- 
- 		},
- 		{
- 			.procname       = "use_optimistic",
- 			.data           = &ipv6_devconf.use_optimistic,
- 			.maxlen         = sizeof(int),
- 			.mode           = 0644,
- 			.proc_handler   = proc_dointvec,
- 
- 		},
+ 	{
+ 		.procname	= "optimistic_dad",
+ 		.data		= &ipv6_devconf.optimistic_dad,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler   = proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "use_optimistic",
+ 		.data		= &ipv6_devconf.use_optimistic,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
  #endif
  #ifdef CONFIG_IPV6_MROUTE
- 		{
- 			.procname	= "mc_forwarding",
- 			.data		= &ipv6_devconf.mc_forwarding,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0444,
- 			.proc_handler	= proc_dointvec,
- 		},
+ 	{
+ 		.procname	= "mc_forwarding",
+ 		.data		= &ipv6_devconf.mc_forwarding,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0444,
+ 		.proc_handler	= proc_dointvec,
+ 	},
  #endif
- 		{
- 			.procname	= "disable_ipv6",
- 			.data		= &ipv6_devconf.disable_ipv6,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_disable,
- 		},
- 		{
- 			.procname	= "accept_dad",
- 			.data		= &ipv6_devconf.accept_dad,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname       = "force_tllao",
- 			.data           = &ipv6_devconf.force_tllao,
- 			.maxlen         = sizeof(int),
- 			.mode           = 0644,
- 			.proc_handler   = proc_dointvec
- 		},
- 		{
- 			.procname       = "ndisc_notify",
- 			.data           = &ipv6_devconf.ndisc_notify,
- 			.maxlen         = sizeof(int),
- 			.mode           = 0644,
- 			.proc_handler   = proc_dointvec
- 		},
- 		{
- 			.procname	= "suppress_frag_ndisc",
- 			.data		= &ipv6_devconf.suppress_frag_ndisc,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec
- 		},
- 		{
- 			.procname	= "accept_ra_from_local",
- 			.data		= &ipv6_devconf.accept_ra_from_local,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "accept_ra_mtu",
- 			.data		= &ipv6_devconf.accept_ra_mtu,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "stable_secret",
- 			.data		= &ipv6_devconf.stable_secret,
- 			.maxlen		= IPV6_MAX_STRLEN,
- 			.mode		= 0600,
- 			.proc_handler	= addrconf_sysctl_stable_secret,
- 		},
- 		{
- 			.procname       = "use_oif_addrs_only",
- 			.data           = &ipv6_devconf.use_oif_addrs_only,
- 			.maxlen         = sizeof(int),
- 			.mode           = 0644,
- 			.proc_handler   = proc_dointvec,
- 		},
- 		{
- 			.procname	= "ignore_routes_with_linkdown",
- 			.data		= &ipv6_devconf.ignore_routes_with_linkdown,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= addrconf_sysctl_ignore_routes_with_linkdown,
- 		},
- 		{
- 			.procname	= "drop_unicast_in_l2_multicast",
- 			.data		= &ipv6_devconf.drop_unicast_in_l2_multicast,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			.procname	= "drop_unsolicited_na",
- 			.data		= &ipv6_devconf.drop_unsolicited_na,
- 			.maxlen		= sizeof(int),
- 			.mode		= 0644,
- 			.proc_handler	= proc_dointvec,
- 		},
- 		{
- 			/* sentinel */
- 		}
+ 	{
+ 		.procname	= "disable_ipv6",
+ 		.data		= &ipv6_devconf.disable_ipv6,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_disable,
+ 	},
+ 	{
+ 		.procname	= "accept_dad",
+ 		.data		= &ipv6_devconf.accept_dad,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "force_tllao",
+ 		.data		= &ipv6_devconf.force_tllao,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec
  	},
+ 	{
+ 		.procname	= "ndisc_notify",
+ 		.data		= &ipv6_devconf.ndisc_notify,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec
+ 	},
+ 	{
+ 		.procname	= "suppress_frag_ndisc",
+ 		.data		= &ipv6_devconf.suppress_frag_ndisc,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec
+ 	},
+ 	{
+ 		.procname	= "accept_ra_from_local",
+ 		.data		= &ipv6_devconf.accept_ra_from_local,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "accept_ra_mtu",
+ 		.data		= &ipv6_devconf.accept_ra_mtu,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "stable_secret",
+ 		.data		= &ipv6_devconf.stable_secret,
+ 		.maxlen		= IPV6_MAX_STRLEN,
+ 		.mode		= 0600,
+ 		.proc_handler	= addrconf_sysctl_stable_secret,
+ 	},
+ 	{
+ 		.procname	= "use_oif_addrs_only",
+ 		.data		= &ipv6_devconf.use_oif_addrs_only,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "ignore_routes_with_linkdown",
+ 		.data		= &ipv6_devconf.ignore_routes_with_linkdown,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= addrconf_sysctl_ignore_routes_with_linkdown,
+ 	},
+ 	{
+ 		.procname	= "drop_unicast_in_l2_multicast",
+ 		.data		= &ipv6_devconf.drop_unicast_in_l2_multicast,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
+ 		.procname	= "drop_unsolicited_na",
+ 		.data		= &ipv6_devconf.drop_unsolicited_na,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= proc_dointvec,
+ 	},
+ 	{
 -		.procname	= "keep_addr_on_down",
 -		.data		= &ipv6_devconf.keep_addr_on_down,
 -		.maxlen		= sizeof(int),
 -		.mode		= 0644,
 -		.proc_handler	= proc_dointvec,
 -
 -	},
 -	{
+ 		/* sentinel */
+ 	}
  };
  
  static int __addrconf_sysctl_register(struct net *net, char *dev_name,

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-04-18  1:30 Stephen Rothwell
@ 2016-04-21 23:54 ` Vivien Didelot
  0 siblings, 0 replies; 325+ messages in thread
From: Vivien Didelot @ 2016-04-21 23:54 UTC (permalink / raw)
  To: David Miller; +Cc: Stephen Rothwell, netdev, linux-next, linux-kernel

Hi David,

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/dsa/mv88e6xxx.c
>
> between commit:
>
>   207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")
>
> from the net tree and commit:
>
>   009a2b9843bf ("net: dsa: mv88e6xxx: add number of ports to info")
>
> from the net-next tree.
>
> I fixed it up (the former removed some of the code updated 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.

I have another series to send to net-next which will also conflict with this
fix from net. As it is also required in net-next, can the fix be merged
in net-next as well?

This fix is the 3 commits:

  65fa40276ac1 ("net: dsa: mv88e6xxx: unlock DSA and CPU ports")
  996ecb824667 ("net: dsa: mv88e6xxx: enable SA learning on DSA ports")
  207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")

For the merge commit:

  cf6b5fb2514d ("Merge branch 'dsa-mv88e6xxx-fix-cross-chip-bridging'")

Regards,
Vivien

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-04-18  1:31 Stephen Rothwell
@ 2016-04-18  1:38 ` Eric Dumazet
  0 siblings, 0 replies; 325+ messages in thread
From: Eric Dumazet @ 2016-04-18  1:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Craig Gallek,
	Eric Dumazet

On Mon, 2016-04-18 at 11:31 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv4/udp.c
> 
> between commit:
> 
>   d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets")
> 
> from the net tree and commit:
> 
>   ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")
> 
> from the net-next tree.
> 
> I tried to fixed it up (see below).  Unfortunately,
> hlist_add_tail_rcu() does not exist.  So instead I have reverted commit
> d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets") for
> today.

Hi Stephen

Craig warned that this would happen indeed, and provided a net-next
patch, to help David with this conflict.

https://patchwork.ozlabs.org/patch/611093/

Thanks

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-04-18  1:31 Stephen Rothwell
  2016-04-18  1:38 ` Eric Dumazet
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-04-18  1:31 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Craig Gallek, Eric Dumazet

Hi all,

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

  net/ipv4/udp.c

between commit:

  d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets")

from the net tree and commit:

  ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")

from the net-next tree.

I tried to fixed it up (see below).  Unfortunately,
hlist_add_tail_rcu() does not exist.  So instead I have reverted commit
d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets") for
today.

-- 
Cheers,
Stephen Rothwell

diff --cc net/ipv4/udp.c
index a2e7f55a1f61,f1863136d3e4..000000000000
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@@ -339,13 -336,8 +336,13 @@@ found
  
  		hslot2 = udp_hashslot2(udptable, udp_sk(sk)->udp_portaddr_hash);
  		spin_lock(&hslot2->lock);
 -		hlist_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
 -					 &hslot2->head);
 +		if (IS_ENABLED(CONFIG_IPV6) && sk->sk_reuseport &&
 +			sk->sk_family == AF_INET6)
- 			hlist_nulls_add_tail_rcu(&udp_sk(sk)->udp_portaddr_node,
- 						 &hslot2->head);
++			hlist_add_tail_rcu(&udp_sk(sk)->udp_portaddr_node,
++					   &hslot2->head);
 +		else
- 			hlist_nulls_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
- 						 &hslot2->head);
++			hlist_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
++					   &hslot2->head);
  		hslot2->count++;
  		spin_unlock(&hslot2->lock);
  	}

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-04-18  1:30 Stephen Rothwell
  2016-04-21 23:54 ` Vivien Didelot
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-04-18  1:30 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Vivien Didelot

Hi all,

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

  drivers/net/dsa/mv88e6xxx.c

between commit:

  207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")

from the net tree and commit:

  009a2b9843bf ("net: dsa: mv88e6xxx: add number of ports to info")

from the net-next tree.

I fixed it up (the former removed some of the code updated 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] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-03-08  0:37 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-03-08  0:37 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Parthasarathy Bhuvaragan

Hi all,

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

  net/tipc/subscr.c

between commit:

  4de13d7ed6ff ("tipc: fix nullptr crash during subscription cancel")

from the net tree and commit:

  7c13c6224123 ("tipc: introduce tipc_subscrb_subscribe() routine")
(and following ones)

from the net-next tree.

I fixed it up (I used the net-next tree version as it is not obvious tha
the net tree patch is still needed) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-03-04  2:09 Stephen Rothwell
@ 2016-03-04  2:17 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2016-03-04  2:17 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Jiri Benc

On 03/04/2016 03:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    drivers/net/vxlan.c
>
> between commit:
>
>    4024fcf70556 ("vxlan: fix missing options_len update on RX with collect metadata")
>
> from the net tree and commit:
>
>    3288af0892e3 ("vxlan: move GBP header parsing to a separate function")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-03-04  2:09 Stephen Rothwell
  2016-03-04  2:17 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-03-04  2:09 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Daniel Borkmann, Jiri Benc

Hi all,

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

  drivers/net/vxlan.c

between commit:

  4024fcf70556 ("vxlan: fix missing options_len update on RX with collect metadata")

from the net tree and commit:

  3288af0892e3 ("vxlan: move GBP header parsing to a separate function")

from the net-next 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/vxlan.c
index 1c32bd104797,775ddb48388d..000000000000
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@@ -1129,49 -1144,61 +1146,63 @@@ static bool vxlan_remcsum(struct vxlanh
  {
  	size_t start, offset, plen;
  
- 	if (skb->remcsum_offload)
- 		return vh;
+ 	if (!(unparsed->vx_flags & VXLAN_HF_RCO) || skb->remcsum_offload)
+ 		goto out;
  
- 	start = (data & VXLAN_RCO_MASK) << VXLAN_RCO_SHIFT;
- 	offset = start + ((data & VXLAN_RCO_UDP) ?
- 			  offsetof(struct udphdr, check) :
- 			  offsetof(struct tcphdr, check));
+ 	start = vxlan_rco_start(unparsed->vx_vni);
+ 	offset = start + vxlan_rco_offset(unparsed->vx_vni);
  
- 	plen = hdrlen + offset + sizeof(u16);
+ 	plen = sizeof(struct vxlanhdr) + offset + sizeof(u16);
  
  	if (!pskb_may_pull(skb, plen))
- 		return NULL;
+ 		return false;
+ 
+ 	skb_remcsum_process(skb, (void *)(vxlan_hdr(skb) + 1), start, offset,
+ 			    !!(vxflags & VXLAN_F_REMCSUM_NOPARTIAL));
+ out:
+ 	unparsed->vx_flags &= ~VXLAN_HF_RCO;
+ 	unparsed->vx_vni &= VXLAN_VNI_MASK;
+ 	return true;
+ }
+ 
+ static void vxlan_parse_gbp_hdr(struct vxlanhdr *unparsed,
+ 				struct sk_buff *skb, u32 vxflags,
+ 				struct vxlan_metadata *md)
+ {
+ 	struct vxlanhdr_gbp *gbp = (struct vxlanhdr_gbp *)unparsed;
+ 	struct metadata_dst *tun_dst;
  
- 	vh = (struct vxlanhdr *)(udp_hdr(skb) + 1);
+ 	if (!(unparsed->vx_flags & VXLAN_HF_GBP))
+ 		goto out;
  
- 	skb_remcsum_process(skb, (void *)vh + hdrlen, start, offset,
- 			    nopartial);
+ 	md->gbp = ntohs(gbp->policy_id);
  
- 	return vh;
+ 	tun_dst = (struct metadata_dst *)skb_dst(skb);
 -	if (tun_dst)
++	if (tun_dst) {
+ 		tun_dst->u.tun_info.key.tun_flags |= TUNNEL_VXLAN_OPT;
++		tun_dst->u.tun_info.options_len = sizeof(*md);
++	}
+ 
+ 	if (gbp->dont_learn)
+ 		md->gbp |= VXLAN_GBP_DONT_LEARN;
+ 
+ 	if (gbp->policy_applied)
+ 		md->gbp |= VXLAN_GBP_POLICY_APPLIED;
+ 
+ 	/* In flow-based mode, GBP is carried in dst_metadata */
+ 	if (!(vxflags & VXLAN_F_COLLECT_METADATA))
+ 		skb->mark = md->gbp;
+ out:
+ 	unparsed->vx_flags &= ~VXLAN_GBP_USED_BITS;
  }
  
- static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff *skb,
- 		      struct vxlan_metadata *md, u32 vni,
- 		      struct metadata_dst *tun_dst)
+ static bool vxlan_set_mac(struct vxlan_dev *vxlan,
+ 			  struct vxlan_sock *vs,
+ 			  struct sk_buff *skb)
  {
- 	struct iphdr *oip = NULL;
- 	struct ipv6hdr *oip6 = NULL;
- 	struct vxlan_dev *vxlan;
- 	struct pcpu_sw_netstats *stats;
  	union vxlan_addr saddr;
- 	int err = 0;
- 
- 	/* For flow based devices, map all packets to VNI 0 */
- 	if (vs->flags & VXLAN_F_COLLECT_METADATA)
- 		vni = 0;
- 
- 	/* Is this VNI defined? */
- 	vxlan = vxlan_vs_find_vni(vs, vni);
- 	if (!vxlan)
- 		goto drop;
  
  	skb_reset_mac_header(skb);
- 	skb_scrub_packet(skb, !net_eq(vxlan->net, dev_net(vxlan->dev)));
  	skb->protocol = eth_type_trans(skb, vxlan->dev);
  	skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-03-03  0:36 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-03-03  0:36 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Gal Pressman, Saeed Mahameed, Matthew Finlay

Hi all,

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

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

between commit:

  b081da5ee186 ("net/mlx5e: Add rx/tx bytes software counters")

from the net tree and commits:

  9879515895ff ("net/mlx5e: Add TX stateless offloads for tunneling")
  89db09eb5979 ("net/mlx5e: Add TX inner packet counters")

from the net-next 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/en_tx.c
index bb4eeeb007de,c34f4f3e9537..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@@ -199,15 -203,21 +204,20 @@@ static netdev_tx_t mlx5e_sq_xmit(struc
  	}
  
  	if (skb_is_gso(skb)) {
- 		u32 payload_len;
- 
  		eseg->mss    = cpu_to_be16(skb_shinfo(skb)->gso_size);
  		opcode       = MLX5_OPCODE_LSO;
- 		ihs          = skb_transport_offset(skb) + tcp_hdrlen(skb);
- 		payload_len  = skb->len - ihs;
+ 
+ 		if (skb->encapsulation) {
+ 			ihs = skb_inner_transport_offset(skb) + inner_tcp_hdrlen(skb);
+ 			sq->stats.tso_inner_packets++;
+ 			sq->stats.tso_inner_bytes += skb->len - ihs;
+ 		} else {
+ 			ihs = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ 			sq->stats.tso_packets++;
+ 			sq->stats.tso_bytes += skb->len - ihs;
+ 		}
+ 
 -		wi->num_bytes = skb->len +
 -				(skb_shinfo(skb)->gso_segs - 1) * ihs;
 +		num_bytes = skb->len + (skb_shinfo(skb)->gso_segs - 1) * ihs;
- 		sq->stats.tso_packets++;
- 		sq->stats.tso_bytes += payload_len;
  	} else {
  		bf = sq->bf_budget &&
  		     !skb->xmit_more &&

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-03-03  0:28 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-03-03  0:28 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Tariq Toukan, Saeed Mahameed

Hi all,

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

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

between commit:

  85082dba0a50 ("net/mlx5e: Correctly handle RSS indirection table when changing number of channels")

from the net tree and commit:

  08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS")

from the net-next 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/en_main.c
index 402994bf7e16,5063c0e0f8ac..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -141,12 -143,10 +143,14 @@@ void mlx5e_update_stats(struct mlx5e_pr
  		return;
  
  	/* Collect firts the SW counters and then HW for consistency */
 +	s->rx_packets		= 0;
 +	s->rx_bytes		= 0;
 +	s->tx_packets		= 0;
 +	s->tx_bytes		= 0;
  	s->tso_packets		= 0;
  	s->tso_bytes		= 0;
+ 	s->tso_inner_packets	= 0;
+ 	s->tso_inner_bytes	= 0;
  	s->tx_queue_stopped	= 0;
  	s->tx_queue_wake	= 0;
  	s->tx_queue_dropped	= 0;
@@@ -170,10 -169,10 +175,12 @@@
  		for (j = 0; j < priv->params.num_tc; j++) {
  			sq_stats = &priv->channel[i]->sq[j].stats;
  
 +			s->tx_packets		+= sq_stats->packets;
 +			s->tx_bytes		+= sq_stats->bytes;
  			s->tso_packets		+= sq_stats->tso_packets;
  			s->tso_bytes		+= sq_stats->tso_bytes;
+ 			s->tso_inner_packets	+= sq_stats->tso_inner_packets;
+ 			s->tso_inner_bytes	+= sq_stats->tso_inner_bytes;
  			s->tx_queue_stopped	+= sq_stats->stopped;
  			s->tx_queue_wake	+= sq_stats->wake;
  			s->tx_queue_dropped	+= sq_stats->dropped;
@@@ -233,8 -233,25 +241,8 @@@
  	s->tx_broadcast_bytes   =
  		MLX5_GET_CTR(out, transmitted_eth_broadcast.octets);
  
 -	s->rx_packets =
 -		s->rx_unicast_packets +
 -		s->rx_multicast_packets +
 -		s->rx_broadcast_packets;
 -	s->rx_bytes =
 -		s->rx_unicast_bytes +
 -		s->rx_multicast_bytes +
 -		s->rx_broadcast_bytes;
 -	s->tx_packets =
 -		s->tx_unicast_packets +
 -		s->tx_multicast_packets +
 -		s->tx_broadcast_packets;
 -	s->tx_bytes =
 -		s->tx_unicast_bytes +
 -		s->tx_multicast_bytes +
 -		s->tx_broadcast_bytes;
 -
  	/* Update calculated offload counters */
- 	s->tx_csum_offload = s->tx_packets - tx_offload_none;
+ 	s->tx_csum_offload = s->tx_packets - tx_offload_none - s->tx_csum_inner;
  	s->rx_csum_good    = s->rx_packets - s->rx_csum_none -
  			       s->rx_csum_sw;
  
@@@ -2091,15 -2235,24 +2237,33 @@@ u16 mlx5e_get_max_inline_cap(struct mlx
  	       2 /*sizeof(mlx5e_tx_wqe.inline_hdr_start)*/;
  }
  
 +void mlx5e_build_default_indir_rqt(u32 *indirection_rqt, int len,
 +				   int num_channels)
 +{
 +	int i;
 +
 +	for (i = 0; i < len; i++)
 +		indirection_rqt[i] = i % num_channels;
 +}
 +
+ #ifdef CONFIG_MLX5_CORE_EN_DCB
+ static void mlx5e_ets_init(struct mlx5e_priv *priv)
+ {
+ 	int i;
+ 
+ 	priv->params.ets.ets_cap = mlx5_max_tc(priv->mdev) + 1;
+ 	for (i = 0; i < priv->params.ets.ets_cap; i++) {
+ 		priv->params.ets.tc_tx_bw[i] = MLX5E_MAX_BW_ALLOC;
+ 		priv->params.ets.tc_tsa[i] = IEEE_8021QAZ_TSA_VENDOR;
+ 		priv->params.ets.prio_tc[i] = i;
+ 	}
+ 
+ 	/* tclass[prio=0]=1, tclass[prio=1]=0, tclass[prio=i]=i (for i>1) */
+ 	priv->params.ets.prio_tc[0] = 1;
+ 	priv->params.ets.prio_tc[1] = 0;
+ }
+ #endif
+ 
  static void mlx5e_build_netdev_priv(struct mlx5_core_dev *mdev,
  				    struct net_device *netdev,
  				    int num_channels)

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-03-03  0:24 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-03-03  0:24 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Gal Pressman, Matthew Finlay,
	Saeed Mahameed, Tariq Toukan

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en.h

between commit:

  b081da5ee186 ("net/mlx5e: Add rx/tx bytes software counters")

from the net tree and commits:

  89db09eb5979 ("net/mlx5e: Add TX inner packet counters")
  3c1b5532191d ("net/mlx5e: Move common case counters within sq_stats struct")

from the net-next 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/en.h
index 5b1753233c5d,9c0e80e64b43..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@@ -244,9 -256,12 +258,13 @@@ struct mlx5e_rq_stats 
  
  static const char sq_stats_strings[][ETH_GSTRING_LEN] = {
  	"packets",
 +	"bytes",
  	"tso_packets",
  	"tso_bytes",
+ 	"tso_inner_packets",
+ 	"tso_inner_bytes",
+ 	"csum_offload_inner",
+ 	"nop",
  	"csum_offload_none",
  	"stopped",
  	"wake",
@@@ -254,11 -269,15 +272,16 @@@
  };
  
  struct mlx5e_sq_stats {
+ 	/* commonly accessed in data path */
  	u64 packets;
 +	u64 bytes;
  	u64 tso_packets;
  	u64 tso_bytes;
+ 	u64 tso_inner_packets;
+ 	u64 tso_inner_bytes;
+ 	u64 csum_offload_inner;
+ 	u64 nop;
+ 	/* less likely accessed in data path */
  	u64 csum_offload_none;
  	u64 stopped;
  	u64 wake;

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-02-26  0:13 Stephen Rothwell
@ 2016-02-26  0:15 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2016-02-26  0:15 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Alexei Starovoitov

On 02/26/2016 01:13 AM, Stephen Rothwell wrote:
[...]
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks Stephen!

Best,
Daniel

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-02-26  0:13 Stephen Rothwell
  2016-02-26  0:15 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-02-26  0:13 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Daniel Borkmann, Alexei Starovoitov

Hi all,

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

  include/uapi/linux/bpf.h

between commit:

  2da897e51d7f ("bpf: fix csum setting for bpf_set_tunnel_key")

from the net tree and commit:

  d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/bpf.h
index 5df4881dea7b,6496f98d3d68..000000000000
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@@ -292,9 -321,12 +321,15 @@@ enum bpf_func_id 
  /* BPF_FUNC_skb_set_tunnel_key and BPF_FUNC_skb_get_tunnel_key flags. */
  #define BPF_F_TUNINFO_IPV6		(1ULL << 0)
  
 +/* BPF_FUNC_skb_set_tunnel_key flags. */
 +#define BPF_F_ZERO_CSUM_TX		(1ULL << 1)
 +
+ /* BPF_FUNC_get_stackid flags. */
+ #define BPF_F_SKIP_FIELD_MASK		0xffULL
+ #define BPF_F_USER_STACK		(1ULL << 8)
+ #define BPF_F_FAST_STACK_CMP		(1ULL << 9)
+ #define BPF_F_REUSE_STACKID		(1ULL << 10)
+ 
  /* user accessible mirror of in-kernel sk_buff.
   * new fields can only be added to the end of this structure
   */

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-02-18 22:50 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-02-18 22:50 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Clemens Gruber, Stefan Roese

Hi all,

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

  drivers/net/phy/marvell.c

between commit:

  79be1a1c9090 ("phy: marvell: Fix and unify reg-init behavior")

from the net tree and commit:

  930b37ee8d84 ("net: phy: Add SGMII support for Marvell 88E1510/1512/1514/1518")

from the net-next tree.

OK, I didn't know how to resolve this, so I just used the net-next
tree version (which is probably wrong, but will build).

-- 
Cheers,
Stephen Rothwell

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-02-17  0:56 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-02-17  0:56 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Florian Fainelli

Hi all,

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

  drivers/net/phy/bcm7xxx.c

between commit:

  c6dd213abe40 ("net: phy: bcm7xxx: Fix 40nm EPHY features")
  815717d1473e ("net: phy: bcm7xxx: Remove wildcard entries"

from the net tree and commit:

  3125c081a593 ("net: phy: bcm7xxx: Reduce boilerplate code for 40nm EPHY")

from the net-next 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/phy/bcm7xxx.c
index db507e3bcab9,9b311041ebfb..000000000000
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@@ -247,9 -247,13 +247,9 @@@ static int bcm7xxx_config_init(struct p
  	int ret;
  
  	/* Enable 64 clock MDIO */
- 	phy_write(phydev, MII_BCM7XXX_AUX_MODE, MII_BCM7XX_64CLK_MDIO);
+ 	phy_write(phydev, MII_BCM7XXX_AUX_MODE, MII_BCM7XXX_64CLK_MDIO);
  	phy_read(phydev, MII_BCM7XXX_AUX_MODE);
  
 -	/* Workaround only required for 100Mbits/sec capable PHYs */
 -	if (phydev->supported & PHY_GBIT_FEATURES)
 -		return 0;
 -
  	/* set shadow mode 2 */
  	ret = phy_set_clr_bits(phydev, MII_BCM7XXX_TEST,
  			MII_BCM7XXX_SHD_MODE_2, MII_BCM7XXX_SHD_MODE_2);
@@@ -324,43 -348,34 +339,10 @@@ static struct phy_driver bcm7xxx_driver
  	BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
  	BCM7XXX_28NM_GPHY(PHY_ID_BCM7439_2, "Broadcom BCM7439 (2)"),
  	BCM7XXX_28NM_GPHY(PHY_ID_BCM7445, "Broadcom BCM7445"),
- {
- 	.phy_id         = PHY_ID_BCM7425,
- 	.phy_id_mask    = 0xfffffff0,
- 	.name           = "Broadcom BCM7425",
- 	.features       = PHY_BASIC_FEATURES |
- 			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
- 	.flags          = PHY_IS_INTERNAL,
- 	.config_init    = bcm7xxx_config_init,
- 	.config_aneg    = genphy_config_aneg,
- 	.read_status    = genphy_read_status,
- 	.suspend        = bcm7xxx_suspend,
- 	.resume         = bcm7xxx_config_init,
- }, {
- 	.phy_id         = PHY_ID_BCM7429,
- 	.phy_id_mask    = 0xfffffff0,
- 	.name           = "Broadcom BCM7429",
- 	.features       = PHY_BASIC_FEATURES |
- 			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
- 	.flags          = PHY_IS_INTERNAL,
- 	.config_init    = bcm7xxx_config_init,
- 	.config_aneg    = genphy_config_aneg,
- 	.read_status    = genphy_read_status,
- 	.suspend        = bcm7xxx_suspend,
- 	.resume         = bcm7xxx_config_init,
- }, {
- 	.phy_id         = PHY_ID_BCM7435,
- 	.phy_id_mask    = 0xfffffff0,
- 	.name           = "Broadcom BCM7435",
- 	.features       = PHY_BASIC_FEATURES |
- 			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
- 	.flags          = PHY_IS_INTERNAL,
- 	.config_init    = bcm7xxx_config_init,
- 	.config_aneg    = genphy_config_aneg,
- 	.read_status    = genphy_read_status,
- 	.suspend        = bcm7xxx_suspend,
- 	.resume         = bcm7xxx_config_init,
- } };
+ 	BCM7XXX_40NM_EPHY(PHY_ID_BCM7425, "Broadcom BCM7425"),
+ 	BCM7XXX_40NM_EPHY(PHY_ID_BCM7429, "Broadcom BCM7429"),
+ 	BCM7XXX_40NM_EPHY(PHY_ID_BCM7435, "Broadcom BCM7435"),
 -{
 -	.phy_id		= PHY_BCM_OUI_4,
 -	.phy_id_mask	= 0xffff0000,
 -	.name		= "Broadcom BCM7XXX 40nm",
 -	.features	= PHY_GBIT_FEATURES |
 -			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
 -	.flags		= PHY_IS_INTERNAL,
 -	.config_init	= bcm7xxx_config_init,
 -	.config_aneg	= genphy_config_aneg,
 -	.read_status	= genphy_read_status,
 -	.suspend	= bcm7xxx_suspend,
 -	.resume		= bcm7xxx_config_init,
 -}, {
 -	.phy_id		= PHY_BCM_OUI_5,
 -	.phy_id_mask	= 0xffffff00,
 -	.name		= "Broadcom BCM7XXX 65nm",
 -	.features	= PHY_BASIC_FEATURES |
 -			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
 -	.flags		= PHY_IS_INTERNAL,
 -	.config_init	= bcm7xxx_dummy_config_init,
 -	.config_aneg	= genphy_config_aneg,
 -	.read_status	= genphy_read_status,
 -	.suspend	= bcm7xxx_suspend,
 -	.resume		= bcm7xxx_config_init,
 -} };
++};
  
  static struct mdio_device_id __maybe_unused bcm7xxx_tbl[] = {
  	{ PHY_ID_BCM7250, 0xfffffff0, },

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-02-11  0:59 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2016-02-11  0:59 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, David Wragg, Jiri Benc

Hi all,

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

  drivers/net/vxlan.c

between commit:

  72564b59ffc4 ("vxlan: Relax MTU constraints")

from the net tree and commit:

  1a8496ba4091 ("vxlan: consolidate output route calculation")

from the net-next 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/vxlan.c
index a31cd954b308,65f52472a52c..000000000000
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@@ -2395,40 -2316,6 +2321,15 @@@ static int __vxlan_change_mtu(struct ne
  	return 0;
  }
  
 +static int vxlan_change_mtu(struct net_device *dev, int new_mtu)
 +{
 +	struct vxlan_dev *vxlan = netdev_priv(dev);
 +	struct vxlan_rdst *dst = &vxlan->default_dst;
 +	struct net_device *lowerdev = __dev_get_by_index(vxlan->net,
 +							 dst->remote_ifindex);
 +	return __vxlan_change_mtu(dev, lowerdev, dst, new_mtu, true);
 +}
 +
- static int egress_ipv4_tun_info(struct net_device *dev, struct sk_buff *skb,
- 				struct ip_tunnel_info *info,
- 				__be16 sport, __be16 dport)
- {
- 	struct vxlan_dev *vxlan = netdev_priv(dev);
- 	struct rtable *rt;
- 	struct flowi4 fl4;
- 
- 	memset(&fl4, 0, sizeof(fl4));
- 	fl4.flowi4_tos = RT_TOS(info->key.tos);
- 	fl4.flowi4_mark = skb->mark;
- 	fl4.flowi4_proto = IPPROTO_UDP;
- 	fl4.daddr = info->key.u.ipv4.dst;
- 
- 	rt = ip_route_output_key(vxlan->net, &fl4);
- 	if (IS_ERR(rt))
- 		return PTR_ERR(rt);
- 	ip_rt_put(rt);
- 
- 	info->key.u.ipv4.src = fl4.saddr;
- 	info->key.tp_src = sport;
- 	info->key.tp_dst = dport;
- 	return 0;
- }
- 
  static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
  {
  	struct vxlan_dev *vxlan = netdev_priv(dev);

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-01-12 11:58   ` Stephen Rothwell
@ 2016-01-12 20:20     ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2016-01-12 20:20 UTC (permalink / raw)
  To: sfr; +Cc: idosch, netdev, linux-next, linux-kernel, jiri

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 12 Jan 2016 22:58:11 +1100

> Hi Ido,
> 
> On Tue, 12 Jan 2016 11:11:02 +0200 Ido Schimmel <idosch@mellanox.com> wrote:
>>
>> The lock can be moved further down, just before mlxsw_reg_sfd_pack.
>> Other than that everything looks fine. Thank you!
> 
> Thanks, I wasn't sure but I will do that tomorrow (unless Dave beats me to it).

I did the merge but did not move the locking.  Feel free to send me
a patch to do so.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-01-12  9:11 ` Ido Schimmel
@ 2016-01-12 11:58   ` Stephen Rothwell
  2016-01-12 20:20     ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-01-12 11:58 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko

Hi Ido,

On Tue, 12 Jan 2016 11:11:02 +0200 Ido Schimmel <idosch@mellanox.com> wrote:
>
> The lock can be moved further down, just before mlxsw_reg_sfd_pack.
> Other than that everything looks fine. Thank you!

Thanks, I wasn't sure but I will do that tomorrow (unless Dave beats me to it).

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2016-01-12  2:15 Stephen Rothwell
@ 2016-01-12  9:11 ` Ido Schimmel
  2016-01-12 11:58   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Ido Schimmel @ 2016-01-12  9:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko

Tue, Jan 12, 2016 at 04:15:05AM IST, sfr@canb.auug.org.au wrote:

Hi Stephen,

>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
>  drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
>
>between commit:
>
>  366ce6031529 ("mlxsw: spectrum: Add FDB lock to prevent session interleaving")
>
>from the net tree and commit:
>
>  54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary (no action
>is required).
>
>-- 
>Cheers,
>Stephen Rothwell                    sfr@canb.auug.org.au
>
>diff --cc drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
>index 80e266063aee,4cdc18e72222..000000000000
>--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
>+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
>@@@ -650,7 -1057,14 +1057,15 @@@ static int mlxsw_sp_port_fdb_dump(struc
>  	if (!sfd_pl)
>  		return -ENOMEM;
>  
> +	mutex_lock(&mlxsw_sp_port->mlxsw_sp->fdb_lock);

The lock can be moved further down, just before mlxsw_reg_sfd_pack.
Other than that everything looks fine. Thank you!

>+ 	if (mlxsw_sp_port_is_vport(mlxsw_sp_port)) {
>+ 		u16 tmp;
>+ 
>+ 		tmp = mlxsw_sp_vport_vfid_get(mlxsw_sp_port);
>+ 		vport_fid = mlxsw_sp_vfid_to_fid(tmp);
>+ 		vport_vid = mlxsw_sp_vport_vid_get(mlxsw_sp_port);
>+ 	}
>+ 
>  	mlxsw_reg_sfd_pack(sfd_pl, MLXSW_REG_SFD_OP_QUERY_DUMP, 0);
>  	do {
>  		mlxsw_reg_sfd_num_rec_set(sfd_pl, MLXSW_REG_SFD_REC_MAX_COUNT);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2016-01-12  2:15 Stephen Rothwell
  2016-01-12  9:11 ` Ido Schimmel
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2016-01-12  2:15 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Ido Schimmel, Jiri Pirko

Hi all,

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

  drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c

between commit:

  366ce6031529 ("mlxsw: spectrum: Add FDB lock to prevent session interleaving")

from the net tree and commit:

  54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices")

from the net-next tree.

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

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

diff --cc drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 80e266063aee,4cdc18e72222..000000000000
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@@ -650,7 -1057,14 +1057,15 @@@ static int mlxsw_sp_port_fdb_dump(struc
  	if (!sfd_pl)
  		return -ENOMEM;
  
 +	mutex_lock(&mlxsw_sp_port->mlxsw_sp->fdb_lock);
+ 	if (mlxsw_sp_port_is_vport(mlxsw_sp_port)) {
+ 		u16 tmp;
+ 
+ 		tmp = mlxsw_sp_vport_vfid_get(mlxsw_sp_port);
+ 		vport_fid = mlxsw_sp_vfid_to_fid(tmp);
+ 		vport_vid = mlxsw_sp_vport_vid_get(mlxsw_sp_port);
+ 	}
+ 
  	mlxsw_reg_sfd_pack(sfd_pl, MLXSW_REG_SFD_OP_QUERY_DUMP, 0);
  	do {
  		mlxsw_reg_sfd_num_rec_set(sfd_pl, MLXSW_REG_SFD_REC_MAX_COUNT);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-12-15  0:31 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-12-15  0:31 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Pravin B Shelar, Tom Herbert

Hi all,

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

  drivers/net/geneve.c

between commit:

  a322a1bcf329 ("geneve: Fix IPv6 xmit stats update.")

from the net tree and commit:

  abe492b4f50c ("geneve: UDP checksum configuration via netlink")

from the net-next tree.

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

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

diff --cc drivers/net/geneve.c
index c2b79f5d1c89,0750d7a93878..000000000000
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@@ -966,7 -984,10 +984,8 @@@ static netdev_tx_t geneve6_xmit_skb(str
  	}
  	err = udp_tunnel6_xmit_skb(dst, gs6->sock->sk, skb, dev,
  				   &fl6.saddr, &fl6.daddr, prio, ttl,
- 				   sport, geneve->dst_port, !udp_csum);
+ 				   sport, geneve->dst_port,
+ 				   !!(flags & GENEVE_F_UDP_ZERO_CSUM6_TX));
 -
 -	iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
  	return NETDEV_TX_OK;
  
  tx_error:

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-11-26  0:01 Stephen Rothwell
@ 2015-11-26  0:16 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2015-11-26  0:16 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev; +Cc: linux-next, linux-kernel

On 11/26/2015 01:01 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    kernel/bpf/syscall.c
>
> between commit:
>
>    c9da161c6517 ("bpf: fix clearing on persistent program array maps")
>
> from the net tree and commit:
>
>    f99bf205dab0 ("bpf: add show_fdinfo handler for maps")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Seems fine, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-11-26  0:01 Stephen Rothwell
  2015-11-26  0:16 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-11-26  0:01 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Daniel Borkmann

Hi all,

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

  kernel/bpf/syscall.c

between commit:

  c9da161c6517 ("bpf: fix clearing on persistent program array maps")

from the net tree and commit:

  f99bf205dab0 ("bpf: add show_fdinfo handler for maps")

from the net-next tree.

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

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

diff --cc kernel/bpf/syscall.c
index 4a8f3c1d7da6,6d1407bc1531..000000000000
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@@ -101,15 -93,34 +101,32 @@@ void bpf_map_put(struct bpf_map *map
  	}
  }
  
+ #ifdef CONFIG_PROC_FS
+ static void bpf_map_show_fdinfo(struct seq_file *m, struct file *filp)
+ {
+ 	const struct bpf_map *map = filp->private_data;
+ 
+ 	seq_printf(m,
+ 		   "map_type:\t%u\n"
+ 		   "key_size:\t%u\n"
+ 		   "value_size:\t%u\n"
+ 		   "max_entries:\t%u\n",
+ 		   map->map_type,
+ 		   map->key_size,
+ 		   map->value_size,
+ 		   map->max_entries);
+ }
+ #endif
+ 
 -static int bpf_map_release(struct inode *inode, struct file *filp)
 +void bpf_map_put_with_uref(struct bpf_map *map)
  {
 -	struct bpf_map *map = filp->private_data;
 -
 -	if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY)
 -		/* prog_array stores refcnt-ed bpf_prog pointers
 -		 * release them all when user space closes prog_array_fd
 -		 */
 -		bpf_fd_array_map_clear(map);
 -
 +	bpf_map_put_uref(map);
  	bpf_map_put(map);
 +}
 +
 +static int bpf_map_release(struct inode *inode, struct file *filp)
 +{
 +	bpf_map_put_with_uref(filp->private_data);
  	return 0;
  }
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-11-24  0:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-11-24  0:18 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nikolay Aleksandrov

Hi all,

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

  net/ipv4/ipmr.c

between commit:

  0e615e9601a1 ("net: ipmr: fix static mfc/dev leaks on table destruction")

from the net tree and commit:

  7ef8f65df976 ("net: ipmr: fix code and comment style")

from the net-next tree.

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

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

diff --cc net/ipv4/ipmr.c
index 292123bc30fa,a2d248d9c35c..000000000000
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@@ -1204,30 -1210,24 +1210,25 @@@ static int ipmr_mfc_add(struct net *net
  	return 0;
  }
  
- /*
-  *	Close the multicast socket, and clear the vif tables etc
-  */
- 
+ /* Close the multicast socket, and clear the vif tables etc */
 -static void mroute_clean_tables(struct mr_table *mrt)
 +static void mroute_clean_tables(struct mr_table *mrt, bool all)
  {
  	int i;
  	LIST_HEAD(list);
  	struct mfc_cache *c, *next;
  
  	/* Shut down all active vif entries */
- 
  	for (i = 0; i < mrt->maxvif; i++) {
 -		if (!(mrt->vif_table[i].flags & VIFF_STATIC))
 -			vif_delete(mrt, i, 0, &list);
 +		if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
 +			continue;
 +		vif_delete(mrt, i, 0, &list);
  	}
  	unregister_netdevice_many(&list);
  
  	/* Wipe the cache */
- 
  	for (i = 0; i < MFC_LINES; i++) {
  		list_for_each_entry_safe(c, next, &mrt->mfc_cache_array[i], list) {
 -			if (c->mfc_flags & MFC_STATIC)
 +			if (!all && (c->mfc_flags & MFC_STATIC))
  				continue;
  			list_del_rcu(&c->list);
  			mroute_netlink_event(mrt, c, RTM_DELROUTE);

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-11-03  0:17 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-11-03  0:17 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Ani Sinha, Eric W. Biederman

Hi all,

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

  net/ipv4/ipmr.c

between commit:

  44f49dd8b5a6 ("ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.")

from the net tree and commit:

  758ccac8e741 ("ipv4: Only compute net once in ipmr_forward_finish")

from the net-next tree.

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

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

diff --cc net/ipv4/ipmr.c
index 8e8203d5c520,fc42525d8694..000000000000
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@@ -1682,8 -1683,8 +1683,8 @@@ static inline int ipmr_forward_finish(s
  {
  	struct ip_options *opt = &(IPCB(skb)->opt);
  
- 	IP_INC_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
- 	IP_ADD_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTOCTETS, skb->len);
 -	IP_INC_STATS_BH(net, IPSTATS_MIB_OUTFORWDATAGRAMS);
 -	IP_ADD_STATS_BH(net, IPSTATS_MIB_OUTOCTETS, skb->len);
++	IP_INC_STATS(net, IPSTATS_MIB_OUTFORWDATAGRAMS);
++	IP_ADD_STATS(net, IPSTATS_MIB_OUTOCTETS, skb->len);
  
  	if (unlikely(opt->optlen))
  		ip_forward_options(skb);
@@@ -1745,7 -1746,7 +1746,7 @@@ static void ipmr_queue_xmit(struct net 
  		 * to blackhole.
  		 */
  
- 		IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
 -		IP_INC_STATS_BH(net, IPSTATS_MIB_FRAGFAILS);
++		IP_INC_STATS(net, IPSTATS_MIB_FRAGFAILS);
  		ip_rt_put(rt);
  		goto out_free;
  	}

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-10-15  1:06 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-10-15  1:06 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nikolay Aleksandrov, Jiri Pirko,
	Vivien Didelot

Hi all,

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

  net/switchdev/switchdev.c

between commit:

  87aaf2caed84 ("switchdev: check if the vlan id is in the proper vlan range")

from the net tree and commits:

  7ea6eb3f56f4 ("switchdev: introduce transaction item queue for attr_set and obj_add")
  ab0690023018 ("net: switchdev: abstract object in add/del ops"

from the net-next tree.

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

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

diff --cc net/switchdev/switchdev.c
index 77f5d17e2612,b8aaf820ef65..000000000000
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@@ -16,7 -16,7 +16,8 @@@
  #include <linux/notifier.h>
  #include <linux/netdevice.h>
  #include <linux/if_bridge.h>
 +#include <linux/if_vlan.h>
+ #include <linux/list.h>
  #include <net/ip_fib.h>
  #include <net/switchdev.h>
  
@@@ -635,32 -722,33 +723,35 @@@ static int switchdev_port_br_afspec(str
  		if (nla_len(attr) != sizeof(struct bridge_vlan_info))
  			return -EINVAL;
  		vinfo = nla_data(attr);
 +		if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
 +			return -EINVAL;
- 		vlan->flags = vinfo->flags;
+ 		vlan.flags = vinfo->flags;
  		if (vinfo->flags & BRIDGE_VLAN_INFO_RANGE_BEGIN) {
- 			if (vlan->vid_begin)
+ 			if (vlan.vid_begin)
+ 				return -EINVAL;
+ 			vlan.vid_begin = vinfo->vid;
+ 			/* don't allow range of pvids */
+ 			if (vlan.flags & BRIDGE_VLAN_INFO_PVID)
  				return -EINVAL;
- 			vlan->vid_begin = vinfo->vid;
  		} else if (vinfo->flags & BRIDGE_VLAN_INFO_RANGE_END) {
- 			if (!vlan->vid_begin)
+ 			if (!vlan.vid_begin)
  				return -EINVAL;
- 			vlan->vid_end = vinfo->vid;
- 			if (vlan->vid_end <= vlan->vid_begin)
+ 			vlan.vid_end = vinfo->vid;
+ 			if (vlan.vid_end <= vlan.vid_begin)
  				return -EINVAL;
- 			err = f(dev, &obj);
+ 			err = f(dev, &vlan.obj);
  			if (err)
  				return err;
- 			memset(vlan, 0, sizeof(*vlan));
+ 			memset(&vlan, 0, sizeof(vlan));
  		} else {
- 			if (vlan->vid_begin)
+ 			if (vlan.vid_begin)
  				return -EINVAL;
- 			vlan->vid_begin = vinfo->vid;
- 			vlan->vid_end = vinfo->vid;
- 			err = f(dev, &obj);
+ 			vlan.vid_begin = vinfo->vid;
+ 			vlan.vid_end = vinfo->vid;
+ 			err = f(dev, &vlan.obj);
  			if (err)
  				return err;
- 			memset(vlan, 0, sizeof(*vlan));
+ 			memset(&vlan, 0, sizeof(vlan));
  		}
  	}
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-10-06  0:16 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-10-06  0:16 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

Hi all,

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

  net/ipv4/inet_connection_sock.c

between commit:

  2306c704ce28 ("inet: fix race in reqsk_queue_unlink()")

from the net tree and commit:

  079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")

from the net-next tree.

I fixed it up (the latter rewrote the function, so I dropped the net
tree fix) and can carry the fix as necessary (no action is required).

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-10-06  0:11 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-10-06  0:11 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, David B. Robins, Dean Jenkins

Hi all,

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

  drivers/net/usb/asix_common.c

between commit:

  f6194bcf03e4 ("net: usb: asix: Fix crash on skb alloc failure")

from the net tree and commit:

  6a570814cd43 ("asix: Continue processing URB if no RX netdev buffer")
(among others)

from the net-next tree.

I fixed it up (I dropped the net tree fixup (assuming that it was fixed
in some other manner in the net-next tree)) and can carry the fix as
necessary (no action is required).

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-09-25  0:50 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-09-25  0:50 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Jiri Benc, Eric W. Biederman

Hi all,

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

  net/ipv4/arp.c

between commit:

  63d008a4e9ee ("ipv4: send arp replies to the correct tunnel")

from the net tree and commit:

  0c4b51f0054c ("netfilter: Pass net into okfn")

from the net-next tree.

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

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

diff --cc net/ipv4/arp.c
index f03db8b7abee,61ff5ea31283..000000000000
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@@ -651,8 -654,6 +657,7 @@@ static int arp_process(struct net *net
  	u16 dev_type = dev->type;
  	int addr_type;
  	struct neighbour *n;
- 	struct net *net = dev_net(dev);
 +	struct dst_entry *reply_dst = NULL;
  	bool is_garp = false;
  
  	/* arp_rcv below verifies the ARP header and verifies the device

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-08-18  2:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-08-18  2:35 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, David Ward, Pieter Hollants

Hi all,

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

  drivers/net/usb/qmi_wwan.c

between commit:

  a8079092c1bb ("net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module")

from the net tree and commit:

  2070c48cf2b7 ("qmi_wwan: Add support for Dell Wireless 5809e 4G Modem")

from the net-next tree.

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

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

diff --cc drivers/net/usb/qmi_wwan.c
index 64a60afbe50c,1f7a7cd97e50..000000000000
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@@ -785,7 -785,7 +785,8 @@@ static const struct usb_device_id produ
  	{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},	/* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
  	{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},	/* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
  	{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},	/* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
+ 	{QMI_FIXED_INTF(0x413c, 0x81b1, 8)},	/* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card */
 +	{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},	/* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
  	{QMI_FIXED_INTF(0x03f0, 0x581d, 4)},	/* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
  
  	/* 4. Gobi 1000 devices */

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-08-10  1:24 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-08-10  1:24 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Ian Campbell, Radha Mohan Chintakuntla

Hi all,

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

  drivers/net/ethernet/cavium/Kconfig

between commit:

  22f54bf932a0 ("net: thunderx: remove effective "default y" from Kconfig if ARCH_THUNDER=y")

from the net tree and commit:

  274b0b3984a9 ("net: thunderx: Select CONFIG_MDIO_OCTEON for ThunderX NIC")

from the net-next tree.

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

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

diff --cc drivers/net/ethernet/cavium/Kconfig
index 02e23e6f1424,358442087878..000000000000
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@@ -34,6 -36,9 +34,8 @@@ config THUNDER_NIC_V
  config	THUNDER_NIC_BGX
  	tristate "Thunder MAC interface driver (BGX)"
  	depends on 64BIT
 -	default ARCH_THUNDER
+ 	select PHYLIB
+ 	select MDIO_OCTEON
  	---help---
  	  This driver supports programming and controlling of MAC
  	  interface from NIC physical function driver.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-07-31  0:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-07-31  0:35 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Karicheri, Muralidharan, WingMan Kwok

Hi all,

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

  drivers/net/ethernet/ti/netcp_ethss.c

between commit:

  31a184b7acbc ("net: netcp: ethss: cleanup gbe_probe() and gbe_remove() functions")

from the net tree and commit:

  489e8a2f09d7 ("net: netcp: Fixes to CPSW statistics collection")

from the net-next tree.

I fixed it up (using the error path from the former) and can carry the
fix as necessary (no action is required).

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-07-30  2:10 Stephen Rothwell
@ 2015-07-30  8:06 ` Nikolay Aleksandrov
  0 siblings, 0 replies; 325+ messages in thread
From: Nikolay Aleksandrov @ 2015-07-30  8:06 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Satish Ashok

On 07/30/2015 04:10 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/bridge/br_multicast.c
> 
> between commit:
> 
>   544586f742b4 ("bridge: mcast: give fast leave precedence over multicast router and querier")
> 
> from the net tree and commit:
> 
>   09cf0211f970 ("bridge: mdb: fill state in br_mdb_notify")
> 
> from the net-next tree.
> 
> I fixed it up (hopefully - see below) and can carry the fix as necessary
> (no action is required).
> 

Right, looks good. Thank you!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-07-30  2:10 Stephen Rothwell
  2015-07-30  8:06 ` Nikolay Aleksandrov
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-07-30  2:10 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Satish Ashok, Nikolay Aleksandrov

Hi all,

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

  net/bridge/br_multicast.c

between commit:

  544586f742b4 ("bridge: mcast: give fast leave precedence over multicast router and querier")

from the net tree and commit:

  09cf0211f970 ("bridge: mdb: fill state in br_mdb_notify")

from the net-next tree.

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

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

diff --cc net/bridge/br_multicast.c
index 0b39dcc65b94,fd238587e032..000000000000
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@@ -1424,31 -1441,6 +1440,32 @@@ br_multicast_leave_group(struct net_bri
  	if (!mp)
  		goto out;
  
 +	if (port && (port->flags & BR_MULTICAST_FAST_LEAVE)) {
 +		struct net_bridge_port_group __rcu **pp;
 +
 +		for (pp = &mp->ports;
 +		     (p = mlock_dereference(*pp, br)) != NULL;
 +		     pp = &p->next) {
 +			if (p->port != port)
 +				continue;
 +
 +			rcu_assign_pointer(*pp, p->next);
 +			hlist_del_init(&p->mglist);
 +			del_timer(&p->timer);
++			br_mdb_notify(br->dev, port, group, RTM_DELMDB,
++				      p->state);
 +			call_rcu_bh(&p->rcu, br_multicast_free_pg);
- 			br_mdb_notify(br->dev, port, group, RTM_DELMDB);
 +
 +			if (!mp->ports && !mp->mglist &&
 +			    netif_running(br->dev))
 +				mod_timer(&mp->timer, jiffies);
 +		}
 +		goto out;
 +	}
 +
 +	if (timer_pending(&other_query->timer))
 +		goto out;
 +
  	if (br->multicast_querier) {
  		__br_multicast_send_query(br, port, &mp->addr);
  

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-07-28  1:26 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-07-28  1:26 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Florian Westphal

Hi all,

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

  net/ipv4/ip_fragment.c

between commit:

  0e60d245a0be ("inet: frag: change *_frag_mem_limit functions to take netns_frags as argument")

from the net tree and commit:

  14fe22e33462 ("Revert "ipv4: use skb coalescing in defragmentation"")

from the net-next tree.

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

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

diff --cc net/ipv4/ip_fragment.c
index 921138f6c97c,f44bccc42494..000000000000
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@@ -587,35 -586,22 +586,22 @@@ static int ip_frag_reasm(struct ipq *qp
  		head->len -= clone->len;
  		clone->csum = 0;
  		clone->ip_summed = head->ip_summed;
 -		add_frag_mem_limit(&qp->q, clone->truesize);
 +		add_frag_mem_limit(qp->q.net, clone->truesize);
  	}
  
+ 	skb_shinfo(head)->frag_list = head->next;
  	skb_push(head, head->data - skb_network_header(head));
  
- 	sum_truesize = head->truesize;
- 	for (fp = head->next; fp;) {
- 		bool headstolen;
- 		int delta;
- 		struct sk_buff *next = fp->next;
- 
- 		sum_truesize += fp->truesize;
+ 	for (fp=head->next; fp; fp = fp->next) {
+ 		head->data_len += fp->len;
+ 		head->len += fp->len;
  		if (head->ip_summed != fp->ip_summed)
  			head->ip_summed = CHECKSUM_NONE;
  		else if (head->ip_summed == CHECKSUM_COMPLETE)
  			head->csum = csum_add(head->csum, fp->csum);
- 
- 		if (skb_try_coalesce(head, fp, &headstolen, &delta)) {
- 			kfree_skb_partial(fp, headstolen);
- 		} else {
- 			if (!skb_shinfo(head)->frag_list)
- 				skb_shinfo(head)->frag_list = fp;
- 			head->data_len += fp->len;
- 			head->len += fp->len;
- 			head->truesize += fp->truesize;
- 		}
- 		fp = next;
+ 		head->truesize += fp->truesize;
  	}
- 	sub_frag_mem_limit(qp->q.net, sum_truesize);
 -	sub_frag_mem_limit(&qp->q, head->truesize);
++	sub_frag_mem_limit(qp->q.net, head->truesize);
  
  	head->next = NULL;
  	head->dev = dev;

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-07-17  0:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-07-17  0:49 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nikolay Aleksandrov, Satish Ashok

Hi all,

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

  net/bridge/br_mdb.c

between commit:

  5ebc784625ea ("bridge: mdb: fix double add notification")

from the net tree and commit:

  09cf0211f970 ("bridge: mdb: fill state in br_mdb_notify")

from the net-next tree.

I fixed it up (I removed the br_mdb_notify call as per the former patch)
and can carry the fix as necessary (no action is required).



-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-06-22  2:58 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-06-22  2:58 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Willem de Bruijn

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

Hi all,

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

  net/packet/af_packet.c

between commit:

  468479e6043c ("packet: avoid out of bounds read in round robin fanout")

from the net tree and commit:

  3b3a5b0aab5b ("packet: rollover huge flows before small flows")

from the net-next tree.

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

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

diff --cc net/packet/af_packet.c
index fe1610ddeacf,20e8c40da90d..000000000000
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@@ -1272,6 -1326,30 +1326,20 @@@ static void packet_sock_destruct(struc
  	sk_refcnt_debug_dec(sk);
  }
  
 -static int fanout_rr_next(struct packet_fanout *f, unsigned int num)
 -{
 -	int x = atomic_read(&f->rr_cur) + 1;
 -
 -	if (x >= num)
 -		x = 0;
 -
 -	return x;
 -}
 -
+ static bool fanout_flow_is_huge(struct packet_sock *po, struct sk_buff *skb)
+ {
+ 	u32 rxhash;
+ 	int i, count = 0;
+ 
+ 	rxhash = skb_get_hash(skb);
+ 	for (i = 0; i < ROLLOVER_HLEN; i++)
+ 		if (po->rollover->history[i] == rxhash)
+ 			count++;
+ 
+ 	po->rollover->history[prandom_u32() % ROLLOVER_HLEN] = rxhash;
+ 	return count > (ROLLOVER_HLEN >> 1);
+ }
+ 
  static unsigned int fanout_demux_hash(struct packet_fanout *f,
  				      struct sk_buff *skb,
  				      unsigned int num)

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-05-21  2:59 Stephen Rothwell
@ 2015-05-21  3:29 ` Florian Fainelli
  0 siblings, 0 replies; 325+ messages in thread
From: Florian Fainelli @ 2015-05-21  3:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Tim Beale

2015-05-20 19:59 GMT-07:00 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
> phy_start() always re-enables the phy interrupts") from the net tree
> and commit 3e2186e02112 ("net: phy: Add state machine state transitions
> debug prints") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks correct to me, thanks Stephen!

>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc drivers/net/phy/phy.c
> index 47cd578052fc,1457ecf75dcc..000000000000
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@@ -783,7 -794,8 +808,8 @@@ void phy_state_machine(struct work_stru
>         struct delayed_work *dwork = to_delayed_work(work);
>         struct phy_device *phydev =
>                         container_of(dwork, struct phy_device, state_queue);
>  -      bool needs_aneg = false, do_suspend = false, do_resume = false;
>  +      bool needs_aneg = false, do_suspend = false;
> +       enum phy_state old_state;
>         int err = 0;
>
>         mutex_lock(&phydev->lock);



-- 
Florian

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-21  2:59 Stephen Rothwell
  2015-05-21  3:29 ` Florian Fainelli
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-21  2:59 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Florian Fainelli, Tim Beale

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
phy_start() always re-enables the phy interrupts") from the net tree
and commit 3e2186e02112 ("net: phy: Add state machine state transitions
debug prints") from the net-next tree.

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

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

diff --cc drivers/net/phy/phy.c
index 47cd578052fc,1457ecf75dcc..000000000000
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@@ -783,7 -794,8 +808,8 @@@ void phy_state_machine(struct work_stru
  	struct delayed_work *dwork = to_delayed_work(work);
  	struct phy_device *phydev =
  			container_of(dwork, struct phy_device, state_queue);
 -	bool needs_aneg = false, do_suspend = false, do_resume = false;
 +	bool needs_aneg = false, do_suspend = false;
+ 	enum phy_state old_state;
  	int err = 0;
  
  	mutex_lock(&phydev->lock);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-18  3:39 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-18  3:39 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Roopa Prabhu, Jiri Pirko, Scott Feldman

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/switchdev/switchdev.c between commit eea39946a1f3 ("rename
RTNH_F_EXTERNAL to RTNH_F_OFFLOAD") from the net tree and various
commits from the net-next tree.

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

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

diff --cc net/switchdev/switchdev.c
index 055453d48668,0409f9b5bdbc..000000000000
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@@ -328,18 -670,13 +670,13 @@@ int switchdev_fib_ipv4_add(u32 dst, in
  	if (fi->fib_net->ipv4.fib_offload_disabled)
  		return 0;
  
- 	dev = netdev_switch_get_dev_by_nhs(fi);
+ 	dev = switchdev_get_dev_by_nhs(fi);
  	if (!dev)
  		return 0;
- 	ops = dev->swdev_ops;
- 
- 	if (ops->swdev_fib_ipv4_add) {
- 		err = ops->swdev_fib_ipv4_add(dev, htonl(dst), dst_len,
- 					      fi, tos, type, nlflags,
- 					      tb_id);
- 		if (!err)
- 			fi->fib_flags |= RTNH_F_OFFLOAD;
- 	}
+ 
+ 	err = switchdev_port_obj_add(dev, &fib_obj);
+ 	if (!err)
 -		fi->fib_flags |= RTNH_F_EXTERNAL;
++		fi->fib_flags |= RTNH_F_OFFLOAD;
  
  	return err;
  }
@@@ -357,27 -694,34 +694,34 @@@ EXPORT_SYMBOL_GPL(switchdev_fib_ipv4_ad
   *
   *	Delete IPv4 route entry from switch device.
   */
- int netdev_switch_fib_ipv4_del(u32 dst, int dst_len, struct fib_info *fi,
- 			       u8 tos, u8 type, u32 tb_id)
+ int switchdev_fib_ipv4_del(u32 dst, int dst_len, struct fib_info *fi,
+ 			   u8 tos, u8 type, u32 tb_id)
  {
+ 	struct switchdev_obj fib_obj = {
+ 		.id = SWITCHDEV_OBJ_IPV4_FIB,
+ 		.u.ipv4_fib = {
+ 			.dst = dst,
+ 			.dst_len = dst_len,
+ 			.fi = fi,
+ 			.tos = tos,
+ 			.type = type,
+ 			.nlflags = 0,
+ 			.tb_id = tb_id,
+ 		},
+ 	};
  	struct net_device *dev;
- 	const struct swdev_ops *ops;
  	int err = 0;
  
 -	if (!(fi->fib_flags & RTNH_F_EXTERNAL))
 +	if (!(fi->fib_flags & RTNH_F_OFFLOAD))
  		return 0;
  
- 	dev = netdev_switch_get_dev_by_nhs(fi);
+ 	dev = switchdev_get_dev_by_nhs(fi);
  	if (!dev)
  		return 0;
- 	ops = dev->swdev_ops;
  
- 	if (ops->swdev_fib_ipv4_del) {
- 		err = ops->swdev_fib_ipv4_del(dev, htonl(dst), dst_len,
- 					      fi, tos, type, tb_id);
- 		if (!err)
- 			fi->fib_flags &= ~RTNH_F_OFFLOAD;
- 	}
+ 	err = switchdev_port_obj_del(dev, &fib_obj);
+ 	if (!err)
 -		fi->fib_flags &= ~RTNH_F_EXTERNAL;
++		fi->fib_flags &= ~RTNH_F_OFFLOAD;
  
  	return err;
  }

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-13  3:05 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-13  3:05 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nicolas Dichtel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/net_namespace.c between commit e3d8ecb70e16 ("netns: return
RTM_NEWNSID instead of RTM_GETNSID on a get") from the net tree and
commit cab3c8ec8d57 ("netns: always provide the id to rtnl_net_fill()")
from the net-next tree.

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

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

diff --cc net/core/net_namespace.c
index 572af0011997,a665bf490c88..000000000000
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@@ -600,8 -639,9 +639,9 @@@ static int rtnl_net_getid(struct sk_buf
  		goto out;
  	}
  
+ 	id = peernet2id(net, peer);
  	err = rtnl_net_fill(msg, NETLINK_CB(skb).portid, nlh->nlmsg_seq, 0,
- 			    RTM_NEWNSID, net, peer, -1);
 -			    RTM_GETNSID, net, id);
++			    RTM_NEWNSID, net, id);
  	if (err < 0)
  		goto err_out;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-12  1:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-12  1:49 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Stefan Wahren, Varka Bhadram

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/qualcomm/qca_spi.c between commit 268be0f7a7d9
("net: qca_spi: Fix possible race during probe") from the net tree and
commit cf9d0dcc5a46 ("ethernet: qualcomm: use spi instead of
spi_device") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/qualcomm/qca_spi.c
index 6af028d5f9bc,c6b749880e46..000000000000
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@@ -909,12 -909,10 +909,12 @@@ qca_spi_probe(struct spi_device *spi
  		return -ENOMEM;
  	}
  	qca->net_dev = qcaspi_devs;
- 	qca->spi_dev = spi_device;
+ 	qca->spi_dev = spi;
  	qca->legacy_mode = legacy_mode;
  
- 	spi_set_drvdata(spi_device, qcaspi_devs);
++	spi_set_drvdata(spi, qcaspi_devs);
 +
- 	mac = of_get_mac_address(spi_device->dev.of_node);
+ 	mac = of_get_mac_address(spi->dev.of_node);
  
  	if (mac)
  		ether_addr_copy(qca->net_dev->dev_addr, mac);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-12  1:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-12  1:49 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
include/net/codel.h between commit a5d280904050 ("codel: fix
maxpacket/mtu confusion") from the net tree and commit 80ba92fa1a92
("codel: add ce_threshold attribute") from the net-next tree.

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

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

diff --cc include/net/codel.h
index 1e18005f7f65,8c0f78f209e8..000000000000
--- a/include/net/codel.h
+++ b/include/net/codel.h
@@@ -119,14 -119,14 +119,16 @@@ static inline u32 codel_time_to_us(code
  /**
   * struct codel_params - contains codel parameters
   * @target:	target queue size (in time units)
+  * @ce_threshold:  threshold for marking packets with ECN CE
   * @interval:	width of moving time window
 + * @mtu:	device mtu, or minimal queue backlog in bytes.
   * @ecn:	is Explicit Congestion Notification enabled
   */
  struct codel_params {
  	codel_time_t	target;
+ 	codel_time_t	ce_threshold;
  	codel_time_t	interval;
 +	u32		mtu;
  	bool		ecn;
  };
  
@@@ -166,14 -167,16 +169,18 @@@ struct codel_stats 
  	u32		maxpacket;
  	u32		drop_count;
  	u32		ecn_mark;
+ 	u32		ce_mark;
  };
  
+ #define CODEL_DISABLED_THRESHOLD INT_MAX
+ 
 -static void codel_params_init(struct codel_params *params)
 +static void codel_params_init(struct codel_params *params,
 +			      const struct Qdisc *sch)
  {
  	params->interval = MS2TIME(100);
  	params->target = MS2TIME(5);
+ 	params->ce_threshold = CODEL_DISABLED_THRESHOLD;
 +	params->mtu = psched_mtu(qdisc_dev(sch));
  	params->ecn = false;
  }
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-05-12  1:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-05-12  1:49 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Herbert Xu, Eric W. Biederman

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/sock.c between commit 2e70aedd3d52 ("Revert "net: kernel
socket should be released in init_net namespace"") from the net tree
and commit affb9792f1d9 ("net: kill sk_change_net and
sk_release_kernel") from the net-next tree.

I fixed it up (the latter removed a function updated by the former) and
can carry the fix as necessary (no action is required).

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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-04-10  3:12 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-04-10  3:12 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Phil Reid, Dinh Nguyen

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c between commit
27015f8c1757 ("stmmac: devm_reset_control_get can return PROBE_DEFER")
from the net tree and commit cbe21d92e4d5 ("net: stmmac: make reset
control an optional requirement") from the net-next tree.

I fixed it up (I just used the net-next version) and can carry the fix
as necessary (no action is required).

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-04-07  3:21 Stephen Rothwell
@ 2015-04-07 16:54 ` Cong Wang
  0 siblings, 0 replies; 325+ messages in thread
From: Cong Wang @ 2015-04-07 16:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Linux Kernel Network Developers, linux-next, LKML,
	Eric W. Biederman

On Mon, Apr 6, 2015 at 8:21 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> net/core/fib_rules.c between commit 419df12fb5fa ("net: move
> fib_rules_unregister() under rtnl lock") from the net tree and commit
> efd7ef1c1929 ("net: Kill hold_net release_net") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>

Looks correct to me.

Thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-04-07  3:18 Stephen Rothwell
@ 2015-04-07 11:42 ` Ido Shamay
  0 siblings, 0 replies; 325+ messages in thread
From: Ido Shamay @ 2015-04-07 11:42 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Jack Morgenstein, Ido Shamay, Or Gerlitz

On 4/7/2015 6:18 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/mellanox/mlx4/cmd.c between commit fde913e25496
> ("net/mlx4_core: Fix error message deprecation for ConnectX-2 cards")
> from the net tree and commit a130b5905732 ("net/mlx4: Add SET_PORT
> opcode modifiers enumeration") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-04-07  3:21 Stephen Rothwell
  2015-04-07 16:54 ` Cong Wang
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-04-07  3:21 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric W. Biederman, WANG Cong

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/fib_rules.c between commit 419df12fb5fa ("net: move
fib_rules_unregister() under rtnl lock") from the net tree and commit
efd7ef1c1929 ("net: Kill hold_net release_net") from the net-next tree.

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

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

diff --cc net/core/fib_rules.c
index e4fdc9dfb2c7,68ea6950cad1..000000000000
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@@ -175,10 -165,10 +165,10 @@@ void fib_rules_unregister(struct fib_ru
  
  	spin_lock(&net->rules_mod_lock);
  	list_del_rcu(&ops->list);
 -	fib_rules_cleanup_ops(ops);
  	spin_unlock(&net->rules_mod_lock);
  
 +	fib_rules_cleanup_ops(ops);
- 	call_rcu(&ops->rcu, fib_rules_put_rcu);
+ 	kfree_rcu(ops, rcu);
  }
  EXPORT_SYMBOL_GPL(fib_rules_unregister);
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-04-07  3:18 Stephen Rothwell
  2015-04-07 11:42 ` Ido Shamay
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-04-07  3:18 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Jack Morgenstein, Ido Shamay, Or Gerlitz

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/mellanox/mlx4/cmd.c between commit fde913e25496
("net/mlx4_core: Fix error message deprecation for ConnectX-2 cards")
from the net tree and commit a130b5905732 ("net/mlx4: Add SET_PORT
opcode modifiers enumeration") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/mellanox/mlx4/cmd.c
index 546ca4226916,06993ea9e6ba..000000000000
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@@ -724,9 -725,9 +725,10 @@@ static int mlx4_cmd_wait(struct mlx4_de
  		 * on the host, we deprecate the error message for this
  		 * specific command/input_mod/opcode_mod/fw-status to be debug.
  		 */
 -		if (op == MLX4_CMD_SET_PORT && in_modifier == 1 &&
 +		if (op == MLX4_CMD_SET_PORT &&
 +		    (in_modifier == 1 || in_modifier == 2) &&
- 		    op_modifier == 0 && context->fw_status == CMD_STAT_BAD_SIZE)
+ 		    op_modifier == MLX4_SET_PORT_IB_OPCODE &&
+ 		    context->fw_status == CMD_STAT_BAD_SIZE)
  			mlx4_dbg(dev, "command 0x%x failed: fw status = 0x%x\n",
  				 op, context->fw_status);
  		else

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-03-25  2:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-25  2:18 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Michal Kubeček, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got conflicts in
net/ipv4/tcp_ipv4.c and net/ipv6/tcp_ipv6.c between commit d0c294c53a77
("tcp: prevent fetching dst twice in early demux code") from the  tree
and commit f7e4eb03f9d9 ("inet: ip early demux should avoid request
sockets") from the net-next tree.

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

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

diff --cc net/ipv4/tcp_ipv4.c
index f1756ee02207,4e90217003e8..000000000000
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@@ -1517,8 -1521,8 +1521,8 @@@ void tcp_v4_early_demux(struct sk_buff 
  	if (sk) {
  		skb->sk = sk;
  		skb->destructor = sock_edemux;
- 		if (sk->sk_state != TCP_TIME_WAIT) {
+ 		if (sk_fullsock(sk)) {
 -			struct dst_entry *dst = sk->sk_rx_dst;
 +			struct dst_entry *dst = READ_ONCE(sk->sk_rx_dst);
  
  			if (dst)
  				dst = dst_check(dst, 0);
diff --cc net/ipv6/tcp_ipv6.c
index b283a498f7a4,4a4e6d30c448..000000000000
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@@ -1584,8 -1544,8 +1544,8 @@@ static void tcp_v6_early_demux(struct s
  	if (sk) {
  		skb->sk = sk;
  		skb->destructor = sock_edemux;
- 		if (sk->sk_state != TCP_TIME_WAIT) {
+ 		if (sk_fullsock(sk)) {
 -			struct dst_entry *dst = sk->sk_rx_dst;
 +			struct dst_entry *dst = READ_ONCE(sk->sk_rx_dst);
  
  			if (dst)
  				dst = dst_check(dst, inet6_sk(sk)->rx_dst_cookie);

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-23 12:47 ` Pablo Neira Ayuso
  2015-03-23 12:55   ` Joe Perches
@ 2015-03-24  2:29   ` David Miller
  1 sibling, 0 replies; 325+ messages in thread
From: David Miller @ 2015-03-24  2:29 UTC (permalink / raw)
  To: pablo; +Cc: sfr, netdev, linux-next, linux-kernel, kaber

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 23 Mar 2015 13:47:23 +0100

> On Mon, Mar 23, 2015 at 02:08:41PM +1100, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the net-next tree got a conflict in
>> net/netfilter/nf_tables_core.c between commit 4017a7ee693d ("netfilter:
>> restore rule tracing via nfnetlink_log") from the net tree and commit
>> 01ef16c2dd2e ("netfilter: nf_tables: minor tracing cleanups") from the
>> net-next tree.
>> 
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
> 
> This looks good, thanks for adressing this conflict Stephen.

Pablo, I just pushed out a merge of net into net-next, please double
check that I handled this conflict correctly.

Thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-23 12:55   ` Joe Perches
@ 2015-03-23 13:06     ` Pablo Neira Ayuso
  0 siblings, 0 replies; 325+ messages in thread
From: Pablo Neira Ayuso @ 2015-03-23 13:06 UTC (permalink / raw)
  To: Joe Perches
  Cc: Stephen Rothwell, David Miller, netdev, linux-next, linux-kernel,
	Patrick McHardy

On Mon, Mar 23, 2015 at 05:55:31AM -0700, Joe Perches wrote:
> On Mon, 2015-03-23 at 13:47 +0100, Pablo Neira Ayuso wrote:
> > On Mon, Mar 23, 2015 at 02:08:41PM +1100, Stephen Rothwell wrote:
> > > Today's linux-next merge of the net-next tree got a conflict in
> > > net/netfilter/nf_tables_core.c between commit 4017a7ee693d ("netfilter:
> > > restore rule tracing via nfnetlink_log") from the net tree and commit
> > > 01ef16c2dd2e ("netfilter: nf_tables: minor tracing cleanups") from the
> > > net-next tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > "
> > This looks good, thanks for adressing this conflict Stephen.
> 
> trivia:
> 
> > > diff --cc net/netfilter/nf_tables_core.c
> []
> > > + static struct nf_loginfo trace_loginfo = {
> > > + 	.type = NF_LOG_TYPE_LOG,
> > > + 	.u = {
> > > + 		.log = {
> > > + 			.level = 4,
> 
> Perhaps all the .level = 4 uses should be LOGLEVEL_WARNING
> and .level = 5 should be LOGLEVEL_NOTICE

Yes, we can push a follow up patch to net-next changing all these
spots in the netfilter tree. Would you send a patch for this?

Thanks.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-23 12:47 ` Pablo Neira Ayuso
@ 2015-03-23 12:55   ` Joe Perches
  2015-03-23 13:06     ` Pablo Neira Ayuso
  2015-03-24  2:29   ` David Miller
  1 sibling, 1 reply; 325+ messages in thread
From: Joe Perches @ 2015-03-23 12:55 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Stephen Rothwell, David Miller, netdev, linux-next, linux-kernel,
	Patrick McHardy

On Mon, 2015-03-23 at 13:47 +0100, Pablo Neira Ayuso wrote:
> On Mon, Mar 23, 2015 at 02:08:41PM +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the net-next tree got a conflict in
> > net/netfilter/nf_tables_core.c between commit 4017a7ee693d ("netfilter:
> > restore rule tracing via nfnetlink_log") from the net tree and commit
> > 01ef16c2dd2e ("netfilter: nf_tables: minor tracing cleanups") from the
> > net-next tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> "
> This looks good, thanks for adressing this conflict Stephen.

trivia:

> > diff --cc net/netfilter/nf_tables_core.c
[]
> > + static struct nf_loginfo trace_loginfo = {
> > + 	.type = NF_LOG_TYPE_LOG,
> > + 	.u = {
> > + 		.log = {
> > + 			.level = 4,

Perhaps all the .level = 4 uses should be LOGLEVEL_WARNING
and .level = 5 should be LOGLEVEL_NOTICE



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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-23  3:08 Stephen Rothwell
@ 2015-03-23 12:47 ` Pablo Neira Ayuso
  2015-03-23 12:55   ` Joe Perches
  2015-03-24  2:29   ` David Miller
  0 siblings, 2 replies; 325+ messages in thread
From: Pablo Neira Ayuso @ 2015-03-23 12:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Patrick McHardy

On Mon, Mar 23, 2015 at 02:08:41PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/netfilter/nf_tables_core.c between commit 4017a7ee693d ("netfilter:
> restore rule tracing via nfnetlink_log") from the net tree and commit
> 01ef16c2dd2e ("netfilter: nf_tables: minor tracing cleanups") from the
> net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This looks good, thanks for adressing this conflict Stephen.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc net/netfilter/nf_tables_core.c
> index 2d298dccb6dd,77165bf023f3..000000000000
> --- a/net/netfilter/nf_tables_core.c
> +++ b/net/netfilter/nf_tables_core.c
> @@@ -21,6 -21,48 +21,48 @@@
>   #include <net/netfilter/nf_tables.h>
>   #include <net/netfilter/nf_log.h>
>   
> + enum nft_trace {
> + 	NFT_TRACE_RULE,
> + 	NFT_TRACE_RETURN,
> + 	NFT_TRACE_POLICY,
> + };
> + 
> + static const char *const comments[] = {
> + 	[NFT_TRACE_RULE]	= "rule",
> + 	[NFT_TRACE_RETURN]	= "return",
> + 	[NFT_TRACE_POLICY]	= "policy",
> + };
> + 
> + static struct nf_loginfo trace_loginfo = {
> + 	.type = NF_LOG_TYPE_LOG,
> + 	.u = {
> + 		.log = {
> + 			.level = 4,
> + 			.logflags = NF_LOG_MASK,
> + 	        },
> + 	},
> + };
> + 
> + static void __nft_trace_packet(const struct nft_pktinfo *pkt,
> + 			       const struct nft_chain *chain,
> + 			       int rulenum, enum nft_trace type)
> + {
> + 	struct net *net = dev_net(pkt->in ? pkt->in : pkt->out);
> + 
>  -	nf_log_packet(net, pkt->xt.family, pkt->ops->hooknum, pkt->skb, pkt->in,
>  -		      pkt->out, &trace_loginfo, "TRACE: %s:%s:%s:%u ",
>  -		      chain->table->name, chain->name, comments[type],
>  -		      rulenum);
> ++	nf_log_trace(net, pkt->xt.family, pkt->ops->hooknum, pkt->skb, pkt->in,
> ++		     pkt->out, &trace_loginfo, "TRACE: %s:%s:%s:%u ",
> ++		     chain->table->name, chain->name, comments[type],
> ++		     rulenum);
> + }
> + 
> + static inline void nft_trace_packet(const struct nft_pktinfo *pkt,
> + 				    const struct nft_chain *chain,
> + 				    int rulenum, enum nft_trace type)
> + {
> + 	if (unlikely(pkt->skb->nf_trace))
> + 		__nft_trace_packet(pkt, chain, rulenum, type);
> + }
> + 
>   static void nft_cmp_fast_eval(const struct nft_expr *expr,
>   			      struct nft_data data[NFT_REG_MAX + 1])
>   {



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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-03-23  3:08 Stephen Rothwell
  2015-03-23 12:47 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-23  3:08 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Pablo Neira Ayuso, Patrick McHardy

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/nf_tables_core.c between commit 4017a7ee693d ("netfilter:
restore rule tracing via nfnetlink_log") from the net tree and commit
01ef16c2dd2e ("netfilter: nf_tables: minor tracing cleanups") from the
net-next tree.

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

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

diff --cc net/netfilter/nf_tables_core.c
index 2d298dccb6dd,77165bf023f3..000000000000
--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@@ -21,6 -21,48 +21,48 @@@
  #include <net/netfilter/nf_tables.h>
  #include <net/netfilter/nf_log.h>
  
+ enum nft_trace {
+ 	NFT_TRACE_RULE,
+ 	NFT_TRACE_RETURN,
+ 	NFT_TRACE_POLICY,
+ };
+ 
+ static const char *const comments[] = {
+ 	[NFT_TRACE_RULE]	= "rule",
+ 	[NFT_TRACE_RETURN]	= "return",
+ 	[NFT_TRACE_POLICY]	= "policy",
+ };
+ 
+ static struct nf_loginfo trace_loginfo = {
+ 	.type = NF_LOG_TYPE_LOG,
+ 	.u = {
+ 		.log = {
+ 			.level = 4,
+ 			.logflags = NF_LOG_MASK,
+ 	        },
+ 	},
+ };
+ 
+ static void __nft_trace_packet(const struct nft_pktinfo *pkt,
+ 			       const struct nft_chain *chain,
+ 			       int rulenum, enum nft_trace type)
+ {
+ 	struct net *net = dev_net(pkt->in ? pkt->in : pkt->out);
+ 
 -	nf_log_packet(net, pkt->xt.family, pkt->ops->hooknum, pkt->skb, pkt->in,
 -		      pkt->out, &trace_loginfo, "TRACE: %s:%s:%s:%u ",
 -		      chain->table->name, chain->name, comments[type],
 -		      rulenum);
++	nf_log_trace(net, pkt->xt.family, pkt->ops->hooknum, pkt->skb, pkt->in,
++		     pkt->out, &trace_loginfo, "TRACE: %s:%s:%s:%u ",
++		     chain->table->name, chain->name, comments[type],
++		     rulenum);
+ }
+ 
+ static inline void nft_trace_packet(const struct nft_pktinfo *pkt,
+ 				    const struct nft_chain *chain,
+ 				    int rulenum, enum nft_trace type)
+ {
+ 	if (unlikely(pkt->skb->nf_trace))
+ 		__nft_trace_packet(pkt, chain, rulenum, type);
+ }
+ 
  static void nft_cmp_fast_eval(const struct nft_expr *expr,
  			      struct nft_data data[NFT_REG_MAX + 1])
  {

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-03-16  2:04 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-16  2:04 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv4/inet_diag.c between commit c8e2c80d7ec0 ("inet_diag: fix
possible overflow in inet_diag_dump_one_icsk()") from the net tree and
commit a4458343ac59 ("inet_diag: factorize code in new
inet_diag_msg_common_fill() helper") from the net-next tree.

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

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

diff --cc net/ipv4/inet_diag.c
index 592aff37366b,ac7b5c909fe7..000000000000
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@@ -71,27 -66,39 +66,53 @@@ static void inet_diag_unlock_handler(co
  	mutex_unlock(&inet_diag_table_mutex);
  }
  
 +static size_t inet_sk_attr_size(void)
 +{
 +	return	  nla_total_size(sizeof(struct tcp_info))
 +		+ nla_total_size(1) /* INET_DIAG_SHUTDOWN */
 +		+ nla_total_size(1) /* INET_DIAG_TOS */
 +		+ nla_total_size(1) /* INET_DIAG_TCLASS */
 +		+ nla_total_size(sizeof(struct inet_diag_meminfo))
 +		+ nla_total_size(sizeof(struct inet_diag_msg))
 +		+ nla_total_size(SK_MEMINFO_VARS * sizeof(u32))
 +		+ nla_total_size(TCP_CA_NAME_MAX)
 +		+ nla_total_size(sizeof(struct tcpvegas_info))
 +		+ 64;
 +}
 +
+ static void inet_diag_msg_common_fill(struct inet_diag_msg *r, struct sock *sk)
+ {
+ 	r->idiag_family = sk->sk_family;
+ 
+ 	r->id.idiag_sport = htons(sk->sk_num);
+ 	r->id.idiag_dport = sk->sk_dport;
+ 	r->id.idiag_if = sk->sk_bound_dev_if;
+ 	sock_diag_save_cookie(sk, r->id.idiag_cookie);
+ 
+ #if IS_ENABLED(CONFIG_IPV6)
+ 	if (sk->sk_family == AF_INET6) {
+ 		*(struct in6_addr *)r->id.idiag_src = sk->sk_v6_rcv_saddr;
+ 		*(struct in6_addr *)r->id.idiag_dst = sk->sk_v6_daddr;
+ 	} else
+ #endif
+ 	{
+ 	memset(&r->id.idiag_src, 0, sizeof(r->id.idiag_src));
+ 	memset(&r->id.idiag_dst, 0, sizeof(r->id.idiag_dst));
+ 
+ 	r->id.idiag_src[0] = sk->sk_rcv_saddr;
+ 	r->id.idiag_dst[0] = sk->sk_daddr;
+ 	}
+ }
+ 
  int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
- 			      struct sk_buff *skb, struct inet_diag_req_v2 *req,
- 			      struct user_namespace *user_ns,		      	
- 			      u32 portid, u32 seq, u16 nlmsg_flags,
- 			      const struct nlmsghdr *unlh)
+ 		      struct sk_buff *skb, const struct inet_diag_req_v2 *req,
+ 		      struct user_namespace *user_ns,
+ 		      u32 portid, u32 seq, u16 nlmsg_flags,
+ 		      const struct nlmsghdr *unlh)
  {
  	const struct inet_sock *inet = inet_sk(sk);
+ 	const struct inet_diag_handler *handler;
+ 	int ext = req->idiag_ext;
  	struct inet_diag_msg *r;
  	struct nlmsghdr  *nlh;
  	struct nlattr *attr;

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-10 21:48   ` Stephen Rothwell
@ 2015-03-10 22:34     ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2015-03-10 22:34 UTC (permalink / raw)
  To: sfr
  Cc: netdev, linux-next, linux-kernel, joshc, boris.brezillon,
	cyrille.pitchen

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 11 Mar 2015 08:48:30 +1100

> Just wondering if you got that merge right?  Here is the diff from what
> I did yesterday to what you have in net-next:
 ...
> That section was removed by commit 421d9df0628b ("net/macb: merge
> at91_ether driver into macb driver") and I presumed its effect was
> moved into macb_probe().

Indeed, you're right, good catch.

Fixed and pushed out to net-next, thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-10  3:43 ` David Miller
@ 2015-03-10 21:48   ` Stephen Rothwell
  2015-03-10 22:34     ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-10 21:48 UTC (permalink / raw)
  To: David Miller
  Cc: netdev, linux-next, linux-kernel, joshc, boris.brezillon,
	cyrille.pitchen

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

Hi Dave,

On Mon, 09 Mar 2015 23:43:29 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Mar 2015 12:08:42 +1100
> 
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/ethernet/cadence/macb.c between commit 0b2eb3e9bc73 ("net:
> > macb: constify macb configuration data") from the net tree and commits
> > a848748959d5 ("net: macb: remove #if defined(CONFIG_ARCH_AT91)
> > sections") and 421d9df0628b ("net/macb: merge at91_ether driver into
> > macb driver") from the net-next tree.
> > 
> > I fixed it up (I think - see below) and can carry the fix as necessary
> > (no action is required).
> 
> Thanks Stephen, I'm merging net into net-next right now and will resolve
> this similarly.

Just wondering if you got that merge right?  Here is the diff from what
I did yesterday to what you have in net-next:

diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index f032e2a245b0..f00be585f661 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2131,24 +2131,8 @@ static const struct net_device_ops macb_netdev_ops = {
  */
 static void macb_configure_caps(struct macb *bp)
 {
-	const struct of_device_id *match;
-	const struct macb_config *config;
 	u32 dcfg;
 
-	if (bp->pdev->dev.of_node) {
-		match = of_match_node(macb_dt_ids, bp->pdev->dev.of_node);
-		if (match && match->data) {
-			config = match->data;
-
-			bp->caps = config->caps;
-			/*
-			 * As we have access to the matching node, configure
-			 * DMA burst length as well
-			 */
-			bp->dma_burst_length = config->dma_burst_length;
-		}
-	}
-
 	if (MACB_BFEXT(IDNUM, macb_readl(bp, MID)) == 0x2)
 		bp->caps |= MACB_CAPS_MACB_IS_GEM;
 
That section was removed by commit 421d9df0628b ("net/macb: merge
at91_ether driver into macb driver") and I presumed its effect was
moved into macb_probe().

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-03-10  1:08 Stephen Rothwell
@ 2015-03-10  3:43 ` David Miller
  2015-03-10 21:48   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: David Miller @ 2015-03-10  3:43 UTC (permalink / raw)
  To: sfr
  Cc: netdev, linux-next, linux-kernel, joshc, boris.brezillon,
	cyrille.pitchen

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Mar 2015 12:08:42 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/cadence/macb.c between commit 0b2eb3e9bc73 ("net:
> macb: constify macb configuration data") from the net tree and commits
> a848748959d5 ("net: macb: remove #if defined(CONFIG_ARCH_AT91)
> sections") and 421d9df0628b ("net/macb: merge at91_ether driver into
> macb driver") from the net-next tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

Thanks Stephen, I'm merging net into net-next right now and will resolve
this similarly.

Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-03-10  1:08 Stephen Rothwell
  2015-03-10  3:43 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-10  1:08 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Josh Cartwright, Boris BREZILLON,
	Cyrille Pitchen

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/cadence/macb.c between commit 0b2eb3e9bc73 ("net:
macb: constify macb configuration data") from the net tree and commits
a848748959d5 ("net: macb: remove #if defined(CONFIG_ARCH_AT91)
sections") and 421d9df0628b ("net/macb: merge at91_ether driver into
macb driver") from the net-next 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 drivers/net/ethernet/cadence/macb.c
index 81d41539fcba,a4c5462c071a..000000000000
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@@ -2366,12 -2294,433 +2294,433 @@@ static int macb_init(struct platform_de
  		dev->hw_features &= ~NETIF_F_SG;
  	dev->features = dev->hw_features;
  
+ 	val = 0;
+ 	if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ 		val = GEM_BIT(RGMII);
+ 	else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
+ 		 (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ 		val = MACB_BIT(RMII);
+ 	else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ 		val = MACB_BIT(MII);
+ 
+ 	if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+ 		val |= MACB_BIT(CLKEN);
+ 
+ 	macb_or_gem_writel(bp, USRIO, val);
+ 
+ 	/* setup capacities */
+ 	macb_configure_caps(bp);
+ 
  	/* Set MII management clock divider */
- 	config = macb_mdc_clk_div(bp);
- 	config |= macb_dbw(bp);
- 	macb_writel(bp, NCFGR, config);
+ 	val = macb_mdc_clk_div(bp);
+ 	val |= macb_dbw(bp);
+ 	macb_writel(bp, NCFGR, val);
+ 
+ 	return 0;
+ 
+ err_disable_tx_clk:
+ 	clk_disable_unprepare(bp->tx_clk);
+ 
+ err_disable_hclk:
+ 	clk_disable_unprepare(bp->hclk);
+ 
+ err_disable_pclk:
+ 	clk_disable_unprepare(bp->pclk);
+ 
+ 	return err;
+ }
+ 
+ #if defined(CONFIG_OF)
+ /* 1518 rounded up */
+ #define AT91ETHER_MAX_RBUFF_SZ	0x600
+ /* max number of receive buffers */
+ #define AT91ETHER_MAX_RX_DESCR	9
+ 
+ /* Initialize and start the Receiver and Transmit subsystems */
+ static int at91ether_start(struct net_device *dev)
+ {
+ 	struct macb *lp = netdev_priv(dev);
+ 	dma_addr_t addr;
+ 	u32 ctl;
+ 	int i;
+ 
+ 	lp->rx_ring = dma_alloc_coherent(&lp->pdev->dev,
+ 					 (AT91ETHER_MAX_RX_DESCR *
+ 					  sizeof(struct macb_dma_desc)),
+ 					 &lp->rx_ring_dma, GFP_KERNEL);
+ 	if (!lp->rx_ring)
+ 		return -ENOMEM;
+ 
+ 	lp->rx_buffers = dma_alloc_coherent(&lp->pdev->dev,
+ 					    AT91ETHER_MAX_RX_DESCR *
+ 					    AT91ETHER_MAX_RBUFF_SZ,
+ 					    &lp->rx_buffers_dma, GFP_KERNEL);
+ 	if (!lp->rx_buffers) {
+ 		dma_free_coherent(&lp->pdev->dev,
+ 				  AT91ETHER_MAX_RX_DESCR *
+ 				  sizeof(struct macb_dma_desc),
+ 				  lp->rx_ring, lp->rx_ring_dma);
+ 		lp->rx_ring = NULL;
+ 		return -ENOMEM;
+ 	}
+ 
+ 	addr = lp->rx_buffers_dma;
+ 	for (i = 0; i < AT91ETHER_MAX_RX_DESCR; i++) {
+ 		lp->rx_ring[i].addr = addr;
+ 		lp->rx_ring[i].ctrl = 0;
+ 		addr += AT91ETHER_MAX_RBUFF_SZ;
+ 	}
+ 
+ 	/* Set the Wrap bit on the last descriptor */
+ 	lp->rx_ring[AT91ETHER_MAX_RX_DESCR - 1].addr |= MACB_BIT(RX_WRAP);
+ 
+ 	/* Reset buffer index */
+ 	lp->rx_tail = 0;
+ 
+ 	/* Program address of descriptor list in Rx Buffer Queue register */
+ 	macb_writel(lp, RBQP, lp->rx_ring_dma);
+ 
+ 	/* Enable Receive and Transmit */
+ 	ctl = macb_readl(lp, NCR);
+ 	macb_writel(lp, NCR, ctl | MACB_BIT(RE) | MACB_BIT(TE));
+ 
+ 	return 0;
+ }
+ 
+ /* Open the ethernet interface */
+ static int at91ether_open(struct net_device *dev)
+ {
+ 	struct macb *lp = netdev_priv(dev);
+ 	u32 ctl;
+ 	int ret;
+ 
+ 	/* Clear internal statistics */
+ 	ctl = macb_readl(lp, NCR);
+ 	macb_writel(lp, NCR, ctl | MACB_BIT(CLRSTAT));
+ 
+ 	macb_set_hwaddr(lp);
+ 
+ 	ret = at91ether_start(dev);
+ 	if (ret)
+ 		return ret;
+ 
+ 	/* Enable MAC interrupts */
+ 	macb_writel(lp, IER, MACB_BIT(RCOMP)	|
+ 			     MACB_BIT(RXUBR)	|
+ 			     MACB_BIT(ISR_TUND)	|
+ 			     MACB_BIT(ISR_RLE)	|
+ 			     MACB_BIT(TCOMP)	|
+ 			     MACB_BIT(ISR_ROVR)	|
+ 			     MACB_BIT(HRESP));
+ 
+ 	/* schedule a link state check */
+ 	phy_start(lp->phy_dev);
+ 
+ 	netif_start_queue(dev);
+ 
+ 	return 0;
+ }
+ 
+ /* Close the interface */
+ static int at91ether_close(struct net_device *dev)
+ {
+ 	struct macb *lp = netdev_priv(dev);
+ 	u32 ctl;
+ 
+ 	/* Disable Receiver and Transmitter */
+ 	ctl = macb_readl(lp, NCR);
+ 	macb_writel(lp, NCR, ctl & ~(MACB_BIT(TE) | MACB_BIT(RE)));
+ 
+ 	/* Disable MAC interrupts */
+ 	macb_writel(lp, IDR, MACB_BIT(RCOMP)	|
+ 			     MACB_BIT(RXUBR)	|
+ 			     MACB_BIT(ISR_TUND)	|
+ 			     MACB_BIT(ISR_RLE)	|
+ 			     MACB_BIT(TCOMP)	|
+ 			     MACB_BIT(ISR_ROVR) |
+ 			     MACB_BIT(HRESP));
+ 
+ 	netif_stop_queue(dev);
+ 
+ 	dma_free_coherent(&lp->pdev->dev,
+ 			  AT91ETHER_MAX_RX_DESCR *
+ 			  sizeof(struct macb_dma_desc),
+ 			  lp->rx_ring, lp->rx_ring_dma);
+ 	lp->rx_ring = NULL;
+ 
+ 	dma_free_coherent(&lp->pdev->dev,
+ 			  AT91ETHER_MAX_RX_DESCR * AT91ETHER_MAX_RBUFF_SZ,
+ 			  lp->rx_buffers, lp->rx_buffers_dma);
+ 	lp->rx_buffers = NULL;
+ 
+ 	return 0;
+ }
+ 
+ /* Transmit packet */
+ static int at91ether_start_xmit(struct sk_buff *skb, struct net_device *dev)
+ {
+ 	struct macb *lp = netdev_priv(dev);
+ 
+ 	if (macb_readl(lp, TSR) & MACB_BIT(RM9200_BNQ)) {
+ 		netif_stop_queue(dev);
  
- 	mac = of_get_mac_address(pdev->dev.of_node);
+ 		/* Store packet information (to free when Tx completed) */
+ 		lp->skb = skb;
+ 		lp->skb_length = skb->len;
+ 		lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
+ 							DMA_TO_DEVICE);
+ 
+ 		/* Set address of the data in the Transmit Address register */
+ 		macb_writel(lp, TAR, lp->skb_physaddr);
+ 		/* Set length of the packet in the Transmit Control register */
+ 		macb_writel(lp, TCR, skb->len);
+ 
+ 	} else {
+ 		netdev_err(dev, "%s called, but device is busy!\n", __func__);
+ 		return NETDEV_TX_BUSY;
+ 	}
+ 
+ 	return NETDEV_TX_OK;
+ }
+ 
+ /* Extract received frame from buffer descriptors and sent to upper layers.
+  * (Called from interrupt context)
+  */
+ static void at91ether_rx(struct net_device *dev)
+ {
+ 	struct macb *lp = netdev_priv(dev);
+ 	unsigned char *p_recv;
+ 	struct sk_buff *skb;
+ 	unsigned int pktlen;
+ 
+ 	while (lp->rx_ring[lp->rx_tail].addr & MACB_BIT(RX_USED)) {
+ 		p_recv = lp->rx_buffers + lp->rx_tail * AT91ETHER_MAX_RBUFF_SZ;
+ 		pktlen = MACB_BF(RX_FRMLEN, lp->rx_ring[lp->rx_tail].ctrl);
+ 		skb = netdev_alloc_skb(dev, pktlen + 2);
+ 		if (skb) {
+ 			skb_reserve(skb, 2);
+ 			memcpy(skb_put(skb, pktlen), p_recv, pktlen);
+ 
+ 			skb->protocol = eth_type_trans(skb, dev);
+ 			lp->stats.rx_packets++;
+ 			lp->stats.rx_bytes += pktlen;
+ 			netif_rx(skb);
+ 		} else {
+ 			lp->stats.rx_dropped++;
+ 		}
+ 
+ 		if (lp->rx_ring[lp->rx_tail].ctrl & MACB_BIT(RX_MHASH_MATCH))
+ 			lp->stats.multicast++;
+ 
+ 		/* reset ownership bit */
+ 		lp->rx_ring[lp->rx_tail].addr &= ~MACB_BIT(RX_USED);
+ 
+ 		/* wrap after last buffer */
+ 		if (lp->rx_tail == AT91ETHER_MAX_RX_DESCR - 1)
+ 			lp->rx_tail = 0;
+ 		else
+ 			lp->rx_tail++;
+ 	}
+ }
+ 
+ /* MAC interrupt handler */
+ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
+ {
+ 	struct net_device *dev = dev_id;
+ 	struct macb *lp = netdev_priv(dev);
+ 	u32 intstatus, ctl;
+ 
+ 	/* MAC Interrupt Status register indicates what interrupts are pending.
+ 	 * It is automatically cleared once read.
+ 	 */
+ 	intstatus = macb_readl(lp, ISR);
+ 
+ 	/* Receive complete */
+ 	if (intstatus & MACB_BIT(RCOMP))
+ 		at91ether_rx(dev);
+ 
+ 	/* Transmit complete */
+ 	if (intstatus & MACB_BIT(TCOMP)) {
+ 		/* The TCOM bit is set even if the transmission failed */
+ 		if (intstatus & (MACB_BIT(ISR_TUND) | MACB_BIT(ISR_RLE)))
+ 			lp->stats.tx_errors++;
+ 
+ 		if (lp->skb) {
+ 			dev_kfree_skb_irq(lp->skb);
+ 			lp->skb = NULL;
+ 			dma_unmap_single(NULL, lp->skb_physaddr,
+ 					 lp->skb_length, DMA_TO_DEVICE);
+ 			lp->stats.tx_packets++;
+ 			lp->stats.tx_bytes += lp->skb_length;
+ 		}
+ 		netif_wake_queue(dev);
+ 	}
+ 
+ 	/* Work-around for EMAC Errata section 41.3.1 */
+ 	if (intstatus & MACB_BIT(RXUBR)) {
+ 		ctl = macb_readl(lp, NCR);
+ 		macb_writel(lp, NCR, ctl & ~MACB_BIT(RE));
+ 		macb_writel(lp, NCR, ctl | MACB_BIT(RE));
+ 	}
+ 
+ 	if (intstatus & MACB_BIT(ISR_ROVR))
+ 		netdev_err(dev, "ROVR error\n");
+ 
+ 	return IRQ_HANDLED;
+ }
+ 
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ static void at91ether_poll_controller(struct net_device *dev)
+ {
+ 	unsigned long flags;
+ 
+ 	local_irq_save(flags);
+ 	at91ether_interrupt(dev->irq, dev);
+ 	local_irq_restore(flags);
+ }
+ #endif
+ 
+ static const struct net_device_ops at91ether_netdev_ops = {
+ 	.ndo_open		= at91ether_open,
+ 	.ndo_stop		= at91ether_close,
+ 	.ndo_start_xmit		= at91ether_start_xmit,
+ 	.ndo_get_stats		= macb_get_stats,
+ 	.ndo_set_rx_mode	= macb_set_rx_mode,
+ 	.ndo_set_mac_address	= eth_mac_addr,
+ 	.ndo_do_ioctl		= macb_ioctl,
+ 	.ndo_validate_addr	= eth_validate_addr,
+ 	.ndo_change_mtu		= eth_change_mtu,
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ 	.ndo_poll_controller	= at91ether_poll_controller,
+ #endif
+ };
+ 
+ static int at91ether_init(struct platform_device *pdev)
+ {
+ 	struct net_device *dev = platform_get_drvdata(pdev);
+ 	struct macb *bp = netdev_priv(dev);
+ 	int err;
+ 	u32 reg;
+ 
+ 	bp->pclk = devm_clk_get(&pdev->dev, "ether_clk");
+ 	if (IS_ERR(bp->pclk))
+ 		return PTR_ERR(bp->pclk);
+ 
+ 	err = clk_prepare_enable(bp->pclk);
+ 	if (err) {
+ 		dev_err(&pdev->dev, "failed to enable pclk (%u)\n", err);
+ 		return err;
+ 	}
+ 
+ 	dev->netdev_ops = &at91ether_netdev_ops;
+ 	dev->ethtool_ops = &macb_ethtool_ops;
+ 
+ 	err = devm_request_irq(&pdev->dev, dev->irq, at91ether_interrupt,
+ 			       0, dev->name, dev);
+ 	if (err)
+ 		goto err_disable_clk;
+ 
+ 	macb_writel(bp, NCR, 0);
+ 
+ 	reg = MACB_BF(CLK, MACB_CLK_DIV32) | MACB_BIT(BIG);
+ 	if (bp->phy_interface == PHY_INTERFACE_MODE_RMII)
+ 		reg |= MACB_BIT(RM9200_RMII);
+ 
+ 	macb_writel(bp, NCFGR, reg);
+ 
+ 	return 0;
+ 
+ err_disable_clk:
+ 	clk_disable_unprepare(bp->pclk);
+ 
+ 	return err;
+ }
+ 
 -static struct macb_config at91sam9260_config = {
++static const struct macb_config at91sam9260_config = {
+ 	.caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII,
+ 	.init = macb_init,
+ };
+ 
 -static struct macb_config pc302gem_config = {
++static const struct macb_config pc302gem_config = {
+ 	.caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE,
+ 	.dma_burst_length = 16,
+ 	.init = macb_init,
+ };
+ 
 -static struct macb_config sama5d3_config = {
++static const struct macb_config sama5d3_config = {
+ 	.caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE,
+ 	.dma_burst_length = 16,
+ 	.init = macb_init,
+ };
+ 
 -static struct macb_config sama5d4_config = {
++static const struct macb_config sama5d4_config = {
+ 	.caps = 0,
+ 	.dma_burst_length = 4,
+ 	.init = macb_init,
+ };
+ 
 -static struct macb_config emac_config = {
++static const struct macb_config emac_config = {
+ 	.init = at91ether_init,
+ };
+ 
+ static const struct of_device_id macb_dt_ids[] = {
+ 	{ .compatible = "cdns,at32ap7000-macb" },
+ 	{ .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
+ 	{ .compatible = "cdns,macb" },
+ 	{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
+ 	{ .compatible = "cdns,gem", .data = &pc302gem_config },
+ 	{ .compatible = "atmel,sama5d3-gem", .data = &sama5d3_config },
+ 	{ .compatible = "atmel,sama5d4-gem", .data = &sama5d4_config },
+ 	{ .compatible = "cdns,at91rm9200-emac", .data = &emac_config },
+ 	{ .compatible = "cdns,emac", .data = &emac_config },
+ 	{ /* sentinel */ }
+ };
+ MODULE_DEVICE_TABLE(of, macb_dt_ids);
+ #endif /* CONFIG_OF */
+ 
+ static int macb_probe(struct platform_device *pdev)
+ {
+ 	int (*init)(struct platform_device *) = macb_init;
+ 	struct device_node *np = pdev->dev.of_node;
+ 	const struct macb_config *macb_config = NULL;
+ 	unsigned int queue_mask, num_queues;
+ 	struct macb_platform_data *pdata;
+ 	struct phy_device *phydev;
+ 	struct net_device *dev;
+ 	struct resource *regs;
+ 	void __iomem *mem;
+ 	const char *mac;
+ 	struct macb *bp;
+ 	int err;
+ 
+ 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ 	mem = devm_ioremap_resource(&pdev->dev, regs);
+ 	if (IS_ERR(mem))
+ 		return PTR_ERR(mem);
+ 
+ 	macb_probe_queues(mem, &queue_mask, &num_queues);
+ 	dev = alloc_etherdev_mq(sizeof(*bp), num_queues);
+ 	if (!dev)
+ 		return -ENOMEM;
+ 
+ 	dev->base_addr = regs->start;
+ 
+ 	SET_NETDEV_DEV(dev, &pdev->dev);
+ 
+ 	bp = netdev_priv(dev);
+ 	bp->pdev = pdev;
+ 	bp->dev = dev;
+ 	bp->regs = mem;
+ 	bp->num_queues = num_queues;
+ 	spin_lock_init(&bp->lock);
+ 
+ 	platform_set_drvdata(pdev, dev);
+ 
+ 	dev->irq = platform_get_irq(pdev, 0);
+ 	if (dev->irq < 0)
+ 		return dev->irq;
+ 
+ 	mac = of_get_mac_address(np);
  	if (mac)
  		memcpy(bp->dev->dev_addr, mac, ETH_ALEN);
  	else

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-03-02  0:31 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-03-02  0:31 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Scott Feldman, Dan Carpenter

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/rocker/rocker.c between commit 5f2ebfbee688
("rocker: silence shift wrapping warning") from the net tree and commit
4a6bb6d35980 ("rocker: rename lport to pport") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/rocker/rocker.c
index 9fb6948e14c6,e5a15a4c4e8f..000000000000
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@@ -1257,9 -1280,9 +1280,9 @@@ static void rocker_port_set_enable(stru
  	u64 val = rocker_read64(rocker_port->rocker, PORT_PHYS_ENABLE);
  
  	if (enable)
- 		val |= 1ULL << rocker_port->lport;
 -		val |= 1 << rocker_port->pport;
++		val |= 1ULL << rocker_port->pport;
  	else
- 		val &= ~(1ULL << rocker_port->lport);
 -		val &= ~(1 << rocker_port->pport);
++		val &= ~(1ULL << rocker_port->pport);
  	rocker_write64(rocker_port->rocker, PORT_PHYS_ENABLE, val);
  }
  

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-02-02  2:33 Stephen Rothwell
@ 2015-02-02  9:09 ` Nicolas Dichtel
  0 siblings, 0 replies; 325+ messages in thread
From: Nicolas Dichtel @ 2015-02-02  9:09 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Thomas Graf

Le 02/02/2015 03:33, Stephen Rothwell a écrit :
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/vxlan.c between commit 33564bbb2cf1 ("vxlan: setup the
> right link netns in newlink hdlr") from the net tree and commit
> ac5132d1a03f ("vxlan: Only bind to sockets with compatible flags
> enabled") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>


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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-02-02  2:40 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-02-02  2:40 UTC (permalink / raw)
  To: David Miller, netdev, Toshiaki Makita, Jiri Pirko
  Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
include/linux/if_vlan.h between commit d4bcef3fbe88 ("net: Fix
vlan_get_protocol for stacked vlan") from the net tree and commit
df8a39defad4 ("net: rename vlan_tx_* helpers since "tx" is misleading
there") from the net-next tree.

I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary (no action is required).

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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-02-02  2:33 Stephen Rothwell
  2015-02-02  9:09 ` Nicolas Dichtel
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-02-02  2:33 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nicolas Dichtel, Thomas Graf

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vxlan.c between commit 33564bbb2cf1 ("vxlan: setup the
right link netns in newlink hdlr") from the net tree and commit
ac5132d1a03f ("vxlan: Only bind to sockets with compatible flags
enabled") from the net-next tree.

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

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

diff --cc drivers/net/vxlan.c
index a8c755dcab14,31bac2a21ce3..000000000000
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@@ -2557,8 -2761,19 +2761,19 @@@ static int vxlan_newlink(struct net *sr
  	    nla_get_u8(data[IFLA_VXLAN_UDP_ZERO_CSUM6_RX]))
  		vxlan->flags |= VXLAN_F_UDP_ZERO_CSUM6_RX;
  
+ 	if (data[IFLA_VXLAN_REMCSUM_TX] &&
+ 	    nla_get_u8(data[IFLA_VXLAN_REMCSUM_TX]))
+ 		vxlan->flags |= VXLAN_F_REMCSUM_TX;
+ 
+ 	if (data[IFLA_VXLAN_REMCSUM_RX] &&
+ 	    nla_get_u8(data[IFLA_VXLAN_REMCSUM_RX]))
+ 		vxlan->flags |= VXLAN_F_REMCSUM_RX;
+ 
+ 	if (data[IFLA_VXLAN_GBP])
+ 		vxlan->flags |= VXLAN_F_GBP;
+ 
 -	if (vxlan_find_vni(net, vni, use_ipv6 ? AF_INET6 : AF_INET,
 +	if (vxlan_find_vni(src_net, vni, use_ipv6 ? AF_INET6 : AF_INET,
- 			   vxlan->dst_port)) {
+ 			   vxlan->dst_port, vxlan->flags)) {
  		pr_info("duplicate VNI %u\n", vni);
  		return -EEXIST;
  	}

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-01-28  1:02 Stephen Rothwell
@ 2015-01-28  8:39 ` Daniel Borkmann
  0 siblings, 0 replies; 325+ messages in thread
From: Daniel Borkmann @ 2015-01-28  8:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko

On 01/28/2015 02:02 AM, Stephen Rothwell wrote:
...
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-01-28  1:02 Stephen Rothwell
  2015-01-28  8:39 ` Daniel Borkmann
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-01-28  1:02 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Jiri Pirko, Daniel Borkmann

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/sched/cls_bpf.c between commit 7913ecf69e24 ("net: cls_bpf: fix
size mismatch on filter preparation") from the net tree and commit
33e9fcc666e2 ("tc: cls_bpf: rename bpf_len to bpf_num_ops") from the
net-next tree.

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

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

diff --cc net/sched/cls_bpf.c
index f59adf8a4cd7,1029923f9e86..000000000000
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@@ -179,12 -179,7 +179,12 @@@ static int cls_bpf_modify_existing(stru
  		goto errout;
  	}
  
- 	bpf_size = bpf_len * sizeof(*bpf_ops);
+ 	bpf_size = bpf_num_ops * sizeof(*bpf_ops);
 +	if (bpf_size != nla_len(tb[TCA_BPF_OPS])) {
 +		ret = -EINVAL;
 +		goto errout;
 +	}
 +
  	bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
  	if (bpf_ops == NULL) {
  		ret = -ENOMEM;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-01-27  2:00 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2015-01-27  2:00 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nimrod Andy

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
arch/arm/boot/dts/imx6sx-sdb.dts between commit 9143e398a443 ("ARM:
dts: imx6sx: correct i.MX6sx sdb board enet phy address") from the net
tree and commit fc8347778017 ("ARM: dts: imx6sx: correct i.MX6sx sdb
board enet phy address") from the net-next tree.

I fixed it up (according to the commit comments, the version from the
net tree is newer, so I used that) and can carry the fix as necessary
(no action is required).

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2015-01-15  2:47 Stephen Rothwell
@ 2015-01-15  6:06 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2015-01-15  6:06 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, david.vrabel

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 15 Jan 2015 13:47:35 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
> use different locks for Rx and Tx stats") from the net tree and commit
> a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
> net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks a lot Stephen, I just resolved this.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2015-01-15  2:47 Stephen Rothwell
  2015-01-15  6:06 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2015-01-15  2:47 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, David Vrabel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
use different locks for Rx and Tx stats") from the net tree and commit
a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
net-next tree.

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

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

diff --cc drivers/net/xen-netfront.c
index d8c10764f130,01a4350eb313..000000000000
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@@ -562,18 -518,15 +517,15 @@@ static u16 xennet_select_queue(struct n
  
  static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
  {
- 	unsigned short id;
  	struct netfront_info *np = netdev_priv(dev);
 -	struct netfront_stats *stats = this_cpu_ptr(np->stats);
 +	struct netfront_stats *tx_stats = this_cpu_ptr(np->tx_stats);
- 	struct xen_netif_tx_request *tx;
- 	char *data = skb->data;
- 	RING_IDX i;
- 	grant_ref_t ref;
- 	unsigned long mfn;
+ 	struct xen_netif_tx_request *tx, *first_tx;
+ 	unsigned int i;
  	int notify;
  	int slots;
- 	unsigned int offset = offset_in_page(data);
- 	unsigned int len = skb_headlen(skb);
+ 	struct page *page;
+ 	unsigned int offset;
+ 	unsigned int len;
  	unsigned long flags;
  	struct netfront_queue *queue = NULL;
  	unsigned int num_queues = dev->real_num_tx_queues;

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-12-10 19:49 ` David Miller
@ 2014-12-10 21:38   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-12-10 21:38 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Thomas.Lendacky, linux-next, linux-kernel

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

Hi Dave,

On Wed, 10 Dec 2014 14:49:43 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> As you have seen there are a lot of merge hassles to sort out between
> the 'net' and 'net-next' tree right now, probably I just added a few
> more :-)
> 
> I'll try to do the merge by the end of today so that these headaches
> go away for you.

Much appreciated.

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-12-10  1:20 Stephen Rothwell
@ 2014-12-10 19:49 ` David Miller
  2014-12-10 21:38   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: David Miller @ 2014-12-10 19:49 UTC (permalink / raw)
  To: sfr; +Cc: netdev, Thomas.Lendacky, linux-next, linux-kernel

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Dec 2014 12:20:36 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/amd/xgbe/xgbe-desc.c between commit 03ccc4c0a9da
> ("amd-xgbe: Do not clear interrupt indicator") from the net tree and
> commit c9f140ebb008 ("amd-xgbe: Separate Tx/Rx ring data fields into
> new structs") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

As you have seen there are a lot of merge hassles to sort out between
the 'net' and 'net-next' tree right now, probably I just added a few
more :-)

I'll try to do the merge by the end of today so that these headaches
go away for you.

Thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-12-10  1:20 Stephen Rothwell
  2014-12-10 19:49 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-12-10  1:20 UTC (permalink / raw)
  To: David Miller, netdev, Lendacky, Thomas; +Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/amd/xgbe/xgbe-desc.c between commit 03ccc4c0a9da
("amd-xgbe: Do not clear interrupt indicator") from the net tree and
commit c9f140ebb008 ("amd-xgbe: Separate Tx/Rx ring data fields into
new structs") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/amd/xgbe/xgbe-desc.c
index b15551bad7fa,51b68d1299fe..000000000000
--- a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
@@@ -354,8 -450,30 +450,29 @@@ static void xgbe_unmap_rdata(struct xgb
  		rdata->skb = NULL;
  	}
  
- 	rdata->tso_header = 0;
- 	rdata->len = 0;
+ 	if (rdata->rx.hdr.pa.pages)
+ 		put_page(rdata->rx.hdr.pa.pages);
+ 
+ 	if (rdata->rx.hdr.pa_unmap.pages) {
+ 		dma_unmap_page(pdata->dev, rdata->rx.hdr.pa_unmap.pages_dma,
+ 			       rdata->rx.hdr.pa_unmap.pages_len,
+ 			       DMA_FROM_DEVICE);
+ 		put_page(rdata->rx.hdr.pa_unmap.pages);
+ 	}
+ 
+ 	if (rdata->rx.buf.pa.pages)
+ 		put_page(rdata->rx.buf.pa.pages);
+ 
+ 	if (rdata->rx.buf.pa_unmap.pages) {
+ 		dma_unmap_page(pdata->dev, rdata->rx.buf.pa_unmap.pages_dma,
+ 			       rdata->rx.buf.pa_unmap.pages_len,
+ 			       DMA_FROM_DEVICE);
+ 		put_page(rdata->rx.buf.pa_unmap.pages);
+ 	}
+ 
+ 	memset(&rdata->tx, 0, sizeof(rdata->tx));
+ 	memset(&rdata->rx, 0, sizeof(rdata->rx));
+ 
 -	rdata->interrupt = 0;
  	rdata->mapped_as_page = 0;
  
  	if (rdata->state_saved) {

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-11-13  0:35 Stephen Rothwell
@ 2014-11-13 21:14 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2014-11-13 21:14 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, hariprasad, alexander.h.duyck

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 13 Nov 2014 11:35:55 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/chelsio/cxgb4vf/sge.c between commit 65f6ecc93e7c
> ("cxgb4vf: Move fl_starv_thres into adapter->sge data structure") from
> the net tree and commit aa9cd31c3f3e ("cxgb4/cxgb4vf: Replace
> __skb_alloc_page with __dev_alloc_page") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This merge resolution looks perfect.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-11-13  0:35 Stephen Rothwell
  2014-11-13 21:14 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-11-13  0:35 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Hariprasad Shenai, Alexander Duyck

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/chelsio/cxgb4vf/sge.c between commit 65f6ecc93e7c
("cxgb4vf: Move fl_starv_thres into adapter->sge data structure") from
the net tree and commit aa9cd31c3f3e ("cxgb4/cxgb4vf: Replace
__skb_alloc_page with __dev_alloc_page") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index fdd078d7d82c,cd538afa40dd..000000000000
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@@ -608,8 -614,7 +610,7 @@@ static unsigned int refill_fl(struct ad
  		goto alloc_small_pages;
  
  	while (n) {
- 		page = alloc_pages(gfp | __GFP_COMP | __GFP_NOWARN,
- 				   s->fl_pg_order);
 -		page = __dev_alloc_pages(gfp, FL_PG_ORDER);
++		page = __dev_alloc_pages(gfp, s->fl_pg_order);
  		if (unlikely(!page)) {
  			/*
  			 * We've failed inour attempt to allocate a "large

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-10-29  0:14 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-10-29  0:14 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Vince Bridgers, Viet Nga Dao

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/marvell.c between commit 99d881f993f0 ("net: phy: Add
SGMII Configuration for Marvell 88E1145 Initialization") from the net
tree and commit b02241755d0e ("net: phy: Adding SGMII support for
Marvell 88ee1145 driver") from the net-next tree.

I fixed it up (they are basically the same patch :-( so I just fixed up
the differences and basically used the net tree version) and can carry
the fix as necessary (no action is required).

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-10-02  4:16 Stephen Rothwell
@ 2014-10-02 18:27 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2014-10-02 18:27 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, hayeswang

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 2 Oct 2014 14:16:41 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/usb/r8152.c between commit 204c87041289 ("r8152: remove
> clearing bp") from the net tree and commit 8ddfa07778af ("r8152: use
> usleep_range") from the net-next tree.
> 
> I fixed it up (the former removed some of the code updated by the
> latter) and can carry the fix as necessary (no action is required).

I'm merging net into net-next today and thus resolving this.

Thanks Stephen!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-10-02  4:16 Stephen Rothwell
  2014-10-02 18:27 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-10-02  4:16 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, hayeswang

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/usb/r8152.c between commit 204c87041289 ("r8152: remove
clearing bp") from the net tree and commit 8ddfa07778af ("r8152: use
usleep_range") from the net-next tree.

I fixed it up (the former removed some of the code updated by the
latter) and can carry the fix as necessary (no action is required).

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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-09-30  2:54 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-09-30  2:54 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Pablo Neira Ayuso

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/nfnetlink.c between commit cbb8125eb40b ("netfilter:
nfnetlink: deliver netlink errors on batch completion") from the net
tree and commit fc04733a1a71 ("netfilter: nfnetlink: use original
skbuff when committing/aborting") from the net-next tree.

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

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

diff --cc net/netfilter/nfnetlink.c
index f37f0716a9fc,f77d3f7f22b5..000000000000
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@@ -380,8 -333,7 +380,8 @@@ replay
  			 * original skb.
  			 */
  			if (err == -EAGAIN) {
 +				nfnl_err_reset(&err_list);
- 				ss->abort(skb);
+ 				ss->abort(oskb);
  				nfnl_unlock(subsys_id);
  				kfree_skb(nskb);
  				goto replay;
@@@ -418,11 -357,10 +418,11 @@@ ack
  	}
  done:
  	if (success && done)
- 		ss->commit(skb);
+ 		ss->commit(oskb);
  	else
- 		ss->abort(skb);
+ 		ss->abort(oskb);
  
 +	nfnl_err_deliver(&err_list, oskb);
  	nfnl_unlock(subsys_id);
  	kfree_skb(nskb);
  }

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-09-30  2:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-09-30  2:51 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, hayeswang

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/usb/r8152.c between commit 445f7f4d6262 ("r8152: fix the
carrier off when autoresuming") from the net tree and commit
b209af9981ee ("r8152: check code with checkpatch.pl") from the net-next
tree.

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

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

diff --cc drivers/net/usb/r8152.c
index e0394427e372,a4d4c4a1354f..000000000000
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -2067,10 -2080,11 +2097,10 @@@ static void rtl_disable(struct r8152 *t
  	for (i = 0; i < 1000; i++) {
  		if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR0) & TCR0_TX_EMPTY)
  			break;
- 		mdelay(1);
+ 		usleep_range(1000, 2000);
  	}
  
 -	for (i = 0; i < RTL8152_MAX_RX; i++)
 -		usb_kill_urb(tp->rx_info[i].urb);
 +	rtl_stop_rx(tp);
  
  	rtl8152_nic_reset(tp);
  }
@@@ -3131,12 -3211,13 +3229,13 @@@ static int rtl8152_resume(struct usb_in
  		} else {
  			tp->rtl_ops.up(tp);
  			rtl8152_set_speed(tp, AUTONEG_ENABLE,
- 				tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
- 				DUPLEX_FULL);
+ 					  tp->mii.supports_gmii ?
+ 					  SPEED_1000 : SPEED_100,
+ 					  DUPLEX_FULL);
 +			tp->speed = 0;
 +			netif_carrier_off(tp->netdev);
 +			set_bit(WORK_ENABLE, &tp->flags);
  		}
 -		tp->speed = 0;
 -		netif_carrier_off(tp->netdev);
 -		set_bit(WORK_ENABLE, &tp->flags);
  		usb_submit_urb(tp->intr_urb, GFP_KERNEL);
  	}
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-09-22  1:52 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-09-22  1:52 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, David Jander, Marc Kleine-Budde, Stefan Agner

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/can/flexcan.c between commit fc05b884a31d ("can: flexcan:
correctly initialize mailboxes") from the net tree and commit
cdce844865be ("can: flexcan: add vf610 support for FlexCAN") from the
net-next tree.

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

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

diff --cc drivers/net/can/flexcan.c
index 6586309329e6,2700865efcad..000000000000
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -824,8 -859,7 +883,8 @@@ static int flexcan_chip_start(struct ne
  	struct flexcan_priv *priv = netdev_priv(dev);
  	struct flexcan_regs __iomem *regs = priv->base;
  	int err;
- 	u32 reg_mcr, reg_ctrl;
+ 	u32 reg_mcr, reg_ctrl, reg_crl2, reg_mecr;
 +	int i;
  
  	/* enable module */
  	err = flexcan_chip_enable(priv);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-08-04  3:28 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-08-04  3:28 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Hannes Frederic Sowa, Tom Herbert

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/sysctl_net_ipv6.c between commit 166bd890a3d8 ("ipv6: data of
fwmark_reflect sysctl needs to be updated on netns construction") from
the net tree and commit cb1ce2ef387b ("ipv6: Implement automatic flow
label generation on transmit") from the net-next tree.

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

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

diff --cc net/ipv6/sysctl_net_ipv6.c
index 818334619abb,5bf7b61f8ae8..000000000000
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@@ -74,7 -81,7 +81,8 @@@ static int __net_init ipv6_sysctl_net_i
  	ipv6_table[0].data = &net->ipv6.sysctl.bindv6only;
  	ipv6_table[1].data = &net->ipv6.sysctl.anycast_src_echo_reply;
  	ipv6_table[2].data = &net->ipv6.sysctl.flowlabel_consistency;
- 	ipv6_table[3].data = &net->ipv6.sysctl.fwmark_reflect;
+ 	ipv6_table[3].data = &net->ipv6.sysctl.auto_flowlabels;
++	ipv6_table[4].data = &net->ipv6.sysctl.fwmark_reflect;
  
  	ipv6_route_table = ipv6_route_sysctl_init(net);
  	if (!ipv6_route_table)

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-06-06  3:54 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-06-06  3:54 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Alexei Starovoitov

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/filter.c between commit 0dcceabb0c1b ("net: filter: fix
SKF_AD_PKTTYPE extension on big-endian") from the net tree and commit
9739eef13c92 ("net: filter: make BPF conversion more readable") from
the net-next tree.

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

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

diff --cc net/core/filter.c
index ab3c74e49f07,9de0c25323b4..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -685,17 -684,7 +688,14 @@@ static bool convert_bpf_extensions(stru
  		if (insn->off < 0)
  			return false;
  		insn++;
- 
- 		insn->code = BPF_ALU | BPF_AND | BPF_K;
- 		insn->a_reg = A_REG;
- 		insn->imm = PKT_TYPE_MAX;
+ 		*insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX);
 +#ifdef __BIG_ENDIAN_BITFIELD
 +		insn++;
 +
 +		insn->code = BPF_ALU | BPF_RSH | BPF_K;
 +		insn->a_reg = A_REG;
 +		insn->imm = 5;
 +#endif
  		break;
  
  	case SKF_AD_OFF + SKF_AD_IFINDEX:

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-06-06  3:45 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-06-06  3:45 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Zoltan Kiss, Wei Liu, Andrew J. Bennieston

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netback/netback.c between commit 59ae9fc67007
("xen-netback: Fix handling of skbs requiring too many slots") from the
net tree and commit e9ce7cb6b107 ("xen-netback: Factor queue-specific
data into queue struct") from the net-next tree.

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

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

diff --cc drivers/net/xen-netback/netback.c
index a160b4ef5ba0,49efff9b99f4..000000000000
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@@ -556,12 -548,18 +563,12 @@@ static void xenvif_add_frag_responses(s
  	}
  }
  
- void xenvif_kick_thread(struct xenvif *vif)
 -struct xenvif_rx_cb {
 -	int meta_slots_used;
 -};
 -
 -#define XENVIF_RX_CB(skb) ((struct xenvif_rx_cb *)(skb)->cb)
 -
+ void xenvif_kick_thread(struct xenvif_queue *queue)
  {
- 	wake_up(&vif->wq);
+ 	wake_up(&queue->wq);
  }
  
- static void xenvif_rx_action(struct xenvif *vif)
+ static void xenvif_rx_action(struct xenvif_queue *queue)
  {
  	s8 status;
  	u16 flags;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-06-03  2:31 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-06-03  2:31 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/output_core.c between commit 39c36094d78c ("net: fix
inet_getid() and ipv6_select_ident() bugs") from the net tree and
commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") from the
net-next tree.

I fixed it up (the latter removed the code that the former updated, so
I did that) and can carry the fix as necessary (no action is required).

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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-06-03  2:28 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-06-03  2:28 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
include/net/inetpeer.h between commit 39c36094d78c ("net: fix
inet_getid() and ipv6_select_ident() bugs") from the  tree and commit
73f156a6e8c1 ("inetpeer: get rid of ip_id_count") from the net-next
tree.

I fixed it up (the latter removed the code that the former updated, so
I did that) and can carry the fix as necessary (no action is required).

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

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-05-23  3:46 Stephen Rothwell
@ 2014-05-24  4:50 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2014-05-24  4:50 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, vyasevic, vfalico

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 May 2014 13:46:02 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/bonding/bond_alb.c between commit d0c21d43a5a1 ("bonding:
> Send ALB learning packets using the right source") from the net tree
> and commit 8557cd74ca8a ("bonding: replace SLAVE_IS_OK() with
> bond_slave_can_tx()") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks Stephen, I just merged net into net-next and this conflict
should therefore be gone.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-05-23  3:46 Stephen Rothwell
  2014-05-24  4:50 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-05-23  3:46 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Vlad Yasevich, Veaceslav Falico

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/bonding/bond_alb.c between commit d0c21d43a5a1 ("bonding:
Send ALB learning packets using the right source") from the net tree
and commit 8557cd74ca8a ("bonding: replace SLAVE_IS_OK() with
bond_slave_can_tx()") from the net-next tree.

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

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

diff --cc drivers/net/bonding/bond_alb.c
index 93580a47cc54,03e0bcade234..000000000000
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@@ -1117,8 -1106,8 +1117,8 @@@ static void alb_fasten_mac_swap(struct 
  	ASSERT_RTNL();
  
  	/* fasten the change in the switch */
- 	if (SLAVE_IS_OK(slave1)) {
+ 	if (bond_slave_can_tx(slave1)) {
 -		alb_send_learning_packets(slave1, slave1->dev->dev_addr);
 +		alb_send_learning_packets(slave1, slave1->dev->dev_addr, false);
  		if (bond->alb_info.rlb_enabled) {
  			/* inform the clients that the mac address
  			 * has changed
@@@ -1129,8 -1118,8 +1129,8 @@@
  		disabled_slave = slave1;
  	}
  
- 	if (SLAVE_IS_OK(slave2)) {
+ 	if (bond_slave_can_tx(slave2)) {
 -		alb_send_learning_packets(slave2, slave2->dev->dev_addr);
 +		alb_send_learning_packets(slave2, slave2->dev->dev_addr, false);
  		if (bond->alb_info.rlb_enabled) {
  			/* inform the clients that the mac address
  			 * has changed

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-05-16  2:08 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-05-16  2:08 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Vince Bridgers, Tobias Klauser

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

Hi all,

Today's linux-next merge of the net-next tree got conflicts in
drivers/net/ethernet/altera/altera_msgdma.c and
drivers/net/ethernet/altera/altera_sgdma.c between commit 898305806ad5
("Altera TSE: Fix sparse errors and warnings") from the net tree and
commit d42f157b3498 ("Altera TSE: Remove unnecessary cast of void
pointers") from the net-next tree.

I fixed it up (mostly the former removed lines updated by the latter,
but see below) and can carry the fix as necessary (no action is
required).

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

diff --cc drivers/net/ethernet/altera/altera_sgdma.c
index 99cc56f451cf,dbd40e15b5cc..000000000000
--- a/drivers/net/ethernet/altera/altera_sgdma.c
+++ b/drivers/net/ethernet/altera/altera_sgdma.c
@@@ -179,11 -184,11 +179,10 @@@ void sgdma_clear_txirq(struct altera_ts
   */
  int sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *buffer)
  {
- 	struct sgdma_descrip __iomem *descbase =
- 		(struct sgdma_descrip __iomem *)priv->tx_dma_desc;
 -	int pktstx = 0;
 -	struct sgdma_descrip *descbase = priv->tx_dma_desc;
++	struct sgdma_descrip __iomem *descbase = priv->tx_dma_desc;
  
 -	struct sgdma_descrip *cdesc = &descbase[0];
 -	struct sgdma_descrip *ndesc = &descbase[1];
 +	struct sgdma_descrip __iomem *cdesc = &descbase[0];
 +	struct sgdma_descrip __iomem *ndesc = &descbase[1];
  
  	/* wait 'til the tx sgdma is ready for the next transmit request */
  	if (sgdma_txbusy(priv))
@@@ -240,13 -245,16 +239,12 @@@ void sgdma_add_rx_desc(struct altera_ts
   */
  u32 sgdma_rx_status(struct altera_tse_private *priv)
  {
- 	struct sgdma_descrip __iomem *base =
- 		(struct sgdma_descrip __iomem *)priv->rx_dma_desc;
 -	struct sgdma_csr *csr = priv->rx_dma_csr;
 -	struct sgdma_descrip *base = priv->rx_dma_desc;
 -	struct sgdma_descrip *desc = NULL;
 -	int pktsrx;
 -	unsigned int rxstatus = 0;
 -	unsigned int pktlength = 0;
 -	unsigned int pktstatus = 0;
++	struct sgdma_descrip __iomem *base = priv->rx_dma_desc;
 +	struct sgdma_descrip __iomem *desc = NULL;
  	struct tse_buffer *rxbuffer = NULL;
 +	unsigned int rxstatus = 0;
  
 -	u32 sts = ioread32(&csr->status);
 +	u32 sts = csrrd32(priv->rx_dma_csr, sgdma_csroffs(status));
  
  	desc = &base[0];
  	if (sts & SGDMA_STSREG_EOP) {
@@@ -348,11 -350,10 +346,10 @@@ static void sgdma_setup_descrip(struct 
   */
  static int sgdma_async_read(struct altera_tse_private *priv)
  {
- 	struct sgdma_descrip __iomem *descbase =
- 		(struct sgdma_descrip __iomem *)priv->rx_dma_desc;
 -	struct sgdma_csr *csr = priv->rx_dma_csr;
 -	struct sgdma_descrip *descbase = priv->rx_dma_desc;
 -	struct sgdma_descrip *cdesc = &descbase[0];
 -	struct sgdma_descrip *ndesc = &descbase[1];
++	struct sgdma_descrip __iomem *descbase = priv->rx_dma_desc;
 +
 +	struct sgdma_descrip __iomem *cdesc = &descbase[0];
 +	struct sgdma_descrip __iomem *ndesc = &descbase[1];
  
  	struct tse_buffer *rxbuffer = NULL;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-05-05  2:10 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-05-05  2:10 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric W. Biederman, \"Stéphane Graber\

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

Hi all,

Today's linux-next merge of the net-next tree got conflicts in
net/sched/sch_api.c and net/sched/cls_api.c between commit 90f62cf30a78
("net: Use netlink_ns_capable to verify the permisions of netlink
messages") from the net tree and commit 4e8bbb819d15 ("net: Allow tc
changes in user namespaces") from the net-next tree.

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

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

diff --cc net/sched/cls_api.c
index bdbdb1a7920a,1a4a20267787..000000000000
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@@ -134,7 -134,8 +134,8 @@@ static int tc_ctl_tfilter(struct sk_buf
  	int err;
  	int tp_created = 0;
  
- 	if ((n->nlmsg_type != RTM_GETTFILTER) && !netlink_capable(skb, CAP_NET_ADMIN))
+ 	if ((n->nlmsg_type != RTM_GETTFILTER) &&
 -	    !ns_capable(net->user_ns, CAP_NET_ADMIN))
++	    !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
  		return -EPERM;
  
  replay:
diff --cc net/sched/sch_api.c
index 400769014bbd,86f8edfd6b8a..000000000000
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@@ -1084,7 -1084,8 +1084,8 @@@ static int tc_get_qdisc(struct sk_buff 
  	struct Qdisc *p = NULL;
  	int err;
  
- 	if ((n->nlmsg_type != RTM_GETQDISC) && !netlink_capable(skb, CAP_NET_ADMIN))
+ 	if ((n->nlmsg_type != RTM_GETQDISC) &&
 -	    !ns_capable(net->user_ns, CAP_NET_ADMIN))
++	    !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
  		return -EPERM;
  
  	err = nlmsg_parse(n, sizeof(*tcm), tca, TCA_MAX, NULL);
@@@ -1151,7 -1152,7 +1152,7 @@@ static int tc_modify_qdisc(struct sk_bu
  	struct Qdisc *q, *p;
  	int err;
  
- 	if (!netlink_capable(skb, CAP_NET_ADMIN))
 -	if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
++	if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
  		return -EPERM;
  
  replay:
@@@ -1490,7 -1491,8 +1491,8 @@@ static int tc_ctl_tclass(struct sk_buf
  	u32 qid;
  	int err;
  
- 	if ((n->nlmsg_type != RTM_GETTCLASS) && !netlink_capable(skb, CAP_NET_ADMIN))
+ 	if ((n->nlmsg_type != RTM_GETTCLASS) &&
 -	    !ns_capable(net->user_ns, CAP_NET_ADMIN))
++	    !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
  		return -EPERM;
  
  	err = nlmsg_parse(n, sizeof(*tcm), tca, TCA_MAX, NULL);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-04-28  2:57 Stephen Rothwell
@ 2014-04-28 18:19 ` Richard Guy Briggs
  0 siblings, 0 replies; 325+ messages in thread
From: Richard Guy Briggs @ 2014-04-28 18:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel,
	Eric W. Biederman, Eric Paris

On 14/04/28, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/netlink/af_netlink.c between commit 5187cd055b6e ("netlink: Rename
> netlink_capable netlink_allowed") from the net tree and commit
> 4f520900522f ("netlink: have netlink per-protocol bind function return an
> error code") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Works for me.  Thanks Stephen.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc net/netlink/af_netlink.c
> index 81dca96d2be6,92f4b6915e89..000000000000
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@@ -1492,8 -1445,8 +1510,8 @@@ static int netlink_bind(struct socket *
>   		return -EINVAL;
>   
>   	/* Only superuser is allowed to listen multicasts */
> - 	if (nladdr->nl_groups) {
> + 	if (groups) {
>  -		if (!netlink_capable(sock, NL_CFG_F_NONROOT_RECV))
>  +		if (!netlink_allowed(sock, NL_CFG_F_NONROOT_RECV))
>   			return -EPERM;
>   		err = netlink_realloc_groups(sk);
>   		if (err)

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-04-28  2:57 Stephen Rothwell
  2014-04-28 18:19 ` Richard Guy Briggs
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-04-28  2:57 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric W. Biederman, Richard Guy Briggs

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/netlink/af_netlink.c between commit 5187cd055b6e ("netlink: Rename
netlink_capable netlink_allowed") from the net tree and commit
4f520900522f ("netlink: have netlink per-protocol bind function return an
error code") from the net-next tree.

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

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

diff --cc net/netlink/af_netlink.c
index 81dca96d2be6,92f4b6915e89..000000000000
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@@ -1492,8 -1445,8 +1510,8 @@@ static int netlink_bind(struct socket *
  		return -EINVAL;
  
  	/* Only superuser is allowed to listen multicasts */
- 	if (nladdr->nl_groups) {
+ 	if (groups) {
 -		if (!netlink_capable(sock, NL_CFG_F_NONROOT_RECV))
 +		if (!netlink_allowed(sock, NL_CFG_F_NONROOT_RECV))
  			return -EPERM;
  		err = netlink_realloc_groups(sk);
  		if (err)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-04-28  2:53 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-04-28  2:53 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Tobias Klauser, Vince Bridgers

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/altera/altera_sgdma.c between commit 37c0ffaad214
("Altera TSE: Work around unaligned DMA receive packet issue with Altera
SGDMA") from the net tree and commit d42f157b3498 ("Altera TSE: Remove
unnecessary cast of void pointers") from the net-next tree.

I fixed it up (the former removes the code updated by the latter, so I
did that) and can carry the fix as necessary (no action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-04-24  2:24 ` Jeff Kirsher
@ 2014-04-24  2:45   ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2014-04-24  2:45 UTC (permalink / raw)
  To: jeffrey.t.kirsher
  Cc: sfr, netdev, linux-next, linux-kernel, kubakici, carolyn.wyborny

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 23 Apr 2014 19:24:38 -0700

> On Thu, 2014-04-24 at 11:47 +1000, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the net-next tree got a conflict in
>> drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
>> ("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree
>> and
>> commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
>> tree.
>> 
>> I fixed it up (the former was a superset of the latter) and can carry
>> the
>> fix as necessary (no action is required).
> 
> Huh, I thought the commit c75c4edfc38d ("igb: Cleanups for messaging")
> in Dave's net-next already took into account the changes in net.  I will
> take a look at your fix Stephen, thanks for letting us know.

Stephen may have pulled net-next before that went in.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-04-24  1:47 Stephen Rothwell
@ 2014-04-24  2:24 ` Jeff Kirsher
  2014-04-24  2:45   ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Jeff Kirsher @ 2014-04-24  2:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Jakub Kicinski,
	Carolyn Wyborny

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

On Thu, 2014-04-24 at 11:47 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
> ("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree
> and
> commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
> tree.
> 
> I fixed it up (the former was a superset of the latter) and can carry
> the
> fix as necessary (no action is required).

Huh, I thought the commit c75c4edfc38d ("igb: Cleanups for messaging")
in Dave's net-next already took into account the changes in net.  I will
take a look at your fix Stephen, thanks for letting us know.

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-04-24  1:51 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-04-24  1:51 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Chema Gonzalez, Alexei Starovoitov

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/filter.c between commit 83d5b7ef99c9 ("net: filter: initialize A
and X registers") from the net tree and commit 4cd3675ebf74 ("filter:
added BPF random opcode") from the net-next tree.

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

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

diff --cc net/core/filter.c
index 9d79ca0a6e8e,78a636e60a0b..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -652,6 -643,19 +652,12 @@@ static u64 __get_raw_cpu_id(u64 ctx, u6
  	return raw_smp_processor_id();
  }
  
+ /* note that this only generates 32-bit random numbers */
+ static u64 __get_random_u32(u64 ctx, u64 A, u64 X, u64 r4, u64 r5)
+ {
+ 	return (u64)prandom_u32();
+ }
+ 
 -/* Register mappings for user programs. */
 -#define A_REG		0
 -#define X_REG		7
 -#define TMP_REG		8
 -#define ARG2_REG	2
 -#define ARG3_REG	3
 -
  static bool convert_bpf_extensions(struct sock_filter *fp,
  				   struct sock_filter_int **insnp)
  {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-04-24  1:47 Stephen Rothwell
  2014-04-24  2:24 ` Jeff Kirsher
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-04-24  1:47 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Jakub Kicinski, Jeff Kirsher, Carolyn Wyborny

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree and
commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
tree.

I fixed it up (the former was a superset of the latter) and can carry the
fix as necessary (no action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-03-31  2:34 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-03-31  2:34 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Paul Durrant, Zoltan Kiss

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netback/netback.c between commit 1425c7a4e8d3
("xen-netback: BUG_ON in xenvif_rx_action() not catching overflow") from
the net tree and commit 8f13dd961228 ("xen-netback: Use skb->cb for
pending_idx") from the net-next 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 drivers/net/xen-netback/netback.c
index cd0bd95ccc14,cb784fe5220c..000000000000
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@@ -531,13 -539,8 +560,11 @@@ static void xenvif_rx_action(struct xen
  		} else
  			vif->rx_last_skb_slots = 0;
  
- 		sco = (struct skb_cb_overlay *)skb->cb;
- 
 +		old_req_cons = vif->rx.req_cons;
- 		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
+ 		XENVIF_RX_CB(skb)->meta_slots_used = xenvif_gop_skb(skb, &npo);
 -		BUG_ON(XENVIF_RX_CB(skb)->meta_slots_used > max_slots_needed);
 +		ring_slots_used = vif->rx.req_cons - old_req_cons;
 +
 +		BUG_ON(ring_slots_used > max_slots_needed);
  
  		__skb_queue_tail(&rxq, skb);
  	}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2014-03-25  2:04 Stephen Rothwell
@ 2014-03-25  4:31 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2014-03-25  4:31 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, roy.qing.li, ebiederm

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 Mar 2014 13:04:47 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> net/core/netpoll.c between commit c27f0872a344 ("netpoll: fix the skb
> check in pkt_is_ns") from the net tree and commit 9c62a68d1311 ("netpoll:
> Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") from the net-next
> tree.
> 
> I fixed it up (the latter removes the code fixed by the former, so I did
> that) and can carry the fix as necessary (no action is required).

That's a perfect resolution, thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-03-25  2:04 Stephen Rothwell
  2014-03-25  4:31 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2014-03-25  2:04 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Li RongQing, Eric W. Biederman

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/core/netpoll.c between commit c27f0872a344 ("netpoll: fix the skb
check in pkt_is_ns") from the net tree and commit 9c62a68d1311 ("netpoll:
Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") from the net-next
tree.

I fixed it up (the latter removes the code fixed by the former, so I did
that) and can carry the fix as necessary (no action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-03-25  1:58 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-03-25  1:58 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nishanth Menon, Sergei Shtylyov

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
Documentation/devicetree/bindings/net/micrel-ks8851.txt between commit
ebf4ad955d3e ("net: micrel : ks8851-ml: add vdd-supply support") from
the  tree and commit e8f08ee0ad86 ("DT: net: document Ethernet bindings
in one place") from the net-next tree.

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

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

diff --cc Documentation/devicetree/bindings/net/micrel-ks8851.txt
index 4fc392763611,8e20c04a1da1..000000000000
--- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@@ -4,7 -4,3 +4,6 @@@ Required properties
  - compatible = "micrel,ks8851-ml" of parallel interface
  - reg : 2 physical address and size of registers for data and command
  - interrupts : interrupt connection
 +
 +Optional properties:
- - local-mac-address : Ethernet mac address to use
 +- vdd-supply:	supply for Ethernet mac

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-03-12 16:00 Mark Brown
  0 siblings, 0 replies; 325+ messages in thread
From: Mark Brown @ 2014-03-12 16:00 UTC (permalink / raw)
  To: David Miller, netdev, hayeswang; +Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in drivers/net/usb/r8152.c between commit 10c3271712f5821 ("r8152: disable the ECM mode") from the net tree and commit 4f1d4d54f99e9 ("r8152: support dumping the hw counters") from the net-next tree.

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

diff --cc drivers/net/usb/r8152.c
index adb12f349a61,aa1d5b2e9c30..000000000000
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -449,6 -465,25 +465,22 @@@ enum rtl8152_flags 
  #define MCU_TYPE_PLA                  0x0100
  #define MCU_TYPE_USB                  0x0000
  
 -#define REALTEK_USB_DEVICE(vend, prod)        \
 -      USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
 -
+ struct tally_counter {
+       __le64  tx_packets;
+       __le64  rx_packets;
+       __le64  tx_errors;
+       __le32  rx_errors;
+       __le16  rx_missed;
+       __le16  align_errors;
+       __le32  tx_one_collision;
+       __le32  tx_multi_collision;
+       __le64  rx_unicast;
+       __le64  rx_broadcast;
+       __le32  rx_multicast;
+       __le16  tx_aborted;
+       __le16  tx_underun;
+ };
+ 
  struct rx_desc {
        __le32 opts1;
  #define RX_LEN_MASK                   0x7fff

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-02-21  2:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-02-21  2:49 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nicolas Dichtel, WANG Cong

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/sit.c between commit cf71d2bc0b8a ("sit: fix panic with route
cache in ip tunnels") from the  tree and commit 1c213bd24ad0 ("net:
introduce netdev_alloc_pcpu_stats() for drivers") from the net-next 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/ipv6/sit.c
index b4d74c86586c,958027be0e94..000000000000
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@@ -1376,18 -1368,6 +1375,12 @@@ static int ipip6_tunnel_init(struct net
  	if (!dev->tstats)
  		return -ENOMEM;
  
- 	for_each_possible_cpu(i) {
- 		struct pcpu_sw_netstats *ipip6_tunnel_stats;
- 		ipip6_tunnel_stats = per_cpu_ptr(dev->tstats, i);
- 		u64_stats_init(&ipip6_tunnel_stats->syncp);
- 	}
- 
 +	tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
 +	if (!tunnel->dst_cache) {
 +		free_percpu(dev->tstats);
 +		return -ENOMEM;
 +	}
 +
  	return 0;
  }
  
@@@ -1412,18 -1391,6 +1404,12 @@@ static int __net_init ipip6_fb_tunnel_i
  	if (!dev->tstats)
  		return -ENOMEM;
  
- 	for_each_possible_cpu(i) {
- 		struct pcpu_sw_netstats *ipip6_fb_stats;
- 		ipip6_fb_stats = per_cpu_ptr(dev->tstats, i);
- 		u64_stats_init(&ipip6_fb_stats->syncp);
- 	}
- 
 +	tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
 +	if (!tunnel->dst_cache) {
 +		free_percpu(dev->tstats);
 +		return -ENOMEM;
 +	}
 +
  	dev_hold(dev);
  	rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
  	return 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-02-18  1:52 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-02-18  1:52 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, dingtianhong, Joe Perches

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/bonding/bond_main.c between commit f80889a5b79c ("bonding:
Fix deadlock in bonding driver when using netpoll") from the net tree and
commit 90194264ceff ("bonding: Neaten pr_<level>") from the net-next tree.

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

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

diff --cc drivers/net/bonding/bond_main.c
index 1c6104d3501d,3bce855e627b..000000000000
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@@ -1547,13 -1544,12 +1545,13 @@@ int bond_enslave(struct net_device *bon
  		write_lock_bh(&bond->curr_slave_lock);
  		bond_select_active_slave(bond);
  		write_unlock_bh(&bond->curr_slave_lock);
 +		unblock_netpoll_tx();
  	}
  
- 	pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
+ 	pr_info("%s: Enslaving %s as %s interface with %s link\n",
  		bond_dev->name, slave_dev->name,
- 		bond_is_active_slave(new_slave) ? "n active" : " backup",
- 		new_slave->link != BOND_LINK_DOWN ? "n up" : " down");
+ 		bond_is_active_slave(new_slave) ? "an active" : "a backup",
+ 		new_slave->link != BOND_LINK_DOWN ? "an up" : "a down");
  
  	/* enslave is successful */
  	return 0;
@@@ -2865,11 -2858,9 +2862,11 @@@ static int bond_slave_netdev_event(unsi
  			break;
  		}
  
- 		pr_info("%s: Primary slave changed to %s, reselecting active slave.\n",
- 			bond->dev->name, bond->primary_slave ? slave_dev->name :
- 							       "none");
+ 		pr_info("%s: Primary slave changed to %s, reselecting active slave\n",
+ 			bond->dev->name,
+ 			bond->primary_slave ? slave_dev->name : "none");
 +
 +		block_netpoll_tx();
  		write_lock_bh(&bond->curr_slave_lock);
  		bond_select_active_slave(bond);
  		write_unlock_bh(&bond->curr_slave_lock);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-02-18  1:48 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-02-18  1:48 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jiri Bohac, Joe Perches

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/bonding/bond_3ad.h between commit 163c8ff30dbe ("bonding:
802.3ad: make aggregator_identifier bond-private") from the net tree and
commit 2ea24f2ecfdc ("bonding: Convert c99 comments") from the net-next
tree.

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

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

diff --cc drivers/net/bonding/bond_3ad.h
index f4dd9592ac62,3b97fe487dca..000000000000
--- a/drivers/net/bonding/bond_3ad.h
+++ b/drivers/net/bonding/bond_3ad.h
@@@ -251,9 -251,8 +251,9 @@@ struct ad_system 
  #define SLAVE_AD_INFO(slave) ((slave)->ad_info)
  
  struct ad_bond_info {
- 	struct ad_system system;	    /* 802.3ad system structure */
- 	u32 agg_select_timer;	    // Timer to select aggregator after all adapter's hand shakes
+ 	struct ad_system system;	/* 802.3ad system structure */
+ 	u32 agg_select_timer;		/* Timer to select aggregator after all adapter's hand shakes */
 +	u16 aggregator_identifier;
  };
  
  struct ad_slave_info {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-01-17  1:09 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-01-17  1:09 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Yuval Mintz

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
d9aee591b0f0 ("bnx2x: Don't release PCI bars on shutdown") from the net
tree and commit 33d8e6a5f555 ("bnx2x: Add AER support (missing bits)")
from the net-next tree.

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

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

diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 0067b975873f,cf17b660b4ee..000000000000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@@ -12942,26 -13082,27 +13082,28 @@@ static void __bnx2x_remove(struct pci_d
  		pci_set_power_state(pdev, PCI_D3hot);
  	}
  
+ 	bnx2x_disable_pcie_error_reporting(bp);
+ 
 -	if (bp->regview)
 -		iounmap(bp->regview);
 +	if (remove_netdev) {
 +		if (bp->regview)
 +			iounmap(bp->regview);
  
 -	/* for vf doorbells are part of the regview and were unmapped along with
 -	 * it. FW is only loaded by PF.
 -	 */
 -	if (IS_PF(bp)) {
 -		if (bp->doorbells)
 -			iounmap(bp->doorbells);
 +		/* For vfs, doorbells are part of the regview and were unmapped
 +		 * along with it. FW is only loaded by PF.
 +		 */
 +		if (IS_PF(bp)) {
 +			if (bp->doorbells)
 +				iounmap(bp->doorbells);
  
 -		bnx2x_release_firmware(bp);
 -	}
 -	bnx2x_free_mem_bp(bp);
 +			bnx2x_release_firmware(bp);
 +		}
 +		bnx2x_free_mem_bp(bp);
  
 -	if (remove_netdev)
  		free_netdev(dev);
  
 -	if (atomic_read(&pdev->enable_cnt) == 1)
 -		pci_release_regions(pdev);
 +		if (atomic_read(&pdev->enable_cnt) == 1)
 +			pci_release_regions(pdev);
 +	}
  
  	pci_disable_device(pdev);
  }

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-01-06  4:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-01-06  4:35 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Manish Chopra

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c between commit
f3e3ccf83bab ("qlcnic: Fix resource allocation for TX queues") from the
net tree and commit 154d0c810c53 ("qlcnic: VLAN enhancement for 84XX
adapters") from the net-next 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 drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
index 024f8161d2fe,98b621fb1227..000000000000
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
@@@ -75,17 -76,22 +76,22 @@@ static int qlcnic_sriov_pf_cal_res_limi
  	num_vfs = sriov->num_vfs;
  	max = num_vfs + 1;
  	info->bit_offsets = 0xffff;
- 	info->max_rx_mcast_mac_filters = res->num_rx_mcast_mac_filters;
- 	num_vf_macs = QLCNIC_SRIOV_VF_MAX_MAC;
 -	info->max_tx_ques = res->num_tx_queues / max;
+ 
+ 	if (qlcnic_83xx_pf_check(adapter))
+ 		num_macs = 1;
  
  	if (adapter->ahw->pci_func == func) {
- 		temp = res->num_rx_mcast_mac_filters - (num_vfs * num_vf_macs);
- 		info->max_rx_ucast_mac_filters = temp;
- 		temp = res->num_tx_mac_filters - (num_vfs * num_vf_macs);
- 		info->max_tx_mac_filters = temp;
  		info->min_tx_bw = 0;
  		info->max_tx_bw = MAX_BW;
 +		info->max_tx_ques = res->num_tx_queues - sriov->num_vfs;
+ 		temp = res->num_rx_ucast_mac_filters - num_macs * num_vfs;
+ 		info->max_rx_ucast_mac_filters = temp;
+ 		temp = res->num_tx_mac_filters - num_macs * num_vfs;
+ 		info->max_tx_mac_filters = temp;
+ 		temp = num_macs * num_vfs * QLCNIC_SRIOV_VF_MAX_MAC;
+ 		temp = res->num_rx_mcast_mac_filters - temp;
+ 		info->max_rx_mcast_mac_filters = temp;
+ 
  	} else {
  		id = qlcnic_sriov_func_to_index(adapter, func);
  		if (id < 0)
@@@ -93,9 -99,10 +99,11 @@@
  		vp = sriov->vf_info[id].vp;
  		info->min_tx_bw = vp->min_tx_bw;
  		info->max_tx_bw = vp->max_tx_bw;
- 		info->max_rx_ucast_mac_filters = num_vf_macs;
- 		info->max_tx_mac_filters = num_vf_macs;
+ 		info->max_rx_ucast_mac_filters = num_macs;
+ 		info->max_tx_mac_filters = num_macs;
 +		info->max_tx_ques = QLCNIC_SINGLE_RING;
+ 		temp = num_macs * QLCNIC_SRIOV_VF_MAX_MAC;
+ 		info->max_rx_mcast_mac_filters = temp;
  	}
  
  	info->max_rx_ip_addr = res->num_destip / max;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-01-06  4:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-01-06  4:35 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Li RongQing

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/ip6_tunnel.c between commit abb6013cca14 ("ipv6: fix the use of
pcpu_tstats in ip6_tunnel") from the net tree and commit 8f84985fec10
("net: unify the pcpu_tstats and br_cpu_netstats as one") from the
net-next tree.

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

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

diff --cc net/ipv6/ip6_tunnel.c
index 7881965a8248,02894216a46d..000000000000
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@@ -103,25 -101,17 +101,26 @@@ struct ip6_tnl_net 
  
  static struct net_device_stats *ip6_get_stats(struct net_device *dev)
  {
- 	struct pcpu_tstats tmp, sum = { 0 };
 -	struct pcpu_sw_netstats sum = { 0 };
++	struct pcpu_sw_netstats tmp, sum = { 0 };
  	int i;
  
  	for_each_possible_cpu(i) {
 +		unsigned int start;
- 		const struct pcpu_tstats *tstats = per_cpu_ptr(dev->tstats, i);
+ 		const struct pcpu_sw_netstats *tstats =
+ 						   per_cpu_ptr(dev->tstats, i);
  
 -		sum.rx_packets += tstats->rx_packets;
 -		sum.rx_bytes   += tstats->rx_bytes;
 -		sum.tx_packets += tstats->tx_packets;
 -		sum.tx_bytes   += tstats->tx_bytes;
 +		do {
 +			start = u64_stats_fetch_begin_bh(&tstats->syncp);
 +			tmp.rx_packets = tstats->rx_packets;
 +			tmp.rx_bytes = tstats->rx_bytes;
 +			tmp.tx_packets = tstats->tx_packets;
 +			tmp.tx_bytes =  tstats->tx_bytes;
 +		} while (u64_stats_fetch_retry_bh(&tstats->syncp, start));
 +
 +		sum.rx_packets += tmp.rx_packets;
 +		sum.rx_bytes   += tmp.rx_bytes;
 +		sum.tx_packets += tmp.tx_packets;
 +		sum.tx_bytes   += tmp.tx_bytes;
  	}
  	dev->stats.rx_packets = sum.rx_packets;
  	dev->stats.rx_bytes   = sum.rx_bytes;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2014-01-06  4:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2014-01-06  4:35 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Li RongQing

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/ip6_vti.c between commit 469bdcefdc47 ("ipv6: fix the use of
pcpu_tstats in ip6_vti.c") from the net tree and commit 8f84985fec10
("net: unify the pcpu_tstats and br_cpu_netstats as one") from the
net-next tree.

I fixed it up (I just used the former version which removes the code
modified by the latter) and can carry the fix as necessary (no action is
required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-12-12  0:58     ` David Miller
@ 2013-12-12  1:01       ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2013-12-12  1:01 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, jasowang, wuzhy

From: David Miller <davem@davemloft.net>
Date: Wed, 11 Dec 2013 19:58:52 -0500 (EST)

> Ok I should probably revert that one too.
> 
> I'll go ahead and do that now, because it's the most straightforward
> way to avoid this merge conflict.

Actually scratch that, there is no dependency between these two changes,
it just causes overlapping changes.

If it were the case that the 'net' bug fix actually added back a use
of that removed variable, things would be different.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-12-12  0:49   ` Stephen Rothwell
@ 2013-12-12  0:58     ` David Miller
  2013-12-12  1:01       ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: David Miller @ 2013-12-12  0:58 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, jasowang, wuzhy

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Dec 2013 11:49:59 +1100

> Hi Dave,
> 
> On Wed, 11 Dec 2013 19:36:39 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Thu, 12 Dec 2013 11:15:39 +1100
>> 
>> > Today's linux-next merge of the net-next tree got a conflict in
>> > drivers/net/macvtap.c between commit ce232ce01d61 ("macvtap: signal
>> > truncated packets") from the net tree and commit 55ec8e25cd97 ("macvtap:
>> > remove unused parameter in macvtap_do_read()") from the net-next tree.
>> > 
>> > I fixed it up (see below) and can carry the fix as necessary (no action
>> > is required).
>> 
>> The net-next commit in question was reverted last night.
> 
> Actually, the only relevant revert in the net-next tree I fetched this
> morning is commit de2aa4760b45 (Revert "macvtap: remove useless codes in
> macvtap_aio_read() and macvtap_recvmsg()") which reverts 41e4af69a598,
> not the commit mentioned above.  Unless you haven't pushed out the
> net-next tree with a later revert ...

Indeed, I was confusing those two commits.  Ok I should probably
revert that one too.

I'll go ahead and do that now, because it's the most straightforward
way to avoid this merge conflict.

Thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-12-12  0:36 ` David Miller
@ 2013-12-12  0:49   ` Stephen Rothwell
  2013-12-12  0:58     ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-12-12  0:49 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, linux-next, linux-kernel, jasowang, wuzhy

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

Hi Dave,

On Wed, 11 Dec 2013 19:36:39 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Dec 2013 11:15:39 +1100
> 
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/macvtap.c between commit ce232ce01d61 ("macvtap: signal
> > truncated packets") from the net tree and commit 55ec8e25cd97 ("macvtap:
> > remove unused parameter in macvtap_do_read()") from the net-next tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> The net-next commit in question was reverted last night.

Actually, the only relevant revert in the net-next tree I fetched this
morning is commit de2aa4760b45 (Revert "macvtap: remove useless codes in
macvtap_aio_read() and macvtap_recvmsg()") which reverts 41e4af69a598,
not the commit mentioned above.  Unless you haven't pushed out the
net-next tree with a later revert ...

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-12-12  0:15 Stephen Rothwell
@ 2013-12-12  0:36 ` David Miller
  2013-12-12  0:49   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: David Miller @ 2013-12-12  0:36 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, jasowang, wuzhy

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Dec 2013 11:15:39 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/macvtap.c between commit ce232ce01d61 ("macvtap: signal
> truncated packets") from the net tree and commit 55ec8e25cd97 ("macvtap:
> remove unused parameter in macvtap_do_read()") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

The net-next commit in question was reverted last night.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-12-12  0:15 Stephen Rothwell
  2013-12-12  0:36 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-12-12  0:15 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jason Wang, Zhi Yong Wu

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/macvtap.c between commit ce232ce01d61 ("macvtap: signal
truncated packets") from the net tree and commit 55ec8e25cd97 ("macvtap:
remove unused parameter in macvtap_do_read()") from the net-next tree.

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

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

diff --cc drivers/net/macvtap.c
index 2a89da080317,4a34bcb6549f..000000000000
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@@ -819,12 -813,13 +815,12 @@@ static ssize_t macvtap_put_user(struct 
  	}
  
  	ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
 -	copied += len;
  
  done:
 -	return ret ? ret : copied;
 +	return ret ? ret : total;
  }
  
- static ssize_t macvtap_do_read(struct macvtap_queue *q, struct kiocb *iocb,
+ static ssize_t macvtap_do_read(struct macvtap_queue *q,
  			       const struct iovec *iv, unsigned long len,
  			       int noblock)
  {
@@@ -875,8 -870,8 +871,8 @@@ static ssize_t macvtap_aio_read(struct 
  		goto out;
  	}
  
- 	ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK);
+ 	ret = macvtap_do_read(q, iv, len, file->f_flags & O_NONBLOCK);
 -	ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */
 +	ret = min_t(ssize_t, ret, len);
  	if (ret > 0)
  		iocb->ki_pos = ret;
  out:

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-10-31  4:19 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-10-31  4:19 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Vlad Yasevich, Joe Perches

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_private.h between commit 06499098a02b ("bridge: pass
correct vlan id to multicast code") from the net tree and commit
348662a1429f ("net: 8021q/bluetooth/bridge/can/ceph: Remove extern from
function prototypes") from the net-next tree.

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

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

diff --cc net/bridge/br_private.h
index 2e8244efb262,d1ca6d956633..000000000000
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@@ -449,44 -434,40 +434,40 @@@ int br_ioctl_deviceless_stub(struct ne
  /* br_multicast.c */
  #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
  extern unsigned int br_mdb_rehash_seq;
- extern int br_multicast_rcv(struct net_bridge *br,
- 			    struct net_bridge_port *port,
- 			    struct sk_buff *skb,
- 			    u16 vid);
- extern struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
- 					       struct sk_buff *skb, u16 vid);
- extern void br_multicast_add_port(struct net_bridge_port *port);
- extern void br_multicast_del_port(struct net_bridge_port *port);
- extern void br_multicast_enable_port(struct net_bridge_port *port);
- extern void br_multicast_disable_port(struct net_bridge_port *port);
- extern void br_multicast_init(struct net_bridge *br);
- extern void br_multicast_open(struct net_bridge *br);
- extern void br_multicast_stop(struct net_bridge *br);
- extern void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
- 				 struct sk_buff *skb);
- extern void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
- 				 struct sk_buff *skb, struct sk_buff *skb2);
- extern int br_multicast_set_router(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_port_router(struct net_bridge_port *p,
- 					unsigned long val);
- extern int br_multicast_toggle(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
- extern struct net_bridge_mdb_entry *br_mdb_ip_get(
- 				struct net_bridge_mdb_htable *mdb,
- 				struct br_ip *dst);
- extern struct net_bridge_mdb_entry *br_multicast_new_group(struct net_bridge *br,
- 				struct net_bridge_port *port, struct br_ip *group);
- extern void br_multicast_free_pg(struct rcu_head *head);
- extern struct net_bridge_port_group *br_multicast_new_port_group(
- 				struct net_bridge_port *port,
- 				struct br_ip *group,
- 				struct net_bridge_port_group __rcu *next,
- 				unsigned char state);
- extern void br_mdb_init(void);
- extern void br_mdb_uninit(void);
- extern void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
- 			  struct br_ip *group, int type);
+ int br_multicast_rcv(struct net_bridge *br, struct net_bridge_port *port,
 -		     struct sk_buff *skb);
++		     struct sk_buff *skb, u16 vid);
+ struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
+ 					struct sk_buff *skb, u16 vid);
+ void br_multicast_add_port(struct net_bridge_port *port);
+ void br_multicast_del_port(struct net_bridge_port *port);
+ void br_multicast_enable_port(struct net_bridge_port *port);
+ void br_multicast_disable_port(struct net_bridge_port *port);
+ void br_multicast_init(struct net_bridge *br);
+ void br_multicast_open(struct net_bridge *br);
+ void br_multicast_stop(struct net_bridge *br);
+ void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
+ 			  struct sk_buff *skb);
+ void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
+ 			  struct sk_buff *skb, struct sk_buff *skb2);
+ int br_multicast_set_router(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_port_router(struct net_bridge_port *p, unsigned long val);
+ int br_multicast_toggle(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
+ struct net_bridge_mdb_entry *
+ br_mdb_ip_get(struct net_bridge_mdb_htable *mdb, struct br_ip *dst);
+ struct net_bridge_mdb_entry *
+ br_multicast_new_group(struct net_bridge *br, struct net_bridge_port *port,
+ 		       struct br_ip *group);
+ void br_multicast_free_pg(struct rcu_head *head);
+ struct net_bridge_port_group *
+ br_multicast_new_port_group(struct net_bridge_port *port, struct br_ip *group,
+ 			    struct net_bridge_port_group __rcu *next,
+ 			    unsigned char state);
+ void br_mdb_init(void);
+ void br_mdb_uninit(void);
+ void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
+ 		   struct br_ip *group, int type);
  
  #define mlock_dereference(X, br) \
  	rcu_dereference_protected(X, lockdep_is_held(&br->multicast_lock))

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-10-30  2:14 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-10-30  2:14 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Nikolay Aleksandrov, Joe Perches

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/netconsole.c between commit c7c6effdeffc ("netconsole: fix
multiple race conditions") from the net tree and commit 22ded57729e6
("netconsole: Convert to pr_<level>") from the net-next tree.

(Thanks for removing that spare blank line :-))

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

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

diff --cc drivers/net/netconsole.c
index c9a15925a1f7,a8ef4c4b94be..000000000000
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@@ -333,18 -336,14 +335,18 @@@ static ssize_t store_enabled(struct net
  		netpoll_print_options(&nt->np);
  
  		err = netpoll_setup(&nt->np);
 -		if (err) {
 -			mutex_unlock(&nt->mutex);
 +		if (err)
  			return err;
 -		}
  
- 		printk(KERN_INFO "netconsole: network logging started\n");
+ 		pr_info("network logging started\n");
 -
  	} else {	/* 0 */
 +		/* We need to disable the netconsole before cleaning it up
 +		 * otherwise we might end up in write_msg() with
 +		 * nt->np.dev == NULL and nt->enabled == 1
 +		 */
 +		spin_lock_irqsave(&target_list_lock, flags);
 +		nt->enabled = 0;
 +		spin_unlock_irqrestore(&target_list_lock, flags);
  		netpoll_cleanup(&nt->np);
  	}
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-10-28  4:23 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-10-28  4:23 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Somnath Kotur, Sathya Perla

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit e9e2a904ef0a
("be2net: Warn users of possible broken functionality on BE2 cards with
very old FW versions with latest driver") from the net tree and commit
6384a4d0dcf9 ("be2net: add support for ndo_busy_poll") from the net-next
tree.

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

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

diff --cc drivers/net/ethernet/emulex/benet/be.h
index c99dac6a9ddf,b2765ebb0268..000000000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -696,23 -733,114 +733,123 @@@ static inline int qnq_async_evt_rcvd(st
  	return adapter->flags & BE_FLAGS_QNQ_ASYNC_EVT_RCVD;
  }
  
 +static inline int fw_major_num(const char *fw_ver)
 +{
 +	int fw_major = 0;
 +
 +	sscanf(fw_ver, "%d.", &fw_major);
 +
 +	return fw_major;
 +}
 +
- extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
- 		u16 num_popped);
- extern void be_link_status_update(struct be_adapter *adapter, u8 link_status);
- extern void be_parse_stats(struct be_adapter *adapter);
- extern int be_load_fw(struct be_adapter *adapter, u8 *func);
- extern bool be_is_wol_supported(struct be_adapter *adapter);
- extern bool be_pause_supported(struct be_adapter *adapter);
- extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+ #ifdef CONFIG_NET_RX_BUSY_POLL
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ 	bool status = true;
+ 
+ 	spin_lock(&eqo->lock); /* BH is already disabled */
+ 	if (eqo->state & BE_EQ_LOCKED) {
+ 		WARN_ON(eqo->state & BE_EQ_NAPI);
+ 		eqo->state |= BE_EQ_NAPI_YIELD;
+ 		status = false;
+ 	} else {
+ 		eqo->state = BE_EQ_NAPI;
+ 	}
+ 	spin_unlock(&eqo->lock);
+ 	return status;
+ }
+ 
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ 	spin_lock(&eqo->lock); /* BH is already disabled */
+ 
+ 	WARN_ON(eqo->state & (BE_EQ_POLL | BE_EQ_NAPI_YIELD));
+ 	eqo->state = BE_EQ_IDLE;
+ 
+ 	spin_unlock(&eqo->lock);
+ }
+ 
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ 	bool status = true;
+ 
+ 	spin_lock_bh(&eqo->lock);
+ 	if (eqo->state & BE_EQ_LOCKED) {
+ 		eqo->state |= BE_EQ_POLL_YIELD;
+ 		status = false;
+ 	} else {
+ 		eqo->state |= BE_EQ_POLL;
+ 	}
+ 	spin_unlock_bh(&eqo->lock);
+ 	return status;
+ }
+ 
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ 	spin_lock_bh(&eqo->lock);
+ 
+ 	WARN_ON(eqo->state & (BE_EQ_NAPI));
+ 	eqo->state = BE_EQ_IDLE;
+ 
+ 	spin_unlock_bh(&eqo->lock);
+ }
+ 
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ 	spin_lock_init(&eqo->lock);
+ 	eqo->state = BE_EQ_IDLE;
+ }
+ 
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ 	local_bh_disable();
+ 
+ 	/* It's enough to just acquire napi lock on the eqo to stop
+ 	 * be_busy_poll() from processing any queueus.
+ 	 */
+ 	while (!be_lock_napi(eqo))
+ 		mdelay(1);
+ 
+ 	local_bh_enable();
+ }
+ 
+ #else /* CONFIG_NET_RX_BUSY_POLL */
+ 
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ 	return true;
+ }
+ 
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ }
+ 
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ 	return false;
+ }
+ 
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ 
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ 
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ #endif /* CONFIG_NET_RX_BUSY_POLL */
+ 
+ void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
+ 		  u16 num_popped);
+ void be_link_status_update(struct be_adapter *adapter, u8 link_status);
+ void be_parse_stats(struct be_adapter *adapter);
+ int be_load_fw(struct be_adapter *adapter, u8 *func);
+ bool be_is_wol_supported(struct be_adapter *adapter);
+ bool be_pause_supported(struct be_adapter *adapter);
+ u32 be_get_fw_log_level(struct be_adapter *adapter);
  int be_update_queues(struct be_adapter *adapter);
  int be_poll(struct napi_struct *napi, int budget);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-06-27  3:49 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-06-27  3:49 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Guenter Roeck, Chris Healy

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/freescale/fec_main.c between commits 32bc9b46d840
("fec: Add support to restart autonegotiate") and d13919301d9a ("net:
fec: Fix build for MCF5272") from the net tree and commit 38ae92dc215e
("ec: Add support for reading RMON registers") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/freescale/fec_main.c
index d48099f,ed6180e..0000000
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@@ -1444,13 -1443,121 +1451,122 @@@ static int fec_enet_set_pauseparam(stru
  	return 0;
  }
  
- #endif /* !defined(CONFIG_M5272) */
 -#ifndef CONFIG_M5272
+ static const struct fec_stat {
+ 	char name[ETH_GSTRING_LEN];
+ 	u16 offset;
+ } fec_stats[] = {
+ 	/* RMON TX */
+ 	{ "tx_dropped", RMON_T_DROP },
+ 	{ "tx_packets", RMON_T_PACKETS },
+ 	{ "tx_broadcast", RMON_T_BC_PKT },
+ 	{ "tx_multicast", RMON_T_MC_PKT },
+ 	{ "tx_crc_errors", RMON_T_CRC_ALIGN },
+ 	{ "tx_undersize", RMON_T_UNDERSIZE },
+ 	{ "tx_oversize", RMON_T_OVERSIZE },
+ 	{ "tx_fragment", RMON_T_FRAG },
+ 	{ "tx_jabber", RMON_T_JAB },
+ 	{ "tx_collision", RMON_T_COL },
+ 	{ "tx_64byte", RMON_T_P64 },
+ 	{ "tx_65to127byte", RMON_T_P65TO127 },
+ 	{ "tx_128to255byte", RMON_T_P128TO255 },
+ 	{ "tx_256to511byte", RMON_T_P256TO511 },
+ 	{ "tx_512to1023byte", RMON_T_P512TO1023 },
+ 	{ "tx_1024to2047byte", RMON_T_P1024TO2047 },
+ 	{ "tx_GTE2048byte", RMON_T_P_GTE2048 },
+ 	{ "tx_octets", RMON_T_OCTETS },
+ 
+ 	/* IEEE TX */
+ 	{ "IEEE_tx_drop", IEEE_T_DROP },
+ 	{ "IEEE_tx_frame_ok", IEEE_T_FRAME_OK },
+ 	{ "IEEE_tx_1col", IEEE_T_1COL },
+ 	{ "IEEE_tx_mcol", IEEE_T_MCOL },
+ 	{ "IEEE_tx_def", IEEE_T_DEF },
+ 	{ "IEEE_tx_lcol", IEEE_T_LCOL },
+ 	{ "IEEE_tx_excol", IEEE_T_EXCOL },
+ 	{ "IEEE_tx_macerr", IEEE_T_MACERR },
+ 	{ "IEEE_tx_cserr", IEEE_T_CSERR },
+ 	{ "IEEE_tx_sqe", IEEE_T_SQE },
+ 	{ "IEEE_tx_fdxfc", IEEE_T_FDXFC },
+ 	{ "IEEE_tx_octets_ok", IEEE_T_OCTETS_OK },
+ 
+ 	/* RMON RX */
+ 	{ "rx_packets", RMON_R_PACKETS },
+ 	{ "rx_broadcast", RMON_R_BC_PKT },
+ 	{ "rx_multicast", RMON_R_MC_PKT },
+ 	{ "rx_crc_errors", RMON_R_CRC_ALIGN },
+ 	{ "rx_undersize", RMON_R_UNDERSIZE },
+ 	{ "rx_oversize", RMON_R_OVERSIZE },
+ 	{ "rx_fragment", RMON_R_FRAG },
+ 	{ "rx_jabber", RMON_R_JAB },
+ 	{ "rx_64byte", RMON_R_P64 },
+ 	{ "rx_65to127byte", RMON_R_P65TO127 },
+ 	{ "rx_128to255byte", RMON_R_P128TO255 },
+ 	{ "rx_256to511byte", RMON_R_P256TO511 },
+ 	{ "rx_512to1023byte", RMON_R_P512TO1023 },
+ 	{ "rx_1024to2047byte", RMON_R_P1024TO2047 },
+ 	{ "rx_GTE2048byte", RMON_R_P_GTE2048 },
+ 	{ "rx_octets", RMON_R_OCTETS },
+ 
+ 	/* IEEE RX */
+ 	{ "IEEE_rx_drop", IEEE_R_DROP },
+ 	{ "IEEE_rx_frame_ok", IEEE_R_FRAME_OK },
+ 	{ "IEEE_rx_crc", IEEE_R_CRC },
+ 	{ "IEEE_rx_align", IEEE_R_ALIGN },
+ 	{ "IEEE_rx_macerr", IEEE_R_MACERR },
+ 	{ "IEEE_rx_fdxfc", IEEE_R_FDXFC },
+ 	{ "IEEE_rx_octets_ok", IEEE_R_OCTETS_OK },
+ };
+ 
+ static void fec_enet_get_ethtool_stats(struct net_device *dev,
+ 	struct ethtool_stats *stats, u64 *data)
+ {
+ 	struct fec_enet_private *fep = netdev_priv(dev);
+ 	int i;
+ 
+ 	for (i = 0; i < ARRAY_SIZE(fec_stats); i++)
+ 		data[i] = readl(fep->hwp + fec_stats[i].offset);
+ }
+ 
+ static void fec_enet_get_strings(struct net_device *netdev,
+ 	u32 stringset, u8 *data)
+ {
+ 	int i;
+ 	switch (stringset) {
+ 	case ETH_SS_STATS:
+ 		for (i = 0; i < ARRAY_SIZE(fec_stats); i++)
+ 			memcpy(data + i * ETH_GSTRING_LEN,
+ 				fec_stats[i].name, ETH_GSTRING_LEN);
+ 		break;
+ 	}
+ }
+ 
+ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
+ {
+ 	switch (sset) {
+ 	case ETH_SS_STATS:
+ 		return ARRAY_SIZE(fec_stats);
+ 	default:
+ 		return -EOPNOTSUPP;
+ 	}
+ }
+ #endif
+ 
+ static int fec_enet_nway_reset(struct net_device *dev)
+ {
+ 	struct fec_enet_private *fep = netdev_priv(dev);
+ 	struct phy_device *phydev = fep->phy_dev;
+ 
+ 	if (!phydev)
+ 		return -ENODEV;
+ 
+ 	return genphy_restart_aneg(phydev);
+ }
  
  static const struct ethtool_ops fec_enet_ethtool_ops = {
 +#if !defined(CONFIG_M5272)
  	.get_pauseparam		= fec_enet_get_pauseparam,
  	.set_pauseparam		= fec_enet_set_pauseparam,
 +#endif
  	.get_settings		= fec_enet_get_settings,
  	.set_settings		= fec_enet_set_settings,
  	.get_drvinfo		= fec_enet_get_drvinfo,
@@@ -1891,9 -2001,13 +2011,14 @@@ fec_probe(struct platform_device *pdev
  	if (pdev->id_entry &&
  	    (pdev->id_entry->driver_data & FEC_QUIRK_HAS_GBIT))
  		fep->pause_flag |= FEC_PAUSE_FLAG_AUTONEG;
 +#endif
  
- 	fep->hwp = devm_request_and_ioremap(&pdev->dev, r);
+ 	fep->hwp = devm_ioremap_resource(&pdev->dev, r);
+ 	if (IS_ERR(fep->hwp)) {
+ 		ret = PTR_ERR(fep->hwp);
+ 		goto failed_ioremap;
+ 	}
+ 
  	fep->pdev = pdev;
  	fep->dev_id = dev_id++;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-06-25  2:54 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-06-25  2:54 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Sergei Shtylyov

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/renesas/sh_eth.c between commit ca8c35852138
("sh_eth: fix unhandled RFE interrupt") from the net tree and commit
8f80899665c4 ("sh_eth: remove 'tx_error_check' field of 'struct
sh_eth_cpu_data'") from the net-next 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 drivers/net/ethernet/renesas/sh_eth.c
index e29fe8d,7732f11..0000000
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@@ -380,10 -382,8 +382,9 @@@ static struct sh_eth_cpu_data r8a777x_d
  	.eesipr_value	= 0x01ff009f,
  
  	.tx_check	= EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
 -	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RDE |
 -			  EESR_RFRMER | EESR_TFE | EESR_TDE | EESR_ECI,
 +	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
 +			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE |
 +			  EESR_ECI,
- 	.tx_error_check	= EESR_TWB | EESR_TABT | EESR_TDE | EESR_TFE,
  
  	.apr		= 1,
  	.mpr		= 1,
@@@ -425,13 -414,11 +415,12 @@@ static struct sh_eth_cpu_data sh7724_da
  
  	.ecsr_value	= ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
  	.ecsipr_value	= ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
- 	.eesipr_value	= DMAC_M_RFRMER | DMAC_M_ECI | 0x01ff009f,
+ 	.eesipr_value	= 0x01ff009f,
  
  	.tx_check	= EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
 -	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RDE |
 -			  EESR_RFRMER | EESR_TFE | EESR_TDE | EESR_ECI,
 +	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
 +			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE |
 +			  EESR_ECI,
- 	.tx_error_check	= EESR_TWB | EESR_TABT | EESR_TDE | EESR_TFE,
  
  	.apr		= 1,
  	.mpr		= 1,
@@@ -480,11 -453,10 +455,11 @@@ static struct sh_eth_cpu_data sh7757_da
  	.rmcr_value	= 0x00000001,
  
  	.tx_check	= EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
 -	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RDE |
 -			  EESR_RFRMER | EESR_TFE | EESR_TDE | EESR_ECI,
 +	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
 +			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE |
 +			  EESR_ECI,
- 	.tx_error_check	= EESR_TWB | EESR_TABT | EESR_TDE | EESR_TFE,
  
+ 	.irq_flags	= IRQF_SHARED,
  	.apr		= 1,
  	.mpr		= 1,
  	.tpauser	= 1,
@@@ -595,11 -521,9 +524,9 @@@ static struct sh_eth_cpu_data sh7757_da
  	.eesipr_value	= DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
  
  	.tx_check	= EESR_TC1 | EESR_FTC,
 -	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT | \
 -			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE | \
 -			  EESR_ECI,
 +	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
 +			  EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
 +			  EESR_TDE | EESR_ECI,
- 	.tx_error_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_TDE | \
- 			  EESR_TFE,
  	.fdr_value	= 0x0000072f,
  	.rmcr_value	= 0x00000001,
  
@@@ -677,11 -579,9 +582,9 @@@ static struct sh_eth_cpu_data sh7734_da
  	.eesipr_value	= DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
  
  	.tx_check	= EESR_TC1 | EESR_FTC,
 -	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT | \
 -			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE | \
 -			  EESR_ECI,
 +	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
 +			  EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
 +			  EESR_TDE | EESR_ECI,
- 	.tx_error_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_TDE | \
- 			  EESR_TFE,
  
  	.apr		= 1,
  	.mpr		= 1,
@@@ -814,11 -643,9 +646,9 @@@ static struct sh_eth_cpu_data r8a7740_d
  	.eesipr_value	= DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
  
  	.tx_check	= EESR_TC1 | EESR_FTC,
 -	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT | \
 -			  EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE | \
 -			  EESR_ECI,
 +	.eesr_err_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
 +			  EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
 +			  EESR_TDE | EESR_ECI,
- 	.tx_error_check	= EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_TDE | \
- 			  EESR_TFE,
  
  	.apr		= 1,
  	.mpr		= 1,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-06-21  2:33 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-06-21  2:33 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Guenter Roeck, Chris Healy

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/freescale/fec_main.c between commit d13919301d9a
("net: fec: Fix build for MCF5272") from the net tree and commit
32bc9b46d840 ("fec: Add support to restart autonegotiate") from the
net-next tree.

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

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

diff --cc drivers/net/ethernet/freescale/fec_main.c
index d48099f,46f2544..0000000
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@@ -1444,13 -1435,20 +1443,24 @@@ static int fec_enet_set_pauseparam(stru
  	return 0;
  }
  
 +#endif /* !defined(CONFIG_M5272) */
 +
+ static int fec_enet_nway_reset(struct net_device *dev)
+ {
+ 	struct fec_enet_private *fep = netdev_priv(dev);
+ 	struct phy_device *phydev = fep->phy_dev;
+ 
+ 	if (!phydev)
+ 		return -ENODEV;
+ 
+ 	return genphy_restart_aneg(phydev);
+ }
+ 
  static const struct ethtool_ops fec_enet_ethtool_ops = {
 +#if !defined(CONFIG_M5272)
  	.get_pauseparam		= fec_enet_get_pauseparam,
  	.set_pauseparam		= fec_enet_set_pauseparam,
 +#endif
  	.get_settings		= fec_enet_get_settings,
  	.set_settings		= fec_enet_set_settings,
  	.get_drvinfo		= fec_enet_get_drvinfo,
@@@ -1891,9 -1887,13 +1900,14 @@@ fec_probe(struct platform_device *pdev
  	if (pdev->id_entry &&
  	    (pdev->id_entry->driver_data & FEC_QUIRK_HAS_GBIT))
  		fep->pause_flag |= FEC_PAUSE_FLAG_AUTONEG;
 +#endif
  
- 	fep->hwp = devm_request_and_ioremap(&pdev->dev, r);
+ 	fep->hwp = devm_ioremap_resource(&pdev->dev, r);
+ 	if (IS_ERR(fep->hwp)) {
+ 		ret = PTR_ERR(fep->hwp);
+ 		goto failed_ioremap;
+ 	}
+ 
  	fep->pdev = pdev;
  	fep->dev_id = dev_id++;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-06-20  2:58 Stephen Rothwell
@ 2013-06-20  3:37 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2013-06-20  3:37 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, johannes.berg

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 20 Jun 2013 12:58:23 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/wireless/nl80211.c between commit 3a5a423bb958 ("nl80211: fix attrbuf
> access race by allocating a separate one") from the net tree and commit
> 5fe231e87372 ("cfg80211: vastly simplify locking") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I did this merge a few hours ago and hit the same conflict.

Although I fixed the bug in that rtnl_unlock() is not performed in
all the return code paths.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-06-20  2:58 Stephen Rothwell
  2013-06-20  3:37 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-06-20  2:58 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Johannes Berg

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/wireless/nl80211.c between commit 3a5a423bb958 ("nl80211: fix attrbuf
access race by allocating a separate one") from the net tree and commit
5fe231e87372 ("cfg80211: vastly simplify locking") from the net-next tree.

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

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

diff --cc net/wireless/nl80211.c
index b14b7e3,31d265f..0000000
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -1564,17 -1527,12 +1527,17 @@@ static int nl80211_dump_wiphy(struct sk
  	struct cfg80211_registered_device *dev;
  	s64 filter_wiphy = -1;
  	bool split = false;
 -	struct nlattr **tb = nl80211_fam.attrbuf;
 +	struct nlattr **tb;
  	int res;
  
 +	/* will be zeroed in nlmsg_parse() */
 +	tb = kmalloc(sizeof(*tb) * (NL80211_ATTR_MAX + 1), GFP_KERNEL);
 +	if (!tb)
 +		return -ENOMEM;
 +
- 	mutex_lock(&cfg80211_mutex);
+ 	rtnl_lock();
  	res = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
 -			  tb, nl80211_fam.maxattr, nl80211_policy);
 +			  tb, NL80211_ATTR_MAX, nl80211_policy);
  	if (res == 0) {
  		split = tb[NL80211_ATTR_SPLIT_WIPHY_DUMP];
  		if (tb[NL80211_ATTR_WIPHY])
@@@ -1586,11 -1544,8 +1549,10 @@@
  			int ifidx = nla_get_u32(tb[NL80211_ATTR_IFINDEX]);
  
  			netdev = dev_get_by_index(sock_net(skb->sk), ifidx);
 -			if (!netdev)
 +			if (!netdev) {
- 				mutex_unlock(&cfg80211_mutex);
 +				kfree(tb);
  				return -ENODEV;
 +			}
  			if (netdev->ieee80211_ptr) {
  				dev = wiphy_to_dev(
  					netdev->ieee80211_ptr->wiphy);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-30  2:24 Stephen Rothwell
  2013-04-30  8:04 ` David Miller
@ 2013-05-02  1:25 ` Chen Gang
  1 sibling, 0 replies; 325+ messages in thread
From: Chen Gang @ 2013-05-02  1:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel, Alan Ott

On 2013年04月30日 10:24, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
> comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
> tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
> packets") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks

-- 
Chen Gang

Asianux Corporation

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-30  2:24 Stephen Rothwell
@ 2013-04-30  8:04 ` David Miller
  2013-05-02  1:25 ` Chen Gang
  1 sibling, 0 replies; 325+ messages in thread
From: David Miller @ 2013-04-30  8:04 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, gang.chen, alan

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 30 Apr 2013 12:24:23 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
> comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
> tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
> packets") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This should be taken care of as well, thanks Stephen.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-26  3:27 Stephen Rothwell
@ 2013-04-30  8:03 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2013-04-30  8:03 UTC (permalink / raw)
  To: sfr
  Cc: netdev, linux-next, linux-kernel, ajit.khaparde,
	vasundhara.volam, sathya.perla

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Apr 2013 13:27:01 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/emulex/benet/be.h between commit bc0c3405abbb
> ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") from the
> net tree and commit 0ad3157e813a ("be2net: Avoid flashing BE3 UFI on
> BE3-R chip") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I fixed it up identically when I merged net into net-next, thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-26  3:24 Stephen Rothwell
  2013-04-28 13:49 ` Yuval Mintz
@ 2013-04-30  8:02 ` David Miller
  1 sibling, 0 replies; 325+ messages in thread
From: David Miller @ 2013-04-30  8:02 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, ariele, yuvalmin, eilong

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Apr 2013 13:24:47 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
> ecf01c22be03 ("bnx2x: Prevent NULL pointer dereference in kdump") from
> the net tree and commit 5b0752c863d7 ("bnx2x: Fix VF statistics") from
> the net-next tree.
> 
> I am not sure about this, but I just used the net tree version but I
> assume something more may be needed and can carry the fix as necessary (no
> action is required).

I've just resolved this when I merged net into net-next.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-04-30  2:24 Stephen Rothwell
  2013-04-30  8:04 ` David Miller
  2013-05-02  1:25 ` Chen Gang
  0 siblings, 2 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-30  2:24 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Chen Gang, Alan Ott

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
packets") from the net-next tree.

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

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

diff --cc net/mac802154/mac802154.h
index 703c121,5c9e021..0000000
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@@ -88,9 -88,7 +88,7 @@@ struct mac802154_sub_if_data 
  
  #define mac802154_to_priv(_hw)	container_of(_hw, struct mac802154_priv, hw)
  
- #define MAC802154_MAX_XMIT_ATTEMPTS	3
- 
 -#define MAC802154_CHAN_NONE		(~(u8)0) /* No channel is assigned */
 +#define MAC802154_CHAN_NONE		0xff /* No channel is assigned */
  
  extern struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced;
  extern struct ieee802154_mlme_ops mac802154_mlme_wpan;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-28 13:49 ` Yuval Mintz
@ 2013-04-28 23:57   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-28 23:57 UTC (permalink / raw)
  To: Yuval Mintz
  Cc: David Miller, netdev, linux-next, linux-kernel, Ariel Elior,
	Eilon Greenstein

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

Hi,

On Sun, 28 Apr 2013 16:49:33 +0300 "Yuval Mintz" <yuvalmin@broadcom.com> wrote:
>
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
> > ecf01c22be03 ("bnx2x: Prevent NULL pointer dereference in kdump") from
> > the net tree and commit 5b0752c863d7 ("bnx2x: Fix VF statistics") from
> > the net-next tree.
> > 
> > I am not sure about this, but I just used the net tree version but I
> > assume something more may be needed and can carry the fix as
> > necessary (no action is required).
> 
> This patch adds the missing functionality from the `net-next' patch
> which was lost due to the merge.

Thanks.

> Is `linux-next' the correct tree to send it into?
> (I couldn't designate it to `net-next' as the merge between `net' and
> `net-next' hasn't occured yet, thus no collision there)

I have added this hunk to the merge conflict resolution in linux-next.  I
assume that Dave will do this as well when he merges the net tree into
the net-next tree.

> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> ---
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index
> 06dee5c..52cf71c 100644 ---
> a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -6053,6 +6053,8
> @@ void bnx2x_pre_irq_nic_init(struct bnx2x *bp) bnx2x_init_def_sb(bp);
>  		bnx2x_update_dsb_idx(bp);
>  		bnx2x_init_sp_ring(bp);
> +	} else {
> +		bnx2x_memset_stats(bp);
>  	}
>  }

This patch was badly corrupted ...

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-26  3:24 Stephen Rothwell
@ 2013-04-28 13:49 ` Yuval Mintz
  2013-04-28 23:57   ` Stephen Rothwell
  2013-04-30  8:02 ` David Miller
  1 sibling, 1 reply; 325+ messages in thread
From: Yuval Mintz @ 2013-04-28 13:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Ariel Elior,
	Yuval Mintz, Eilon Greenstein

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
> ecf01c22be03 ("bnx2x: Prevent NULL pointer dereference in kdump") from
> the net tree and commit 5b0752c863d7 ("bnx2x: Fix VF statistics") from
> the net-next tree.
> 
> I am not sure about this, but I just used the net tree version but I
> assume something more may be needed and can carry the fix as
> necessary (no action is required).
> 

Hi Stephen,

This patch adds the missing functionality from the `net-next' patch
which was lost due to the merge.

Is `linux-next' the correct tree to send it into?
(I couldn't designate it to `net-next' as the merge between `net' and
`net-next' hasn't occured yet, thus no collision there)

Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index
06dee5c..52cf71c 100644 ---
a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -6053,6 +6053,8
@@ void bnx2x_pre_irq_nic_init(struct bnx2x *bp) bnx2x_init_def_sb(bp);
 		bnx2x_update_dsb_idx(bp);
 		bnx2x_init_sp_ring(bp);
+	} else {
+		bnx2x_memset_stats(bp);
 	}
 }
 
-- 
1.8.1.227.g44fe835


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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-04-26  3:38 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-26  3:38 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
include/net/tcp.h between commit 093162553c33 ("tcp: force a dst refcount
when prequeue packet") from the net tree and commit b2fb4f54ecd4 ("tcp:
uninline tcp_prequeue()") from the net-next tree.

I fixed it up (I used the next-next version of tcp.h and added the
following patch) and can carry the fix as necessary (no action is
required).  Thanks for the heads up Dave!

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Apr 2013 13:35:50 +1000
Subject: [PATCH] tcp: merge fixup for movemenet of tcp_prequeue

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/ipv4/tcp_ipv4.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8667aaa..5dcf177 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1926,6 +1926,7 @@ bool tcp_prequeue(struct sock *sk, struct sk_buff *skb)
 	    skb_queue_len(&tp->ucopy.prequeue) == 0)
 		return false;
 
+	skb_dst_force(skb);
 	__skb_queue_tail(&tp->ucopy.prequeue, skb);
 	tp->ucopy.memory += skb->truesize;
 	if (tp->ucopy.memory > sk->sk_rcvbuf) {
-- 
1.8.1

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-04-26  3:27 Stephen Rothwell
  2013-04-30  8:03 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-26  3:27 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Ajit Khaparde, Vasundhara Volam, Sathya Perla

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit bc0c3405abbb
("be2net: fix a Tx stall bug caused by a specific ipv6 packet") from the
net tree and commit 0ad3157e813a ("be2net: Avoid flashing BE3 UFI on
BE3-R chip") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/emulex/benet/be.h
index 941aa1f,e2d5ced..0000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -435,7 -435,7 +436,8 @@@ struct be_adapter 
  	u8 wol_cap;
  	bool wol;
  	u32 uc_macs;		/* Count of secondary UC MAC programmed */
 +	u16 qnq_vid;
+ 	u16 asic_rev;
  	u32 msg_enable;
  	int be_get_temp_freq;
  	u16 max_mcast_mac;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-04-26  3:24 Stephen Rothwell
  2013-04-28 13:49 ` Yuval Mintz
  2013-04-30  8:02 ` David Miller
  0 siblings, 2 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-26  3:24 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Ariel Elior, Yuval Mintz, Eilon Greenstein

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
ecf01c22be03 ("bnx2x: Prevent NULL pointer dereference in kdump") from
the net tree and commit 5b0752c863d7 ("bnx2x: Fix VF statistics") from
the net-next tree.

I am not sure about this, but I just used the net tree version but I
assume something more may be needed and can carry the fix as necessary (no
action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-04-19  2:53 Stephen Rothwell
@ 2013-04-23  0:38 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2013-04-23  0:38 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, ordex, lindner_marek, martin

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 19 Apr 2013 12:53:04 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/batman-adv/routing.c between commit fe8a93b95145 ("batman-adv: make
> is_my_mac() check for the current mesh only") from the net tree and
> commits f86ce0ad107b ("batman-adv: Return reason for failure in
> batadv_check_unicast_packet()") and 612d2b4fe0a1 ("batman-adv: network
> coding - save overheard and tx packets for decoding") from the net-next
> tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I've merged net into net-next and added all the necessary fixups
in the merge commit.

Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-04-19  2:53 Stephen Rothwell
  2013-04-23  0:38 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-04-19  2:53 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Antonio Quartulli, Marek Lindner,
	Martin Hundebøll

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/batman-adv/routing.c between commit fe8a93b95145 ("batman-adv: make
is_my_mac() check for the current mesh only") from the net tree and
commits f86ce0ad107b ("batman-adv: Return reason for failure in
batadv_check_unicast_packet()") and 612d2b4fe0a1 ("batman-adv: network
coding - save overheard and tx packets for decoding") from the net-next
tree.

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

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

diff --cc net/batman-adv/routing.c
index 319f290,8f88967..0000000
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@@ -548,8 -549,17 +549,19 @@@ batadv_find_ifalter_router(struct batad
  	return router;
  }
  
+ /**
+  * batadv_check_unicast_packet - Check for malformed unicast packets
++ * @batpriv: some description ...
+  * @skb: packet to check
+  * @hdr_size: size of header to pull
+  *
+  * Check for short header and bad addresses in given packet. Returns negative
+  * value when check fails and 0 otherwise. The negative value depends on the
+  * reason: -ENODATA for bad header, -EBADR for broadcast destination or source,
+  * and -EREMOTE for non-local (other host) destination.
+  */
 -static int batadv_check_unicast_packet(struct sk_buff *skb, int hdr_size)
 +static int batadv_check_unicast_packet(struct batadv_priv *bat_priv,
 +				       struct sk_buff *skb, int hdr_size)
  {
  	struct ethhdr *ethhdr;
  
@@@ -565,11 -575,11 +577,11 @@@
  
  	/* packet with broadcast sender address */
  	if (is_broadcast_ether_addr(ethhdr->h_source))
- 		return -1;
+ 		return -EBADR;
  
  	/* not for me */
 -	if (!batadv_is_my_mac(ethhdr->h_dest))
 +	if (!batadv_is_my_mac(bat_priv, ethhdr->h_dest))
- 		return -1;
+ 		return -EREMOTE;
  
  	return 0;
  }
@@@ -1046,7 -1058,16 +1061,16 @@@ int batadv_recv_unicast_packet(struct s
  	if (is4addr)
  		hdr_size = sizeof(*unicast_4addr_packet);
  
- 	if (batadv_check_unicast_packet(bat_priv, skb, hdr_size) < 0)
+ 	/* function returns -EREMOTE for promiscuous packets */
 -	check = batadv_check_unicast_packet(skb, hdr_size);
++	check = batadv_check_unicast_packet(bat_priv, skb, hdr_size);
+ 
+ 	/* Even though the packet is not for us, we might save it to use for
+ 	 * decoding a later received coded packet
+ 	 */
+ 	if (check == -EREMOTE)
+ 		batadv_nc_skb_store_sniffed_unicast(bat_priv, skb);
+ 
+ 	if (check < 0)
  		return NET_RX_DROP;
  
  	if (!batadv_check_unicast_ttvn(bat_priv, skb))

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-02-12  0:57 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-02-12  0:57 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Yuval Mintz, Michael S. Tsirkin, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c between commit
0aba93e2b9fb ("bnx2x: set gso_type") from the net tree and commit
cbf1de72324a ("bnx2x: fix GRO parameters") from the net-next tree.

I fixed it up (since the former commit says that the latter is the more
complex fix, I just used that) and can carry the fix as necessary (no
action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-02-02 10:05 ` Jiri Pirko
@ 2013-02-04 23:21   ` Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-02-04 23:21 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: David Miller, netdev, linux-next, linux-kernel,
	Marcelo Ricardo Leitner,
	\"YOSHIFUJI Hideaki / 吉藤英明\

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

Hi Jiri,

On Sat, 2 Feb 2013 11:05:06 +0100 Jiri Pirko <jiri@resnulli.us> wrote:
>
> >diff --cc net/ipv6/route.c
> >index 363d8b7,f3328bc..0000000
> >--- a/net/ipv6/route.c
> >+++ b/net/ipv6/route.c
> >@@@ -928,7 -884,7 +884,7 @@@ restart
> >  	dst_hold(&rt->dst);
> >  	read_unlock_bh(&table->tb6_lock);
> >  
> >- 	if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
> > -	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
> >++	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL | RTF_GATEWAY)))
> 
> I believe that no change here is correct to do. RTF_LOCAL here is needed
> only before Yoshifuji's "IPv6 rt->n removal"

Thanks for the feedback.  I have removed the " | RTF_LOCAL" from the
merge resolution.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2013-02-02  3:22 Stephen Rothwell
@ 2013-02-02 10:05 ` Jiri Pirko
  2013-02-04 23:21   ` Stephen Rothwell
  0 siblings, 1 reply; 325+ messages in thread
From: Jiri Pirko @ 2013-02-02 10:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel,
	Marcelo Ricardo Leitner,
	\"YOSHIFUJI Hideaki / 吉藤英明\

Sat, Feb 02, 2013 at 04:22:53AM CET, sfr@canb.auug.org.au wrote:
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in
>net/ipv6/route.c between commit bd30e947207e ("ipv6: do not create
>neighbor entries for local delivery") from the net tree and commit
>c440f1609b65 ("ipv6: Do not depend on rt->n in ip6_pol_route()") from the
>net-next 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/ipv6/route.c
>index 363d8b7,f3328bc..0000000
>--- a/net/ipv6/route.c
>+++ b/net/ipv6/route.c
>@@@ -928,7 -884,7 +884,7 @@@ restart
>  	dst_hold(&rt->dst);
>  	read_unlock_bh(&table->tb6_lock);
>  
>- 	if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
> -	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
>++	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL | RTF_GATEWAY)))

I believe that no change here is correct to do. RTF_LOCAL here is needed
only before Yoshifuji's "IPv6 rt->n removal"
	
	
>  		nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
>  	else if (!(rt->dst.flags & DST_HOST))
>  		nrt = rt6_alloc_clone(rt, &fl6->daddr);



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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-02-02  3:22 Stephen Rothwell
  2013-02-02 10:05 ` Jiri Pirko
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2013-02-02  3:22 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Marcelo Ricardo Leitner, Jiri Pirko,
	\"YOSHIFUJI Hideaki / 吉藤英明\

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/route.c between commit bd30e947207e ("ipv6: do not create
neighbor entries for local delivery") from the net tree and commit
c440f1609b65 ("ipv6: Do not depend on rt->n in ip6_pol_route()") from the
net-next 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/ipv6/route.c
index 363d8b7,f3328bc..0000000
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@@ -928,7 -884,7 +884,7 @@@ restart
  	dst_hold(&rt->dst);
  	read_unlock_bh(&table->tb6_lock);
  
- 	if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
 -	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
++	if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL | RTF_GATEWAY)))
  		nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
  	else if (!(rt->dst.flags & DST_HOST))
  		nrt = rt6_alloc_clone(rt, &fl6->daddr);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-02-02  3:22 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-02-02  3:22 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Neil Horman, Stephen Hemminger

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vmxnet3/vmxnet3_drv.c between commit 6cdd20c380eb ("vmxnet3:
set carrier state properly on probe") from the net tree and commit
204a6e659439 ("vmxnet3: use netdev_ printk wrappers") from the net-next
tree.

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

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

diff --cc drivers/net/vmxnet3/vmxnet3_drv.c
index 12c6440,b1c90f8..0000000
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@@ -152,9 -148,10 +148,9 @@@ vmxnet3_check_link(struct vmxnet3_adapt
  
  	adapter->link_speed = ret >> 16;
  	if (ret & 1) { /* Link is up. */
- 		printk(KERN_INFO "%s: NIC Link is Up %d Mbps\n",
- 		       adapter->netdev->name, adapter->link_speed);
+ 		netdev_info(adapter->netdev, "NIC Link is Up %d Mbps\n",
+ 			    adapter->link_speed);
 -		if (!netif_carrier_ok(adapter->netdev))
 -			netif_carrier_on(adapter->netdev);
 +		netif_carrier_on(adapter->netdev);
  
  		if (affectTxQueue) {
  			for (i = 0; i < adapter->num_tx_queues; i++)
@@@ -162,9 -159,9 +158,8 @@@
  						 adapter);
  		}
  	} else {
- 		printk(KERN_INFO "%s: NIC Link is Down\n",
- 		       adapter->netdev->name);
+ 		netdev_info(adapter->netdev, "NIC Link is Down\n");
 -		if (netif_carrier_ok(adapter->netdev))
 -			netif_carrier_off(adapter->netdev);
 +		netif_carrier_off(adapter->netdev);
  
  		if (affectTxQueue) {
  			for (i = 0; i < adapter->num_tx_queues; i++)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2013-01-11  2:03 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2013-01-11  2:03 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Yuval Mintz, Ariel Elior, Eilon Greenstein

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c between commit
4864a16ae69d ("bnx2x: Fix fastpath structures when memory allocation
fails") from the net tree and commit 8ca5e17e58c9 ("bnx2x: Support of PF
driver of a VF acquire request") from the net-next tree.

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

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

diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index f771ddf,00706c4..0000000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@@ -87,30 -85,33 +85,58 @@@ static inline void bnx2x_move_fp(struc
  }
  
  /**
 + * bnx2x_shrink_eth_fp - guarantees fastpath structures stay intact
 + *
 + * @bp:	driver handle
 + * @delta:	number of eth queues which were not allocated
 + */
 +static void bnx2x_shrink_eth_fp(struct bnx2x *bp, int delta)
 +{
 +	int i, cos, old_eth_num = BNX2X_NUM_ETH_QUEUES(bp);
 +
 +	/* Queue pointer cannot be re-set on an fp-basis, as moving pointer
 +	 * backward along the array could cause memory to be overriden
 +	 */
 +	for (cos = 1; cos < bp->max_cos; cos++) {
 +		for (i = 0; i < old_eth_num - delta; i++) {
 +			struct bnx2x_fastpath *fp = &bp->fp[i];
 +			int new_idx = cos * (old_eth_num - delta) + i;
 +
 +			memcpy(&bp->bnx2x_txq[new_idx], fp->txdata_ptr[cos],
 +			       sizeof(struct bnx2x_fp_txdata));
 +			fp->txdata_ptr[cos] = &bp->bnx2x_txq[new_idx];
 +		}
 +	}
 +}
 +
++/**
+  * bnx2x_fill_fw_str - Fill buffer with FW version string.
+  *
+  * @bp:        driver handle
+  * @buf:       character buffer to fill with the fw name
+  * @buf_len:   length of the above buffer
+  *
+  */
+ void bnx2x_fill_fw_str(struct bnx2x *bp, char *buf, size_t buf_len)
+ {
+ 	if (IS_PF(bp)) {
+ 		u8 phy_fw_ver[PHY_FW_VER_LEN];
+ 
+ 		phy_fw_ver[0] = '\0';
+ 		bnx2x_get_ext_phy_fw_version(&bp->link_params,
+ 					     phy_fw_ver, PHY_FW_VER_LEN);
+ 		strlcpy(buf, bp->fw_ver, buf_len);
+ 		snprintf(buf + strlen(bp->fw_ver), 32 - strlen(bp->fw_ver),
+ 			 "bc %d.%d.%d%s%s",
+ 			 (bp->common.bc_ver & 0xff0000) >> 16,
+ 			 (bp->common.bc_ver & 0xff00) >> 8,
+ 			 (bp->common.bc_ver & 0xff),
+ 			 ((phy_fw_ver[0] != '\0') ? " phy " : ""), phy_fw_ver);
+ 	} else {
+ 		bnx2x_vf_fill_fw_str(bp, buf, buf_len);
+ 	}
+ }
+ 
  int load_count[2][3] = { {0} }; /* per-path: 0-common, 1-port0, 2-port1 */
  
  /* free skb in the packet ring at pos idx

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-09-28  1:35 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2012-09-28  1:35 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Wei Yongjun, Eric W. Biederman

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/l2tp/l2tp_netlink.c between commit 7f8436a1269e ("l2tp: fix return
value check") from the net tree and commit 15e473046cb6 ("netlink: Rename
pid to portid to avoid confusion") from the net-next tree.

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

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

diff --cc net/l2tp/l2tp_netlink.c
index 6f93635,6ec3f67..0000000
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@@ -78,10 -78,10 +78,10 @@@ static int l2tp_nl_cmd_noop(struct sk_b
  		goto out;
  	}
  
- 	hdr = genlmsg_put(msg, info->snd_pid, info->snd_seq,
+ 	hdr = genlmsg_put(msg, info->snd_portid, info->snd_seq,
  			  &l2tp_nl_family, 0, L2TP_CMD_NOOP);
 -	if (IS_ERR(hdr)) {
 -		ret = PTR_ERR(hdr);
 +	if (!hdr) {
 +		ret = -EMSGSIZE;
  		goto err_out;
  	}
  
@@@ -248,10 -248,10 +248,10 @@@ static int l2tp_nl_tunnel_send(struct s
  	struct l2tp_stats stats;
  	unsigned int start;
  
- 	hdr = genlmsg_put(skb, pid, seq, &l2tp_nl_family, flags,
+ 	hdr = genlmsg_put(skb, portid, seq, &l2tp_nl_family, flags,
  			  L2TP_CMD_TUNNEL_GET);
 -	if (IS_ERR(hdr))
 -		return PTR_ERR(hdr);
 +	if (!hdr)
 +		return -EMSGSIZE;
  
  	if (nla_put_u8(skb, L2TP_ATTR_PROTO_VERSION, tunnel->version) ||
  	    nla_put_u32(skb, L2TP_ATTR_CONN_ID, tunnel->tunnel_id) ||
@@@ -616,9 -616,9 +616,9 @@@ static int l2tp_nl_session_send(struct 
  
  	sk = tunnel->sock;
  
- 	hdr = genlmsg_put(skb, pid, seq, &l2tp_nl_family, flags, L2TP_CMD_SESSION_GET);
+ 	hdr = genlmsg_put(skb, portid, seq, &l2tp_nl_family, flags, L2TP_CMD_SESSION_GET);
 -	if (IS_ERR(hdr))
 -		return PTR_ERR(hdr);
 +	if (!hdr)
 +		return -EMSGSIZE;
  
  	if (nla_put_u32(skb, L2TP_ATTR_CONN_ID, tunnel->tunnel_id) ||
  	    nla_put_u32(skb, L2TP_ATTR_SESSION_ID, session->session_id) ||

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-09-25  5:13   ` David Miller
@ 2012-09-25  5:23     ` Eric Dumazet
  0 siblings, 0 replies; 325+ messages in thread
From: Eric Dumazet @ 2012-09-25  5:23 UTC (permalink / raw)
  To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, edumazet

On Tue, 2012-09-25 at 01:13 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 25 Sep 2012 07:10:42 +0200
> 
> > Oops, my bad, net/ipv4/raw.c changes in 5640f7685831 ("net: use a per
> > task frag allocator") should not be there :
> > 
> > I accidentally left a debugging version of the patch I sent to fix the
> > icmp bug.
> > 
> > Sorry David for this, I am not sure how I can help on this ?
> 
> The thing to do is send me a patch to revert the raw.c change from
> net-next, right?

Sure, I'll do that after my breakfast and some coffee ;)




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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-09-25  5:10 ` Eric Dumazet
@ 2012-09-25  5:13   ` David Miller
  2012-09-25  5:23     ` Eric Dumazet
  0 siblings, 1 reply; 325+ messages in thread
From: David Miller @ 2012-09-25  5:13 UTC (permalink / raw)
  To: eric.dumazet; +Cc: sfr, netdev, linux-next, linux-kernel, edumazet

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 25 Sep 2012 07:10:42 +0200

> Oops, my bad, net/ipv4/raw.c changes in 5640f7685831 ("net: use a per
> task frag allocator") should not be there :
> 
> I accidentally left a debugging version of the patch I sent to fix the
> icmp bug.
> 
> Sorry David for this, I am not sure how I can help on this ?

The thing to do is send me a patch to revert the raw.c change from
net-next, right?

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-09-25  2:34 Stephen Rothwell
@ 2012-09-25  5:10 ` Eric Dumazet
  2012-09-25  5:13   ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Eric Dumazet @ 2012-09-25  5:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Eric Dumazet

On Tue, 2012-09-25 at 12:34 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv4/raw.c between commit ab43ed8b7490 ("ipv4: raw: fix icmp_filter
> ()") from the net tree and commit 5640f7685831 ("net: use a per task frag
> allocator") from the net-next tree.
> 
> They are basically the same patch (for this file) except the net-next
> version adds two pr_err() calls. I used the net-next version and can carry
> the fix as necessary (no action is required).
> 
> I do wonder if this change belongs in the net-next patch?

Oops, my bad, net/ipv4/raw.c changes in 5640f7685831 ("net: use a per
task frag allocator") should not be there :

I accidentally left a debugging version of the patch I sent to fix the
icmp bug.

Sorry David for this, I am not sure how I can help on this ?




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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-09-25  2:34 Stephen Rothwell
  2012-09-25  5:10 ` Eric Dumazet
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-09-25  2:34 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv4/raw.c between commit ab43ed8b7490 ("ipv4: raw: fix icmp_filter
()") from the net tree and commit 5640f7685831 ("net: use a per task frag
allocator") from the net-next tree.

They are basically the same patch (for this file) except the net-next
version adds two pr_err() calls. I used the net-next version and can carry
the fix as necessary (no action is required).

I do wonder if this change belongs in the net-next patch?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-09-21  1:30 Stephen Rothwell
@ 2012-09-21 18:58 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-09-21 18:58 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, bjorn

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 21 Sep 2012 11:30:09 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/usb/qmi_wwan.c between commit 9db273f45686 ("net:
> qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200") from the
> net tree and commit bd877e489126 ("net: qmi_wwan: use a single bind
> function for all device types") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks Stephen, this should be resolved over the weekend as I plan
to do a merge during this time.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-09-21  1:30 Stephen Rothwell
  2012-09-21 18:58 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-09-21  1:30 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, \"Bjørn Mork\

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in drivers/net/usb/qmi_wwan.c between commit 9db273f45686 ("net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200") from the net tree and commit bd877e489126 ("net: qmi_wwan: use a single bind function for all device types") from the net-next tree.

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

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

diff --cc drivers/net/usb/qmi_wwan.c
index 3543c9e,e7b53f0..0000000
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@@ -366,21 -353,17 +353,21 @@@ static const struct usb_device_id produ
  	},
  
  	/* 2. Combined interface devices matching on class+protocol */
 +	{	/* Huawei E367 and possibly others in "Windows mode" */
 +		USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 7),
 +		.driver_info        = (unsigned long)&qmi_wwan_info,
 +	},
  	{	/* Huawei E392, E398 and possibly others in "Windows mode" */
  		USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
- 		.driver_info        = (unsigned long)&qmi_wwan_shared,
+ 		.driver_info        = (unsigned long)&qmi_wwan_info,
  	},
 -	{	/* Pantech UML290 */
 -		USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
 +	{	/* Pantech UML290, P4200 and more */
 +		USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
- 		.driver_info        = (unsigned long)&qmi_wwan_shared,
+ 		.driver_info        = (unsigned long)&qmi_wwan_info,
  	},
  	{	/* Pantech UML290 - newer firmware */
 -		USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
 +		USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
- 		.driver_info        = (unsigned long)&qmi_wwan_shared,
+ 		.driver_info        = (unsigned long)&qmi_wwan_info,
  	},
  
  	/* 3. Combined interface devices matching on interface number */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-09-14  1:18 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2012-09-14  1:18 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric Dumazet, Eric W. Biederman

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/nfnetlink_log.c between commit 0626af313957 ("netfilter:
take care of timewait sockets") from the  tree and commit 9eea9515cb5f
("userns: nfnetlink_log: Report socket uids in the log sockets user
namespace") from the net-next tree.

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

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

diff --cc net/netfilter/nfnetlink_log.c
index 5cfb5be,8cb67c4..0000000
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@@ -500,14 -501,16 +502,17 @@@ __build_packet_message(struct nfulnl_in
  	}
  
  	/* UID */
 -	if (skb->sk) {
 -		read_lock_bh(&skb->sk->sk_callback_lock);
 -		if (skb->sk->sk_socket && skb->sk->sk_socket->file) {
 -			struct file *file = skb->sk->sk_socket->file;
 +	sk = skb->sk;
 +	if (sk && sk->sk_state != TCP_TIME_WAIT) {
 +		read_lock_bh(&sk->sk_callback_lock);
 +		if (sk->sk_socket && sk->sk_socket->file) {
 +			struct file *file = sk->sk_socket->file;
- 			__be32 uid = htonl(file->f_cred->fsuid);
- 			__be32 gid = htonl(file->f_cred->fsgid);
+ 			__be32 uid = htonl(from_kuid_munged(inst->peer_user_ns,
+ 							    file->f_cred->fsuid));
+ 			__be32 gid = htonl(from_kgid_munged(inst->peer_user_ns,
+ 							    file->f_cred->fsgid));
+ 			/* need to unlock here since NLA_PUT may goto */
 -			read_unlock_bh(&skb->sk->sk_callback_lock);
 +			read_unlock_bh(&sk->sk_callback_lock);
  			if (nla_put_be32(inst->skb, NFULA_UID, uid) ||
  			    nla_put_be32(inst->skb, NFULA_GID, gid))
  				goto nla_put_failure;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-09-14  1:17 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2012-09-14  1:17 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric W. Biederman, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/xt_LOG.c between commit 0626af313957 ("netfilter: take care
of timewait sockets") from the net tree and commit 8c6e2a941ae7 ("userns:
Convert xt_LOG to print socket kuids and kgids as uids and gids") from
the net-next 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/netfilter/xt_LOG.c
index 91e9af4,02a2bf4..0000000
--- a/net/netfilter/xt_LOG.c
+++ b/net/netfilter/xt_LOG.c
@@@ -145,19 -145,6 +145,21 @@@ static int dump_tcp_header(struct sbuf
  	return 0;
  }
  
 +static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
 +{
 +	if (!sk || sk->sk_state == TCP_TIME_WAIT)
 +		return;
 +
 +	read_lock_bh(&sk->sk_callback_lock);
 +	if (sk->sk_socket && sk->sk_socket->file) {
++		const struct cred *cred = sk->sk_socket->file->f_cred;
 +		sb_add(m, "UID=%u GID=%u ",
- 			sk->sk_socket->file->f_cred->fsuid,
- 			sk->sk_socket->file->f_cred->fsgid);
++			from_kuid_munged(&init_user_ns, cred->fsuid),
++			from_kgid_munged(&init_user_ns, cred->fsgid));
++	}
 +	read_unlock_bh(&sk->sk_callback_lock);
 +}
 +
  /* One level of recursion won't kill us */
  static void dump_ipv4_packet(struct sbuff *m,
  			const struct nf_loginfo *info,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* RE: linux-next: manual merge of the net-next tree with the net tree
  2012-06-26  3:15 Stephen Rothwell
@ 2012-06-29  6:46 ` Sjur BRENDELAND
  0 siblings, 0 replies; 325+ messages in thread
From: Sjur BRENDELAND @ 2012-06-29  6:46 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Per ELLEFSEN, Kim LILLIESTIERNA

Hi Stephen,

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/caif/caif_hsi.c between commits 3935600a7f34 ("caif-hsi:
> Bugfix - Piggyback'ed embedded CAIF frame lost") and 1fdc7630b2cb
> ("caif-hsi: Add missing return in error path") from the net tree and
> commits 4e7bb59d49fb ("caif-hsi: Removed dead code") and c41254006377
> ("caif-hsi: Add rtnl support") from the net-next tree.
> 
> I fixed them up (see below) and can carry the fix as necessary.

Sorry for late response. Your merge looks perfect.

Thanks,
Sjur

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-06-26  3:15 Stephen Rothwell
  2012-06-29  6:46 ` Sjur BRENDELAND
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-06-26  3:15 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Per Ellefsen,
	\"Sjur Brændeland\,
	Kim Lilliestierna

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/caif/caif_hsi.c between commits 3935600a7f34 ("caif-hsi:
Bugfix - Piggyback'ed embedded CAIF frame lost") and 1fdc7630b2cb
("caif-hsi: Add missing return in error path") from the net tree and
commits 4e7bb59d49fb ("caif-hsi: Removed dead code") and c41254006377
("caif-hsi: Add rtnl support") from the net-next tree.

I fixed them up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/caif/caif_hsi.c
index 4a27adb,1c2bd01..0000000
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@@ -693,8 -678,8 +678,6 @@@ static void cfhsi_rx_done(struct cfhsi 
  			 */
  			memcpy(rx_buf, (u8 *)piggy_desc,
  					CFHSI_DESC_SHORT_SZ);
- 			if (desc_pld_len == -EPROTO)
- 				goto out_of_sync;
 -			/* Mark no embedded frame here */
 -			piggy_desc->offset = 0;
  		}
  	}
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-06-25  3:38 Stephen Rothwell
@ 2012-06-25 23:04 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-06-25 23:04 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, ordex, sven

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Jun 2012 13:38:12 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/batman-adv/translation-table.c between commit 8b8e4bc0391f
> ("batman-adv: fix race condition in TT full-table replacement") from the
> net tree and commit 7d211efc5087 ("batman-adv: Prefix originator
> non-static functions with batadv_") from the net-next tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

I've also resolved this during today's net --> net-next merge.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-06-25  3:33 Stephen Rothwell
@ 2012-06-25 23:04 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-06-25 23:04 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, bjorn

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Jun 2012 13:33:18 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/usb/qmi_wwan.c between commit b9f90eb27402 ("net: qmi_wwan:
> fix Gobi device probing") from the net tree and various commits from the
> net-next tree.
> 
> I am not sure how to fix this, but the comments in the net tree commit
> implied that it would be placed in the 3.6 code, so I just used the
> version of this file from the net-next tree.

I've resolved this during today's net --> net-next merge.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-06-25  3:38 Stephen Rothwell
  2012-06-25 23:04 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-06-25  3:38 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Antonio Quartulli, Sven Eckelmann

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/batman-adv/translation-table.c between commit 8b8e4bc0391f
("batman-adv: fix race condition in TT full-table replacement") from the
net tree and commit 7d211efc5087 ("batman-adv: Prefix originator
non-static functions with batadv_") from the net-next tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/batman-adv/translation-table.c
index 2ab83d7,5180d50..0000000
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@@ -141,7 -139,8 +139,7 @@@ static void tt_orig_list_entry_free_rcu
  	struct tt_orig_list_entry *orig_entry;
  
  	orig_entry = container_of(rcu, struct tt_orig_list_entry, rcu);
- 	orig_node_free_ref(orig_entry->orig_node);
 -	atomic_dec(&orig_entry->orig_node->tt_size);
+ 	batadv_orig_node_free_ref(orig_entry->orig_node);
  	kfree(orig_entry);
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-06-25  3:33 Stephen Rothwell
  2012-06-25 23:04 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-06-25  3:33 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, \"Bjørn Mork\

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/usb/qmi_wwan.c between commit b9f90eb27402 ("net: qmi_wwan:
fix Gobi device probing") from the net tree and various commits from the
net-next tree.

I am not sure how to fix this, but the comments in the net tree commit
implied that it would be placed in the 3.6 code, so I just used the
version of this file from the net-next tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-04-27  2:02 Stephen Rothwell
  0 siblings, 0 replies; 325+ messages in thread
From: Stephen Rothwell @ 2012-04-27  2:02 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jeff Kirsher, Bruce Allan

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/intel/e1000e/param.c between commit 727c356f4d79
("e1000e: Fix default interrupt throttle rate not set in NIC HW") from
the net tree and commit 6ad651456e3c ("e1000e: cleanup remaining strings
split across multiple lines") from the net-next tree.

The former included the change from the latter, so I used that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-03-05  2:11 Stephen Rothwell
@ 2012-03-06  2:17 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-03-06  2:17 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, sbhatewara, eric.dumazet

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Mar 2012 13:11:03 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/vmxnet3/vmxnet3_drv.c between commit efead8710aad ("vmxnet3:
> Fix transport header size") from the net tree and commit 8bca5d1ebb8b
> ("vmxnet3: cleanup tso headers manipulation") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

I'm taking care of this right now, thanks Stephen.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-03-05  2:11 Stephen Rothwell
  2012-03-06  2:17 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-03-05  2:11 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Shreyas Bhatewara, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vmxnet3/vmxnet3_drv.c between commit efead8710aad ("vmxnet3:
Fix transport header size") from the net tree and commit 8bca5d1ebb8b
("vmxnet3: cleanup tso headers manipulation") from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/vmxnet3/vmxnet3_drv.c
index 756c0f5,adf527e..0000000
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@@ -824,14 -820,17 +820,12 @@@ vmxnet3_parse_and_copy_hdr(struct sk_bu
  			ctx->eth_ip_hdr_size = skb_checksum_start_offset(skb);
  
  			if (ctx->ipv4) {
- 				struct iphdr *iph = (struct iphdr *)
- 						    skb_network_header(skb);
+ 				const struct iphdr *iph = ip_hdr(skb);
+ 
  				if (iph->protocol == IPPROTO_TCP)
- 					ctx->l4_hdr_size = ((struct tcphdr *)
- 					   skb_transport_header(skb))->doff * 4;
+ 					ctx->l4_hdr_size = tcp_hdrlen(skb);
  				else if (iph->protocol == IPPROTO_UDP)
- 					ctx->l4_hdr_size =
- 							sizeof(struct udphdr);
 -					/*
 -					 * Use tcp header size so that bytes to
 -					 * be copied are more than required by
 -					 * the device.
 -					 */
 -					ctx->l4_hdr_size = sizeof(struct tcphdr);
++					ctx->l4_hdr_size = sizeof(struct udphdr);
  				else
  					ctx->l4_hdr_size = 0;
  			} else {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-03-01  2:33 Stephen Rothwell
@ 2012-03-01 22:24 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-03-01 22:24 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, mcarlson, mchan

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 1 Mar 2012 13:33:33 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/tg3.c between commit 65ec698d1368 ("tg3:
> Fix tg3_get_stats64 for 5700 / 5701 devs") from the net tree and various
> commits from the net-next tree.
> 
> I just used the version from the net-next tree for today (assuming that
> this conflict will be fixed shortly).

I'll try to take care of this now, thanks Stephen.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-03-01  2:33 Stephen Rothwell
  2012-03-01 22:24 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-03-01  2:33 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Matt Carlson, Michael Chan

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/tg3.c between commit 65ec698d1368 ("tg3:
Fix tg3_get_stats64 for 5700 / 5701 devs") from the net tree and various
commits from the net-next tree.

I just used the version from the net-next tree for today (assuming that
this conflict will be fixed shortly).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-02-16 23:30   ` Stephen Rothwell
@ 2012-02-19 22:41     ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2012-02-19 22:41 UTC (permalink / raw)
  To: sfr; +Cc: yuvalmin, netdev, linux-next, linux-kernel, eilong, eric.dumazet

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Feb 2012 10:30:11 +1100

> Hi,
> 
> On Thu, 16 Feb 2012 13:24:10 +0200 "Yuval Mintz" <yuvalmin@broadcom.com> wrote:
>>
>> I don't fully understand your merge - it seems to create a mash between
>> the "bnx2x: fix bnx2x_storm_stats_update() on big endian" patch in net,
>> and the "bnx2x: consistent statistics after internal driver reload"
>> patch in net-next.
> 
> That is exactly what the merge conflict resolution did.  i.e. the patch
> you supplied below is not needed in linux-next because that is
> effectively what I did.  It is the same as Dave will do when he merges
> the net tree into the net-next tree as well, I assume.

I've taken care of this.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-02-16 11:24 ` Yuval Mintz
  2012-02-16 13:47   ` Yuval Mintz
@ 2012-02-16 23:30   ` Stephen Rothwell
  2012-02-19 22:41     ` David Miller
  1 sibling, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-02-16 23:30 UTC (permalink / raw)
  To: Yuval Mintz; +Cc: davem, netdev, linux-next, linux-kernel, eilong, eric.dumazet

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

Hi,

On Thu, 16 Feb 2012 13:24:10 +0200 "Yuval Mintz" <yuvalmin@broadcom.com> wrote:
>
> I don't fully understand your merge - it seems to create a mash between
> the "bnx2x: fix bnx2x_storm_stats_update() on big endian" patch in net,
> and the "bnx2x: consistent statistics after internal driver reload"
> patch in net-next.

That is exactly what the merge conflict resolution did.  i.e. the patch
you supplied below is not needed in linux-next because that is
effectively what I did.  It is the same as Dave will do when he merges
the net tree into the net-next tree as well, I assume.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-02-16 11:24 ` Yuval Mintz
@ 2012-02-16 13:47   ` Yuval Mintz
  2012-02-16 23:30   ` Stephen Rothwell
  1 sibling, 0 replies; 325+ messages in thread
From: Yuval Mintz @ 2012-02-16 13:47 UTC (permalink / raw)
  To: sfr; +Cc: davem, netdev, linux-next, linux-kernel, eilong, eric.dumazet

On Thu, 2012-02-16 at 13:24 +0200, Yuval Mintz wrote:
> On Wed, 2012-02-15 at 17:38 -0800, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c between commit
> > 66d885cba670 ("bnx2x: fix bnx2x_storm_stats_update() on big endian") from
> > the net tree and commit 1355b704b9ba ("bnx2x: consistent statistics after
> > internal driver reload") from the net-next tree.
> > 
> > I fixed it up (see below) but suspect that there may be more needed.
> 
> Hey Stephen,
> 
> I don't fully understand your merge - it seems to create a mash between
> the "bnx2x: fix bnx2x_storm_stats_update() on big endian" patch in net,
> and the "bnx2x: consistent statistics after internal driver reload"
> patch in net-next.
> 
> If the purpose of this merge is simply to update net-next tree with the
> changes from "bnx2x: fix bnx2x_storm_stats_update() on big endian", you
> might consider the following patch:
> 
> Subject: [PATCH 1/1] bnx2x: merge net --> net-next
> From: Mintz Yuval <yuvalmin@broadcom.com>
> 
> This patch applies the changes made in the patch
> "bnx2x: fix bnx2x_storm_stats_update() on big endian" to net into net-next.
> 
> Signed-off-by: Mintz Yuval <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
We need of course to thank Eric Dumazet <eric.dumazet@gmail.com> for the
original patch.



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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2012-02-16  1:38 Stephen Rothwell
@ 2012-02-16 11:24 ` Yuval Mintz
  2012-02-16 13:47   ` Yuval Mintz
  2012-02-16 23:30   ` Stephen Rothwell
  0 siblings, 2 replies; 325+ messages in thread
From: Yuval Mintz @ 2012-02-16 11:24 UTC (permalink / raw)
  To: sfr, davem, netdev; +Cc: linux-next, linux-kernel, eilong, eric.dumazet

On Wed, 2012-02-15 at 17:38 -0800, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c between commit
> 66d885cba670 ("bnx2x: fix bnx2x_storm_stats_update() on big endian") from
> the net tree and commit 1355b704b9ba ("bnx2x: consistent statistics after
> internal driver reload") from the net-next tree.
> 
> I fixed it up (see below) but suspect that there may be more needed.

Hey Stephen,

I don't fully understand your merge - it seems to create a mash between
the "bnx2x: fix bnx2x_storm_stats_update() on big endian" patch in net,
and the "bnx2x: consistent statistics after internal driver reload"
patch in net-next.

If the purpose of this merge is simply to update net-next tree with the
changes from "bnx2x: fix bnx2x_storm_stats_update() on big endian", you
might consider the following patch:

Subject: [PATCH 1/1] bnx2x: merge net --> net-next
From: Mintz Yuval <yuvalmin@broadcom.com>

This patch applies the changes made in the patch
"bnx2x: fix bnx2x_storm_stats_update() on big endian" to net into net-next.

Signed-off-by: Mintz Yuval <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
index abd310d..14c961b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
@@ -1006,14 +1006,14 @@ static int bnx2x_storm_stats_update(struct bnx2x *bp)
 	       estats->rx_stat_ifhcinbadoctets_lo);
 
 	ADD_64(estats->total_bytes_received_hi,
-	       tfunc->rcv_error_bytes.hi,
+	       le32_to_cpu(tfunc->rcv_error_bytes.hi),
 	       estats->total_bytes_received_lo,
-	       tfunc->rcv_error_bytes.lo);
+	       le32_to_cpu(tfunc->rcv_error_bytes.lo));
 
 	ADD_64(estats->error_bytes_received_hi,
-	       tfunc->rcv_error_bytes.hi,
+	       le32_to_cpu(tfunc->rcv_error_bytes.hi),
 	       estats->error_bytes_received_lo,
-	       tfunc->rcv_error_bytes.lo);
+	       le32_to_cpu(tfunc->rcv_error_bytes.lo));
 
 	UPDATE_ESTAT(etherstatsoverrsizepkts, rx_stat_dot3statsframestoolong);
 
-- 
1.7.9.rc2




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

* linux-next: manual merge of the net-next tree with the net tree
@ 2012-02-16  1:38 Stephen Rothwell
  2012-02-16 11:24 ` Yuval Mintz
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2012-02-16  1:38 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Mintz Yuval, Eilon Greenstein, Eric Dumazet

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c between commit
66d885cba670 ("bnx2x: fix bnx2x_storm_stats_update() on big endian") from
the net tree and commit 1355b704b9ba ("bnx2x: consistent statistics after
internal driver reload") from the net-next tree.

I fixed it up (see below) but suspect that there may be more needed.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
index 1adef26,abd310d..0000000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
@@@ -1006,97 -980,43 +980,43 @@@ static int bnx2x_storm_stats_update(str
  				    total_transmitted_dropped_packets_error);
  
  		/* TPA aggregations completed */
- 		UPDATE_EXTEND_USTAT(coalesced_events, total_tpa_aggregations);
+ 		UPDATE_EXTEND_E_USTAT(coalesced_events, total_tpa_aggregations);
  		/* Number of network frames aggregated by TPA */
- 		UPDATE_EXTEND_USTAT(coalesced_pkts,
- 				    total_tpa_aggregated_frames);
+ 		UPDATE_EXTEND_E_USTAT(coalesced_pkts,
+ 				      total_tpa_aggregated_frames);
  		/* Total number of bytes in completed TPA aggregations */
- 		qstats->total_tpa_bytes_lo =
- 			le32_to_cpu(uclient->coalesced_bytes.lo);
- 		qstats->total_tpa_bytes_hi =
- 			le32_to_cpu(uclient->coalesced_bytes.hi);
- 
- 		/* TPA stats per-function */
- 		ADD_64(estats->total_tpa_aggregations_hi,
- 		       qstats->total_tpa_aggregations_hi,
- 		       estats->total_tpa_aggregations_lo,
- 		       qstats->total_tpa_aggregations_lo);
- 		ADD_64(estats->total_tpa_aggregated_frames_hi,
- 		       qstats->total_tpa_aggregated_frames_hi,
- 		       estats->total_tpa_aggregated_frames_lo,
- 		       qstats->total_tpa_aggregated_frames_lo);
- 		ADD_64(estats->total_tpa_bytes_hi,
- 		       qstats->total_tpa_bytes_hi,
- 		       estats->total_tpa_bytes_lo,
- 		       qstats->total_tpa_bytes_lo);
- 
- 		ADD_64(fstats->total_bytes_received_hi,
- 		       qstats->total_bytes_received_hi,
- 		       fstats->total_bytes_received_lo,
- 		       qstats->total_bytes_received_lo);
- 		ADD_64(fstats->total_bytes_transmitted_hi,
- 		       qstats->total_bytes_transmitted_hi,
- 		       fstats->total_bytes_transmitted_lo,
- 		       qstats->total_bytes_transmitted_lo);
- 		ADD_64(fstats->total_unicast_packets_received_hi,
- 		       qstats->total_unicast_packets_received_hi,
- 		       fstats->total_unicast_packets_received_lo,
- 		       qstats->total_unicast_packets_received_lo);
- 		ADD_64(fstats->total_multicast_packets_received_hi,
- 		       qstats->total_multicast_packets_received_hi,
- 		       fstats->total_multicast_packets_received_lo,
- 		       qstats->total_multicast_packets_received_lo);
- 		ADD_64(fstats->total_broadcast_packets_received_hi,
- 		       qstats->total_broadcast_packets_received_hi,
- 		       fstats->total_broadcast_packets_received_lo,
- 		       qstats->total_broadcast_packets_received_lo);
- 		ADD_64(fstats->total_unicast_packets_transmitted_hi,
- 		       qstats->total_unicast_packets_transmitted_hi,
- 		       fstats->total_unicast_packets_transmitted_lo,
- 		       qstats->total_unicast_packets_transmitted_lo);
- 		ADD_64(fstats->total_multicast_packets_transmitted_hi,
- 		       qstats->total_multicast_packets_transmitted_hi,
- 		       fstats->total_multicast_packets_transmitted_lo,
- 		       qstats->total_multicast_packets_transmitted_lo);
- 		ADD_64(fstats->total_broadcast_packets_transmitted_hi,
- 		       qstats->total_broadcast_packets_transmitted_hi,
- 		       fstats->total_broadcast_packets_transmitted_lo,
- 		       qstats->total_broadcast_packets_transmitted_lo);
- 		ADD_64(fstats->valid_bytes_received_hi,
- 		       qstats->valid_bytes_received_hi,
- 		       fstats->valid_bytes_received_lo,
- 		       qstats->valid_bytes_received_lo);
- 
- 		ADD_64(estats->etherstatsoverrsizepkts_hi,
- 		       qstats->etherstatsoverrsizepkts_hi,
- 		       estats->etherstatsoverrsizepkts_lo,
- 		       qstats->etherstatsoverrsizepkts_lo);
- 		ADD_64(estats->no_buff_discard_hi, qstats->no_buff_discard_hi,
- 		       estats->no_buff_discard_lo, qstats->no_buff_discard_lo);
+ 		UPDATE_QSTAT(uclient->coalesced_bytes, total_tpa_bytes);
+ 
+ 		UPDATE_ESTAT_QSTAT_64(total_tpa_bytes);
+ 
+ 		UPDATE_FSTAT_QSTAT(total_bytes_received);
+ 		UPDATE_FSTAT_QSTAT(total_bytes_transmitted);
+ 		UPDATE_FSTAT_QSTAT(total_unicast_packets_received);
+ 		UPDATE_FSTAT_QSTAT(total_multicast_packets_received);
+ 		UPDATE_FSTAT_QSTAT(total_broadcast_packets_received);
+ 		UPDATE_FSTAT_QSTAT(total_unicast_packets_transmitted);
+ 		UPDATE_FSTAT_QSTAT(total_multicast_packets_transmitted);
+ 		UPDATE_FSTAT_QSTAT(total_broadcast_packets_transmitted);
+ 		UPDATE_FSTAT_QSTAT(valid_bytes_received);
  	}
  
- 	ADD_64(fstats->total_bytes_received_hi,
+ 	ADD_64(estats->total_bytes_received_hi,
  	       estats->rx_stat_ifhcinbadoctets_hi,
- 	       fstats->total_bytes_received_lo,
+ 	       estats->total_bytes_received_lo,
  	       estats->rx_stat_ifhcinbadoctets_lo);
  
- 	ADD_64(fstats->total_bytes_received_hi,
+ 	ADD_64(estats->total_bytes_received_hi,
 -	       tfunc->rcv_error_bytes.hi,
 +	       le32_to_cpu(tfunc->rcv_error_bytes.hi),
- 	       fstats->total_bytes_received_lo,
+ 	       estats->total_bytes_received_lo,
 -	       tfunc->rcv_error_bytes.lo);
 +	       le32_to_cpu(tfunc->rcv_error_bytes.lo));
  
- 	memcpy(estats, &(fstats->total_bytes_received_hi),
- 	       sizeof(struct host_func_stats) - 2*sizeof(u32));
- 
  	ADD_64(estats->error_bytes_received_hi,
 -	       tfunc->rcv_error_bytes.hi,
 +	       le32_to_cpu(tfunc->rcv_error_bytes.hi),
  	       estats->error_bytes_received_lo,
 -	       tfunc->rcv_error_bytes.lo);
 +	       le32_to_cpu(tfunc->rcv_error_bytes.lo));
  
- 	ADD_64(estats->etherstatsoverrsizepkts_hi,
- 	       estats->rx_stat_dot3statsframestoolong_hi,
- 	       estats->etherstatsoverrsizepkts_lo,
- 	       estats->rx_stat_dot3statsframestoolong_lo);
+ 	UPDATE_ESTAT(etherstatsoverrsizepkts, rx_stat_dot3statsframestoolong);
+ 
  	ADD_64(estats->error_bytes_received_hi,
  	       estats->rx_stat_ifhcinbadoctets_hi,
  	       estats->error_bytes_received_lo,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2011-12-16  1:07 Stephen Rothwell
@ 2011-12-16  7:34 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2011-12-16  7:34 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Dec 2011 12:07:58 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv6/route.c between commit bb3c36863e80 ("ipv6: Check dest prefix
> length on original route not copied one in rt6_alloc_cow()") from the net
> tree and commit 3830847396fa ("ipv6: Various cleanups in route.c") from
> the net-next tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Yep, thanks, I just resolved this by merging net into net-next.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2011-12-16  1:07 Stephen Rothwell
  2011-12-16  7:34 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2011-12-16  1:07 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/route.c between commit bb3c36863e80 ("ipv6: Check dest prefix
length on original route not copied one in rt6_alloc_cow()") from the net
tree and commit 3830847396fa ("ipv6: Various cleanups in route.c") from
the net-next tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/ipv6/route.c
index b582a0a,4bf362b..0000000
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@@ -727,11 -727,11 +727,11 @@@ static struct rt6_info *rt6_alloc_cow(c
  		struct neighbour *neigh;
  		int attempts = !in_softirq();
  
- 		if (!(rt->rt6i_flags&RTF_GATEWAY)) {
+ 		if (!(rt->rt6i_flags & RTF_GATEWAY)) {
 -			if (rt->rt6i_dst.plen != 128 &&
 +			if (ort->rt6i_dst.plen != 128 &&
  			    ipv6_addr_equal(&ort->rt6i_dst.addr, daddr))
  				rt->rt6i_flags |= RTF_ANYCAST;
- 			ipv6_addr_copy(&rt->rt6i_gateway, daddr);
+ 			rt->rt6i_gateway = *daddr;
  		}
  
  		rt->rt6i_flags |= RTF_CACHE;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2011-12-14  2:25 Stephen Rothwell
@ 2011-12-14 18:36 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2011-12-14 18:36 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, ordex

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Dec 2011 13:25:58 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in
> net/batman-adv/translation-table.c between commits 03fc3070457d
> ("batman-adv: in case of roaming mark the client with TT_CLIENT_ROAM")
> and 797399b415b7 ("batman-adv: delete global entry in case of roaming")
> from the net tree and commit 48100bac89a6 ("batman-adv: create a common
> substructure for tt_global/local_entry") from the net-next tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

Thanks, we expected this, I'll take care of it next time I merge
over the net tree.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2011-12-14  2:25 Stephen Rothwell
  2011-12-14 18:36 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2011-12-14  2:25 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Antonio Quartulli

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

Hi all,

Today's linux-next merge of the net-next tree got conflicts in
net/batman-adv/translation-table.c between commits 03fc3070457d
("batman-adv: in case of roaming mark the client with TT_CLIENT_ROAM")
and 797399b415b7 ("batman-adv: delete global entry in case of roaming")
from the net tree and commit 48100bac89a6 ("batman-adv: create a common
substructure for tt_global/local_entry") from the net-next tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/batman-adv/translation-table.c
index 5f09a57,cc87acf..0000000
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@@ -245,12 -242,10 +242,12 @@@ void tt_local_add(struct net_device *so
  	if (tt_global_entry) {
  		/* This node is probably going to update its tt table */
  		tt_global_entry->orig_node->tt_poss_change = true;
 -		/* The global entry has to be marked as PENDING and has to be
 +		/* The global entry has to be marked as ROAMING and has to be
  		 * kept for consistency purpose */
- 		tt_global_entry->flags |= TT_CLIENT_ROAM;
 -		tt_global_entry->common.flags |= TT_CLIENT_PENDING;
++		tt_global_entry->common.flags |= TT_CLIENT_ROAM;
 +		tt_global_entry->roam_at = jiffies;
 +
- 		send_roam_adv(bat_priv, tt_global_entry->addr,
+ 		send_roam_adv(bat_priv, tt_global_entry->common.addr,
  			      tt_global_entry->orig_node);
  	}
  out:
@@@ -704,21 -668,9 +671,21 @@@ void tt_global_del(struct bat_priv *bat
  
  	if (tt_global_entry->orig_node == orig_node) {
  		if (roaming) {
 -			tt_global_entry->common.flags |= TT_CLIENT_ROAM;
 -			tt_global_entry->roam_at = jiffies;
 -			goto out;
 +			/* if we are deleting a global entry due to a roam
 +			 * event, there are two possibilities:
 +			 * 1) the client roamed from node A to node B => we mark
 +			 *    it with TT_CLIENT_ROAM, we start a timer and we
 +			 *    wait for node B to claim it. In case of timeout
 +			 *    the entry is purged.
 +			 * 2) the client roamed to us => we can directly delete
 +			 *    the global entry, since it is useless now. */
 +			tt_local_entry = tt_local_hash_find(bat_priv,
 -							tt_global_entry->addr);
++							tt_global_entry->common.addr);
 +			if (!tt_local_entry) {
- 				tt_global_entry->flags |= TT_CLIENT_ROAM;
++				tt_global_entry->common.flags |= TT_CLIENT_ROAM;
 +				tt_global_entry->roam_at = jiffies;
 +				goto out;
 +			}
  		}
  		_tt_global_del(bat_priv, tt_global_entry, message);
  	}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 325+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the net tree
  2011-11-23  0:17 Stephen Rothwell
@ 2011-11-23  0:23 ` David Miller
  0 siblings, 0 replies; 325+ messages in thread
From: David Miller @ 2011-11-23  0:23 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, maze, adobriyan

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 23 Nov 2011 11:17:51 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv4/inet_diag.c between commit 717b6d836646 ("net-netlink: fix diag
> to export IPv4 tos for dual-stack IPv6 sockets") from the net tree and
> commit 4e3fd7a06dc2 ("net: remove ipv6_addr_copy()") from the net-next
> tree.
> 
> Just context changes.  I fixed it up (see below) can can carry the fix as
> necessary,

Yep, I anticipated this one too, thanks Stephen.

^ permalink raw reply	[flat|nested] 325+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2011-11-23  0:17 Stephen Rothwell
  2011-11-23  0:23 ` David Miller
  0 siblings, 1 reply; 325+ messages in thread
From: Stephen Rothwell @ 2011-11-23  0:17 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Maciej Żenczykowski, Alexey Dobriyan

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv4/inet_diag.c between commit 717b6d836646 ("net-netlink: fix diag
to export IPv4 tos for dual-stack IPv6 sockets") from the net tree and
commit 4e3fd7a06dc2 ("net: remove ipv6_addr_copy()") from the net-next
tree.

Just context changes.  I fixed it up (see below) can can carry the fix as
necessary,
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/ipv4/inet_diag.c
index ccee270,bbebdec..0000000
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@@ -132,13 -129,10 +132,11 @@@ static int inet_csk_diag_fill(struct so
  	if (r->idiag_family == AF_INET6) {
  		const struct ipv6_pinfo *np = inet6_sk(sk);
  
 -		*(struct in6_addr *)r->id.idiag_src = np->rcv_saddr;
 -		*(struct in6_addr *)r->id.idiag_dst = np->daddr;
  		if (ext & (1 << (INET_DIAG_TCLASS - 1)))
  			RTA_PUT_U8(skb, INET_DIAG_TCLASS, np->tclass);
 +
- 		ipv6_addr_copy((struct in6_addr *)r->id.idiag_src,
- 			       &np->rcv_saddr);
- 		ipv6_addr_copy((struct in6_addr *)r->id.idiag_dst,
- 			       &np->daddr);
++		*(struct in6_addr *)r->id.idiag_src = np->rcv_saddr;
++		*(struct in6_addr *)r->id.idiag_dst = np->daddr;
  	}
  #endif
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 325+ messages in thread

end of thread, back to index

Thread overview: 325+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-07  1:39 linux-next: manual merge of the net-next tree with the net tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2018-12-10  1:36 Stephen Rothwell
2018-12-10 11:38 ` Or Gerlitz
2018-12-10 18:38 ` Nambiar, Amritha
2018-12-10  1:31 Stephen Rothwell
2018-12-05  0:33 Stephen Rothwell
2018-12-03  1:50 Stephen Rothwell
2018-10-18 23:56 Stephen Rothwell
2018-10-16 23:46 Stephen Rothwell
2018-10-11 23:53 Stephen Rothwell
2018-10-12  0:10 ` Stephen Rothwell
2018-10-11 23:45 Stephen Rothwell
2018-10-14  7:58 ` Kiyanovski, Arthur
2018-10-09  1:21 Stephen Rothwell
2018-10-09 10:02 ` Jamal Hadi Salim
2018-10-09 20:58   ` Stephen Rothwell
2018-10-03  2:18 Stephen Rothwell
2018-09-21  0:24 Stephen Rothwell
2018-09-18  0:11 Stephen Rothwell
2018-09-18  8:44 ` Daniel Borkmann
2018-09-18  9:10   ` Vakul Garg
2018-09-18  9:26     ` Daniel Borkmann
2018-09-18  9:32       ` Vakul Garg
2018-09-18  9:53         ` Daniel Borkmann
2018-09-18 10:15           ` Daniel Borkmann
2018-09-18 10:17             ` Vakul Garg
2018-09-18 11:48               ` Stephen Rothwell
2018-09-18 12:08                 ` Daniel Borkmann
2018-09-18 16:32           ` David Miller
2018-07-19  1:25 Stephen Rothwell
2018-07-17