Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the net-next tree with the net tree
@ 2019-10-27 23:59 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-10-27 23:59 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jiri Pirko,
	Taehee Yoo

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

Hi all,

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

  include/linux/netdevice.h

between commit:

  ab92d68fc22f ("net: core: add generic lockdep keys")

from the net tree and commits:

  ff92741270bf ("net: introduce name_node struct to be used in hashlist")
  36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames")

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/netdevice.h
index c20f190b4c18,3207e0b9ec4e..000000000000
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@@ -925,7 -925,16 +925,17 @@@ struct dev_ifalias 
  struct devlink;
  struct tlsdev_ops;
  
+ struct netdev_name_node {
+ 	struct hlist_node hlist;
+ 	struct list_head list;
+ 	struct net_device *dev;
+ 	const char *name;
+ };
+ 
+ int netdev_name_node_alt_create(struct net_device *dev, const char *name);
+ int netdev_name_node_alt_destroy(struct net_device *dev, const char *name);
+ 
 +
  /*
   * This structure defines the management hooks for network devices.
   * The following hooks can be defined; unless noted otherwise, they are

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-11-21  0:48 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-11-21  0:48 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Julian Wiedmann

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

Hi all,

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

  drivers/s390/net/qeth_l2_main.c

between commit:

  c8183f548902 ("s390/qeth: fix potential deadlock on workqueue flush")

from the net tree and commit:

  9897d583b015 ("s390/qeth: consolidate some duplicated HW cmd 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 drivers/s390/net/qeth_l2_main.c
index 4bccdce19b5a,ae69c981650d..000000000000
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@@ -802,14 -779,6 +784,7 @@@ static int qeth_l2_set_online(struct cc
  		goto out_remove;
  	}
  
- 	if (qeth_is_diagass_supported(card, QETH_DIAGS_CMD_TRAP)) {
- 		if (card->info.hwtrap &&
- 		    qeth_hw_trap(card, QETH_DIAGS_TRAP_ARM))
- 			card->info.hwtrap = 0;
- 	} else
- 		card->info.hwtrap = 0;
- 
 +	mutex_lock(&card->sbp_lock);
  	qeth_bridgeport_query_support(card);
  	if (card->options.sbp.supported_funcs)
  		dev_info(&card->gdev->dev,

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-11-12 23:55 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-11-12 23:55 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Aya Levin,
	Jiri Pirko

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

Hi all,

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

  include/uapi/linux/devlink.h

between commit:

  d279505b723c ("devlink: Add method for time-stamp on reporter's dump")

from the net tree and commit:

  070c63f20f6c ("net: devlink: allow to change namespaces during reload")

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/uapi/linux/devlink.h
index a8a2174db030,b558ea88b766..000000000000
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@@ -421,7 -421,10 +421,12 @@@ enum devlink_attr 
  
  	DEVLINK_ATTR_RELOAD_FAILED,			/* u8 0 or 1 */
  
 +	DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS_NS,	/* u64 */
++
+ 	DEVLINK_ATTR_NETNS_FD,			/* u32 */
+ 	DEVLINK_ATTR_NETNS_PID,			/* u32 */
+ 	DEVLINK_ATTR_NETNS_ID,			/* u32 */
+ 
  	/* add new attributes above here, update the policy in devlink.c */
  
  	__DEVLINK_ATTR_MAX,

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-10-13 23:02 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-10-13 23:02 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, YueHaibing,
	Jiri Pirko

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

Hi all,

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

  drivers/net/netdevsim/fib.c

between commit:

  33902b4a4227 ("netdevsim: Fix error handling in nsim_fib_init and nsim_fib_exit")

from the net tree and commit:

  a5facc4cac4d ("netdevsim: change fib accounting and limitations to be per-device")

from the net-next tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-09-12 16:25 Stephen Rothwell
@ 2019-09-12 16:29 ` Jeff Kirsher
  0 siblings, 0 replies; 375+ messages in thread
From: Jeff Kirsher @ 2019-09-12 16:29 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ilya Maximets

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

On Fri, 2019-09-13 at 02:25 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> 
> between commit:
> 
>   5c129241e2de ("ixgbe: add support for AF_XDP need_wakeup feature")
> 
> from the net tree and commit:
> 
>   bf280c0387eb ("ixgbe: fix double clean of Tx descriptors with xdp")
> 
> 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.
> 

Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

On how you fixed up the conflict.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-09-12 16:25 Stephen Rothwell
  2019-09-12 16:29 ` Jeff Kirsher
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-09-12 16:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Ilya Maximets, Jeff Kirsher

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

Hi all,

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

  drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c

between commit:

  5c129241e2de ("ixgbe: add support for AF_XDP need_wakeup feature")

from the net tree and commit:

  bf280c0387eb ("ixgbe: fix double clean of Tx descriptors with xdp")

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/ixgbe/ixgbe_xsk.c
index a3b6d8c89127,ad802a8909e0..000000000000
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@@ -682,10 -697,19 +691,17 @@@ bool ixgbe_clean_xdp_tx_irq(struct ixgb
  	if (xsk_frames)
  		xsk_umem_complete_tx(umem, xsk_frames);
  
+ 	if (xsk_umem_uses_need_wakeup(tx_ring->xsk_umem)) {
+ 		if (tx_ring->next_to_clean == tx_ring->next_to_use)
+ 			xsk_set_tx_need_wakeup(tx_ring->xsk_umem);
+ 		else
+ 			xsk_clear_tx_need_wakeup(tx_ring->xsk_umem);
+ 	}
+ 
 -	xmit_done = ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
 -
 -	return budget > 0 && xmit_done;
 +	return ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
  }
  
- int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
+ int ixgbe_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags)
  {
  	struct ixgbe_adapter *adapter = netdev_priv(dev);
  	struct ixgbe_ring *ring;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-09-12 16:19 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-09-12 16:19 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Mario Limonciello, Marcel Holtmann, Alex Lu

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

Hi all,

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

  drivers/bluetooth/btusb.c

between commit:

  1ffdb51f28e8 ("Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"")

from the net tree and commit:

  9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices")

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/bluetooth/btusb.c
index ba4149054304,ed455de598ea..000000000000
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@@ -1173,7 -1201,18 +1204,14 @@@ static int btusb_open(struct hci_dev *h
  	}
  
  	data->intf->needs_remote_wakeup = 1;
 -	/* device specific wakeup source enabled and required for USB
 -	 * remote wakeup while host is suspended
 -	 */
 -	device_wakeup_enable(&data->udev->dev);
  
+ 	/* Disable device remote wakeup when host is suspended
+ 	 * For Realtek chips, global suspend without
+ 	 * SET_FEATURE (DEVICE_REMOTE_WAKEUP) can save more power in device.
+ 	 */
+ 	if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+ 		device_wakeup_disable(&data->udev->dev);
+ 
  	if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
  		goto done;
  
@@@ -1237,6 -1276,12 +1275,11 @@@ static int btusb_close(struct hci_dev *
  		goto failed;
  
  	data->intf->needs_remote_wakeup = 0;
+ 
+ 	/* Enable remote wake up for auto-suspend */
+ 	if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+ 		data->intf->needs_remote_wakeup = 1;
+ 
 -	device_wakeup_disable(&data->udev->dev);
  	usb_autopm_put_interface(data->intf);
  
  failed:

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-08-30  4:19 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-08-30  4:19 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Hayes Wang

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

Hi all,

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

  drivers/net/usb/r8152.c

between commits:

  49d4b14113ca ("Revert "r8152: napi hangup fix after disconnect"")
  973dc6cfc0e2 ("r8152: remove calling netif_napi_del")

from the net tree and commit:

  d2187f8e4454 ("r8152: divide the tx and rx bottom 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/usb/r8152.c
index 04137ac373b0,c6fa0c17c13d..000000000000
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -4021,7 -4214,9 +4214,8 @@@ static int rtl8152_close(struct net_dev
  #ifdef CONFIG_PM_SLEEP
  	unregister_pm_notifier(&tp->pm_notifier);
  #endif
+ 	tasklet_disable(&tp->tx_tl);
 -	if (!test_bit(RTL8152_UNPLUG, &tp->flags))
 -		napi_disable(&tp->napi);
 +	napi_disable(&tp->napi);
  	clear_bit(WORK_ENABLE, &tp->flags);
  	usb_kill_urb(tp->intr_urb);
  	cancel_delayed_work_sync(&tp->schedule);
@@@ -5352,6 -5604,8 +5603,7 @@@ static int rtl8152_probe(struct usb_int
  	return 0;
  
  out1:
 -	netif_napi_del(&tp->napi);
+ 	tasklet_kill(&tp->tx_tl);
  	usb_set_intfdata(intf, NULL);
  out:
  	free_netdev(netdev);
@@@ -5366,7 -5620,9 +5618,8 @@@ static void rtl8152_disconnect(struct u
  	if (tp) {
  		rtl_set_unplug(tp);
  
 -		netif_napi_del(&tp->napi);
  		unregister_netdev(tp->netdev);
+ 		tasklet_kill(&tp->tx_tl);
  		cancel_delayed_work_sync(&tp->hw_phy_work);
  		tp->rtl_ops.unload(tp);
  		free_netdev(tp->netdev);

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-08-26  2:27 Stephen Rothwell
@ 2019-08-26  5:27 ` Heiner Kallweit
  0 siblings, 0 replies; 375+ messages in thread
From: Heiner Kallweit @ 2019-08-26  5:27 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

On 26.08.2019 04:27, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/realtek/r8169_main.c
> 
> between commit:
> 
>   345b93265b3a ("Revert "r8169: remove not needed call to dma_sync_single_for_device"")
> 
> from the net tree and commit:
> 
>   fcd4e60885af ("r8169: improve rtl_rx")
>   d4ed7463d02a ("r8169: fix DMA issue on MIPS platform")
> 
> from the net-next tree.
> 
> I fixed it up (the latter seems to do the same as the net tree 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.
> 
Due to other changes there have been two versions of the fix, one for net
and one for net-next. Therefore ignoring the one from net when merging into
net-next was correct. Thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-08-26  2:27 Stephen Rothwell
  2019-08-26  5:27 ` Heiner Kallweit
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-08-26  2:27 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Heiner Kallweit

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

Hi all,

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

  drivers/net/ethernet/realtek/r8169_main.c

between commit:

  345b93265b3a ("Revert "r8169: remove not needed call to dma_sync_single_for_device"")

from the net tree and commit:

  fcd4e60885af ("r8169: improve rtl_rx")
  d4ed7463d02a ("r8169: fix DMA issue on MIPS platform")

from the net-next tree.

I fixed it up (the latter seems to do the same as the net tree 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.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-08-12  2:21 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-08-12  2:21 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Huy Nguyen,
	Vlad Buslov, Saeed Mahameed

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

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:

  93b3586e070b ("net/mlx5: Support inner header match criteria for non decap flow action")

from the net tree and commit:

  226f2ca3075a ("net/mlx5e: Change flow flags type to unsigned long")

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 deeb65da99f3,5be3da621499..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1839,18 -2057,15 +2061,20 @@@ static int parse_cls_flower(struct mlx5
  	struct mlx5_core_dev *dev = priv->mdev;
  	struct mlx5_eswitch *esw = dev->priv.eswitch;
  	struct mlx5e_rep_priv *rpriv = priv->ppriv;
 -	u8 match_level, tunnel_match_level = MLX5_MATCH_NONE;
  	struct mlx5_eswitch_rep *rep;
+ 	bool is_eswitch_flow;
  	int err;
  
 -	err = __parse_cls_flower(priv, spec, f, filter_dev, &match_level, &tunnel_match_level);
 +	inner_match_level = MLX5_MATCH_NONE;
 +	outer_match_level = MLX5_MATCH_NONE;
 +
 +	err = __parse_cls_flower(priv, spec, f, filter_dev, &inner_match_level,
 +				 &outer_match_level);
 +	non_tunnel_match_level = (inner_match_level == MLX5_MATCH_NONE) ?
 +				 outer_match_level : inner_match_level;
  
- 	if (!err && (flow->flags & MLX5E_TC_FLOW_ESWITCH)) {
+ 	is_eswitch_flow = mlx5e_is_eswitch_flow(flow);
+ 	if (!err && is_eswitch_flow) {
  		rep = rpriv->rep;
  		if (rep->vport != MLX5_VPORT_UPLINK &&
  		    (esw->offloads.inline_mode != MLX5_INLINE_MODE_NONE &&
@@@ -1864,11 -2079,11 +2088,11 @@@
  		}
  	}
  
- 	if (flow->flags & MLX5E_TC_FLOW_ESWITCH) {
+ 	if (is_eswitch_flow) {
 -		flow->esw_attr->match_level = match_level;
 -		flow->esw_attr->tunnel_match_level = tunnel_match_level;
 +		flow->esw_attr->inner_match_level = inner_match_level;
 +		flow->esw_attr->outer_match_level = outer_match_level;
  	} else {
 -		flow->nic_attr->match_level = match_level;
 +		flow->nic_attr->match_level = non_tunnel_match_level;
  	}
  
  	return err;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-07-25  0:58 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-07-25  0:58 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Wen Yang,
	Sean Nyekjaer

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

Hi all,

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

  drivers/net/can/flexcan.c

between commit:

  e9f2a856e102 ("can: flexcan: fix an use-after-free in flexcan_setup_stop_mode()")

from the net tree and commit:

  915f9666421c ("can: flexcan: add support for DT property 'wakeup-source'")

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/can/flexcan.c
index fcec8bcb53d6,09d8e623dcf6..000000000000
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -1473,9 -1473,10 +1491,12 @@@ static int flexcan_setup_stop_mode(stru
  
  	device_set_wakeup_capable(&pdev->dev, true);
  
+ 	if (of_property_read_bool(np, "wakeup-source"))
+ 		device_set_wakeup_enable(&pdev->dev, true);
+ 
 -	return 0;
 +out_put_node:
 +	of_node_put(gpr_np);
 +	return ret;
  }
  
  static const struct of_device_id flexcan_of_match[] = {

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-07-09  0:27 ` Stephen Rothwell
@ 2019-07-09  2:57   ` David Miller
  0 siblings, 0 replies; 375+ messages in thread
From: David Miller @ 2019-07-09  2:57 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, mcroce, fw

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jul 2019 10:27:28 +1000

> I am still getting this conflict (the commit ids may have changed).
> Just a reminder in case you think Linus may need to know.

I'm resolving this right now, thanks Stephen.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-07-02  2:13 Stephen Rothwell
@ 2019-07-09  0:27 ` Stephen Rothwell
  2019-07-09  2:57   ` David Miller
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-07-09  0:27 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Matteo Croce,
	Florian Westphal

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

Hi all,

On Tue, 2 Jul 2019 12:13:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv4/devinet.c
> 
> between commit:
> 
>   2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")
> 
> from the net tree and commit:
> 
>   2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
> 
> 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/devinet.c
> index c5ebfa199794,137d1892395d..000000000000
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
>   	ifa->ifa_flags &= ~IFA_F_SECONDARY;
>   	last_primary = &in_dev->ifa_list;
>   
>  +	/* Don't set IPv6 only flags to IPv4 addresses */
>  +	ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
>  +
> - 	for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
> - 	     ifap = &ifa1->ifa_next) {
> + 	ifap = &in_dev->ifa_list;
> + 	ifa1 = rtnl_dereference(*ifap);
> + 
> + 	while (ifa1) {
>   		if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>   		    ifa->ifa_scope <= ifa1->ifa_scope)
>   			last_primary = &ifa1->ifa_next;


I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-07-04  2:07 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-07-04  2:07 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Po-Hsu Lin,
	Willem de Bruijn, Mahesh Bandewar

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

Hi all,

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

  tools/testing/selftests/net/config

between commit:

  ff95bf28c234 ("selftests/net: skip psock_tpacket test if KALLSYMS was not enabled")

from the net tree and commit:

  af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
  509e56b37cc3 ("blackhole_dev: add a selftest")

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/config
index 3dea2cba2325,e4b878d95ba0..000000000000
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@@ -25,4 -25,6 +25,7 @@@ CONFIG_NF_TABLES_IPV6=
  CONFIG_NF_TABLES_IPV4=y
  CONFIG_NFT_CHAIN_NAT_IPV6=m
  CONFIG_NFT_CHAIN_NAT_IPV4=m
 +CONFIG_KALLSYMS=y
+ CONFIG_NET_SCH_FQ=m
+ CONFIG_NET_SCH_ETF=m
+ CONFIG_TEST_BLACKHOLE_DEV=m

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-07-02  2:13 Stephen Rothwell
  2019-07-09  0:27 ` Stephen Rothwell
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-07-02  2:13 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Matteo Croce,
	Florian Westphal

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

Hi all,

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

  net/ipv4/devinet.c

between commit:

  2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")

from the net tree and commit:

  2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")

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/devinet.c
index c5ebfa199794,137d1892395d..000000000000
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
  	ifa->ifa_flags &= ~IFA_F_SECONDARY;
  	last_primary = &in_dev->ifa_list;
  
 +	/* Don't set IPv6 only flags to IPv4 addresses */
 +	ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
 +
- 	for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
- 	     ifap = &ifa1->ifa_next) {
+ 	ifap = &in_dev->ifa_list;
+ 	ifa1 = rtnl_dereference(*ifap);
+ 
+ 	while (ifa1) {
  		if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
  		    ifa->ifa_scope <= ifa1->ifa_scope)
  			last_primary = &ifa1->ifa_next;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-28  1:45 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-28  1:45 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Dmitry Bogdanov, Igor Russkikh

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

Hi all,

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

  drivers/net/ethernet/aquantia/atlantic/aq_nic.c
  drivers/net/ethernet/aquantia/atlantic/aq_nic.h

between commit:

  48dd73d08d4d ("net: aquantia: fix vlans not working over bridged network")

from the net tree and commit:

  d3ed7c5cf79b ("net: aquantia: adding fields and device features for vlan 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/aquantia/atlantic/aq_nic.c
index 41172fbebddd,746f85e6de13..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@@ -126,7 -126,8 +126,9 @@@ void aq_nic_cfg_start(struct aq_nic_s *
  
  	cfg->link_speed_msk &= cfg->aq_hw_caps->link_speed_msk;
  	cfg->features = cfg->aq_hw_caps->hw_features;
 +	cfg->is_vlan_force_promisc = true;
+ 	cfg->is_vlan_rx_strip = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_RX);
+ 	cfg->is_vlan_tx_insert = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_TX);
  }
  
  static int aq_nic_update_link_status(struct aq_nic_s *self)
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_nic.h
index 0f22f5d5691b,26c72f298684..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
@@@ -35,7 -35,8 +35,9 @@@ struct aq_nic_cfg_s 
  	u32 flow_control;
  	u32 link_speed_msk;
  	u32 wol;
 +	bool is_vlan_force_promisc;
+ 	u8 is_vlan_rx_strip;
+ 	u8 is_vlan_tx_insert;
  	u16 is_mc_list_enabled;
  	u16 mc_list_count;
  	bool is_autoneg;

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-27  3:26 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-27  3:26 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Stephen Suryaputra, Lawrence Brakmo, Alexei Starovoitov

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

Hi all,

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

  net/ipv4/ip_output.c

between commit:

  5b18f1289808 ("ipv4: reset rt_iif for recirculated mcast/bcast out pkts")

from the net tree and commit:

  956fe2190820 ("bpf: Update BPF_CGROUP_RUN_PROG_INET_EGRESS calls")

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/ip_output.c
index 8c2ec35b6512,cdd6c3418b9e..000000000000
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -322,7 -330,12 +331,26 @@@ static int ip_mc_finish_output(struct n
  	int ret;
  
  	ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
- 	if (ret) {
+ 	switch (ret) {
++	case NET_XMIT_SUCCESS:
++	case NET_XMIT_CN:
++		/* Reset rt_iif so that inet_iif() will return skb->skb_iif.
++		 * Setting this to non-zero causes ipi_ifindex in in_pktinfo
++		 * to be overwritten, see ipv4_pktinfo_prepare().
++		 */
++		new_rt = rt_dst_clone(net->loopback_dev, skb_rtable(skb));
++		if (new_rt) {
++			new_rt->rt_iif = 0;
++			skb_dst_drop(skb);
++			skb_dst_set(skb, &new_rt->dst);
++		}
++	}
++	switch (ret) {
+ 	case NET_XMIT_SUCCESS:
+ 		return dev_loopback_xmit(net, sk, skb);
+ 	case NET_XMIT_CN:
+ 		return dev_loopback_xmit(net, sk, skb) ? : ret;
+ 	default:
  		kfree_skb(skb);
  		return ret;
  	}

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-17  1:55 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-17  1:55 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Johannes Berg

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

Hi all,

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

  net/wireless/nl80211.c

between commit:

  180aa422ef27 ("nl80211: fill all policy .type entries")

from the net tree and commit:

  1a28ed213696 ("nl80211: fill all policy .type entries")

from the net-next tree.

I fixed it up (they were just formatted differently, so I used 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

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-17  1:50 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-17  1:50 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dexuan Cui,
	Sunil Muthuswamy

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

Hi all,

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

  net/vmw_vsock/hyperv_transport.c

between commit:

  d424a2afd7da ("hv_sock: Suppress bogus "may be used uninitialized" warnings")

from the net tree and commit:

  ac383f58f3c9 ("hv_sock: perf: Allow the socket buffer size options to influence the actual socket buffers")

from the net-next tree.

I fixed it up (the latter include the former fix) 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] 375+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-11  1:37 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-11  1:37 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, Alexei Starovoitov, Lawrence Brakmo

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

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  983695fa6765 ("bpf: fix unconnected udp hooks")

from the net tree and commit:

  5cf1e9145630 ("bpf: cgroup inet skb programs can return 0 to 3")

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 a5c369e60343,5c2cb5bd84ce..000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -5353,12 -5513,13 +5505,16 @@@ static int check_return_code(struct bpf
  	struct tnum range = tnum_range(0, 1);
  
  	switch (env->prog->type) {
 +	case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
 +		if (env->prog->expected_attach_type == BPF_CGROUP_UDP4_RECVMSG ||
 +		    env->prog->expected_attach_type == BPF_CGROUP_UDP6_RECVMSG)
 +			range = tnum_range(1, 1);
  	case BPF_PROG_TYPE_CGROUP_SKB:
+ 		if (env->prog->expected_attach_type == BPF_CGROUP_INET_EGRESS) {
+ 			range = tnum_range(0, 3);
+ 			enforce_attach_type_range = tnum_range(2, 3);
+ 		}
  	case BPF_PROG_TYPE_CGROUP_SOCK:
 -	case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
  	case BPF_PROG_TYPE_SOCK_OPS:
  	case BPF_PROG_TYPE_CGROUP_DEVICE:
  	case BPF_PROG_TYPE_CGROUP_SYSCTL:
@@@ -5385,9 -5546,13 +5541,13 @@@
  			verbose(env, "has unknown scalar value");
  		}
  		tnum_strn(tn_buf, sizeof(tn_buf), range);
 -		verbose(env, " should have been %s\n", tn_buf);
 +		verbose(env, " should have been in %s\n", tn_buf);
  		return -EINVAL;
  	}
+ 
+ 	if (!tnum_is_unknown(enforce_attach_type_range) &&
+ 	    tnum_in(enforce_attach_type_range, reg->var_off))
+ 		env->prog->enforce_expected_attach_type = 1;
  	return 0;
  }
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-06-11  1:28 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-06-11  1:28 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Edward Srouji, Saeed Mahameed, Vu Pham

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

Hi all,

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

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

between commit:

  6a6fabbfa3e8 ("net/mlx5: Update pci error handler entries and command translation")

from the net tree and commit:

  cd56f929e6a5 ("net/mlx5: E-Switch, Replace host_params event with functions_changed event")

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/cmd.c
index e94686c42000,30f7dffb5b1b..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@@ -632,11 -628,7 +632,11 @@@ const char *mlx5_command_str(int comman
  	MLX5_COMMAND_STR_CASE(QUERY_MODIFY_HEADER_CONTEXT);
  	MLX5_COMMAND_STR_CASE(ALLOC_MEMIC);
  	MLX5_COMMAND_STR_CASE(DEALLOC_MEMIC);
- 	MLX5_COMMAND_STR_CASE(QUERY_HOST_PARAMS);
+ 	MLX5_COMMAND_STR_CASE(QUERY_ESW_FUNCTIONS);
 +	MLX5_COMMAND_STR_CASE(CREATE_UCTX);
 +	MLX5_COMMAND_STR_CASE(DESTROY_UCTX);
 +	MLX5_COMMAND_STR_CASE(CREATE_UMEM);
 +	MLX5_COMMAND_STR_CASE(DESTROY_UMEM);
  	default: return "unknown command opcode";
  	}
  }

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-05-31  0:25 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-05-31  0:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Russell King,
	Ioana Ciornei

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

Hi all,

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

  drivers/net/phy/phylink.c

between commit:

  c678726305b9 ("net: phylink: ensure consistent phy interface mode")

from the net tree and commit:

  27755ff88c0e ("net: phylink: Add phylink_mac_link_{up, down} wrapper 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/phylink.c
index 9044b95d2afe,68d0a89c52be..000000000000
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@@ -399,6 -414,36 +418,36 @@@ static const char *phylink_pause_to_str
  	}
  }
  
+ static void phylink_mac_link_up(struct phylink *pl,
+ 				struct phylink_link_state link_state)
+ {
+ 	struct net_device *ndev = pl->netdev;
+ 
++	pl->cur_interface = link_state.interface;
+ 	pl->ops->mac_link_up(pl->config, pl->link_an_mode,
 -			     pl->phy_state.interface,
 -			     pl->phydev);
++			     pl->cur_interface, pl->phydev);
+ 
+ 	if (ndev)
+ 		netif_carrier_on(ndev);
+ 
+ 	phylink_info(pl,
+ 		     "Link is Up - %s/%s - flow control %s\n",
+ 		     phy_speed_to_str(link_state.speed),
+ 		     phy_duplex_to_str(link_state.duplex),
+ 		     phylink_pause_to_str(link_state.pause));
+ }
+ 
+ static void phylink_mac_link_down(struct phylink *pl)
+ {
+ 	struct net_device *ndev = pl->netdev;
+ 
+ 	if (ndev)
+ 		netif_carrier_off(ndev);
+ 	pl->ops->mac_link_down(pl->config, pl->link_an_mode,
 -			       pl->phy_state.interface);
++			       pl->cur_interface);
+ 	phylink_info(pl, "Link is Down\n");
+ }
+ 
  static void phylink_resolve(struct work_struct *w)
  {
  	struct phylink *pl = container_of(w, struct phylink, resolve);

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-05-29 23:56 Stephen Rothwell
@ 2019-05-30  6:51 ` Maxim Uvarov
  0 siblings, 0 replies; 375+ messages in thread
From: Maxim Uvarov @ 2019-05-30  6:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Trent Piepho, Vivien Didelot

Merge fix looks like correct. Might be my fault I sent dp83867 patches
against linux.git, not linux-next.git. If you want I can resend
updated version for linux-next.

Max.

чт, 30 мая 2019 г. в 02:56, 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/dp83867.c
>
> between commits:
>
>   2b892649254f ("net: phy: dp83867: Set up RGMII TX delay")
>   333061b92453 ("net: phy: dp83867: fix speed 10 in sgmii mode")
>
> from the net tree and commits:
>
>   c11669a2757e ("net: phy: dp83867: Rework delay rgmii delay handling")
>   27708eb5481b ("net: phy: dp83867: IO impedance is not dependent on RGMII delay")
>
> from the net-next tree.
>
> I fixed it up (I took a guess - 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/dp83867.c
> index c71c7d0f53f0,3bdf94043693..000000000000
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@@ -26,18 -26,11 +26,19 @@@
>
>   /* Extended Registers */
>   #define DP83867_CFG4            0x0031
>  +#define DP83867_CFG4_SGMII_ANEG_MASK (BIT(5) | BIT(6))
>  +#define DP83867_CFG4_SGMII_ANEG_TIMER_11MS   (3 << 5)
>  +#define DP83867_CFG4_SGMII_ANEG_TIMER_800US  (2 << 5)
>  +#define DP83867_CFG4_SGMII_ANEG_TIMER_2US    (1 << 5)
>  +#define DP83867_CFG4_SGMII_ANEG_TIMER_16MS   (0 << 5)
>  +
>   #define DP83867_RGMIICTL      0x0032
>   #define DP83867_STRAP_STS1    0x006E
> + #define DP83867_STRAP_STS2    0x006f
>   #define DP83867_RGMIIDCTL     0x0086
>   #define DP83867_IO_MUX_CFG    0x0170
>  +#define DP83867_10M_SGMII_CFG   0x016F
>  +#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
>
>   #define DP83867_SW_RESET      BIT(15)
>   #define DP83867_SW_RESTART    BIT(14)
> @@@ -255,10 -321,18 +329,17 @@@ static int dp83867_config_init(struct p
>                 ret = phy_write(phydev, MII_DP83867_PHYCTRL, val);
>                 if (ret)
>                         return ret;
>  -      }
>
>  -      /* If rgmii mode with no internal delay is selected, we do NOT use
>  -       * aligned mode as one might expect.  Instead we use the PHY's default
>  -       * based on pin strapping.  And the "mode 0" default is to *use*
>  -       * internal delay with a value of 7 (2.00 ns).
>  -       */
>  -      if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
>  -          (phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
>  +              /* Set up RGMII delays */
> ++              /* If rgmii mode with no internal delay is selected,
> ++               * we do NOT use aligned mode as one might expect.  Instead
> ++               * we use the PHY's default based on pin strapping.  And the
> ++               * "mode 0" default is to *use* * internal delay with a
> ++               * value of 7 (2.00 ns).
> ++              */
>                 val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
>
> +               val &= ~(DP83867_RGMII_TX_CLK_DELAY_EN | DP83867_RGMII_RX_CLK_DELAY_EN);
>                 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
>                         val |= (DP83867_RGMII_TX_CLK_DELAY_EN | DP83867_RGMII_RX_CLK_DELAY_EN);
>
> @@@ -275,41 -349,14 +356,41 @@@
>
>                 phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
>                               delay);
> -
> -               if (dp83867->io_impedance >= 0)
> -                       phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
> -                                      DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL,
> -                                      dp83867->io_impedance &
> -                                      DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL);
>         }
>
> +       /* If specified, set io impedance */
> +       if (dp83867->io_impedance >= 0)
> +               phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
> +                              DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
> +                              dp83867->io_impedance);
> +
>  +      if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
>  +              /* For support SPEED_10 in SGMII mode
>  +               * DP83867_10M_SGMII_RATE_ADAPT bit
>  +               * has to be cleared by software. That
>  +               * does not affect SPEED_100 and
>  +               * SPEED_1000.
>  +               */
>  +              ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
>  +                                   DP83867_10M_SGMII_CFG,
>  +                                   DP83867_10M_SGMII_RATE_ADAPT_MASK,
>  +                                   0);
>  +              if (ret)
>  +                      return ret;
>  +
>  +              /* After reset SGMII Autoneg timer is set to 2us (bits 6 and 5
>  +               * are 01). That is not enough to finalize autoneg on some
>  +               * devices. Increase this timer duration to maximum 16ms.
>  +               */
>  +              ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
>  +                                   DP83867_CFG4,
>  +                                   DP83867_CFG4_SGMII_ANEG_MASK,
>  +                                   DP83867_CFG4_SGMII_ANEG_TIMER_16MS);
>  +
>  +              if (ret)
>  +                      return ret;
>  +      }
>  +
>         /* Enable Interrupt output INT_OE in CFG3 register */
>         if (phy_interrupt_is_valid(phydev)) {
>                 val = phy_read(phydev, DP83867_CFG3);



-- 
Best regards,
Maxim Uvarov

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-05-29 23:56 Stephen Rothwell
  2019-05-30  6:51 ` Maxim Uvarov
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-05-29 23:56 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Max Uvarov,
	Trent Piepho

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

Hi all,

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

  drivers/net/phy/dp83867.c

between commits:

  2b892649254f ("net: phy: dp83867: Set up RGMII TX delay")
  333061b92453 ("net: phy: dp83867: fix speed 10 in sgmii mode")

from the net tree and commits:

  c11669a2757e ("net: phy: dp83867: Rework delay rgmii delay handling")
  27708eb5481b ("net: phy: dp83867: IO impedance is not dependent on RGMII delay")

from the net-next tree.

I fixed it up (I took a guess - 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/dp83867.c
index c71c7d0f53f0,3bdf94043693..000000000000
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@@ -26,18 -26,11 +26,19 @@@
  
  /* Extended Registers */
  #define DP83867_CFG4            0x0031
 +#define DP83867_CFG4_SGMII_ANEG_MASK (BIT(5) | BIT(6))
 +#define DP83867_CFG4_SGMII_ANEG_TIMER_11MS   (3 << 5)
 +#define DP83867_CFG4_SGMII_ANEG_TIMER_800US  (2 << 5)
 +#define DP83867_CFG4_SGMII_ANEG_TIMER_2US    (1 << 5)
 +#define DP83867_CFG4_SGMII_ANEG_TIMER_16MS   (0 << 5)
 +
  #define DP83867_RGMIICTL	0x0032
  #define DP83867_STRAP_STS1	0x006E
+ #define DP83867_STRAP_STS2	0x006f
  #define DP83867_RGMIIDCTL	0x0086
  #define DP83867_IO_MUX_CFG	0x0170
 +#define DP83867_10M_SGMII_CFG   0x016F
 +#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
  
  #define DP83867_SW_RESET	BIT(15)
  #define DP83867_SW_RESTART	BIT(14)
@@@ -255,10 -321,18 +329,17 @@@ static int dp83867_config_init(struct p
  		ret = phy_write(phydev, MII_DP83867_PHYCTRL, val);
  		if (ret)
  			return ret;
 -	}
  
 -	/* If rgmii mode with no internal delay is selected, we do NOT use
 -	 * aligned mode as one might expect.  Instead we use the PHY's default
 -	 * based on pin strapping.  And the "mode 0" default is to *use*
 -	 * internal delay with a value of 7 (2.00 ns).
 -	 */
 -	if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
 -	    (phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
 +		/* Set up RGMII delays */
++		/* If rgmii mode with no internal delay is selected,
++		 * we do NOT use aligned mode as one might expect.  Instead
++		 * we use the PHY's default based on pin strapping.  And the
++		 * "mode 0" default is to *use* * internal delay with a
++		 * value of 7 (2.00 ns).
++		*/
  		val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
  
+ 		val &= ~(DP83867_RGMII_TX_CLK_DELAY_EN | DP83867_RGMII_RX_CLK_DELAY_EN);
  		if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
  			val |= (DP83867_RGMII_TX_CLK_DELAY_EN | DP83867_RGMII_RX_CLK_DELAY_EN);
  
@@@ -275,41 -349,14 +356,41 @@@
  
  		phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
  			      delay);
- 
- 		if (dp83867->io_impedance >= 0)
- 			phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
- 				       DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL,
- 				       dp83867->io_impedance &
- 				       DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL);
  	}
  
+ 	/* If specified, set io impedance */
+ 	if (dp83867->io_impedance >= 0)
+ 		phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
+ 			       DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
+ 			       dp83867->io_impedance);
+ 
 +	if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
 +		/* For support SPEED_10 in SGMII mode
 +		 * DP83867_10M_SGMII_RATE_ADAPT bit
 +		 * has to be cleared by software. That
 +		 * does not affect SPEED_100 and
 +		 * SPEED_1000.
 +		 */
 +		ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
 +				     DP83867_10M_SGMII_CFG,
 +				     DP83867_10M_SGMII_RATE_ADAPT_MASK,
 +				     0);
 +		if (ret)
 +			return ret;
 +
 +		/* After reset SGMII Autoneg timer is set to 2us (bits 6 and 5
 +		 * are 01). That is not enough to finalize autoneg on some
 +		 * devices. Increase this timer duration to maximum 16ms.
 +		 */
 +		ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
 +				     DP83867_CFG4,
 +				     DP83867_CFG4_SGMII_ANEG_MASK,
 +				     DP83867_CFG4_SGMII_ANEG_TIMER_16MS);
 +
 +		if (ret)
 +			return ret;
 +	}
 +
  	/* Enable Interrupt output INT_OE in CFG3 register */
  	if (phy_interrupt_is_valid(phydev)) {
  		val = phy_read(phydev, DP83867_CFG3);

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-05-02  2:57 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-05-02  2:57 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Martin KaFai Lau, David Ahern

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

Hi all,

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

  net/ipv6/route.c

between commit:

  886b7a50100a ("ipv6: A few fixes on dereferencing rt->from")

from the net tree and commits:

  85bd05deb35a ("ipv6: Pass fib6_result to ip6_rt_cache_alloc")
  5012f0a5944c ("ipv6: Pass fib6_result to rt6_insert_exception")

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/route.c
index 0520aca3354b,b18e85cd7587..000000000000
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@@ -3391,11 -3494,17 +3489,14 @@@ static void rt6_do_redirect(struct dst_
  		     NDISC_REDIRECT, &ndopts);
  
  	rcu_read_lock();
- 	from = rcu_dereference(rt->from);
- 	if (!from)
+ 	res.f6i = rcu_dereference(rt->from);
 -	/* This fib6_info_hold() is safe here because we hold reference to rt
 -	 * and rt already holds reference to fib6_info.
 -	 */
 -	fib6_info_hold(res.f6i);
 -	rcu_read_unlock();
++	if (!res.f6i)
 +		goto out;
  
- 	nrt = ip6_rt_cache_alloc(from, &msg->dest, NULL);
+ 	res.nh = &res.f6i->fib6_nh;
+ 	res.fib6_flags = res.f6i->fib6_flags;
+ 	res.fib6_type = res.f6i->fib6_type;
+ 	nrt = ip6_rt_cache_alloc(&res, &msg->dest, NULL);
  	if (!nrt)
  		goto out;
  
@@@ -3405,8 -3514,11 +3506,8 @@@
  
  	nrt->rt6i_gateway = *(struct in6_addr *)neigh->primary_key;
  
 -	/* No need to remove rt from the exception table if rt is
 -	 * a cached route because rt6_insert_exception() will
 -	 * takes care of it
 -	 */
 +	/* rt6_insert_exception() will take care of duplicated exceptions */
- 	if (rt6_insert_exception(nrt, from)) {
+ 	if (rt6_insert_exception(nrt, &res)) {
  		dst_release_immediate(&nrt->dst);
  		goto out;
  	}

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-04-15  0:54 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-04-15  0:54 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ursula Braun

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

Hi all,

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

  net/smc/af_smc.c

between commit:

  07603b230895 ("net/smc: propagate file from SMC to TCP socket")

from the net tree and commit:

  50717a37db03 ("net/smc: nonblocking connect rework")

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/smc/af_smc.c
index 6f869ef49b32,e066899de72d..000000000000
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@@ -457,9 -447,10 +455,10 @@@ static void smc_switch_to_fallback(stru
  /* fall back during connect */
  static int smc_connect_fallback(struct smc_sock *smc, int reason_code)
  {
 -	smc->use_fallback = true;
 +	smc_switch_to_fallback(smc);
  	smc->fallback_rsn = reason_code;
  	smc_copy_sock_settings_to_clc(smc);
+ 	smc->connect_nonblock = 0;
  	if (smc->sk.sk_state == SMC_INIT)
  		smc->sk.sk_state = SMC_ACTIVE;
  	return 0;
@@@ -783,16 -780,10 +788,14 @@@ static void smc_connect_work(struct wor
  		smc->sk.sk_err = -rc;
  
  out:
 -	if (smc->sk.sk_err)
 -		smc->sk.sk_state_change(&smc->sk);
 -	else
 -		smc->sk.sk_write_space(&smc->sk);
 +	if (!sock_flag(&smc->sk, SOCK_DEAD)) {
 +		if (smc->sk.sk_err) {
 +			smc->sk.sk_state_change(&smc->sk);
 +		} else { /* allow polling before and after fallback decision */
 +			smc->clcsock->sk->sk_write_space(smc->clcsock->sk);
 +			smc->sk.sk_write_space(&smc->sk);
 +		}
 +	}
- 	kfree(smc->connect_info);
- 	smc->connect_info = NULL;
  	release_sock(&smc->sk);
  }
  
@@@ -1244,19 -1215,11 +1232,14 @@@ static void smc_listen_work(struct work
  	struct socket *newclcsock = new_smc->clcsock;
  	struct smc_clc_msg_accept_confirm cclc;
  	struct smc_clc_msg_proposal *pclc;
- 	struct smc_ib_device *ibdev;
+ 	struct smc_init_info ini = {0};
  	bool ism_supported = false;
- 	struct smcd_dev *ismdev;
  	u8 buf[SMC_CLC_MAX_LEN];
- 	int local_contact = 0;
- 	unsigned short vlan;
- 	int reason_code = 0;
  	int rc = 0;
- 	u8 ibport;
  
 +	if (new_smc->listen_smc->sk.sk_state != SMC_LISTEN)
 +		return smc_listen_out_err(new_smc);
 +
  	if (new_smc->use_fallback) {
  		smc_listen_out_connected(new_smc);
  		return;

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-03-31 22:11 Stephen Rothwell
@ 2019-04-01 18:15 ` Saeed Mahameed
  0 siblings, 0 replies; 375+ messages in thread
From: Saeed Mahameed @ 2019-04-01 18:15 UTC (permalink / raw)
  To: sfr, davem, netdev; +Cc: linux-kernel, Huy Nguyen, linux-next

On Mon, 2019-04-01 at 09:11 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
> 
> between commit:
> 
>   e28408e98bce ("net/mlx5e: Update xon formula")
> 
> from the net tree and commit:
> 
>   d3669ca9ff33 ("net/mlx5e: Fix port buffer function documentation
> format")
> 
> 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 resolution looks good,
Dave was already notified about this.


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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-03-31 22:11 Stephen Rothwell
  2019-04-01 18:15 ` Saeed Mahameed
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-03-31 22:11 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Saeed Mahameed, Huy Nguyen

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c

between commit:

  e28408e98bce ("net/mlx5e: Update xon formula")

from the net tree and commit:

  d3669ca9ff33 ("net/mlx5e: Fix port buffer function documentation format")

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/port_buffer.c
index 4ab0d030b544,b0ce68feb0f3..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
@@@ -167,25 -165,25 +167,25 @@@ static int update_xoff_threshold(struc
  }
  
  /**
-  * update_buffer_lossy()
-  *   max_mtu: netdev's max_mtu
-  *   pfc_en: <input> current pfc configuration
-  *   buffer: <input> current prio to buffer mapping
-  *   xoff:   <input> xoff value
-  *   port_buffer: <output> port receive buffer configuration
-  *   change: <output>
+  *	update_buffer_lossy	- Update buffer configuration based on pfc
 - *	@mtu: device's MTU
++ *	@max_mtu: netdev's max_mtu
+  *	@pfc_en: <input> current pfc configuration
+  *	@buffer: <input> current prio to buffer mapping
+  *	@xoff:   <input> xoff value
+  *	@port_buffer: <output> port receive buffer configuration
+  *	@change: <output>
   *
-  *   Update buffer configuration based on pfc configuraiton and priority
-  *   to buffer mapping.
-  *   Buffer's lossy bit is changed to:
-  *     lossless if there is at least one PFC enabled priority mapped to this buffer
-  *     lossy if all priorities mapped to this buffer are PFC disabled
+  *	Update buffer configuration based on pfc configuraiton and
+  *	priority to buffer mapping.
+  *	Buffer's lossy bit is changed to:
+  *		lossless if there is at least one PFC enabled priority
+  *		mapped to this buffer lossy if all priorities mapped to
+  *		this buffer are PFC disabled
   *
-  *   Return:
-  *     Return 0 if no error.
-  *     Set change to true if buffer configuration is modified.
+  *	@return: 0 if no error,
+  *	sets change to true if buffer configuration was modified.
   */
 -static int update_buffer_lossy(unsigned int mtu,
 +static int update_buffer_lossy(unsigned int max_mtu,
  			       u8 pfc_en, u8 *buffer, u32 xoff,
  			       struct mlx5e_port_buffer *port_buffer,
  			       bool *change)

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-02-19  0:30 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-02-19  0:30 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Eric Dumazet

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

Hi all,

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

  net/ipv4/tcp.c

between commit:

  04c03114be82 ("tcp: clear icsk_backoff in tcp_write_queue_purge()")

from the net tree and commit:

  3a9a57f63794 ("tcp: move snd_cwnd & snd_cwnd_cnt init to tcp_disconnect()")

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.c
index cf3c5095c10e,cab6b2f2f61d..000000000000
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@@ -2577,9 -2595,11 +2596,10 @@@ int tcp_disconnect(struct sock *sk, in
  	tp->write_seq += tp->max_window + 2;
  	if (tp->write_seq == 0)
  		tp->write_seq = 1;
- 	tp->snd_cwnd = 2;
 -	icsk->icsk_backoff = 0;
  	icsk->icsk_probes_out = 0;
+ 	icsk->icsk_rto = TCP_TIMEOUT_INIT;
  	tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
+ 	tp->snd_cwnd = TCP_INIT_CWND;
  	tp->snd_cwnd_cnt = 0;
  	tp->window_clamp = 0;
  	tp->delivered_ce = 0;

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-02-13  0:13 Stephen Rothwell
@ 2019-02-13  0:33 ` Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-02-13  0:33 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Cong Wang,
	Vlad Buslov

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

Hi all,

On Wed, 13 Feb 2019 11:13:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/cls_tcindex.c
> 
> between commits:
> 
>   8015d93ebd27 ("net_sched: fix a race condition in tcindex_destroy()")
>   033b228e7f26 ("net_sched: fix a memory leak in cls_tcindex")
> 
> from the net tree and commit:
> 
>   12db03b65c2b ("net: sched: extend proto ops to support unlocked classifiers")
> 
> from the net-next tree.
> 
> I fixed it up (see the final resolution when linux-next is published)
> 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.

Actually, see the below resolution.

-- 
Cheers,
Stephen Rothwell

diff --cc net/sched/cls_tcindex.c
index 38bb882bb958,14d6b4058045..e6cf20bc8e80
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@@ -559,34 -563,15 +560,34 @@@ static void tcindex_destroy(struct tcf_
  			    struct netlink_ext_ack *extack)
  {
  	struct tcindex_data *p = rtnl_dereference(tp->root);
 -	struct tcf_walker walker;
 +	int i;
  
  	pr_debug("tcindex_destroy(tp %p),p %p\n", tp, p);
 -	walker.count = 0;
 -	walker.skip = 0;
 -	walker.fn = tcindex_destroy_element;
 -	tcindex_walk(tp, &walker, true);
  
 -	call_rcu(&p->rcu, __tcindex_destroy);
 +	if (p->perfect) {
 +		for (i = 0; i < p->hash; i++) {
 +			struct tcindex_filter_result *r = p->perfect + i;
 +
 +			tcf_unbind_filter(tp, &r->res);
 +			if (tcf_exts_get_net(&r->exts))
 +				tcf_queue_work(&r->rwork,
 +					       tcindex_destroy_rexts_work);
 +			else
 +				__tcindex_destroy_rexts(r);
 +		}
 +	}
 +
 +	for (i = 0; p->h && i < p->hash; i++) {
 +		struct tcindex_filter *f, *next;
 +		bool last;
 +
 +		for (f = rtnl_dereference(p->h[i]); f; f = next) {
 +			next = rtnl_dereference(f->next);
- 			tcindex_delete(tp, &f->result, &last, NULL);
++			tcindex_delete(tp, &f->result, &last, false, NULL);
 +		}
 +	}
 +
 +	tcf_queue_work(&p->rwork, tcindex_destroy_work);
  }
  
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-02-13  0:13 Stephen Rothwell
  2019-02-13  0:33 ` Stephen Rothwell
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-02-13  0:13 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Cong Wang,
	Vlad Buslov

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

Hi all,

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

  net/sched/cls_tcindex.c

between commits:

  8015d93ebd27 ("net_sched: fix a race condition in tcindex_destroy()")
  033b228e7f26 ("net_sched: fix a memory leak in cls_tcindex")

from the net tree and commit:

  12db03b65c2b ("net: sched: extend proto ops to support unlocked classifiers")

from the net-next tree.

I fixed it up (see the final resolution when linux-next is published)
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_tcindex.c
index 38bb882bb958,14d6b4058045..000000000000
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c

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

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

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

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

Hi all,

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

  net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
  net/ipv6/netfilter/nf_nat_l3proto_ipv6.c

between commit:

  8303b7e8f018 ("netfilter: nat: fix spurious connection timeouts")

from the net tree and commit:

  303e0c558959 ("netfilter: conntrack: avoid unneeded nf_conntrack_l4proto lookups")

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/netfilter/nf_nat_l3proto_ipv4.c
index fa2ba7c500e4,e26165af45cb..000000000000
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@@ -214,8 -214,7 +214,8 @@@ int nf_nat_icmp_reply_translation(struc
  	}
  
  	/* Change outer to look like the reply to an incoming packet */
- 	nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
+ 	nf_ct_invert_tuple(&target, &ct->tuplehash[!dir].tuple);
 +	target.dst.protonum = IPPROTO_ICMP;
  	if (!nf_nat_ipv4_manip_pkt(skb, 0, &target, manip))
  		return 0;
  
diff --cc net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
index 7a41ee3c11b4,9c914db44bec..000000000000
--- a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
@@@ -225,8 -225,7 +225,8 @@@ int nf_nat_icmpv6_reply_translation(str
  						     skb->len - hdrlen, 0));
  	}
  
- 	nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
+ 	nf_ct_invert_tuple(&target, &ct->tuplehash[!dir].tuple);
 +	target.dst.protonum = IPPROTO_ICMPV6;
  	if (!nf_nat_ipv6_manip_pkt(skb, 0, &target, manip))
  		return 0;
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-02-08  0:24 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-02-08  0:24 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Tonghao Zhang, Pablo Neira Ayuso

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

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:

  218d05ce326f ("net/mlx5e: Don't overwrite pedit action when multiple pedit used")

from the net tree and commit:

  c500c86b0c75 ("net/mlx5e: support for two independent packet edit actions")

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 b5c1b039375a,85c5dd7fc2c7..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1310,15 -1308,12 +1309,12 @@@ static int parse_tunnel_attr(struct mlx
  				       outer_headers);
  	void *headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
  				       outer_headers);
- 
- 	struct flow_dissector_key_control *enc_control =
- 		skb_flow_dissector_target(f->dissector,
- 					  FLOW_DISSECTOR_KEY_ENC_CONTROL,
- 					  f->key);
- 	int err = 0;
+ 	struct flow_rule *rule = tc_cls_flower_offload_flow_rule(f);
+ 	struct flow_match_control enc_control;
+ 	int err;
  
  	err = mlx5e_tc_tun_parse(filter_dev, priv, spec, f,
 -				 headers_c, headers_v);
 +				 headers_c, headers_v, match_level);
  	if (err) {
  		NL_SET_ERR_MSG_MOD(extack,
  				   "failed to parse tunnel attributes");
@@@ -1466,19 -1454,17 +1455,17 @@@ static int __parse_cls_flower(struct ml
  		return -EOPNOTSUPP;
  	}
  
- 	if ((dissector_uses_key(f->dissector,
- 				FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
- 	     dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
- 	     dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
- 	    dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
- 		struct flow_dissector_key_control *key =
- 			skb_flow_dissector_target(f->dissector,
- 						  FLOW_DISSECTOR_KEY_ENC_CONTROL,
- 						  f->key);
- 		switch (key->addr_type) {
+ 	if ((flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
+ 	     flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
+ 	     flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
+ 	    flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
+ 		struct flow_match_control match;
+ 
+ 		flow_rule_match_enc_control(rule, &match);
+ 		switch (match.key->addr_type) {
  		case FLOW_DISSECTOR_KEY_IPV4_ADDRS:
  		case FLOW_DISSECTOR_KEY_IPV6_ADDRS:
 -			if (parse_tunnel_attr(priv, spec, f, filter_dev))
 +			if (parse_tunnel_attr(priv, spec, f, filter_dev, tunnel_match_level))
  				return -EOPNOTSUPP;
  			break;
  		default:
@@@ -1937,12 -1880,11 +1883,11 @@@ static struct mlx5_fields fields[] = 
  	OFFLOAD(UDP_DPORT, 2, udp.dest,   0),
  };
  
 -/* On input attr->num_mod_hdr_actions tells how many HW actions can be parsed at
 - * max from the SW pedit action. On success, it says how many HW actions were
 - * actually parsed.
 +/* On input attr->max_mod_hdr_actions tells how many HW actions can be parsed at
 + * max from the SW pedit action. On success, attr->num_mod_hdr_actions
 + * says how many HW actions were actually parsed.
   */
- static int offload_pedit_fields(struct pedit_headers *masks,
- 				struct pedit_headers *vals,
+ static int offload_pedit_fields(struct pedit_headers_action *hdrs,
  				struct mlx5e_tc_flow_parse_attr *parse_attr,
  				struct netlink_ext_ack *extack)
  {
@@@ -1957,17 -1899,15 +1902,17 @@@
  	__be16 mask_be16;
  	void *action;
  
- 	set_masks = &masks[TCA_PEDIT_KEY_EX_CMD_SET];
- 	add_masks = &masks[TCA_PEDIT_KEY_EX_CMD_ADD];
- 	set_vals = &vals[TCA_PEDIT_KEY_EX_CMD_SET];
- 	add_vals = &vals[TCA_PEDIT_KEY_EX_CMD_ADD];
+ 	set_masks = &hdrs[0].masks;
+ 	add_masks = &hdrs[1].masks;
+ 	set_vals = &hdrs[0].vals;
+ 	add_vals = &hdrs[1].vals;
  
  	action_size = MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto);
 -	action = parse_attr->mod_hdr_actions;
 -	max_actions = parse_attr->num_mod_hdr_actions;
 -	nactions = 0;
 +	action = parse_attr->mod_hdr_actions +
 +		 parse_attr->num_mod_hdr_actions * action_size;
 +
 +	max_actions = parse_attr->max_mod_hdr_actions;
 +	nactions = parse_attr->num_mod_hdr_actions;
  
  	for (i = 0; i < ARRAY_SIZE(fields); i++) {
  		f = &fields[i];
@@@ -2085,52 -2027,53 +2032,55 @@@ static int alloc_mod_hdr_actions(struc
  static const struct pedit_headers zero_masks = {};
  
  static int parse_tc_pedit_action(struct mlx5e_priv *priv,
- 				 const struct tc_action *a, int namespace,
+ 				 const struct flow_action_entry *act, int namespace,
  				 struct mlx5e_tc_flow_parse_attr *parse_attr,
+ 				 struct pedit_headers_action *hdrs,
  				 struct netlink_ext_ack *extack)
  {
- 	struct pedit_headers masks[__PEDIT_CMD_MAX], vals[__PEDIT_CMD_MAX], *cmd_masks;
- 	int nkeys, i, err = -EOPNOTSUPP;
+ 	u8 cmd = (act->id == FLOW_ACTION_MANGLE) ? 0 : 1;
+ 	int err = -EOPNOTSUPP;
  	u32 mask, val, offset;
- 	u8 cmd, htype;
+ 	u8 htype;
  
- 	nkeys = tcf_pedit_nkeys(a);
+ 	htype = act->mangle.htype;
+ 	err = -EOPNOTSUPP; /* can't be all optimistic */
  
- 	memset(masks, 0, sizeof(struct pedit_headers) * __PEDIT_CMD_MAX);
- 	memset(vals,  0, sizeof(struct pedit_headers) * __PEDIT_CMD_MAX);
+ 	if (htype == FLOW_ACT_MANGLE_UNSPEC) {
+ 		NL_SET_ERR_MSG_MOD(extack, "legacy pedit isn't offloaded");
+ 		goto out_err;
+ 	}
  
- 	for (i = 0; i < nkeys; i++) {
- 		htype = tcf_pedit_htype(a, i);
- 		cmd = tcf_pedit_cmd(a, i);
- 		err = -EOPNOTSUPP; /* can't be all optimistic */
+ 	mask = act->mangle.mask;
+ 	val = act->mangle.val;
+ 	offset = act->mangle.offset;
  
- 		if (htype == TCA_PEDIT_KEY_EX_HDR_TYPE_NETWORK) {
- 			NL_SET_ERR_MSG_MOD(extack,
- 					   "legacy pedit isn't offloaded");
- 			goto out_err;
- 		}
+ 	err = set_pedit_val(htype, ~mask, val, offset, &hdrs[cmd]);
+ 	if (err)
+ 		goto out_err;
  
- 		if (cmd != TCA_PEDIT_KEY_EX_CMD_SET && cmd != TCA_PEDIT_KEY_EX_CMD_ADD) {
- 			NL_SET_ERR_MSG_MOD(extack, "pedit cmd isn't offloaded");
- 			goto out_err;
- 		}
+ 	hdrs[cmd].pedits++;
  
- 		mask = tcf_pedit_mask(a, i);
- 		val = tcf_pedit_val(a, i);
- 		offset = tcf_pedit_offset(a, i);
+ 	return 0;
+ out_err:
+ 	return err;
+ }
  
- 		err = set_pedit_val(htype, ~mask, val, offset, &masks[cmd], &vals[cmd]);
- 		if (err)
- 			goto out_err;
- 	}
+ static int alloc_tc_pedit_action(struct mlx5e_priv *priv, int namespace,
+ 				 struct mlx5e_tc_flow_parse_attr *parse_attr,
+ 				 struct pedit_headers_action *hdrs,
+ 				 struct netlink_ext_ack *extack)
+ {
+ 	struct pedit_headers *cmd_masks;
+ 	int err;
+ 	u8 cmd;
  
 -	err = alloc_mod_hdr_actions(priv, hdrs, namespace, parse_attr);
 -	if (err)
 -		goto out_err;
 +	if (!parse_attr->mod_hdr_actions) {
- 		err = alloc_mod_hdr_actions(priv, a, namespace, parse_attr);
++		err = alloc_mod_hdr_actions(priv, hdrs, namespace, parse_attr);
 +		if (err)
 +			goto out_err;
 +	}
  
- 	err = offload_pedit_fields(masks, vals, parse_attr, extack);
+ 	err = offload_pedit_fields(hdrs, parse_attr, extack);
  	if (err < 0)
  		goto out_dealloc_parsed_actions;
  
@@@ -2185,22 -2128,17 +2135,22 @@@ static bool csum_offload_supported(stru
  }
  
  static bool modify_header_match_supported(struct mlx5_flow_spec *spec,
- 					  struct tcf_exts *exts,
+ 					  struct flow_action *flow_action,
 +					  u32 actions,
  					  struct netlink_ext_ack *extack)
  {
- 	const struct tc_action *a;
+ 	const struct flow_action_entry *act;
  	bool modify_ip_header;
  	u8 htype, ip_proto;
  	void *headers_v;
  	u16 ethertype;
- 	int nkeys, i;
+ 	int i;
  
 -	headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, outer_headers);
 +	if (actions & MLX5_FLOW_CONTEXT_ACTION_DECAP)
 +		headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, inner_headers);
 +	else
 +		headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, outer_headers);
 +
  	ethertype = MLX5_GET(fte_match_set_lyr_2_4, headers_v, ethertype);
  
  	/* for non-IP we only re-write MACs, so we're okay */
@@@ -2256,8 -2190,9 +2202,9 @@@ static bool actions_match_supported(str
  		return false;
  
  	if (actions & MLX5_FLOW_CONTEXT_ACTION_MOD_HDR)
- 		return modify_header_match_supported(&parse_attr->spec, exts,
+ 		return modify_header_match_supported(&parse_attr->spec,
+ 						     flow_action,
 -						     extack);
 +						     actions, extack);
  
  	return true;
  }

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2019-02-07  0:54 Stephen Rothwell
@ 2019-02-07 18:36 ` Pablo Neira Ayuso
  0 siblings, 0 replies; 375+ messages in thread
From: Pablo Neira Ayuso @ 2019-02-07 18:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Guy Shattah, Saeed Mahameed

Hi Stephen,

On Thu, Feb 07, 2019 at 11:54:24AM +1100, Stephen Rothwell wrote:
> 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:
> 
>   1651925d403e ("net/mlx5e: Use the inner headers to determine tc/pedit offload limitation on decap flows")
> 
> from the net tree and commit:
> 
>   738678817573 ("drivers: net: use flow action infrastructure")
> 
> from the net-next tree.

This conflict resolution when merging net into net-next looks good to me.

Thanks.

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-02-07  0:54 Stephen Rothwell
  2019-02-07 18:36 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2019-02-07  0:54 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Guy Shattah,
	Saeed Mahameed, Pablo Neira Ayuso

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

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:

  1651925d403e ("net/mlx5e: Use the inner headers to determine tc/pedit offload limitation on decap flows")

from the net tree and commit:

  738678817573 ("drivers: net: use flow action infrastructure")

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 1c3c9fa26b55,83522c926d7c..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1309,15 -1309,12 +1309,12 @@@ static int parse_tunnel_attr(struct mlx
  				       outer_headers);
  	void *headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
  				       outer_headers);
- 
- 	struct flow_dissector_key_control *enc_control =
- 		skb_flow_dissector_target(f->dissector,
- 					  FLOW_DISSECTOR_KEY_ENC_CONTROL,
- 					  f->key);
- 	int err = 0;
+ 	struct flow_rule *rule = tc_cls_flower_offload_flow_rule(f);
+ 	struct flow_match_control enc_control;
+ 	int err;
  
  	err = mlx5e_tc_tun_parse(filter_dev, priv, spec, f,
 -				 headers_c, headers_v);
 +				 headers_c, headers_v, match_level);
  	if (err) {
  		NL_SET_ERR_MSG_MOD(extack,
  				   "failed to parse tunnel attributes");
@@@ -1465,19 -1455,17 +1455,17 @@@ static int __parse_cls_flower(struct ml
  		return -EOPNOTSUPP;
  	}
  
- 	if ((dissector_uses_key(f->dissector,
- 				FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
- 	     dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
- 	     dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
- 	    dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
- 		struct flow_dissector_key_control *key =
- 			skb_flow_dissector_target(f->dissector,
- 						  FLOW_DISSECTOR_KEY_ENC_CONTROL,
- 						  f->key);
- 		switch (key->addr_type) {
+ 	if ((flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
+ 	     flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
+ 	     flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
+ 	    flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
+ 		struct flow_match_control match;
+ 
+ 		flow_rule_match_enc_control(rule, &match);
+ 		switch (match.key->addr_type) {
  		case FLOW_DISSECTOR_KEY_IPV4_ADDRS:
  		case FLOW_DISSECTOR_KEY_IPV6_ADDRS:
 -			if (parse_tunnel_attr(priv, spec, f, filter_dev))
 +			if (parse_tunnel_attr(priv, spec, f, filter_dev, tunnel_match_level))
  				return -EOPNOTSUPP;
  			break;
  		default:
@@@ -2180,22 -2129,17 +2131,22 @@@ static bool csum_offload_supported(stru
  }
  
  static bool modify_header_match_supported(struct mlx5_flow_spec *spec,
- 					  struct tcf_exts *exts,
+ 					  struct flow_action *flow_action,
 +					  u32 actions,
  					  struct netlink_ext_ack *extack)
  {
- 	const struct tc_action *a;
+ 	const struct flow_action_entry *act;
  	bool modify_ip_header;
  	u8 htype, ip_proto;
  	void *headers_v;
  	u16 ethertype;
- 	int nkeys, i;
+ 	int i;
  
 -	headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, outer_headers);
 +	if (actions & MLX5_FLOW_CONTEXT_ACTION_DECAP)
 +		headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, inner_headers);
 +	else
 +		headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, outer_headers);
 +
  	ethertype = MLX5_GET(fte_match_set_lyr_2_4, headers_v, ethertype);
  
  	/* for non-IP we only re-write MACs, so we're okay */
@@@ -2251,8 -2191,9 +2198,9 @@@ static bool actions_match_supported(str
  		return false;
  
  	if (actions & MLX5_FLOW_CONTEXT_ACTION_MOD_HDR)
- 		return modify_header_match_supported(&parse_attr->spec, exts,
+ 		return modify_header_match_supported(&parse_attr->spec,
+ 						     flow_action,
 -						     extack);
 +						     actions, extack);
  
  	return true;
  }

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2019-01-17  1:27 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2019-01-17  1:27 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, yupeng, Randy Dunlap

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

Hi all,

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

  Documentation/networking/snmp_counter.rst

between commit:

  a6c7c7aac2de ("net: add document for several snmp counters")

from the net tree and commit:

  ae5220c67218 ("networking: Documentation: fix snmp_counters.rst Sphinx warnings")

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 Documentation/networking/snmp_counter.rst
index fe8f741193be,486ab33acc3a..000000000000
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@@ -336,27 -364,8 +364,27 @@@ time client replies ACK, this socket wi
  to the accept queue.
  
  
 -TCP Fast Open
 +* TcpEstabResets
 +Defined in `RFC1213 tcpEstabResets`_.
 +
 +.. _RFC1213 tcpEstabResets: https://tools.ietf.org/html/rfc1213#page-48
 +
 +* TcpAttemptFails
 +Defined in `RFC1213 tcpAttemptFails`_.
 +
 +.. _RFC1213 tcpAttemptFails: https://tools.ietf.org/html/rfc1213#page-48
 +
 +* TcpOutRsts
 +Defined in `RFC1213 tcpOutRsts`_. The RFC says this counter indicates
 +the 'segments sent containing the RST flag', but in linux kernel, this
 +couner indicates the segments kerenl tried to send. The sending
 +process might be failed due to some errors (e.g. memory alloc failed).
 +
 +.. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52
 +
 +
 +TCP Fast Path
- ============
+ =============
  When kernel receives a TCP packet, it has two paths to handler the
  packet, one is fast path, another is slow path. The comment in kernel
  code provides a good explanation of them, I pasted them below::
@@@ -582,7 -612,8 +630,8 @@@ The TCP stack receives an out of order 
  DSACK to the sender.
  
  * TcpExtTCPDSACKRecv
+ 
 -The TCP stack receives a DSACK, which indicate an acknowledged
 +The TCP stack receives a DSACK, which indicates an acknowledged
  duplicate packet is received.
  
  * TcpExtTCPDSACKOfoRecv
@@@ -589,59 -621,10 +639,60 @@@
  The TCP stack receives a DSACK, which indicate an out of order
  duplicate packet is received.
  
 +invalid SACK and DSACK
- ====================
++======================
 +When a SACK (or DSACK) block is invalid, a corresponding counter would
 +be updated. The validation method is base on the start/end sequence
 +number of the SACK block. For more details, please refer the comment
 +of the function tcp_is_sackblock_valid in the kernel source code. A
 +SACK option could have up to 4 blocks, they are checked
 +individually. E.g., if 3 blocks of a SACk is invalid, the
 +corresponding counter would be updated 3 times. The comment of the
 +`Add counters for discarded SACK blocks`_ patch has additional
 +explaination:
 +
 +.. _Add counters for discarded SACK blocks: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f02545a9a16c9a89778b91a162ad16d510bb32
 +
 +* TcpExtTCPSACKDiscard
 +This counter indicates how many SACK blocks are invalid. If the invalid
 +SACK block is caused by ACK recording, the TCP stack will only ignore
 +it and won't update this counter.
 +
 +* TcpExtTCPDSACKIgnoredOld and TcpExtTCPDSACKIgnoredNoUndo
 +When a DSACK block is invalid, one of these two counters would be
 +updated. Which counter will be updated depends on the undo_marker flag
 +of the TCP socket. If the undo_marker is not set, the TCP stack isn't
 +likely to re-transmit any packets, and we still receive an invalid
 +DSACK block, the reason might be that the packet is duplicated in the
 +middle of the network. In such scenario, TcpExtTCPDSACKIgnoredNoUndo
 +will be updated. If the undo_marker is set, TcpExtTCPDSACKIgnoredOld
 +will be updated. As implied in its name, it might be an old packet.
 +
 +SACK shift
- =========
++==========
 +The linux networking stack stores data in sk_buff struct (skb for
 +short). If a SACK block acrosses multiple skb, the TCP stack will try
 +to re-arrange data in these skb. E.g. if a SACK block acknowledges seq
 +10 to 15, skb1 has seq 10 to 13, skb2 has seq 14 to 20. The seq 14 and
 +15 in skb2 would be moved to skb1. This operation is 'shift'. If a
 +SACK block acknowledges seq 10 to 20, skb1 has seq 10 to 13, skb2 has
 +seq 14 to 20. All data in skb2 will be moved to skb1, and skb2 will be
 +discard, this operation is 'merge'.
 +
 +* TcpExtTCPSackShifted
 +A skb is shifted
 +
 +* TcpExtTCPSackMerged
 +A skb is merged
 +
 +* TcpExtTCPSackShiftFallback
 +A skb should be shifted or merged, but the TCP stack doesn't do it for
 +some reasons.
 +
  TCP out of order
- ===============
+ ================
  * TcpExtTCPOFOQueue
+ 
  The TCP layer receives an out of order packet and has enough memory
  to queue it.
  
@@@ -728,66 -721,12 +789,66 @@@ unacknowledged number (more strict tha
  .. _RFC 5961 section 4.2: https://tools.ietf.org/html/rfc5961#page-9
  .. _RFC 5961 section 5.2: https://tools.ietf.org/html/rfc5961#page-11
  
 +TCP receive window
- =================
++==================
 +* TcpExtTCPWantZeroWindowAdv
 +Depending on current memory usage, the TCP stack tries to set receive
 +window to zero. But the receive window might still be a no-zero
 +value. For example, if the previous window size is 10, and the TCP
 +stack receives 3 bytes, the current window size would be 7 even if the
 +window size calculated by the memory usage is zero.
 +
 +* TcpExtTCPToZeroWindowAdv
 +The TCP receive window is set to zero from a no-zero value.
 +
 +* TcpExtTCPFromZeroWindowAdv
 +The TCP receive window is set to no-zero value from zero.
 +
 +
 +Delayed ACK
- ==========
++===========
 +The TCP Delayed ACK is a technique which is used for reducing the
 +packet count in the network. For more details, please refer the
 +`Delayed ACK wiki`_
 +
 +.. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
 +
 +* TcpExtDelayedACKs
 +A delayed ACK timer expires. The TCP stack will send a pure ACK packet
 +and exit the delayed ACK mode.
 +
 +* TcpExtDelayedACKLocked
 +A delayed ACK timer expires, but the TCP stack can't send an ACK
 +immediately due to the socket is locked by a userspace program. The
 +TCP stack will send a pure ACK later (after the userspace program
 +unlock the socket). When the TCP stack sends the pure ACK later, the
 +TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK
 +mode.
 +
 +* TcpExtDelayedACKLost
 +It will be updated when the TCP stack receives a packet which has been
 +ACKed. A Delayed ACK loss might cause this issue, but it would also be
 +triggered by other reasons, such as a packet is duplicated in the
 +network.
 +
 +Tail Loss Probe (TLP)
- ===================
++=====================
 +TLP is an algorithm which is used to detect TCP packet loss. For more
 +details, please refer the `TLP paper`_.
 +
 +.. _TLP paper: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
 +
 +* TcpExtTCPLossProbes
 +A TLP probe packet is sent.
 +
 +* TcpExtTCPLossProbeRecovery
 +A packet loss is detected and recovered by TLP.
  
  examples
- =======
+ ========
  
  ping test
- --------
+ ---------
  Run the ping command against the public dns server 8.8.8.8::
  
    nstatuser@nstat-a:~$ ping 8.8.8.8 -c 1

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-20  1:56 Stephen Rothwell
@ 2018-12-20 10:38 ` Petr Machata
  0 siblings, 0 replies; 375+ messages in thread
From: Petr Machata @ 2018-12-20 10:38 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: David Miller, Networking, Linux Next Mailing List

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

> diff --cc drivers/net/vxlan.c
> index 0565f8880199,71c3b7b6b1ab..000000000000
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@@ -3297,16 -3483,9 +3484,16 @@@ static int __vxlan_dev_create(struct ne
>   
>   	list_add(&vxlan->next, &vn->vxlan_list);
>   	return 0;
>  +
>   errout:
>  +	/* unregister_netdevice() destroys the default FDB entry with deletion
>  +	 * notification. But the addition notification was not sent yet, so
>  +	 * destroy the entry by hand here.
>  +	 */
>   	if (f)
> - 		vxlan_fdb_destroy(vxlan, f, false);
> + 		vxlan_fdb_destroy(vxlan, f, false, false);
>  +	if (unregister)
>  +		unregister_netdevice(dev);
>   	return err;
>   }
>   
> @@@ -3540,8 -3719,10 +3727,9 @@@ static int vxlan_changelink(struct net_
>   {
>   	struct vxlan_dev *vxlan = netdev_priv(dev);
>   	struct vxlan_rdst *dst = &vxlan->default_dst;
> + 	unsigned long old_age_interval;
>   	struct vxlan_rdst old_dst;
>   	struct vxlan_config conf;
>  -	struct vxlan_fdb *f = NULL;
>   	int err;
>   
>   	err = vxlan_nl2conf(tb, data,
> @@@ -3564,13 -3749,13 +3756,14 @@@
>   					   vxlan->cfg.dst_port,
>   					   old_dst.remote_vni,
>   					   old_dst.remote_vni,
> - 					   old_dst.remote_ifindex, 0);
> + 					   old_dst.remote_ifindex,
> + 					   true);
>   
>   		if (!vxlan_addr_any(&dst->remote_ip)) {
>  -			err = vxlan_fdb_create(vxlan, all_zeros_mac,
>  +			err = vxlan_fdb_update(vxlan, all_zeros_mac,
>   					       &dst->remote_ip,
>   					       NUD_REACHABLE | NUD_PERMANENT,
>  +					       NLM_F_APPEND | NLM_F_CREATE,
>   					       vxlan->cfg.dst_port,
>   					       dst->remote_vni,
>   					       dst->remote_vni,

The above looks correct, but the last hunk has one non-conflicting line
that nonetheless needs fixing up:

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index efd709a5e3a8..5209ee9aac47 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3768,7 +3768,7 @@ static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],
                                               dst->remote_vni,
                                               dst->remote_vni,
                                               dst->remote_ifindex,
-                                              NTF_SELF);
+                                              NTF_SELF, true);
                        if (err) {
                                spin_unlock_bh(&vxlan->hash_lock);
                                return err;

Thanks!

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-20  2:07 Stephen Rothwell
@ 2018-12-20  6:54 ` Or Gerlitz
  0 siblings, 0 replies; 375+ messages in thread
From: Or Gerlitz @ 2018-12-20  6:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Gavi Teitz, Or Gerlitz,
	Saeed Mahameed

On Thu, Dec 20, 2018 at 4:47 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_rep.c
>
> between commit:
>
>   8956f0014ea5 ("net/mlx5e: Fix default amount of channels for VF representors")
>
> from the net tree and commit:
>
>   d9ee0491c2ff ("net/mlx5e: Use dedicated uplink vport netdev representor")
>
> 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, this is correct, thanks!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-20  2:07 Stephen Rothwell
  2018-12-20  6:54 ` Or Gerlitz
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-20  2:07 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Gavi Teitz,
	Or Gerlitz, Saeed Mahameed

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

Hi all,

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

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

between commit:

  8956f0014ea5 ("net/mlx5e: Fix default amount of channels for VF representors")

from the net tree and commit:

  d9ee0491c2ff ("net/mlx5e: Use dedicated uplink vport netdev representor")

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] 375+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-20  2:00 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-20  2:00 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Petr Machata,
	Paolo Abeni

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

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  55cbe0794294 ("selftests: net: Add test_vxlan_fdb_changelink.sh")

from the net tree and commit:

  e87f53b4fab7 ("selftests: add some benchmark for UDP GRO")

( and following ones) 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 923570a9708a,9543a4c2f9be..000000000000
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -4,14 -4,15 +4,16 @@@
  CFLAGS =  -Wall -Wl,--no-as-needed -O2 -g
  CFLAGS += -I../../../../usr/include/
  
- TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
+ TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh \
+ 	      rtnetlink.sh xfrm_policy.sh
  TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh ip_defrag.sh
  TEST_PROGS += udpgso_bench.sh fib_rule_tests.sh msg_zerocopy.sh psock_snd.sh
 +TEST_PROGS += test_vxlan_fdb_changelink.sh
+ TEST_PROGS += udpgro_bench.sh udpgro.sh test_vxlan_under_vrf.sh reuseport_addr_any.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 psock_snd
+ TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
+ TEST_GEN_FILES += tcp_mmap tcp_inq psock_snd txring_overwrite
  TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx ip_defrag
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls

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

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

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

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

Hi all,

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

  drivers/net/vxlan.c

between commits:

  6db924687139 ("vxlan: Fix error path in __vxlan_dev_create()")
  ce5e098f7a10 ("vxlan: changelink: Fix handling of default remotes")

from the net tree and commit:

  0e6160f3f5a9 ("vxlan: vxlan_fdb_notify(): Make switchdev notification configurable")

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/vxlan.c
index 0565f8880199,71c3b7b6b1ab..000000000000
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@@ -3297,16 -3483,9 +3484,16 @@@ static int __vxlan_dev_create(struct ne
  
  	list_add(&vxlan->next, &vn->vxlan_list);
  	return 0;
 +
  errout:
 +	/* unregister_netdevice() destroys the default FDB entry with deletion
 +	 * notification. But the addition notification was not sent yet, so
 +	 * destroy the entry by hand here.
 +	 */
  	if (f)
- 		vxlan_fdb_destroy(vxlan, f, false);
+ 		vxlan_fdb_destroy(vxlan, f, false, false);
 +	if (unregister)
 +		unregister_netdevice(dev);
  	return err;
  }
  
@@@ -3540,8 -3719,10 +3727,9 @@@ static int vxlan_changelink(struct net_
  {
  	struct vxlan_dev *vxlan = netdev_priv(dev);
  	struct vxlan_rdst *dst = &vxlan->default_dst;
+ 	unsigned long old_age_interval;
  	struct vxlan_rdst old_dst;
  	struct vxlan_config conf;
 -	struct vxlan_fdb *f = NULL;
  	int err;
  
  	err = vxlan_nl2conf(tb, data,
@@@ -3564,13 -3749,13 +3756,14 @@@
  					   vxlan->cfg.dst_port,
  					   old_dst.remote_vni,
  					   old_dst.remote_vni,
- 					   old_dst.remote_ifindex, 0);
+ 					   old_dst.remote_ifindex,
+ 					   true);
  
  		if (!vxlan_addr_any(&dst->remote_ip)) {
 -			err = vxlan_fdb_create(vxlan, all_zeros_mac,
 +			err = vxlan_fdb_update(vxlan, all_zeros_mac,
  					       &dst->remote_ip,
  					       NUD_REACHABLE | NUD_PERMANENT,
 +					       NLM_F_APPEND | NLM_F_CREATE,
  					       vxlan->cfg.dst_port,
  					       dst->remote_vni,
  					       dst->remote_vni,

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-17 22:01   ` Or Gerlitz
@ 2018-12-17 22:14     ` Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-17 22:14 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Saeed Mahameed, David Miller, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Or Gerlitz,
	Saeed Mahameed, Eli Britstein

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

Hi,

On Tue, 18 Dec 2018 00:01:57 +0200 Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> Just a note,
> 
> e88afe759a49  ("net/mlx5e: Err if asked to mirror a goto chain tc eswitch rule")
>
> is from net  and not net-next

Yeah, my mistake ...

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-17 21:20 ` Saeed Mahameed
@ 2018-12-17 22:01   ` Or Gerlitz
  2018-12-17 22:14     ` Stephen Rothwell
  0 siblings, 1 reply; 375+ messages in thread
From: Or Gerlitz @ 2018-12-17 22:01 UTC (permalink / raw)
  To: Saeed Mahameed
  Cc: Stephen Rothwell, David Miller, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Or Gerlitz,
	Saeed Mahameed, Eli Britstein

On Mon, Dec 17, 2018 at 11:29 PM Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sun, Dec 16, 2018 at 4:25 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

> Looks good to me.

here too


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

> >   154e62abe9cd ("net/mlx5e: Properly initialize flow attributes for slow path eswitch rule deletion")
> > from the net tree and commit:

> >   e88afe759a49 ("net/mlx5e: Err if asked to mirror a goto chain tc eswitch rule")
> >   e85e02bad29e ("net/mlx5: E-Switch, Rename esw attr mirror count field")
> > from the net-next tree.

Just a note,

e88afe759a49  ("net/mlx5e: Err if asked to mirror a goto chain tc
eswitch rule")i

s from net  and not net-next

see it here [1] among the top 10 patches

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/log/?qt=grep&q=mlx5

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-17  0:25 Stephen Rothwell
@ 2018-12-17 21:20 ` Saeed Mahameed
  2018-12-17 22:01   ` Or Gerlitz
  0 siblings, 1 reply; 375+ messages in thread
From: Saeed Mahameed @ 2018-12-17 21:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Or Gerlitz, Saeed Mahameed,
	Eli Britstein

On Sun, Dec 16, 2018 at 4: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:
>
>   drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
>
> between commit:
>
>   154e62abe9cd ("net/mlx5e: Properly initialize flow attributes for slow path eswitch rule deletion")
>
> from the net tree and commit:
>
>   e88afe759a49 ("net/mlx5e: Err if asked to mirror a goto chain tc eswitch rule")
>   e85e02bad29e ("net/mlx5: E-Switch, Rename esw attr mirror count field")
>
> 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 9dabe9d4b279,53ebb5a48018..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> @@@ -870,9 -903,9 +903,9 @@@ mlx5e_tc_offload_to_slow_path(struct ml
>         struct mlx5_flow_handle *rule;
>
>         memcpy(slow_attr, flow->esw_attr, sizeof(*slow_attr));
>  -      slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST,
>  -      slow_attr->split_count = 0,
>  -      slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN,
>  +      slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
> -       slow_attr->mirror_count = 0;
> ++      slow_attr->split_count = 0;
>  +      slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN;
>
>         rule = mlx5e_tc_offload_fdb_rules(esw, flow, spec, slow_attr);
>         if (!IS_ERR(rule))
> @@@ -887,9 -920,6 +920,9 @@@ mlx5e_tc_unoffload_from_slow_path(struc
>                                   struct mlx5_esw_flow_attr *slow_attr)
>   {
>         memcpy(slow_attr, flow->esw_attr, sizeof(*slow_attr));
>  +      slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
> -       slow_attr->mirror_count = 0;
> ++      slow_attr->split_count = 0;
>  +      slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN;
>         mlx5e_tc_unoffload_fdb_rules(esw, flow, slow_attr);
>         flow->flags &= ~MLX5E_TC_FLOW_SLOW;
>   }
> @@@ -909,11 -939,13 +942,12 @@@ mlx5e_tc_add_fdb_flow(struct mlx5e_pri
>         struct mlx5e_rep_priv *rpriv;
>         struct mlx5e_priv *out_priv;
>         int err = 0, encap_err = 0;
> +       int out_index;
>
>  -      /* if prios are not supported, keep the old behaviour of using same prio
>  -       * for all offloaded rules.
>  -       */
>  -      if (!mlx5_eswitch_prios_supported(esw))
>  -              attr->prio = 1;
>  +      if (!mlx5_eswitch_prios_supported(esw) && attr->prio != 1) {
>  +              NL_SET_ERR_MSG(extack, "E-switch priorities unsupported, upgrade FW");
>  +              return -EOPNOTSUPP;
>  +      }
>
>         if (attr->chain > max_chain) {
>                 NL_SET_ERR_MSG(extack, "Requested chain is out of supported range");
> @@@ -2980,15 -2667,7 +2667,15 @@@ static int parse_tc_fdb_actions(struct
>         if (!actions_match_supported(priv, exts, parse_attr, flow, extack))
>                 return -EOPNOTSUPP;
>
>  +      if (attr->dest_chain) {
>  +              if (attr->action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
>  +                      NL_SET_ERR_MSG(extack, "Mirroring goto chain rules isn't supported");
>  +                      return -EOPNOTSUPP;
>  +              }
>  +              attr->action |= MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
>  +      }
>  +
> -       if (attr->mirror_count > 0 && !mlx5_esw_has_fwd_fdb(priv->mdev)) {
> +       if (attr->split_count > 0 && !mlx5_esw_has_fwd_fdb(priv->mdev)) {
>                 NL_SET_ERR_MSG_MOD(extack,
>                                    "current firmware doesn't support split rule for port mirroring");
>                 netdev_warn_once(priv->netdev, "current firmware doesn't support split rule for port mirroring\n");

Looks good to me.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-17 10:03 ` Ido Schimmel
@ 2018-12-17 10:12   ` Eric Dumazet
  0 siblings, 0 replies; 375+ messages in thread
From: Eric Dumazet @ 2018-12-17 10:12 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: Stephen Rothwell, David Miller, netdev, linux-next, LKML

On Mon, Dec 17, 2018 at 2:03 AM Ido Schimmel <idosch@mellanox.com> wrote:
>
> On Mon, Dec 17, 2018 at 11:31:06AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> >   net/ipv6/ip6_output.c
> >
> > between commit:
> >
> >   8203e2d844d3 ("net: clear skb->tstamp in forwarding paths")
> >
> > from the net tree and commit:
> >
> >   f839a6c92504 ("net: Do not route unicast IP packets twice")
> >
> > from the net-next tree.
> >
> > I fixed it up (I was not quite sure of the correct ordering - 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. Eric?
>
> Thank you!


Yes, SGTM,  thanks.

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

* Re: linux-next: manual merge of the net-next tree with the net tree
  2018-12-17  0:31 Stephen Rothwell
@ 2018-12-17 10:03 ` Ido Schimmel
  2018-12-17 10:12   ` Eric Dumazet
  0 siblings, 1 reply; 375+ messages in thread
From: Ido Schimmel @ 2018-12-17 10:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Eric Dumazet

On Mon, Dec 17, 2018 at 11:31:06AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv6/ip6_output.c
> 
> between commit:
> 
>   8203e2d844d3 ("net: clear skb->tstamp in forwarding paths")
> 
> from the net tree and commit:
> 
>   f839a6c92504 ("net: Do not route unicast IP packets twice")
> 
> from the net-next tree.
> 
> I fixed it up (I was not quite sure of the correct ordering - 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. Eric?

Thank you!

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-17  0:31 Stephen Rothwell
  2018-12-17 10:03 ` Ido Schimmel
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-17  0:31 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Eric Dumazet,
	Ido Schimmel

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

Hi all,

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

  net/ipv6/ip6_output.c

between commit:

  8203e2d844d3 ("net: clear skb->tstamp in forwarding paths")

from the net tree and commit:

  f839a6c92504 ("net: Do not route unicast IP packets twice")

from the net-next tree.

I fixed it up (I was not quite sure of the correct ordering - 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 4591ca4bdbe8,9d55ee33b7f9..000000000000
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@@ -378,7 -378,13 +378,14 @@@ static inline int ip6_forward_finish(st
  	__IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTFORWDATAGRAMS);
  	__IP6_ADD_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTOCTETS, skb->len);
  
+ #ifdef CONFIG_NET_SWITCHDEV
+ 	if (skb->offload_l3_fwd_mark) {
+ 		consume_skb(skb);
+ 		return 0;
+ 	}
+ #endif
+ 
 +	skb->tstamp = 0;
  	return dst_output(net, sk, skb);
  }
  

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-17  0:25 Stephen Rothwell
  2018-12-17 21:20 ` Saeed Mahameed
  0 siblings, 1 reply; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-17  0:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Or Gerlitz,
	Saeed Mahameed, Eli Britstein

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

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:

  154e62abe9cd ("net/mlx5e: Properly initialize flow attributes for slow path eswitch rule deletion")

from the net tree and commit:

  e88afe759a49 ("net/mlx5e: Err if asked to mirror a goto chain tc eswitch rule")
  e85e02bad29e ("net/mlx5: E-Switch, Rename esw attr mirror count field")

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 9dabe9d4b279,53ebb5a48018..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -870,9 -903,9 +903,9 @@@ mlx5e_tc_offload_to_slow_path(struct ml
  	struct mlx5_flow_handle *rule;
  
  	memcpy(slow_attr, flow->esw_attr, sizeof(*slow_attr));
 -	slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST,
 -	slow_attr->split_count = 0,
 -	slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN,
 +	slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
- 	slow_attr->mirror_count = 0;
++	slow_attr->split_count = 0;
 +	slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN;
  
  	rule = mlx5e_tc_offload_fdb_rules(esw, flow, spec, slow_attr);
  	if (!IS_ERR(rule))
@@@ -887,9 -920,6 +920,9 @@@ mlx5e_tc_unoffload_from_slow_path(struc
  				  struct mlx5_esw_flow_attr *slow_attr)
  {
  	memcpy(slow_attr, flow->esw_attr, sizeof(*slow_attr));
 +	slow_attr->action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
- 	slow_attr->mirror_count = 0;
++	slow_attr->split_count = 0;
 +	slow_attr->dest_chain = FDB_SLOW_PATH_CHAIN;
  	mlx5e_tc_unoffload_fdb_rules(esw, flow, slow_attr);
  	flow->flags &= ~MLX5E_TC_FLOW_SLOW;
  }
@@@ -909,11 -939,13 +942,12 @@@ mlx5e_tc_add_fdb_flow(struct mlx5e_pri
  	struct mlx5e_rep_priv *rpriv;
  	struct mlx5e_priv *out_priv;
  	int err = 0, encap_err = 0;
+ 	int out_index;
  
 -	/* if prios are not supported, keep the old behaviour of using same prio
 -	 * for all offloaded rules.
 -	 */
 -	if (!mlx5_eswitch_prios_supported(esw))
 -		attr->prio = 1;
 +	if (!mlx5_eswitch_prios_supported(esw) && attr->prio != 1) {
 +		NL_SET_ERR_MSG(extack, "E-switch priorities unsupported, upgrade FW");
 +		return -EOPNOTSUPP;
 +	}
  
  	if (attr->chain > max_chain) {
  		NL_SET_ERR_MSG(extack, "Requested chain is out of supported range");
@@@ -2980,15 -2667,7 +2667,15 @@@ static int parse_tc_fdb_actions(struct 
  	if (!actions_match_supported(priv, exts, parse_attr, flow, extack))
  		return -EOPNOTSUPP;
  
 +	if (attr->dest_chain) {
 +		if (attr->action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) {
 +			NL_SET_ERR_MSG(extack, "Mirroring goto chain rules isn't supported");
 +			return -EOPNOTSUPP;
 +		}
 +		attr->action |= MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
 +	}
 +
- 	if (attr->mirror_count > 0 && !mlx5_esw_has_fwd_fdb(priv->mdev)) {
+ 	if (attr->split_count > 0 && !mlx5_esw_has_fwd_fdb(priv->mdev)) {
  		NL_SET_ERR_MSG_MOD(extack,
  				   "current firmware doesn't support split rule for port mirroring");
  		netdev_warn_once(priv->netdev, "current firmware doesn't support split rule for port mirroring\n");

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

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

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-17  0:13 Stephen Rothwell
  0 siblings, 0 replies; 375+ messages in thread
From: Stephen Rothwell @ 2018-12-17  0:13 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Atul Gupta,
	Santosh Rastapur, Ganesh Goudar

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

Hi all,

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

  drivers/crypto/chelsio/chtls/chtls_cm.c

between commit:

  0c3a16be700e ("crypto/chelsio/chtls: send/recv window update")

from the net tree and commit:

  02d805dc5fe3 ("cxgb4: use new fw interface to get the VIN and smt index")

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/crypto/chelsio/chtls/chtls_cm.c
index 931b96c220af,228b91b7d6b5..000000000000
--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
@@@ -1079,11 -1074,10 +1079,10 @@@ static struct sock *chtls_recv_sock(str
  	csk->txq_idx = (rxq_idx < cdev->lldi->ntxq) ? rxq_idx :
  			port_id * step;
  	csk->sndbuf = newsk->sk_sndbuf;
- 	csk->smac_idx = cxgb4_tp_smt_idx(cdev->lldi->adapter_type,
- 					 cxgb4_port_viid(ndev));
+ 	csk->smac_idx = ((struct port_info *)netdev_priv(ndev))->smt_idx;
 -	tp->rcv_wnd = select_rcv_wnd(csk);
  	RCV_WSCALE(tp) = select_rcv_wscale(tcp_full_space(newsk),
 -					   WSCALE_OK(tp),
 +					   sock_net(newsk)->
 +						ipv4.sysctl_tcp_window_scaling,
  					   tp->window_clamp);
  	neigh_release(n);
  	inet_inherit_port(&tcp_hashinfo, lsk, newsk);

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

^ permalink raw reply	[flat|nested] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ messages in thread

* linux-next: manual merge of the net-next tree with the net tree
@ 2018-12-07  1:39 Stephen Rothwell
  0 siblings, 0 replies; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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] 375+ 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; 375+ 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: We