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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
packets") from the net-next tree.

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

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

diff --cc net/mac802154/mac802154.h
index 703c121,5c9e021..0000000
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@@ -88,9 -88,7 +88,7 @@@ struct mac802154_sub_if_data 
  
  #define mac802154_to_priv(_hw)	container_of(_hw, struct mac802154_priv, hw)
  
- #define MAC802154_MAX_XMIT_ATTEMPTS	3
- 
 -#define MAC802154_CHAN_NONE		(~(u8)0) /* No channel is assigned */
 +#define MAC802154_CHAN_NONE		0xff /* No channel is assigned */
  
  extern struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced;
  extern struct ieee802154_mlme_ops mac802154_mlme_wpan;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 30 Apr 2013 12:24:23 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
> comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
> tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
> packets") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This should be taken care of as well, thanks Stephen.

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

[Chen Gang]

On 2013年04月30日 10:24, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> net/mac802154/mac802154.h between commit 2c1bbbffa0b6 ("net: mac802154:
> comparision issue of type cast, finding by EXTRA_CFLAGS=-W") from the net
> tree and commit 7dd43d356e73 ("mac802154: Do not try to resend failed
> packets") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks

-- 
Chen Gang

Asianux Corporation

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

[Matthieu Baerts]

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

Hi Stephen,

On 21/08/2023 03:06, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   include/net/inet_sock.h
> 
> between commit:
> 
>   f866fbc842de ("ipv4: fix data-races around inet->inet_id")
> 
> from the net tree and commit:
> 
>   c274af224269 ("inet: introduce inet->inet_flags")
> 
> from the net-next tree.

Thank you for this conflict resolution!

I had the same issue on our side with MPTCP tree when syncing -net and
net-next and I resolved it a bit differently. Here my comment on the
patch you used:

> diff --cc include/net/inet_sock.h
> index 491ceb7ebe5d,acbb93d7607a..000000000000
> --- a/include/net/inet_sock.h
> +++ b/include/net/inet_sock.h
> @@@ -218,12 -218,12 +218,12 @@@ struct inet_sock 
>   #define inet_dport		sk.__sk_common.skc_dport
>   #define inet_num		sk.__sk_common.skc_num
>   
> + 	unsigned long		inet_flags;
>   	__be32			inet_saddr;
>   	__s16			uc_ttl;
> - 	__u16			cmsg_flags;
> - 	struct ip_options_rcu __rcu	*inet_opt;
> - 	atomic_t		inet_id;
>   	__be16			inet_sport;
> ++	atomic_t		inet_id;
> + 	struct ip_options_rcu __rcu	*inet_opt;

I first put "inet_opt", then "inet_id" here to avoid a hole of 4 bytes.
So just switching these two lines.

Here is the output of pahole when using your patch:

> struct inet_sock {
>         struct sock                sk __attribute__((__aligned__(8))); /*     0   768 */
>         /* --- cacheline 12 boundary (768 bytes) --- */
>         struct ipv6_pinfo *        pinet6;               /*   768     8 */
>         long unsigned int          inet_flags;           /*   776     8 */
>         __be32                     inet_saddr;           /*   784     4 */
>         __s16                      uc_ttl;               /*   788     2 */
>         __be16                     inet_sport;           /*   790     2 */
>         atomic_t                   inet_id;              /*   792     4 */
> 
>         /* XXX 4 bytes hole, try to pack */
> 
>         struct ip_options_rcu *    inet_opt;             /*   800     8 */
>         __u8                       tos;                  /*   808     1 */
>         __u8                       min_ttl;              /*   809     1 */
>         __u8                       mc_ttl;               /*   810     1 */
>         __u8                       pmtudisc;             /*   811     1 */
>         __u8                       rcv_tos;              /*   812     1 */
>         __u8                       convert_csum;         /*   813     1 */
> 
>         /* XXX 2 bytes hole, try to pack */
> 
>         int                        uc_index;             /*   816     4 */
>         int                        mc_index;             /*   820     4 */
>         __be32                     mc_addr;              /*   824     4 */

And now when "inet_id" is placed after "inet_opt":

> struct inet_sock {
>         struct sock                sk __attribute__((__aligned__(8))); /*     0   768 */
>         /* --- cacheline 12 boundary (768 bytes) --- */
>         struct ipv6_pinfo *        pinet6;               /*   768     8 */
>         long unsigned int          inet_flags;           /*   776     8 */
>         __be32                     inet_saddr;           /*   784     4 */
>         __s16                      uc_ttl;               /*   788     2 */
>         __be16                     inet_sport;           /*   790     2 */
>         struct ip_options_rcu *    inet_opt;             /*   792     8 */
>         atomic_t                   inet_id;              /*   800     4 */
>         __u8                       tos;                  /*   804     1 */
>         __u8                       min_ttl;              /*   805     1 */
>         __u8                       mc_ttl;               /*   806     1 */
>         __u8                       pmtudisc;             /*   807     1 */
>         __u8                       rcv_tos;              /*   808     1 */
>         __u8                       convert_csum;         /*   809     1 */
> 
>         /* XXX 2 bytes hole, try to pack */
> 
>         int                        uc_index;             /*   812     4 */
>         int                        mc_index;             /*   816     4 */
>         __be32                     mc_addr;              /*   820     4 */

I noticed that in Eric's patch for the net tree -- f866fbc842de ("ipv4:
fix data-races around inet->inet_id") -- he moved "inet_id" above, I
guess for a similar reason.

Just in case you are interested by taking my version, I attached the
patch I used and the Rerere cache is available there:

https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/e63f34f8

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

[-- Attachment #2: 47fe53ec8c3d4381989f0541eb0a0abd31b8cbee.patch --]
[-- Type: text/x-patch, Size: 548 bytes --]

diff --cc include/net/inet_sock.h
index acbb93d7607a,491ceb7ebe5d..2de0e4d4a027
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@@ -218,12 -218,12 +218,12 @@@ struct inet_sock 
  #define inet_dport		sk.__sk_common.skc_dport
  #define inet_num		sk.__sk_common.skc_num
  
 +	unsigned long		inet_flags;
  	__be32			inet_saddr;
  	__s16			uc_ttl;
 -	__u16			cmsg_flags;
 +	__be16			inet_sport;
  	struct ip_options_rcu __rcu	*inet_opt;
- 	__u16			inet_id;
+ 	atomic_t		inet_id;
 -	__be16			inet_sport;
  
  	__u8			tos;
  	__u8			min_ttl;

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

[Stephen Rothwell]

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

Hi all,

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

  include/net/inet_sock.h

between commit:

  f866fbc842de ("ipv4: fix data-races around inet->inet_id")

from the net tree and commit:

  c274af224269 ("inet: introduce inet->inet_flags")

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/inet_sock.h
index 491ceb7ebe5d,acbb93d7607a..000000000000
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@@ -218,12 -218,12 +218,12 @@@ struct inet_sock 
  #define inet_dport		sk.__sk_common.skc_dport
  #define inet_num		sk.__sk_common.skc_num
  
+ 	unsigned long		inet_flags;
  	__be32			inet_saddr;
  	__s16			uc_ttl;
- 	__u16			cmsg_flags;
- 	struct ip_options_rcu __rcu	*inet_opt;
- 	atomic_t		inet_id;
  	__be16			inet_sport;
++	atomic_t		inet_id;
+ 	struct ip_options_rcu __rcu	*inet_opt;
 -	__u16			inet_id;
  
  	__u8			tos;
  	__u8			min_ttl;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/sfc/tc.c

between commit:

  fa165e194997 ("sfc: don't unregister flow_indr if it was never registered")

from the net tree and commit:

  3bf969e88ada ("sfc: add MAE table machinery for conntrack 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/ethernet/sfc/tc.c
index fe268b6c1cac,246657222958..000000000000
--- a/drivers/net/ethernet/sfc/tc.c
+++ b/drivers/net/ethernet/sfc/tc.c
@@@ -1657,11 -2087,17 +2087,17 @@@ int efx_init_tc(struct efx_nic *efx
  	rc = efx_tc_configure_fallback_acts_reps(efx);
  	if (rc)
  		return rc;
- 	rc = flow_indr_dev_register(efx_tc_indr_setup_cb, efx);
+ 	rc = efx_mae_get_tables(efx);
  	if (rc)
  		return rc;
 -	efx->tc->up = true;
+ 	rc = flow_indr_dev_register(efx_tc_indr_setup_cb, efx);
+ 	if (rc)
+ 		goto out_free;
 +	efx->tc->up = true;
  	return 0;
+ out_free:
+ 	efx_mae_free_tables(efx);
+ 	return rc;
  }
  
  void efx_fini_tc(struct efx_nic *efx)

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/broadcom/bnxt/bnxt.c

between commit:

  37b61cda9c16 ("bnxt: don't handle XDP in netpoll")

from the net tree and commit:

  2b56b3d99241 ("eth: bnxt: handle invalid Tx completions more gracefully")

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

idiff --cc drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 06b238bef9dd,a3bbd13c070f..000000000000
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@@ -686,10 -744,9 +745,10 @@@ static void bnxt_tx_int(struct bnxt *bp
  next_tx_int:
  		cons = NEXT_TX(cons);
  
- 		dev_kfree_skb_any(skb);
+ 		dev_consume_skb_any(skb);
  	}
  
 +	bnapi->tx_pkts = 0;
  	WRITE_ONCE(txr->tx_cons, cons);
  
  	__netif_txq_completed_wake(txq, nr_pkts, tx_bytes,
@@@ -2571,11 -2595,12 +2597,11 @@@ static int __bnxt_poll_work(struct bnx
  	return rx_pkts;
  }
  
 -static void __bnxt_poll_work_done(struct bnxt *bp, struct bnxt_napi *bnapi)
 +static void __bnxt_poll_work_done(struct bnxt *bp, struct bnxt_napi *bnapi,
 +				  int budget)
  {
- 	if (bnapi->tx_pkts)
 -	if (bnapi->tx_pkts && !bnapi->tx_fault) {
 -		bnapi->tx_int(bp, bnapi, bnapi->tx_pkts);
 -		bnapi->tx_pkts = 0;
 -	}
++	if (bnapi->tx_pkts && !bnapi->tx_fault)
 +		bnapi->tx_int(bp, bnapi, budget);
  
  	if ((bnapi->events & BNXT_RX_EVENT) && !(bnapi->in_reset)) {
  		struct bnxt_rx_ring_info *rxr = bnapi->rx_ring;

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

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

[Russell King (Oracle)]

On Mon, Jul 31, 2023 at 10:22:54AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/dsa/port.c
> 
> between commit:
> 
>   9945c1fb03a3 ("net: dsa: fix older DSA drivers using phylink")
> 
> from the net tree and commit:
> 
>   a88dd7538461 ("net: dsa: remove legacy_pre_march2020 detection")
> 
> 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/port.c
> index 2f6195d7b741,c63cbfbe6489..000000000000
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@@ -1720,22 -1686,8 +1686,15 @@@ int dsa_port_phylink_create(struct dsa_
>   	if (err)
>   		mode = PHY_INTERFACE_MODE_NA;
>   
> - 	/* Presence of phylink_mac_link_state or phylink_mac_an_restart is
> - 	 * an indicator of a legacy phylink driver.
> - 	 */
> - 	if (ds->ops->phylink_mac_link_state ||
> - 	    ds->ops->phylink_mac_an_restart)
> - 		dp->pl_config.legacy_pre_march2020 = true;
> - 
>  -	if (ds->ops->phylink_get_caps)
>  +	if (ds->ops->phylink_get_caps) {
>   		ds->ops->phylink_get_caps(ds, dp->index, &dp->pl_config);
>  +	} else {
>  +		/* For legacy drivers */
>  +		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
>  +			  dp->pl_config.supported_interfaces);
>  +		__set_bit(PHY_INTERFACE_MODE_GMII,
>  +			  dp->pl_config.supported_interfaces);
>  +	}
>   
>   	pl = phylink_create(&dp->pl_config, of_fwnode_handle(dp->dn),
>   			    mode, &dsa_port_phylink_mac_ops);

LGTM, thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Stephen Rothwell]

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

Hi all,

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

  net/xdp/xsk.c

between commit:

  3c5b4d69c358 ("net: annotate data-races around sk->sk_mark")

from the net tree and commit:

  b7f72a30e9ac ("xsk: introduce wrappers and helpers for supporting multi-buffer in Tx 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/xdp/xsk.c
index b89adb52a977,4f1e0599146e..000000000000
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@@ -505,11 -682,22 +682,22 @@@ static struct sk_buff *xsk_build_skb(st
  
  	skb->dev = dev;
  	skb->priority = xs->sk.sk_priority;
 -	skb->mark = xs->sk.sk_mark;
 +	skb->mark = READ_ONCE(xs->sk.sk_mark);
- 	skb_shinfo(skb)->destructor_arg = (void *)(long)desc->addr;
  	skb->destructor = xsk_destruct_skb;
+ 	xsk_set_destructor_arg(skb);
  
  	return skb;
+ 
+ free_err:
+ 	if (err == -EAGAIN) {
+ 		xsk_cq_cancel_locked(xs, 1);
+ 	} else {
+ 		xsk_set_destructor_arg(skb);
+ 		xsk_drop_skb(skb);
+ 		xskq_cons_release(xs->tx);
+ 	}
+ 
+ 	return ERR_PTR(err);
  }
  
  static int __xsk_generic_xmit(struct sock *sk)

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/dsa/port.c

between commit:

  9945c1fb03a3 ("net: dsa: fix older DSA drivers using phylink")

from the net tree and commit:

  a88dd7538461 ("net: dsa: remove legacy_pre_march2020 detection")

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/port.c
index 2f6195d7b741,c63cbfbe6489..000000000000
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@@ -1720,22 -1686,8 +1686,15 @@@ int dsa_port_phylink_create(struct dsa_
  	if (err)
  		mode = PHY_INTERFACE_MODE_NA;
  
- 	/* Presence of phylink_mac_link_state or phylink_mac_an_restart is
- 	 * an indicator of a legacy phylink driver.
- 	 */
- 	if (ds->ops->phylink_mac_link_state ||
- 	    ds->ops->phylink_mac_an_restart)
- 		dp->pl_config.legacy_pre_march2020 = true;
- 
 -	if (ds->ops->phylink_get_caps)
 +	if (ds->ops->phylink_get_caps) {
  		ds->ops->phylink_get_caps(ds, dp->index, &dp->pl_config);
 +	} else {
 +		/* For legacy drivers */
 +		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 +			  dp->pl_config.supported_interfaces);
 +		__set_bit(PHY_INTERFACE_MODE_GMII,
 +			  dp->pl_config.supported_interfaces);
 +	}
  
  	pl = phylink_create(&dp->pl_config, of_fwnode_handle(dp->dn),
  			    mode, &dsa_port_phylink_mac_ops);

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/fcnal-test.sh

between commit:

  d7a2fc1437f7 ("selftests: net: fcnal-test: check if FIPS mode is enabled")

from the net tree and commit:

  dd017c72dde6 ("selftests: fcnal: Test SO_DONTROUTE on TCP sockets.")

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/fcnal-test.sh
index ee6880ac3e5e,05b5c4af7a08..000000000000
--- a/tools/testing/selftests/net/fcnal-test.sh
+++ b/tools/testing/selftests/net/fcnal-test.sh
@@@ -1223,7 -1283,10 +1290,10 @@@ ipv4_tcp_novrf(
  	run_cmd nettest -d ${NSA_DEV} -r ${a}
  	log_test_addr ${a} $? 1 "No server, device client, local conn"
  
 -	ipv4_tcp_md5_novrf
 +	[ "$fips_enabled" = "1" ] || ipv4_tcp_md5_novrf
+ 
+ 	ipv4_tcp_dontroute 0
+ 	ipv4_tcp_dontroute 2
  }
  
  ipv4_tcp_vrf()

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

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

[Matthieu Baerts]

Hi Jakub,

On 14/06/2023 19:41, Jakub Kicinski wrote:
> On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts wrote:
>> I added a note about the conflicts on the cover-letter:
>>
>> https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/
>>
>> Maybe it was not a good place? I didn't know where to put it as there
>> were multiple patches that were conflicting with each others even if the
>> major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip
>> check if MIB counter not supported") and 0639fa230a21 ("selftests:
>> mptcp: add explicit check for new mibs"). I guess next time I should add
>> a comment referring to the cover-letter in the patches creating conflicts.
> 
> Hm, yeah, I think the cover letter may not be the best way.
> Looks like Stephen didn't use it, anyway, and it confused patchwork.
> No better idea where to put it tho :(
> 
> Maybe a link to a git rerere resolution uploaded somewhere we can wget
> from easily?

Good idea, I didn't think about git rerere! I will try to remember about
that next time :)

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

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

[Jakub Kicinski]

On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts wrote:
> I added a note about the conflicts on the cover-letter:
> 
> https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/
> 
> Maybe it was not a good place? I didn't know where to put it as there
> were multiple patches that were conflicting with each others even if the
> major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip
> check if MIB counter not supported") and 0639fa230a21 ("selftests:
> mptcp: add explicit check for new mibs"). I guess next time I should add
> a comment referring to the cover-letter in the patches creating conflicts.

Hm, yeah, I think the cover letter may not be the best way.
Looks like Stephen didn't use it, anyway, and it confused patchwork.
No better idea where to put it tho :(

Maybe a link to a git rerere resolution uploaded somewhere we can wget
from easily?

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

[Stephen Rothwell]

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

Hi Matthieu,

On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts <matthieu.baerts@tessares.net> wrote:
>
> Thank you for the conflicts resolution. If I'm not mistaken, it looks
> good except the last chunk where the new call to chk_rm_tx_nr() should
> go inside the 'if' statement. So instead of this bit you have on your side:

Thanks for checking this.  I will amend my resolution in linux-next
from tomorrow.

-- 
Cheers,
Stephen Rothwell

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

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

[Matthieu Baerts]

Hi Stephen,

On 14/06/2023 03:17, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/net/mptcp/mptcp_join.sh
> 
> between commits:
> 
>   47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported")
>   425ba803124b ("selftests: mptcp: join: support RM_ADDR for used endpoints or not")
> 
> from the net tree and commits:
> 
>   45b1a1227a7a ("mptcp: introduces more address related mibs")
>   0639fa230a21 ("selftests: mptcp: add explicit check for new mibs")
> 
> 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.

Thank you for the conflicts resolution. If I'm not mistaken, it looks
good except the last chunk where the new call to chk_rm_tx_nr() should
go inside the 'if' statement. So instead of this bit you have on your side:

> @@@ -2394,12 -2290,8 +2399,13 @@@ remove_tests(
>   		pm_nl_add_endpoint $ns2 10.0.4.2 flags subflow
>   		run_tests $ns1 $ns2 10.0.1.1 0 -8 -8 slow
>   		chk_join_nr 3 3 3
> + 		chk_rm_tx_nr 0
>  -		chk_rm_nr 0 3 simult
>  +
>  +		if mptcp_lib_kversion_ge 5.18; then
>  +			chk_rm_nr 0 3 simult
>  +		else
>  +			chk_rm_nr 3 3
>  +		fi
>   	fi
>   
>   	# addresses flush

We should have:

> @@@ -2394,12 -2290,8 +2399,13 @@@ remove_tests(
>   		pm_nl_add_endpoint $ns2 10.0.4.2 flags subflow
>   		run_tests $ns1 $ns2 10.0.1.1 0 -8 -8 slow
>   		chk_join_nr 3 3 3
>  -		chk_rm_tx_nr 0
>  -		chk_rm_nr 0 3 simult
>  +
>  +		if mptcp_lib_kversion_ge 5.18; then
> ++			chk_rm_tx_nr 0
>  +			chk_rm_nr 0 3 simult
>  +		else
>  +			chk_rm_nr 3 3
>  +		fi
>   	fi
>   
>   	# addresses flush

("chk_rm_tx_nr 0" needs to be inside the 'if')


I added a note about the conflicts on the cover-letter:


https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/

Maybe it was not a good place? I didn't know where to put it as there
were multiple patches that were conflicting with each others even if the
major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip
check if MIB counter not supported") and 0639fa230a21 ("selftests:
mptcp: add explicit check for new mibs"). I guess next time I should add
a comment referring to the cover-letter in the patches creating conflicts.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/mptcp/mptcp_join.sh

between commits:

  47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported")
  425ba803124b ("selftests: mptcp: join: support RM_ADDR for used endpoints or not")

from the net tree and commits:

  45b1a1227a7a ("mptcp: introduces more address related mibs")
  0639fa230a21 ("selftests: mptcp: add explicit check for new mibs")

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 tools/testing/selftests/net/mptcp/mptcp_join.sh
index 0ae8cafde439,85474e029784..000000000000
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@@ -1360,27 -1265,23 +1355,25 @@@ chk_fclose_nr(
  	fi
  
  	printf "%-${nr_blank}s %s" " " "ctx"
 -	count=$(ip netns exec $ns_tx nstat -as | grep MPTcpExtMPFastcloseTx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	[ "$count" != "$fclose_tx" ] && extra_msg="$extra_msg,tx=$count"
 -	if [ "$count" != "$fclose_tx" ]; then
 +	count=$(get_counter ${ns_tx} "MPTcpExtMPFastcloseTx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$fclose_tx" ]; then
 +		extra_msg="$extra_msg,tx=$count"
  		echo "[fail] got $count MP_FASTCLOSE[s] TX expected $fclose_tx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	echo -n " - fclzrx"
 -	count=$(ip netns exec $ns_rx nstat -as | grep MPTcpExtMPFastcloseRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	[ "$count" != "$fclose_rx" ] && extra_msg="$extra_msg,rx=$count"
 -	if [ "$count" != "$fclose_rx" ]; then
 +	count=$(get_counter ${ns_rx} "MPTcpExtMPFastcloseRx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$fclose_rx" ]; then
 +		extra_msg="$extra_msg,rx=$count"
  		echo "[fail] got $count MP_FASTCLOSE[s] RX expected $fclose_rx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
@@@ -1408,25 -1306,21 +1398,23 @@@ chk_rst_nr(
  	fi
  
  	printf "%-${nr_blank}s %s" " " "rtx"
 -	count=$(ip netns exec $ns_tx nstat -as | grep MPTcpExtMPRstTx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ $count -lt $rst_tx ]; then
 +	count=$(get_counter ${ns_tx} "MPTcpExtMPRstTx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ $count -lt $rst_tx ]; then
  		echo "[fail] got $count MP_RST[s] TX expected $rst_tx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	echo -n " - rstrx "
 -	count=$(ip netns exec $ns_rx nstat -as | grep MPTcpExtMPRstRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" -lt "$rst_rx" ]; then
 +	count=$(get_counter ${ns_rx} "MPTcpExtMPRstRx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" -lt "$rst_rx" ]; then
  		echo "[fail] got $count MP_RST[s] RX expected $rst_rx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
@@@ -1441,28 -1333,23 +1427,25 @@@ chk_infi_nr(
  	local infi_tx=$1
  	local infi_rx=$2
  	local count
- 	local dump_stats
  
  	printf "%-${nr_blank}s %s" " " "itx"
 -	count=$(ip netns exec $ns2 nstat -as | grep InfiniteMapTx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$infi_tx" ]; then
 +	count=$(get_counter ${ns2} "MPTcpExtInfiniteMapTx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$infi_tx" ]; then
  		echo "[fail] got $count infinite map[s] TX expected $infi_tx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	echo -n " - infirx"
 -	count=$(ip netns exec $ns1 nstat -as | grep InfiniteMapRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$infi_rx" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtInfiniteMapRx")
 +	if [ -z "$count" ]; then
 +		echo "[skip]"
 +	elif [ "$count" != "$infi_rx" ]; then
  		echo "[fail] got $count infinite map[s] RX expected $infi_rx"
  		fail_test
- 		dump_stats=1
  	else
  		echo "[ ok ]"
  	fi
@@@ -1491,13 -1375,11 +1471,12 @@@ chk_join_nr(
  	fi
  
  	printf "%03u %-36s %s" "${TEST_COUNT}" "${title}" "syn"
 -	count=$(ip netns exec $ns1 nstat -as | grep MPTcpExtMPJoinSynRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$syn_nr" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtMPJoinSynRx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$syn_nr" ]; then
  		echo "[fail] got $count JOIN[s] syn expected $syn_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
@@@ -1523,13 -1403,11 +1501,12 @@@
  	fi
  
  	echo -n " - ack"
 -	count=$(ip netns exec $ns1 nstat -as | grep MPTcpExtMPJoinAckRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$ack_nr" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtMPJoinAckRx")
 +	if [ -z "$count" ]; then
 +		echo "[skip]"
 +	elif [ "$count" != "$ack_nr" ]; then
  		echo "[fail] got $count JOIN[s] ack expected $ack_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo "[ ok ]"
  	fi
@@@ -1599,40 -1475,35 +1574,37 @@@ chk_add_nr(
  	timeout=$(ip netns exec $ns1 sysctl -n net.mptcp.add_addr_timeout)
  
  	printf "%-${nr_blank}s %s" " " "add"
 -	count=$(ip netns exec $ns2 nstat -as MPTcpExtAddAddr | grep MPTcpExtAddAddr | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -
 +	count=$(get_counter ${ns2} "MPTcpExtAddAddr")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
  	# if the test configured a short timeout tolerate greater then expected
  	# add addrs options, due to retransmissions
 -	if [ "$count" != "$add_nr" ] && { [ "$timeout" -gt 1 ] || [ "$count" -lt "$add_nr" ]; }; then
 +	elif [ "$count" != "$add_nr" ] && { [ "$timeout" -gt 1 ] || [ "$count" -lt "$add_nr" ]; }; then
  		echo "[fail] got $count ADD_ADDR[s] expected $add_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	echo -n " - echo  "
 -	count=$(ip netns exec $ns1 nstat -as MPTcpExtEchoAdd | grep MPTcpExtEchoAdd | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$echo_nr" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtEchoAdd")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$echo_nr" ]; then
  		echo "[fail] got $count ADD_ADDR echo[s] expected $echo_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	if [ $port_nr -gt 0 ]; then
  		echo -n " - pt "
 -		count=$(ip netns exec $ns2 nstat -as | grep MPTcpExtPortAdd | awk '{print $2}')
 -		[ -z "$count" ] && count=0
 -		if [ "$count" != "$port_nr" ]; then
 +		count=$(get_counter ${ns2} "MPTcpExtPortAdd")
 +		if [ -z "$count" ]; then
 +			echo "[skip]"
 +		elif [ "$count" != "$port_nr" ]; then
  			echo "[fail] got $count ADD_ADDR[s] with a port-number expected $port_nr"
  			fail_test
- 			dump_stats=1
  		else
  			echo "[ ok ]"
  		fi
@@@ -1737,13 -1633,11 +1734,12 @@@ chk_rm_nr(
  	fi
  
  	printf "%-${nr_blank}s %s" " " "rm "
 -	count=$(ip netns exec $addr_ns nstat -as MPTcpExtRmAddr | grep MPTcpExtRmAddr | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$rm_addr_nr" ]; then
 +	count=$(get_counter ${addr_ns} "MPTcpExtRmAddr")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$rm_addr_nr" ]; then
  		echo "[fail] got $count RM_ADDR[s] expected $rm_addr_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
@@@ -1767,12 -1661,12 +1763,10 @@@
  		else
  			echo "[fail] got $count RM_SUBFLOW[s] expected in range [$rm_subflow_nr:$((rm_subflow_nr*2))]"
  			fail_test
- 			dump_stats=1
  		fi
 -		return
 -	fi
 -	if [ "$count" != "$rm_subflow_nr" ]; then
 +	elif [ "$count" != "$rm_subflow_nr" ]; then
  		echo "[fail] got $count RM_SUBFLOW[s] expected $rm_subflow_nr"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
@@@ -1787,28 -1696,23 +1796,25 @@@ chk_prio_nr(
  	local mp_prio_nr_tx=$1
  	local mp_prio_nr_rx=$2
  	local count
- 	local dump_stats
  
  	printf "%-${nr_blank}s %s" " " "ptx"
 -	count=$(ip netns exec $ns1 nstat -as | grep MPTcpExtMPPrioTx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$mp_prio_nr_tx" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtMPPrioTx")
 +	if [ -z "$count" ]; then
 +		echo -n "[skip]"
 +	elif [ "$count" != "$mp_prio_nr_tx" ]; then
  		echo "[fail] got $count MP_PRIO[s] TX expected $mp_prio_nr_tx"
  		fail_test
- 		dump_stats=1
  	else
  		echo -n "[ ok ]"
  	fi
  
  	echo -n " - prx   "
 -	count=$(ip netns exec $ns1 nstat -as | grep MPTcpExtMPPrioRx | awk '{print $2}')
 -	[ -z "$count" ] && count=0
 -	if [ "$count" != "$mp_prio_nr_rx" ]; then
 +	count=$(get_counter ${ns1} "MPTcpExtMPPrioRx")
 +	if [ -z "$count" ]; then
 +		echo "[skip]"
 +	elif [ "$count" != "$mp_prio_nr_rx" ]; then
  		echo "[fail] got $count MP_PRIO[s] RX expected $mp_prio_nr_rx"
  		fail_test
- 		dump_stats=1
  	else
  		echo "[ ok ]"
  	fi
@@@ -2394,12 -2290,8 +2399,13 @@@ remove_tests(
  		pm_nl_add_endpoint $ns2 10.0.4.2 flags subflow
  		run_tests $ns1 $ns2 10.0.1.1 0 -8 -8 slow
  		chk_join_nr 3 3 3
+ 		chk_rm_tx_nr 0
 -		chk_rm_nr 0 3 simult
 +
 +		if mptcp_lib_kversion_ge 5.18; then
 +			chk_rm_nr 0 3 simult
 +		else
 +			chk_rm_nr 3 3
 +		fi
  	fi
  
  	# addresses flush

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/sched/sch_taprio.c

between commit:

  d636fc5dd692 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping")

from the net tree and commit:

  dced11ef84fb ("net/sched: taprio: don't overwrite "sch" variable in taprio_dump_class_stats()")

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/sch_taprio.c
index dd7dea2f6e83,3c4c2c334878..000000000000
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@@ -2388,12 -2456,19 +2456,19 @@@ static int taprio_dump_class_stats(stru
  	__acquires(d->lock)
  {
  	struct netdev_queue *dev_queue = taprio_queue_get(sch, cl);
 -	struct Qdisc *child = dev_queue->qdisc_sleeping;
++	struct Qdisc *child = rtnl_dereference(dev_queue->qdisc_sleeping);
+ 	struct tc_taprio_qopt_offload offload = {
+ 		.cmd = TAPRIO_CMD_TC_STATS,
+ 		.tc_stats = {
+ 			.tc = cl - 1,
+ 		},
+ 	};
  
- 	sch = rtnl_dereference(dev_queue->qdisc_sleeping);
- 	if (gnet_stats_copy_basic(d, NULL, &sch->bstats, true) < 0 ||
- 	    qdisc_qstats_copy(d, sch) < 0)
+ 	if (gnet_stats_copy_basic(d, NULL, &child->bstats, true) < 0 ||
+ 	    qdisc_qstats_copy(d, child) < 0)
  		return -1;
- 	return 0;
+ 
+ 	return taprio_dump_xstats(sch, d, &offload, &offload.tc_stats.stats);
  }
  
  static void taprio_walk(struct Qdisc *sch, struct qdisc_walker *arg)

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

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

[Stephen Rothwell]

[-- 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/ipv4/sysctl_net_ipv4.c

between commit:

  e209fee4118f ("net/ipv4: ping_group_range: allow GID from 2147483648 to 4294967294")

from the net tree and commit:

  ccce324dabfe ("tcp: make the first N SYN RTO backoffs linear")

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/sysctl_net_ipv4.c
index 88dfe51e68f3,6ae3345a3bdf..000000000000
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@@ -34,8 -34,9 +34,9 @@@ static int ip_ttl_min = 1
  static int ip_ttl_max = 255;
  static int tcp_syn_retries_min = 1;
  static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
+ static int tcp_syn_linear_timeouts_max = MAX_TCP_SYNCNT;
 -static int ip_ping_group_range_min[] = { 0, 0 };
 -static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
 +static unsigned long ip_ping_group_range_min[] = { 0, 0 };
 +static unsigned long ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
  static u32 u32_max_div_HZ = UINT_MAX / HZ;
  static int one_day_secs = 24 * 3600;
  static u32 fib_multipath_hash_fields_all_mask __maybe_unused =

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

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

[Guillaume Nault]

On Thu, May 25, 2023 at 11:00:37AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv4/raw.c
> 
> between commit:
> 
>   3632679d9e4f ("ipv{4,6}/raw: fix output xfrm lookup wrt protocol")
> 
> from the net tree and commit:
> 
>   c85be08fc4fa ("raw: Stop using RTO_ONLINK.")
> 
> 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/raw.c
> index eadf1c9ef7e4,8b7b5c842bdd..000000000000
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@@ -600,9 -596,8 +599,8 @@@ static int raw_sendmsg(struct sock *sk
>   		}
>   	}
>   
> - 	flowi4_init_output(&fl4, ipc.oif, ipc.sockc.mark, tos,
> - 			   RT_SCOPE_UNIVERSE,
> + 	flowi4_init_output(&fl4, ipc.oif, ipc.sockc.mark, tos, scope,
>  -			   hdrincl ? IPPROTO_RAW : sk->sk_protocol,
>  +			   hdrincl ? ipc.protocol : sk->sk_protocol,
>   			   inet_sk_flowi_flags(sk) |
>   			    (hdrincl ? FLOWI_FLAG_KNOWN_NH : 0),
>   			   daddr, saddr, 0, 0, sk->sk_uid);

Looks good. Thanks!

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

[Stephen Rothwell]

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

Hi all,

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

  net/ipv4/raw.c

between commit:

  3632679d9e4f ("ipv{4,6}/raw: fix output xfrm lookup wrt protocol")

from the net tree and commit:

  c85be08fc4fa ("raw: Stop using RTO_ONLINK.")

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/raw.c
index eadf1c9ef7e4,8b7b5c842bdd..000000000000
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@@ -600,9 -596,8 +599,8 @@@ static int raw_sendmsg(struct sock *sk
  		}
  	}
  
- 	flowi4_init_output(&fl4, ipc.oif, ipc.sockc.mark, tos,
- 			   RT_SCOPE_UNIVERSE,
+ 	flowi4_init_output(&fl4, ipc.oif, ipc.sockc.mark, tos, scope,
 -			   hdrincl ? IPPROTO_RAW : sk->sk_protocol,
 +			   hdrincl ? ipc.protocol : sk->sk_protocol,
  			   inet_sk_flowi_flags(sk) |
  			    (hdrincl ? FLOWI_FLAG_KNOWN_NH : 0),
  			   daddr, saddr, 0, 0, sk->sk_uid);

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/freescale/fec_main.c

between commit:

  6ead9c98cafc ("net: fec: remove the xdp_return_frame when lack of tx BDs")

from the net tree and commit:

  144470c88c5d ("net: fec: using the standard return codes when xdp xmit errors")

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/freescale/fec_main.c
index 577d94821b3e,cd215ab20ff9..000000000000
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@@ -3798,7 -3798,8 +3798,7 @@@ static int fec_enet_txq_xmit_frame(stru
  	entries_free = fec_enet_get_free_txdesc_num(txq);
  	if (entries_free < MAX_SKB_FRAGS + 1) {
  		netdev_err(fep->netdev, "NOT enough BD for SG!\n");
- 		return NETDEV_TX_BUSY;
 -		xdp_return_frame(frame);
+ 		return -EBUSY;
  	}
  
  	/* Fill in a Tx ring entry */

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

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

[Jakub Kicinski]

On Thu, 6 Apr 2023 10:49:27 +1000 Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/google/gve/gve.h
> 
> between commit:
> 
>   3ce934558097 ("gve: Secure enough bytes in the first TX desc for all TCP pkts")
> 
> from the net tree and commit:
> 
>   75eaae158b1b ("gve: Add XDP DROP and TX support for GQI-QPL format")
> 
> from the net-next tree.

I fixed the conflict in net-next but Praveen, Shailend - one of you
called the constant MIN and the other one MAX. So which one is it?
Please send a patch to net-next which removes one of them and uses
the other consistently, they seem to serve the same purpose.

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/google/gve/gve.h

between commit:

  3ce934558097 ("gve: Secure enough bytes in the first TX desc for all TCP pkts")

from the net tree and commit:

  75eaae158b1b ("gve: Add XDP DROP and TX support for GQI-QPL format")

from the net-next tree.

Matthieu, thanks for the head up.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for 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/google/gve/gve.h
index 005cb9dfe078,e214b51d3c8b..000000000000
--- a/drivers/net/ethernet/google/gve/gve.h
+++ b/drivers/net/ethernet/google/gve/gve.h
@@@ -47,8 -47,10 +47,12 @@@
  
  #define GVE_RX_BUFFER_SIZE_DQO 2048
  
 +#define GVE_GQ_TX_MIN_PKT_DESC_BYTES 182
 +
+ #define GVE_XDP_ACTIONS 5
+ 
+ #define GVE_TX_MAX_HEADER_SIZE 182
+ 
  /* Each slot in the desc ring has a 1:1 mapping to a slot in the data ring */
  struct gve_rx_desc_queue {
  	struct gve_rx_desc *desc_ring; /* the descriptor ring */

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

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

[Stephen Rothwell]

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

  6e9d51b1a5cb ("net/mlx5e: Initialize link speed to zero")

from the net tree and commit:

  1bffcea42926 ("net/mlx5e: Add devlink hairpin queues parameters")

from the net-next tree.

I fixed it up (I used the latter version of this file and added the
following 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: Fri, 24 Mar 2023 12:02:44 +1100
Subject: [PATCH] fix up for "net/mlx5e: Initialize link speed to zero"

interacting with "net/mlx5e: Add devlink hairpin queues parameters"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
index 1ee2a472e1d2..25d1a04ef443 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
@@ -529,8 +529,8 @@ static void mlx5_devlink_hairpin_params_init_values(struct devlink *devlink)
 {
 	struct mlx5_core_dev *dev = devlink_priv(devlink);
 	union devlink_param_value value;
+	u32 link_speed = 0;
 	u64 link_speed64;
-	u32 link_speed;
 
 	/* set hairpin pair per each 50Gbs share of the link */
 	mlx5_port_max_linkspeed(dev, &link_speed);
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/hsr/hsr_framereg.c

between commit:

  28e8cabe80f3 ("net: hsr: Don't log netdev_err message on unknown prp dst node")

from the net tree and commit:

  4821c186b9c3 ("net: hsr: Don't log netdev_err message on unknown prp dst node")

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/wireless/nl80211.c

between commit:

  b27f07c50a73 ("wifi: nl80211: fix puncturing bitmap policy")

from the net tree and commit:

  cbbaf2bb829b ("wifi: nl80211: add a command to enable/disable HW timestamping")

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 for the heads up.

-- 
Cheers,
Stephen Rothwell

diff --cc net/wireless/nl80211.c
index 4f63059efd81,0a31b1d2845d..000000000000
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -810,8 -805,10 +810,11 @@@ static const struct nla_policy nl80211_
  	[NL80211_ATTR_MLD_ADDR] = NLA_POLICY_EXACT_LEN(ETH_ALEN),
  	[NL80211_ATTR_MLO_SUPPORT] = { .type = NLA_FLAG },
  	[NL80211_ATTR_MAX_NUM_AKM_SUITES] = { .type = NLA_REJECT },
 -	[NL80211_ATTR_PUNCT_BITMAP] = NLA_POLICY_RANGE(NLA_U8, 0, 0xffff),
 +	[NL80211_ATTR_PUNCT_BITMAP] =
 +		NLA_POLICY_FULL_RANGE(NLA_U32, &nl80211_punct_bitmap_range),
+ 
+ 	[NL80211_ATTR_MAX_HW_TIMESTAMP_PEERS] = { .type = NLA_U16 },
+ 	[NL80211_ATTR_HW_TIMESTAMP_ENABLED] = { .type = NLA_FLAG },
  };
  
  /* policy for the key attributes */

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

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

[Matthieu Baerts]

Hi Stephen,

On 13/02/2023 00:20, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/intel/ice/ice_xsk.c
> 
> between commit:
> 
>   1f090494170e ("ice: xsk: Fix cleaning of XDP_TX frames")
> 
> from the net tree and commit:
> 
>   a24b4c6e9aab ("ice: xsk: Do not convert to buff to frame for XDP_TX")
> 
> from the net-next tree.

Thank you for having shared this patch! We had the same conflict on our
side:

Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net>

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice_xsk.c

between commit:

  1f090494170e ("ice: xsk: Fix cleaning of XDP_TX frames")

from the net tree and commit:

  a24b4c6e9aab ("ice: xsk: Do not convert to buff to frame for XDP_TX")

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/ice/ice_xsk.c
index 374b7f10b549,a25a68c69f22..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@@ -597,6 -597,107 +597,110 @@@ ice_construct_skb_zc(struct ice_rx_rin
  	return skb;
  }
  
+ /**
+  * ice_clean_xdp_irq_zc - AF_XDP ZC specific Tx cleaning routine
+  * @xdp_ring: XDP Tx ring
+  */
+ static void ice_clean_xdp_irq_zc(struct ice_tx_ring *xdp_ring)
+ {
+ 	u16 ntc = xdp_ring->next_to_clean;
+ 	struct ice_tx_desc *tx_desc;
+ 	u16 cnt = xdp_ring->count;
+ 	struct ice_tx_buf *tx_buf;
++	u16 completed_frames = 0;
+ 	u16 xsk_frames = 0;
+ 	u16 last_rs;
+ 	int i;
+ 
+ 	last_rs = xdp_ring->next_to_use ? xdp_ring->next_to_use - 1 : cnt - 1;
+ 	tx_desc = ICE_TX_DESC(xdp_ring, last_rs);
+ 	if (tx_desc->cmd_type_offset_bsz &
+ 	    cpu_to_le64(ICE_TX_DESC_DTYPE_DESC_DONE)) {
+ 		if (last_rs >= ntc)
 -			xsk_frames = last_rs - ntc + 1;
++			completed_frames = last_rs - ntc + 1;
+ 		else
 -			xsk_frames = last_rs + cnt - ntc + 1;
++			completed_frames = last_rs + cnt - ntc + 1;
+ 	}
+ 
 -	if (!xsk_frames)
++	if (!completed_frames)
+ 		return;
+ 
 -	if (likely(!xdp_ring->xdp_tx_active))
++	if (likely(!xdp_ring->xdp_tx_active)) {
++		xsk_frames = completed_frames;
+ 		goto skip;
++	}
+ 
+ 	ntc = xdp_ring->next_to_clean;
 -	for (i = 0; i < xsk_frames; i++) {
++	for (i = 0; i < completed_frames; i++) {
+ 		tx_buf = &xdp_ring->tx_buf[ntc];
+ 
+ 		if (tx_buf->xdp) {
+ 			xsk_buff_free(tx_buf->xdp);
+ 			xdp_ring->xdp_tx_active--;
+ 		} else {
+ 			xsk_frames++;
+ 		}
+ 
+ 		ntc++;
+ 		if (ntc == cnt)
+ 			ntc = 0;
+ 	}
+ skip:
+ 	tx_desc->cmd_type_offset_bsz = 0;
 -	xdp_ring->next_to_clean += xsk_frames;
++	xdp_ring->next_to_clean += completed_frames;
+ 	if (xdp_ring->next_to_clean >= cnt)
+ 		xdp_ring->next_to_clean -= cnt;
+ 	if (xsk_frames)
+ 		xsk_tx_completed(xdp_ring->xsk_pool, xsk_frames);
+ }
+ 
+ /**
+  * ice_xmit_xdp_tx_zc - AF_XDP ZC handler for XDP_TX
+  * @xdp: XDP buffer to xmit
+  * @xdp_ring: XDP ring to produce descriptor onto
+  *
+  * note that this function works directly on xdp_buff, no need to convert
+  * it to xdp_frame. xdp_buff pointer is stored to ice_tx_buf so that cleaning
+  * side will be able to xsk_buff_free() it.
+  *
+  * Returns ICE_XDP_TX for successfully produced desc, ICE_XDP_CONSUMED if there
+  * was not enough space on XDP ring
+  */
+ static int ice_xmit_xdp_tx_zc(struct xdp_buff *xdp,
+ 			      struct ice_tx_ring *xdp_ring)
+ {
+ 	u32 size = xdp->data_end - xdp->data;
+ 	u32 ntu = xdp_ring->next_to_use;
+ 	struct ice_tx_desc *tx_desc;
+ 	struct ice_tx_buf *tx_buf;
+ 	dma_addr_t dma;
+ 
+ 	if (ICE_DESC_UNUSED(xdp_ring) < ICE_RING_QUARTER(xdp_ring)) {
+ 		ice_clean_xdp_irq_zc(xdp_ring);
+ 		if (!ICE_DESC_UNUSED(xdp_ring)) {
+ 			xdp_ring->ring_stats->tx_stats.tx_busy++;
+ 			return ICE_XDP_CONSUMED;
+ 		}
+ 	}
+ 
+ 	dma = xsk_buff_xdp_get_dma(xdp);
+ 	xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, size);
+ 
+ 	tx_buf = &xdp_ring->tx_buf[ntu];
+ 	tx_buf->xdp = xdp;
+ 	tx_desc = ICE_TX_DESC(xdp_ring, ntu);
+ 	tx_desc->buf_addr = cpu_to_le64(dma);
+ 	tx_desc->cmd_type_offset_bsz = ice_build_ctob(ICE_TX_DESC_CMD_EOP,
+ 						      0, size, 0);
+ 	xdp_ring->xdp_tx_active++;
+ 
+ 	if (++ntu == xdp_ring->count)
+ 		ntu = 0;
+ 	xdp_ring->next_to_use = ntu;
+ 
+ 	return ICE_XDP_TX;
+ }
+ 
  /**
   * ice_run_xdp_zc - Executes an XDP program in zero-copy path
   * @rx_ring: Rx ring

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

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

[Matthieu Baerts]

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

Hi Stephen,

On 07/02/2023 23:46, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/devlink/leftover.c (net/core/devlink.c in the net tree)
> 
> between commit:
> 
>   565b4824c39f ("devlink: change port event netdev notifier from per-net to global")
> 
> from the net tree and commits:
> 
>   f05bd8ebeb69 ("devlink: move code to a dedicated directory")
>   687125b5799c ("devlink: split out core code")
> 
> from the net-next tree.
> 
> I fixed it up (I used the latter version of this file and applied the
> following merge fix up) and can carry the fix as necessary.

Thank you for the fix!

I also had the same conflicts on MPTCP side when merging mptcp-next with
-net and I used the same resolution:

Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net>

I was just a bit confused because I didn't see the modifications in
net/devlink/leftover.c -- devlink_port_netdevice_event() function -- in
the patch you attached but I saw them on linux-next. I guess that's
because you used the latter version of this file.

Just in case it would help the net maintainers, I attached to this email
the modification I had on my side which looks the same as Jiri's
original patch but using the new paths.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

[-- Attachment #2: d5f649fee1672d3d077610dd4878d49be18debaf.patch --]
[-- Type: text/x-patch, Size: 1810 bytes --]

diff --git a/net/devlink/core.c b/net/devlink/core.c
index aeffd1b8206d..a4f47dafb864 100644
--- a/net/devlink/core.c
+++ b/net/devlink/core.c
@@ -205,7 +205,7 @@ struct devlink *devlink_alloc_ns(const struct devlink_ops *ops,
 		goto err_xa_alloc;
 
 	devlink->netdevice_nb.notifier_call = devlink_port_netdevice_event;
-	ret = register_netdevice_notifier_net(net, &devlink->netdevice_nb);
+	ret = register_netdevice_notifier(&devlink->netdevice_nb);
 	if (ret)
 		goto err_register_netdevice_notifier;
 
@@ -266,8 +266,7 @@ void devlink_free(struct devlink *devlink)
 	xa_destroy(&devlink->snapshot_ids);
 	xa_destroy(&devlink->ports);
 
-	WARN_ON_ONCE(unregister_netdevice_notifier_net(devlink_net(devlink),
-						       &devlink->netdevice_nb));
+	WARN_ON_ONCE(unregister_netdevice_notifier(&devlink->netdevice_nb));
 
 	xa_erase(&devlinks, devlink->index);
 
diff --git a/net/devlink/leftover.c b/net/devlink/leftover.c
index 9d6373603340..f05ab093d231 100644
--- a/net/devlink/leftover.c
+++ b/net/devlink/leftover.c
@@ -8430,6 +8430,8 @@ int devlink_port_netdevice_event(struct notifier_block *nb,
 		break;
 	case NETDEV_REGISTER:
 	case NETDEV_CHANGENAME:
+		if (devlink_net(devlink) != dev_net(netdev))
+			return NOTIFY_OK;
 		/* Set the netdev on top of previously set type. Note this
 		 * event happens also during net namespace change so here
 		 * we take into account netdev pointer appearing in this
@@ -8439,6 +8441,8 @@ int devlink_port_netdevice_event(struct notifier_block *nb,
 					netdev);
 		break;
 	case NETDEV_UNREGISTER:
+		if (devlink_net(devlink) != dev_net(netdev))
+			return NOTIFY_OK;
 		/* Clear netdev pointer, but not the type. This event happens
 		 * also during net namespace change so we need to clear
 		 * pointer to netdev that is going to another net namespace.

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

[Stephen Rothwell]

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

Hi all,

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

  net/devlink/leftover.c (net/core/devlink.c in the net tree)

between commit:

  565b4824c39f ("devlink: change port event netdev notifier from per-net to global")

from the net tree and commits:

  f05bd8ebeb69 ("devlink: move code to a dedicated directory")
  687125b5799c ("devlink: split out core code")

from the net-next tree.

I fixed it up (I used the latter version of this file and applied the
following merge fix up) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree 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: Wed, 8 Feb 2023 09:43:53 +1100
Subject: [PATCH] fxup for "devlink: split out core code"

interacting with "devlink: change port event netdev notifier from per-net to global"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/devlink/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/devlink/core.c b/net/devlink/core.c
index aeffd1b8206d..a4f47dafb864 100644
--- a/net/devlink/core.c
+++ b/net/devlink/core.c
@@ -205,7 +205,7 @@ struct devlink *devlink_alloc_ns(const struct devlink_ops *ops,
 		goto err_xa_alloc;
 
 	devlink->netdevice_nb.notifier_call = devlink_port_netdevice_event;
-	ret = register_netdevice_notifier_net(net, &devlink->netdevice_nb);
+	ret = register_netdevice_notifier(&devlink->netdevice_nb);
 	if (ret)
 		goto err_register_netdevice_notifier;
 
@@ -266,8 +266,7 @@ void devlink_free(struct devlink *devlink)
 	xa_destroy(&devlink->snapshot_ids);
 	xa_destroy(&devlink->ports);
 
-	WARN_ON_ONCE(unregister_netdevice_notifier_net(devlink_net(devlink),
-						       &devlink->netdevice_nb));
+	WARN_ON_ONCE(unregister_netdevice_notifier(&devlink->netdevice_nb));
 
 	xa_erase(&devlinks, devlink->index);
 
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/core/gro.c

between commit:

  7d2c89b32587 ("skb: Do mix page pool and page referenced frags in GRO")

from the net tree and commit:

  b1a78b9b9886 ("net: add support for ipv4 big tcp")

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/gro.c
index 4bac7ea6e025,b15f85546bdd..000000000000
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@@ -162,17 -162,10 +162,19 @@@ int skb_gro_receive(struct sk_buff *p, 
  	struct sk_buff *lp;
  	int segs;
  
 +	/* Do not splice page pool based packets w/ non-page pool
 +	 * packets. This can result in reference count issues as page
 +	 * pool pages will not decrement the reference count and will
 +	 * instead be immediately returned to the pool or have frag
 +	 * count decremented.
 +	 */
 +	if (p->pp_recycle != skb->pp_recycle)
 +		return -ETOOMANYREFS;
 +
- 	/* pairs with WRITE_ONCE() in netif_set_gro_max_size() */
- 	gro_max_size = READ_ONCE(p->dev->gro_max_size);
+ 	/* pairs with WRITE_ONCE() in netif_set_gro(_ipv4)_max_size() */
+ 	gro_max_size = p->protocol == htons(ETH_P_IPV6) ?
+ 			READ_ONCE(p->dev->gro_max_size) :
+ 				READ_ONCE(p->dev->gro_ipv4_max_size);
  
  	if (unlikely(p->len + len >= gro_max_size || NAPI_GRO_CB(skb)->flush))
  		return -E2BIG;

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

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

[Jakub Kicinski]

On Fri, 27 Jan 2023 11:39:41 +0100 Matthieu Baerts wrote:
> On 27/01/2023 02:36, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the net-next tree got a conflict in:
> > 
> >   drivers/net/ethernet/engleder/tsnep_main.c
> > 
> > between commit:
> > 
> >   3d53aaef4332 ("tsnep: Fix TX queue stop/wake for multiple queues")
> > 
> > from the net tree and commit:
> > 
> >   25faa6a4c5ca ("tsnep: Replace TX spin_lock with __netif_tx_lock")
> > 
> > from the net-next tree.  
> 
> Thank you for the proposed patch. I had the same conflict on my side
> with MPTCP when merging net-next with -net and your fix seems to do the
> job correctly!
> 
> Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net>

BTW would it be possible to get these in form of rr-cache?
Or otherwise to import the resolution without fetching all objects 
from your trees?

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

[Matthieu Baerts]

Hi Stephen,

On 27/01/2023 02:36, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/engleder/tsnep_main.c
> 
> between commit:
> 
>   3d53aaef4332 ("tsnep: Fix TX queue stop/wake for multiple queues")
> 
> from the net tree and commit:
> 
>   25faa6a4c5ca ("tsnep: Replace TX spin_lock with __netif_tx_lock")
> 
> from the net-next tree.

Thank you for the proposed patch. I had the same conflict on my side
with MPTCP when merging net-next with -net and your fix seems to do the
job correctly!

Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net>

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

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

[Stephen Rothwell]

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

Hi all,

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

  net/netfilter/nf_conntrack_proto_sctp.c

between commits:

  13bd9b31a969 ("Revert "netfilter: conntrack: add sctp DATA_SENT state"")
  a44b7651489f ("netfilter: conntrack: unify established states for SCTP paths")

from the net tree and commit:

  f71cb8f45d09 ("netfilter: conntrack: sctp: use nf log infrastructure for invalid packets")

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_proto_sctp.c
index 945dd40e7077,dbdfcc6cd2aa..000000000000
--- a/net/netfilter/nf_conntrack_proto_sctp.c
+++ b/net/netfilter/nf_conntrack_proto_sctp.c
@@@ -238,14 -243,16 +227,12 @@@ static int sctp_new_state(enum ip_connt
  		i = 9;
  		break;
  	case SCTP_CID_HEARTBEAT_ACK:
- 		pr_debug("SCTP_CID_HEARTBEAT_ACK");
  		i = 10;
  		break;
 -	case SCTP_CID_DATA:
 -	case SCTP_CID_SACK:
 -		i = 11;
 -		break;
  	default:
  		/* Other chunks like DATA or SACK do not change the state */
- 		pr_debug("Unknown chunk type, Will stay in %s\n",
- 			 sctp_conntrack_names[cur_state]);
+ 		pr_debug("Unknown chunk type %d, Will stay in %s\n",
+ 			 chunk_type, sctp_conntrack_names[cur_state]);
  		return cur_state;
  	}
  
@@@ -381,19 -386,21 +364,21 @@@ int nf_conntrack_sctp_packet(struct nf_
  
  		if (!sctp_new(ct, skb, sh, dataoff))
  			return -NF_ACCEPT;
 -	} else {
 -		/* Check the verification tag (Sec 8.5) */
 -		if (!test_bit(SCTP_CID_INIT, map) &&
 -		    !test_bit(SCTP_CID_SHUTDOWN_COMPLETE, map) &&
 -		    !test_bit(SCTP_CID_COOKIE_ECHO, map) &&
 -		    !test_bit(SCTP_CID_ABORT, map) &&
 -		    !test_bit(SCTP_CID_SHUTDOWN_ACK, map) &&
 -		    !test_bit(SCTP_CID_HEARTBEAT, map) &&
 -		    !test_bit(SCTP_CID_HEARTBEAT_ACK, map) &&
 -		    sh->vtag != ct->proto.sctp.vtag[dir]) {
 -			nf_ct_l4proto_log_invalid(skb, ct, state,
 -						  "verification tag check failed %x vs %x for dir %d",
 -						  sh->vtag, ct->proto.sctp.vtag[dir], dir);
 -			goto out;
 -		}
 +	}
 +
 +	/* Check the verification tag (Sec 8.5) */
 +	if (!test_bit(SCTP_CID_INIT, map) &&
 +	    !test_bit(SCTP_CID_SHUTDOWN_COMPLETE, map) &&
 +	    !test_bit(SCTP_CID_COOKIE_ECHO, map) &&
 +	    !test_bit(SCTP_CID_ABORT, map) &&
 +	    !test_bit(SCTP_CID_SHUTDOWN_ACK, map) &&
 +	    !test_bit(SCTP_CID_HEARTBEAT, map) &&
 +	    !test_bit(SCTP_CID_HEARTBEAT_ACK, map) &&
 +	    sh->vtag != ct->proto.sctp.vtag[dir]) {
- 		pr_debug("Verification tag check failed\n");
++		nf_ct_l4proto_log_invalid(skb, ct, state,
++					  "verification tag check failed %x vs %x for dir %d",
++					  sh->vtag, ct->proto.sctp.vtag[dir], dir);
 +		goto out;
  	}
  
  	old_state = new_state = SCTP_CONNTRACK_NONE;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice_main.c

between commit:

  418e53401e47 ("ice: move devlink port creation/deletion")

from the net tree and commit:

  643ef23bd9dd ("ice: Introduce local var for readability")

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/ice/ice_main.c
index 237ede2cffb0,cb870da5c317..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@@ -5090,8 -5083,7 +5091,8 @@@ static void ice_remove(struct pci_dev *
  		ice_remove_arfs(pf);
  	ice_setup_mc_magic_wake(pf);
  	ice_vsi_release_all(pf);
- 	mutex_destroy(&(&pf->hw)->fdir_fltr_lock);
+ 	mutex_destroy(&hw->fdir_fltr_lock);
 +	ice_devlink_destroy_pf_port(pf);
  	ice_set_wake(pf);
  	ice_free_irq_msix_misc(pf);
  	ice_for_each_vsi(pf, i) {

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/engleder/tsnep_main.c

between commit:

  3d53aaef4332 ("tsnep: Fix TX queue stop/wake for multiple queues")

from the net tree and commit:

  25faa6a4c5ca ("tsnep: Replace TX spin_lock with __netif_tx_lock")

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/engleder/tsnep_main.c
index 00e2108f2ca4,e9dfefba5973..000000000000
--- a/drivers/net/ethernet/engleder/tsnep_main.c
+++ b/drivers/net/ethernet/engleder/tsnep_main.c
@@@ -450,10 -458,8 +458,8 @@@ static netdev_tx_t tsnep_xmit_frame_rin
  		/* ring full, shall not happen because queue is stopped if full
  		 * below
  		 */
 -		netif_stop_queue(tx->adapter->netdev);
 +		netif_stop_subqueue(tx->adapter->netdev, tx->queue_index);
  
- 		spin_unlock_irqrestore(&tx->lock, flags);
- 
  		return NETDEV_TX_BUSY;
  	}
  
@@@ -493,11 -495,9 +495,9 @@@
  
  	if (tsnep_tx_desc_available(tx) < (MAX_SKB_FRAGS + 1)) {
  		/* ring can get full with next frame */
 -		netif_stop_queue(tx->adapter->netdev);
 +		netif_stop_subqueue(tx->adapter->netdev, tx->queue_index);
  	}
  
- 	spin_unlock_irqrestore(&tx->lock, flags);
- 
  	return NETDEV_TX_OK;
  }
  
@@@ -567,13 -701,13 +701,13 @@@ static bool tsnep_tx_poll(struct tsnep_
  	} while (likely(budget));
  
  	if ((tsnep_tx_desc_available(tx) >= ((MAX_SKB_FRAGS + 1) * 2)) &&
 -	    netif_queue_stopped(tx->adapter->netdev)) {
 -		netif_wake_queue(tx->adapter->netdev);
 +	    netif_tx_queue_stopped(nq)) {
 +		netif_tx_wake_queue(nq);
  	}
  
- 	spin_unlock_irqrestore(&tx->lock, flags);
+ 	__netif_tx_unlock(nq);
  
- 	return (budget != 0);
+ 	return budget != 0;
  }
  
  static bool tsnep_tx_pending(struct tsnep_tx *tx)

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

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

[Caleb Connolly]

On 19/01/2023 00:41, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   drivers/net/ipa/ipa_interrupt.c
>   drivers/net/ipa/ipa_interrupt.h
> 
> between commit:
> 
>   9ec9b2a30853 ("net: ipa: disable ipa interrupt during suspend")
> 
> from the net tree and commits:
> 
>   8e461e1f092b ("net: ipa: introduce ipa_interrupt_enable()")
>   d50ed3558719 ("net: ipa: enable IPA interrupt handlers separate from registration")
> 
> 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.
> 

Hi all, sorry for the delayed response to this.

If this is the same fixup in Matthieu's email [1] (which it appears to
be), I can confirm that it's the correct fix here.

I based the patch on master as it is a bug fix which we intend to
backport, I should have mentioned the conflict with Alex's patch on
-next, apologies for the miscommunication.

-- 
Kind Regards,
Caleb (they/them)

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ipa/ipa_interrupt.c
  drivers/net/ipa/ipa_interrupt.h

between commit:

  9ec9b2a30853 ("net: ipa: disable ipa interrupt during suspend")

from the net tree and commits:

  8e461e1f092b ("net: ipa: introduce ipa_interrupt_enable()")
  d50ed3558719 ("net: ipa: enable IPA interrupt handlers separate from registration")

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/ipa/ipa_interrupt.c
index c1b3977e1ae4,fd982cec8068..000000000000
--- a/drivers/net/ipa/ipa_interrupt.c
+++ b/drivers/net/ipa/ipa_interrupt.c
@@@ -127,16 -129,29 +129,39 @@@ out_power_put
  	return IRQ_HANDLED;
  }
  
 +void ipa_interrupt_irq_disable(struct ipa *ipa)
 +{
 +	disable_irq(ipa->interrupt->irq);
 +}
 +
 +void ipa_interrupt_irq_enable(struct ipa *ipa)
 +{
 +	enable_irq(ipa->interrupt->irq);
 +}
 +
+ static void ipa_interrupt_enabled_update(struct ipa *ipa)
+ {
+ 	const struct ipa_reg *reg = ipa_reg(ipa, IPA_IRQ_EN);
+ 
+ 	iowrite32(ipa->interrupt->enabled, ipa->reg_virt + ipa_reg_offset(reg));
+ }
+ 
+ /* Enable an IPA interrupt type */
+ void ipa_interrupt_enable(struct ipa *ipa, enum ipa_irq_id ipa_irq)
+ {
+ 	/* Update the IPA interrupt mask to enable it */
+ 	ipa->interrupt->enabled |= BIT(ipa_irq);
+ 	ipa_interrupt_enabled_update(ipa);
+ }
+ 
+ /* Disable an IPA interrupt type */
+ void ipa_interrupt_disable(struct ipa *ipa, enum ipa_irq_id ipa_irq)
+ {
+ 	/* Update the IPA interrupt mask to disable it */
+ 	ipa->interrupt->enabled &= ~BIT(ipa_irq);
+ 	ipa_interrupt_enabled_update(ipa);
+ }
+ 
  /* Common function used to enable/disable TX_SUSPEND for an endpoint */
  static void ipa_interrupt_suspend_control(struct ipa_interrupt *interrupt,
  					  u32 endpoint_id, bool enable)
diff --cc drivers/net/ipa/ipa_interrupt.h
index 8a1bd5b89393,764a65e6b503..000000000000
--- a/drivers/net/ipa/ipa_interrupt.h
+++ b/drivers/net/ipa/ipa_interrupt.h
@@@ -85,22 -53,20 +53,36 @@@ void ipa_interrupt_suspend_clear_all(st
   */
  void ipa_interrupt_simulate_suspend(struct ipa_interrupt *interrupt);
  
 +/**
 + * ipa_interrupt_irq_enable() - Enable IPA interrupts
 + * @ipa:	IPA pointer
 + *
 + * This enables the IPA interrupt line
 + */
 +void ipa_interrupt_irq_enable(struct ipa *ipa);
 +
 +/**
 + * ipa_interrupt_irq_disable() - Disable IPA interrupts
 + * @ipa:	IPA pointer
 + *
 + * This disables the IPA interrupt line
 + */
 +void ipa_interrupt_irq_disable(struct ipa *ipa);
 +
+ /**
+  * ipa_interrupt_enable() - Enable an IPA interrupt type
+  * @ipa:	IPA pointer
+  * @ipa_irq:	IPA interrupt ID
+  */
+ void ipa_interrupt_enable(struct ipa *ipa, enum ipa_irq_id ipa_irq);
+ 
+ /**
+  * ipa_interrupt_disable() - Disable an IPA interrupt type
+  * @ipa:	IPA pointer
+  * @ipa_irq:	IPA interrupt ID
+  */
+ void ipa_interrupt_disable(struct ipa *ipa, enum ipa_irq_id ipa_irq);
+ 
  /**
   * ipa_interrupt_config() - Configure the IPA interrupt framework
   * @ipa:	IPA pointer

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/usb/r8152.c

between commit:

  be53771c87f4 ("r8152: add vendor/device ID pair for Microsoft Devkit")

from the net tree and commit:

  ec51fbd1b8a2 ("r8152: add USB device driver for config selection")

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 23da1d9dafd1,66e70b5f8417..000000000000
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -9817,40 -9820,31 +9820,32 @@@ static void rtl8152_disconnect(struct u
  /* table of devices that work with this driver */
  static const struct usb_device_id rtl8152_table[] = {
  	/* Realtek */
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8050),
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8053),
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152),
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153),
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8155),
- 	REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8156),
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8050) },
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8053) },
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8152) },
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8153) },
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8155) },
+ 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8156) },
  
  	/* Microsoft */
- 	REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab),
- 	REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6),
- 	REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927),
- 	REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0c5e),
- 	REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x304f),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3054),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3062),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3069),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3082),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7205),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x720c),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7214),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x721e),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0xa387),
- 	REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041),
- 	REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA,  0x09ff),
- 	REALTEK_USB_DEVICE(VENDOR_ID_TPLINK,  0x0601),
+ 	{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab) },
+ 	{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6) },
+ 	{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927) },
++	{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0c5e) },
+ 	{ USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x304f) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x3054) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x3062) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x3069) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x3082) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x7205) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x720c) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x7214) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0x721e) },
+ 	{ USB_DEVICE(VENDOR_ID_LENOVO,  0xa387) },
+ 	{ USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041) },
+ 	{ USB_DEVICE(VENDOR_ID_NVIDIA,  0x09ff) },
+ 	{ USB_DEVICE(VENDOR_ID_TPLINK,  0x0601) },
  	{}
  };
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/bpf.h

between commit:

  1f6e04a1c7b8 ("bpf: Fix offset calculation error in __copy_map_value and zero_map_value")

from the net tree and commits:

  aa3496accc41 ("bpf: Refactor kptr_off_tab into btf_record")
  f71b2f64177a ("bpf: Refactor map->off_arr handling")

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/linux/bpf.h
index c1bd1bd10506,798aec816970..000000000000
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@@ -311,13 -356,14 +356,14 @@@ static inline void bpf_obj_memcpy(struc
  		return;
  	}
  
- 	for (i = 0; i < map->off_arr->cnt; i++) {
- 		u32 next_off = map->off_arr->field_off[i];
+ 	for (i = 0; i < foffs->cnt; i++) {
+ 		u32 next_off = foffs->field_off[i];
+ 		u32 sz = next_off - curr_off;
  
- 		memcpy(dst + curr_off, src + curr_off, next_off - curr_off);
- 		curr_off = next_off + map->off_arr->field_sz[i];
+ 		memcpy(dst + curr_off, src + curr_off, sz);
 -		curr_off += foffs->field_sz[i];
++		curr_off = next_off + foffs->field_sz[i];
  	}
- 	memcpy(dst + curr_off, src + curr_off, map->value_size - curr_off);
+ 	memcpy(dst + curr_off, src + curr_off, size - curr_off);
  }
  
  static inline void copy_map_value(struct bpf_map *map, void *dst, void *src)
@@@ -340,13 -386,19 +386,19 @@@ static inline void bpf_obj_memzero(stru
  		return;
  	}
  
- 	for (i = 0; i < map->off_arr->cnt; i++) {
- 		u32 next_off = map->off_arr->field_off[i];
+ 	for (i = 0; i < foffs->cnt; i++) {
+ 		u32 next_off = foffs->field_off[i];
+ 		u32 sz = next_off - curr_off;
  
- 		memset(dst + curr_off, 0, next_off - curr_off);
- 		curr_off = next_off + map->off_arr->field_sz[i];
+ 		memset(dst + curr_off, 0, sz);
 -		curr_off += foffs->field_sz[i];
++		curr_off = next_off + foffs->field_sz[i];
  	}
- 	memset(dst + curr_off, 0, map->value_size - curr_off);
+ 	memset(dst + curr_off, 0, size - curr_off);
+ }
+ 
+ static inline void zero_map_value(struct bpf_map *map, void *dst)
+ {
+ 	bpf_obj_memzero(map->field_offs, dst, map->value_size);
  }
  
  void copy_map_value_locked(struct bpf_map *map, void *dst, void *src,

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

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

[Oliver Hartkopp]

Hello Stephen,

On 10.11.22 00:25, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>    drivers/net/can/pch_can.c
> 
> between commit:
> 
>    ae64438be192 ("can: dev: fix skb drop check")
> 
> from the net tree and commit:
> 
>    1dd1b521be85 ("can: remove obsolete PCH CAN driver")
> 
> from the net-next tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 

Yes, this is known.

The removal of the PCH CAN driver missed the last net-next phase for 
Linux 6.1 by some hours and therefore showed up relatively early in the 
net-next for 6.2.

Maybe we should generally try to commit "complete removals" of drivers 
preferably at the end of a -next phase which would have omitted this 
conflict.

Thanks for your work!

Best regards,
Oliver

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/can/pch_can.c

between commit:

  ae64438be192 ("can: dev: fix skb drop check")

from the net tree and commit:

  1dd1b521be85 ("can: remove obsolete PCH CAN driver")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/mediatek/mtk_ppe.c

between commit:

  ae3ed15da588 ("net: ethernet: mtk_eth_soc: fix state in __mtk_foe_entry_clear")

from the net tree and commit:

  9d8cb4c096ab ("net: ethernet: mtk_eth_soc: add foe_entry_size to mtk_eth_soc")

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_ppe.c
index 148ea636ef97,887f430734f7..000000000000
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@@ -410,9 -439,10 +439,10 @@@ __mtk_foe_entry_clear(struct mtk_ppe *p
  
  	hlist_del_init(&entry->list);
  	if (entry->hash != 0xffff) {
- 		ppe->foe_table[entry->hash].ib1 &= ~MTK_FOE_IB1_STATE;
- 		ppe->foe_table[entry->hash].ib1 |= FIELD_PREP(MTK_FOE_IB1_STATE,
- 							      MTK_FOE_STATE_INVALID);
+ 		struct mtk_foe_entry *hwe = mtk_foe_get_entry(ppe, entry->hash);
+ 
+ 		hwe->ib1 &= ~MTK_FOE_IB1_STATE;
 -		hwe->ib1 |= FIELD_PREP(MTK_FOE_IB1_STATE, MTK_FOE_STATE_UNBIND);
++		hwe->ib1 |= FIELD_PREP(MTK_FOE_IB1_STATE, MTK_FOE_STATE_INVALID);
  		dma_wmb();
  	}
  	entry->hash = 0xffff;

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

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

[Jakub Kicinski]

On Fri, 23 Sep 2022 10:28:10 +0200 Matthieu Baerts wrote:
> Or maybe because you were again disappointed by Lewandowski's
> performance yesterday when you were resolving the conflicts at the same
> time :-D

:D

> Anyway I just sent a small patch to fix this:
> 
> https://lore.kernel.org/netdev/20220923082306.2468081-1-matthieu.baerts@tessares.net/T/
> https://patchwork.kernel.org/project/netdevbpf/patch/20220923082306.2468081-1-matthieu.baerts@tessares.net/

Thanks!

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

[Matthieu Baerts]

Hi Jakub,

On 22/09/2022 21:59, Jakub Kicinski wrote:
> On Wed, 21 Sep 2022 11:18:17 +0200 Matthieu Baerts wrote:
>> Hi Stephen,
>>
>> On 21/09/2022 03:04, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the net-next tree got a conflict in:
>>>
>>>   tools/testing/selftests/drivers/net/bonding/Makefile
>>>
>>> between commit:
>>>
>>>   bbb774d921e2 ("net: Add tests for bonding and team address list management")
>>>
>>> from the net tree and commit:
>>>
>>>   152e8ec77640 ("selftests/bonding: add a test for bonding lladdr target")
>>>
>>> from the net-next tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary.  
>> Thank you for sharing this fix (and all the others!).
>>
>> I also had this conflict on my side[1] and I resolved it differently,
>> more like what is done in the -net tree I think, please see the patch
>> attached to this email.
>>
>> I guess I should probably use your version. It is just I saw it after
>> having resolved the conflict on my side :)
>> I will check later how the network maintainers will resolve this
>> conflict and update my tree if needed.
> 
> I took this opportunity to sort 'em:
> 
> - TEST_PROGS := bond-break-lacpdu-tx.sh
> - TEST_PROGS += bond-lladdr-target.sh
>  -TEST_PROGS := bond-break-lacpdu-tx.sh \
>  -            dev_addr_lists.sh \
>  -            bond-arp-interval-causes-panic.sh
> ++TEST_PROGS := \
> ++      bond-arp-interval-causes-panic.sh \
> ++      bond-break-lacpdu-tx.sh \
> ++      dev_addr_lists.sh
> + 
> + TEST_FILES := lag_lib.sh
> 
> Here's to hoping there are no more bond selftests before final..

Good idea to sort them!

It looks like you accidentally removed 'bond-lladdr-target.sh' from the
list. Most probably because there was yet another conflict in this file,
see commit 2ffd57327ff1 ("selftests: bonding: cause oops in
bond_rr_gen_slave_id") :)

Or maybe because you were again disappointed by Lewandowski's
performance yesterday when you were resolving the conflicts at the same
time :-D

Anyway I just sent a small patch to fix this:

https://lore.kernel.org/netdev/20220923082306.2468081-1-matthieu.baerts@tessares.net/T/
https://patchwork.kernel.org/project/netdevbpf/patch/20220923082306.2468081-1-matthieu.baerts@tessares.net/

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

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

[Jakub Kicinski]

On Wed, 21 Sep 2022 11:18:17 +0200 Matthieu Baerts wrote:
> Hi Stephen,
> 
> On 21/09/2022 03:04, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the net-next tree got a conflict in:
> > 
> >   tools/testing/selftests/drivers/net/bonding/Makefile
> > 
> > between commit:
> > 
> >   bbb774d921e2 ("net: Add tests for bonding and team address list management")
> > 
> > from the net tree and commit:
> > 
> >   152e8ec77640 ("selftests/bonding: add a test for bonding lladdr target")
> > 
> > from the net-next tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.  
> Thank you for sharing this fix (and all the others!).
> 
> I also had this conflict on my side[1] and I resolved it differently,
> more like what is done in the -net tree I think, please see the patch
> attached to this email.
> 
> I guess I should probably use your version. It is just I saw it after
> having resolved the conflict on my side :)
> I will check later how the network maintainers will resolve this
> conflict and update my tree if needed.

I took this opportunity to sort 'em:

- TEST_PROGS := bond-break-lacpdu-tx.sh
- TEST_PROGS += bond-lladdr-target.sh
 -TEST_PROGS := bond-break-lacpdu-tx.sh \
 -            dev_addr_lists.sh \
 -            bond-arp-interval-causes-panic.sh
++TEST_PROGS := \
++      bond-arp-interval-causes-panic.sh \
++      bond-break-lacpdu-tx.sh \
++      dev_addr_lists.sh
+ 
+ TEST_FILES := lag_lib.sh

Here's to hoping there are no more bond selftests before final..

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

[Matthieu Baerts]

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

Hi Stephen,

On 21/09/2022 03:04, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/drivers/net/bonding/Makefile
> 
> between commit:
> 
>   bbb774d921e2 ("net: Add tests for bonding and team address list management")
> 
> from the net tree and commit:
> 
>   152e8ec77640 ("selftests/bonding: add a test for bonding lladdr target")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.
Thank you for sharing this fix (and all the others!).

I also had this conflict on my side[1] and I resolved it differently,
more like what is done in the -net tree I think, please see the patch
attached to this email.

I guess I should probably use your version. It is just I saw it after
having resolved the conflict on my side :)
I will check later how the network maintainers will resolve this
conflict and update my tree if needed.

Cheers,
Matt

[1] https://github.com/multipath-tcp/mptcp_net-next/commit/c02e0180887c
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

[-- Attachment #2: c02e0180887cdb8c2bc98fcbb0ad6a6d7c68578c.patch --]
[-- Type: text/x-patch, Size: 561 bytes --]

diff --cc tools/testing/selftests/drivers/net/bonding/Makefile
index 0f9659407969,d209f7a98b6c..1ed01e960d51
--- a/tools/testing/selftests/drivers/net/bonding/Makefile
+++ b/tools/testing/selftests/drivers/net/bonding/Makefile
@@@ -1,9 -1,7 +1,10 @@@
  # SPDX-License-Identifier: GPL-2.0
  # Makefile for net selftests
  
 -TEST_PROGS := bond-break-lacpdu-tx.sh
 -TEST_PROGS += bond-lladdr-target.sh
 +TEST_PROGS := bond-break-lacpdu-tx.sh \
++	      bond-lladdr-target.sh \
 +	      dev_addr_lists.sh
 +
 +TEST_FILES := lag_lib.sh
  
  include ../../../lib.mk

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/drivers/net/bonding/Makefile

between commit:

  bbb774d921e2 ("net: Add tests for bonding and team address list management")

from the net tree and commit:

  152e8ec77640 ("selftests/bonding: add a test for bonding lladdr target")

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/drivers/net/bonding/Makefile
index 0f9659407969,d209f7a98b6c..000000000000
--- a/tools/testing/selftests/drivers/net/bonding/Makefile
+++ b/tools/testing/selftests/drivers/net/bonding/Makefile
@@@ -1,9 -1,7 +1,10 @@@
  # SPDX-License-Identifier: GPL-2.0
  # Makefile for net selftests
  
 -TEST_PROGS := bond-break-lacpdu-tx.sh
 +TEST_PROGS := bond-break-lacpdu-tx.sh \
 +	      dev_addr_lists.sh
+ TEST_PROGS += bond-lladdr-target.sh
  
 +TEST_FILES := lag_lib.sh
 +
  include ../../../lib.mk

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/freescale/fec.h

between commit:

  7b15515fc1ca ("Revert "fec: Restart PPS after link state change"")

from the net tree and commit:

  40c79ce13b03 ("net: fec: add stop mode support for imx8 platform")

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/freescale/fec.h
index a5fed00cb971,dd055d734363..000000000000
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@@ -639,6 -641,15 +642,8 @@@ struct fec_enet_private 
  	int pps_enable;
  	unsigned int next_counter;
  
 -	struct {
 -		struct timespec64 ts_phc;
 -		u64 ns_sys;
 -		u32 at_corr;
 -		u8 at_inc_corr;
 -	} ptp_saved_state;
 -
+ 	struct imx_sc_ipc *ipc_handle;
+ 
  	u64 ethtool_stats[];
  };
  

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

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

[Axel Rasmussen]

On Wed, Aug 31, 2022 at 5:55 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:
>
>   tools/testing/selftests/net/.gitignore
>
> between commit:
>
>   5a3a59981027 ("selftests: net: sort .gitignore file")
>
> from the net tree and commits:
>
>   c35ecb95c448 ("selftests/net: Add test for timing a bind request to a port with a populated bhash entry")
>   1be9ac87a75a ("selftests/net: Add sk_bind_sendto_listen and sk_connect_zero_addr")
>
> 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, and sorry for the trouble.

For what it's worth, I talked about the potential for conflicts with
Jakub in this thread [1]. For next time, is calling it out in the
commit message explicitly the right thing to do?

[1]: https://patchwork.kernel.org/project/netdevbpf/patch/20220819190558.477166-1-axelrasmussen@google.com/

>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc tools/testing/selftests/net/.gitignore
> index de7d5cc15f85,bec5cf96984c..000000000000
> --- a/tools/testing/selftests/net/.gitignore
> +++ b/tools/testing/selftests/net/.gitignore
> @@@ -1,15 -1,7 +1,16 @@@
>   # SPDX-License-Identifier: GPL-2.0-only
> ++bind_bhash
>  +cmsg_sender
>  +fin_ack_lat
>  +gro
>  +hwtstamp_config
>  +ioam6_parser
>  +ip_defrag
>   ipsec
>  +ipv6_flowlabel
>  +ipv6_flowlabel_mgr
>   msg_zerocopy
>  -socket
>  +nettest
>   psock_fanout
>   psock_snd
>   psock_tpacket
> @@@ -20,23 -11,35 +21,25 @@@ reuseport_bp
>   reuseport_bpf_cpu
>   reuseport_bpf_numa
>   reuseport_dualstack
>  -reuseaddr_conflict
>  -tcp_mmap
>  -udpgso
>  -udpgso_bench_rx
>  -udpgso_bench_tx
>  -tcp_inq
>  -tls
>  -txring_overwrite
>  -ip_defrag
>  -ipv6_flowlabel
>  -ipv6_flowlabel_mgr
>  -so_txtime
>  -tcp_fastopen_backup_key
>  -nettest
>  -fin_ack_lat
>  -reuseaddr_ports_exhausted
>  -hwtstamp_config
>   rxtimestamp
> - socket
>  -timestamping
>  -txtimestamp
> ++sk_bind_sendto_listen
> ++sk_connect_zero_addr
>   so_netns_cookie
>  +so_txtime
> ++socket
>  +stress_reuseport_listen
>  +tap
>  +tcp_fastopen_backup_key
>  +tcp_inq
>  +tcp_mmap
>   test_unix_oob
>  -gro
>  -ioam6_parser
>  +timestamping
>  +tls
>   toeplitz
>   tun
>  -cmsg_sender
>  +txring_overwrite
>  +txtimestamp
>  +udpgso
>  +udpgso_bench_rx
>  +udpgso_bench_tx
>   unix_connect
>  -tap
>  -bind_bhash
>  -sk_bind_sendto_listen
>  -sk_connect_zero_addr

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/.gitignore

between commit:

  5a3a59981027 ("selftests: net: sort .gitignore file")

from the net tree and commits:

  c35ecb95c448 ("selftests/net: Add test for timing a bind request to a port with a populated bhash entry")
  1be9ac87a75a ("selftests/net: Add sk_bind_sendto_listen and sk_connect_zero_addr")

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/.gitignore
index de7d5cc15f85,bec5cf96984c..000000000000
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@@ -1,15 -1,7 +1,16 @@@
  # SPDX-License-Identifier: GPL-2.0-only
++bind_bhash
 +cmsg_sender
 +fin_ack_lat
 +gro
 +hwtstamp_config
 +ioam6_parser
 +ip_defrag
  ipsec
 +ipv6_flowlabel
 +ipv6_flowlabel_mgr
  msg_zerocopy
 -socket
 +nettest
  psock_fanout
  psock_snd
  psock_tpacket
@@@ -20,23 -11,35 +21,25 @@@ reuseport_bp
  reuseport_bpf_cpu
  reuseport_bpf_numa
  reuseport_dualstack
 -reuseaddr_conflict
 -tcp_mmap
 -udpgso
 -udpgso_bench_rx
 -udpgso_bench_tx
 -tcp_inq
 -tls
 -txring_overwrite
 -ip_defrag
 -ipv6_flowlabel
 -ipv6_flowlabel_mgr
 -so_txtime
 -tcp_fastopen_backup_key
 -nettest
 -fin_ack_lat
 -reuseaddr_ports_exhausted
 -hwtstamp_config
  rxtimestamp
- socket
 -timestamping
 -txtimestamp
++sk_bind_sendto_listen
++sk_connect_zero_addr
  so_netns_cookie
 +so_txtime
++socket
 +stress_reuseport_listen
 +tap
 +tcp_fastopen_backup_key
 +tcp_inq
 +tcp_mmap
  test_unix_oob
 -gro
 -ioam6_parser
 +timestamping
 +tls
  toeplitz
  tun
 -cmsg_sender
 +txring_overwrite
 +txtimestamp
 +udpgso
 +udpgso_bench_rx
 +udpgso_bench_tx
  unix_connect
 -tap
 -bind_bhash
 -sk_bind_sendto_listen
 -sk_connect_zero_addr

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

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  21234e3a84c7 ("net/mlx5e: Fix use after free in mlx5e_fs_init()")

from the net tree and commit:

  c7eafc5ed068 ("net/mlx5e: Convert ethtool_steering member of flow_steering struct to 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
index e0ce5a233d0b,ef1dfbb78464..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
@@@ -1394,12 -1454,17 +1454,17 @@@ struct mlx5e_flow_steering *mlx5e_fs_in
  			goto err_free_vlan;
  	}
  
- 	return fs;
+ 	err = mlx5e_fs_ethtool_alloc(fs);
+ 	if (err)
+ 		goto err_free_tc;
  
+ 	return fs;
+ err_free_tc:
+ 	mlx5e_fs_tc_free(fs);
 -err_free_fs:
 -	kvfree(fs);
  err_free_vlan:
  	mlx5e_fs_vlan_free(fs);
 +err_free_fs:
 +	kvfree(fs);
  err:
  	return NULL;
  }

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

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

[Mark Brown]

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

On Wed, Aug 03, 2022 at 12:42:30AM -0700, Eric Dumazet wrote:
> On Tue, Aug 2, 2022 at 8:19 AM <broonie@kernel.org> wrote:

> >                         s->ax25_dev = NULL;
> >                         if (sk->sk_socket) {
> > -                               dev_put_track(ax25_dev->dev, &ax25_dev->dev_tracker);
> > +                               netdev_put(ax25_dev->dev,
> >  -                                         &ax25_dev->dev_tracker);

> This part seems wrong.

> Commit d7c4c9e075f8c only changed the two spots, one in ax25_release()
> and one in ax25_bind()

It is, I fixed it up later.

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

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

[Eric Dumazet]

On Tue, Aug 2, 2022 at 8:19 AM <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/ax25/af_ax25.c
>
> between commit:
>
>   d7c4c9e075f8c ("ax25: fix incorrect dev_tracker usage")
>
> from the net tree and commit:
>
>   d62607c3fe459 ("net: rename reference+tracking 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.
>
> diff --cc net/ax25/af_ax25.c
> index 5b5363c99ed50,bbac3cb4dc99d..0000000000000
> --- a/net/ax25/af_ax25.c
> +++ b/net/ax25/af_ax25.c
> @@@ -102,7 -102,8 +102,8 @@@ again
>                         ax25_disconnect(s, ENETUNREACH);
>                         s->ax25_dev = NULL;
>                         if (sk->sk_socket) {
> -                               dev_put_track(ax25_dev->dev, &ax25_dev->dev_tracker);
> +                               netdev_put(ax25_dev->dev,
>  -                                         &ax25_dev->dev_tracker);

This part seems wrong.

Commit d7c4c9e075f8c only changed the two spots, one in ax25_release()
and one in ax25_bind()

> ++                                         &ax25->dev_tracker);
>                                 ax25_dev_put(ax25_dev);
>                         }
>                         ax25_cb_del(s);
> @@@ -1065,7 -1066,7 +1066,7 @@@ static int ax25_release(struct socket *
>                         del_timer_sync(&ax25->t3timer);
>                         del_timer_sync(&ax25->idletimer);
>                 }
> -               dev_put_track(ax25_dev->dev, &ax25->dev_tracker);
>  -              netdev_put(ax25_dev->dev, &ax25_dev->dev_tracker);
> ++              netdev_put(ax25_dev->dev, &ax25->dev_tracker);
>                 ax25_dev_put(ax25_dev);
>         }
>
> @@@ -1146,7 -1147,7 +1147,7 @@@ static int ax25_bind(struct socket *soc
>
>         if (ax25_dev) {
>                 ax25_fillin_cb(ax25, ax25_dev);
> -               dev_hold_track(ax25_dev->dev, &ax25->dev_tracker, GFP_ATOMIC);
>  -              netdev_hold(ax25_dev->dev, &ax25_dev->dev_tracker, GFP_ATOMIC);
> ++              netdev_hold(ax25_dev->dev, &ax25->dev_tracker, GFP_ATOMIC);
>         }
>
>   done:

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

[broonie]

Hi all,

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

  net/ax25/af_ax25.c

between commit:

  d7c4c9e075f8c ("ax25: fix incorrect dev_tracker usage")

from the net tree and commit:

  d62607c3fe459 ("net: rename reference+tracking 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.

diff --cc net/ax25/af_ax25.c
index 5b5363c99ed50,bbac3cb4dc99d..0000000000000
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@@ -102,7 -102,8 +102,8 @@@ again
  			ax25_disconnect(s, ENETUNREACH);
  			s->ax25_dev = NULL;
  			if (sk->sk_socket) {
- 				dev_put_track(ax25_dev->dev, &ax25_dev->dev_tracker);
+ 				netdev_put(ax25_dev->dev,
 -					   &ax25_dev->dev_tracker);
++					   &ax25->dev_tracker);
  				ax25_dev_put(ax25_dev);
  			}
  			ax25_cb_del(s);
@@@ -1065,7 -1066,7 +1066,7 @@@ static int ax25_release(struct socket *
  			del_timer_sync(&ax25->t3timer);
  			del_timer_sync(&ax25->idletimer);
  		}
- 		dev_put_track(ax25_dev->dev, &ax25->dev_tracker);
 -		netdev_put(ax25_dev->dev, &ax25_dev->dev_tracker);
++		netdev_put(ax25_dev->dev, &ax25->dev_tracker);
  		ax25_dev_put(ax25_dev);
  	}
  
@@@ -1146,7 -1147,7 +1147,7 @@@ static int ax25_bind(struct socket *soc
  
  	if (ax25_dev) {
  		ax25_fillin_cb(ax25, ax25_dev);
- 		dev_hold_track(ax25_dev->dev, &ax25->dev_tracker, GFP_ATOMIC);
 -		netdev_hold(ax25_dev->dev, &ax25_dev->dev_tracker, GFP_ATOMIC);
++		netdev_hold(ax25_dev->dev, &ax25->dev_tracker, GFP_ATOMIC);
  	}
  
  done:

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

[Stephen Rothwell]

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

Hi all,

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

  include/net/sock.h

between commit:

  310731e2f161 ("net: Fix data-races around sysctl_mem.")

from the net tree and commit:

  e70f3c701276 ("Revert "net: set SK_MEM_QUANTUM to 4096"")

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/sock.h
index 9fa54762e077,0dd43c3df49b..000000000000
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -1521,22 -1541,10 +1541,10 @@@ void __sk_mem_reclaim(struct sock *sk, 
  #define SK_MEM_SEND	0
  #define SK_MEM_RECV	1
  
- /* sysctl_mem values are in pages, we convert them in SK_MEM_QUANTUM units */
+ /* sysctl_mem values are in pages */
  static inline long sk_prot_mem_limits(const struct sock *sk, int index)
  {
- 	long val = READ_ONCE(sk->sk_prot->sysctl_mem[index]);
- 
- #if PAGE_SIZE > SK_MEM_QUANTUM
- 	val <<= PAGE_SHIFT - SK_MEM_QUANTUM_SHIFT;
- #elif PAGE_SIZE < SK_MEM_QUANTUM
- 	val >>= SK_MEM_QUANTUM_SHIFT - PAGE_SHIFT;
- #endif
- 	return val;
 -	return sk->sk_prot->sysctl_mem[index];
++	return READ_ONCE(sk->sk_prot->sysctl_mem[index]);
  }
  
  static inline int sk_mem_pages(int amt)

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/smc/af_smc.c

between commit:

  75c1edf23b95 ("net/smc: postpone sk_refcnt increment in connect()")

from the net tree and commit:

  3aba103006bc ("net/smc: align the connect behaviour with TCP")

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 d3de54b70c05,5f70642a8044..000000000000
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@@ -1564,9 -1584,11 +1584,11 @@@ static int smc_connect(struct socket *s
  	if (rc && rc != -EINPROGRESS)
  		goto out;
  
- 	if (smc->use_fallback)
 -	sock_hold(&smc->sk); /* sock put in passive closing */
+ 	if (smc->use_fallback) {
+ 		sock->state = rc ? SS_CONNECTING : SS_CONNECTED;
  		goto out;
+ 	}
 +	sock_hold(&smc->sk); /* sock put in passive closing */
  	if (flags & O_NONBLOCK) {
  		if (queue_work(smc_hs_wq, &smc->connect_work))
  			smc->connect_nonblock = 1;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/cadence/macb_main.c

between commit:

  5cebb40bc955 ("net: macb: Fix PTP one step sync support")

from the net tree and commit:

  138badbc21a0 ("net: macb: use NAPI for TX completion 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/cadence/macb_main.c
index 3a1b5ac48ca5,d6cdb97bfb38..000000000000
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@@ -1123,57 -1119,20 +1120,50 @@@ static void macb_tx_error_task(struct w
  	macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
  
  	spin_unlock_irqrestore(&bp->lock, flags);
+ 	napi_enable(&queue->napi_tx);
  }
  
 +static bool ptp_one_step_sync(struct sk_buff *skb)
 +{
 +	struct ptp_header *hdr;
 +	unsigned int ptp_class;
 +	u8 msgtype;
 +
 +	/* No need to parse packet if PTP TS is not involved */
 +	if (likely(!(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)))
 +		goto not_oss;
 +
 +	/* Identify and return whether PTP one step sync is being processed */
 +	ptp_class = ptp_classify_raw(skb);
 +	if (ptp_class == PTP_CLASS_NONE)
 +		goto not_oss;
 +
 +	hdr = ptp_parse_header(skb, ptp_class);
 +	if (!hdr)
 +		goto not_oss;
 +
 +	if (hdr->flag_field[0] & PTP_FLAG_TWOSTEP)
 +		goto not_oss;
 +
 +	msgtype = ptp_get_msgtype(hdr, ptp_class);
 +	if (msgtype == PTP_MSGTYPE_SYNC)
 +		return true;
 +
 +not_oss:
 +	return false;
 +}
 +
- static void macb_tx_interrupt(struct macb_queue *queue)
+ static int macb_tx_complete(struct macb_queue *queue, int budget)
  {
- 	unsigned int tail;
- 	unsigned int head;
- 	u32 status;
  	struct macb *bp = queue->bp;
  	u16 queue_index = queue - bp->queues;
+ 	unsigned int tail;
+ 	unsigned int head;
+ 	int packets = 0;
  
- 	status = macb_readl(bp, TSR);
- 	macb_writel(bp, TSR, status);
- 
- 	if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
- 		queue_writel(queue, ISR, MACB_BIT(TCOMP));
- 
- 	netdev_vdbg(bp->dev, "macb_tx_interrupt status = 0x%03lx\n",
- 		    (unsigned long)status);
- 
+ 	spin_lock(&queue->tx_ptr_lock);
  	head = queue->tx_head;
- 	for (tail = queue->tx_tail; tail != head; tail++) {
+ 	for (tail = queue->tx_tail; tail != head && packets < budget; tail++) {
  		struct macb_tx_skb	*tx_skb;
  		struct sk_buff		*skb;
  		struct macb_dma_desc	*desc;

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/subflow.c

between commit:

  ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure")

from the net tree and commits:

  0348c690ed37 ("mptcp: add the fallback check")
  f8d4bcacff3b ("mptcp: infinite mapping receiving")

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/mptcp/subflow.c
index be76ada89d96,6d59336a8e1e..000000000000
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@@ -1218,35 -1215,45 +1230,45 @@@ no_data
  	return false;
  
  fallback:
- 	/* RFC 8684 section 3.7. */
- 	if (subflow->send_mp_fail) {
- 		if (mptcp_has_another_subflow(ssk)) {
- 			while ((skb = skb_peek(&ssk->sk_receive_queue)))
- 				sk_eat_skb(ssk, skb);
+ 	if (!__mptcp_check_fallback(msk)) {
+ 		/* RFC 8684 section 3.7. */
+ 		if (subflow->send_mp_fail) {
+ 			if (mptcp_has_another_subflow(ssk) ||
+ 			    !READ_ONCE(msk->allow_infinite_fallback)) {
+ 				ssk->sk_err = EBADMSG;
+ 				tcp_set_state(ssk, TCP_CLOSE);
+ 				subflow->reset_transient = 0;
+ 				subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
+ 				tcp_send_active_reset(ssk, GFP_ATOMIC);
+ 				while ((skb = skb_peek(&ssk->sk_receive_queue)))
+ 					sk_eat_skb(ssk, skb);
+ 			} else {
+ 				WRITE_ONCE(subflow->mp_fail_response_expect, true);
+ 				/* The data lock is acquired in __mptcp_move_skbs() */
+ 				sk_reset_timer((struct sock *)msk,
+ 					       &((struct sock *)msk)->sk_timer,
+ 					       jiffies + TCP_RTO_MAX);
+ 			}
+ 			WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA);
+ 			return true;
  		}
- 		ssk->sk_err = EBADMSG;
- 		tcp_set_state(ssk, TCP_CLOSE);
- 		subflow->reset_transient = 0;
- 		subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
- 		tcp_send_active_reset(ssk, GFP_ATOMIC);
- 		WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA);
- 		return true;
- 	}
  
- 	if (!subflow_can_fallback(subflow)) {
- 		/* fatal protocol error, close the socket.
- 		 * subflow_error_report() will introduce the appropriate barriers
- 		 */
- 		ssk->sk_err = EBADMSG;
- 		tcp_set_state(ssk, TCP_CLOSE);
- 		subflow->reset_transient = 0;
- 		subflow->reset_reason = MPTCP_RST_EMPTCP;
- 		tcp_send_active_reset(ssk, GFP_ATOMIC);
- 		WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA);
- 		return false;
 -		if ((subflow->mp_join || subflow->fully_established) && subflow->map_data_len) {
++		if (!subflow_can_fallback(subflow) && subflow->map_data_len) {
+ 			/* fatal protocol error, close the socket.
+ 			 * subflow_error_report() will introduce the appropriate barriers
+ 			 */
+ 			ssk->sk_err = EBADMSG;
+ 			tcp_set_state(ssk, TCP_CLOSE);
+ 			subflow->reset_transient = 0;
+ 			subflow->reset_reason = MPTCP_RST_EMPTCP;
+ 			tcp_send_active_reset(ssk, GFP_ATOMIC);
+ 			WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA);
+ 			return false;
+ 		}
+ 
+ 		__mptcp_do_fallback(msk);
  	}
  
- 	__mptcp_do_fallback(msk);
  	skb = skb_peek(&ssk->sk_receive_queue);
  	subflow->map_valid = 1;
  	subflow->map_seq = READ_ONCE(msk->ack_seq);

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/options.c

between commit:

  ba2c89e0ea74 ("mptcp: fix checksum byte order")

from the net tree and commits:

  1e39e5a32ad7 ("mptcp: infinite mapping sending")
  ea66758c1795 ("tcp: allow MPTCP to update the announced window")

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/mptcp/options.c
index b548cec86c9d,ac3b7b8a02f6..000000000000
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@@ -1234,13 -1236,53 +1236,53 @@@ static void mptcp_set_rwin(struct tcp_s
  	subflow = mptcp_subflow_ctx(ssk);
  	msk = mptcp_sk(subflow->conn);
  
- 	ack_seq = READ_ONCE(msk->ack_seq) + tp->rcv_wnd;
+ 	ack_seq = READ_ONCE(msk->ack_seq);
+ 	rcv_wnd_new = ack_seq + tp->rcv_wnd;
+ 
+ 	rcv_wnd_old = atomic64_read(&msk->rcv_wnd_sent);
+ 	if (after64(rcv_wnd_new, rcv_wnd_old)) {
+ 		u64 rcv_wnd;
+ 
+ 		for (;;) {
+ 			rcv_wnd = atomic64_cmpxchg(&msk->rcv_wnd_sent, rcv_wnd_old, rcv_wnd_new);
+ 
+ 			if (rcv_wnd == rcv_wnd_old)
+ 				break;
+ 			if (before64(rcv_wnd_new, rcv_wnd)) {
+ 				MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_RCVWNDCONFLICTUPDATE);
+ 				goto raise_win;
+ 			}
+ 			MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_RCVWNDCONFLICT);
+ 			rcv_wnd_old = rcv_wnd;
+ 		}
+ 		return;
+ 	}
+ 
+ 	if (rcv_wnd_new != rcv_wnd_old) {
+ raise_win:
+ 		win = rcv_wnd_old - ack_seq;
+ 		tp->rcv_wnd = min_t(u64, win, U32_MAX);
+ 		new_win = tp->rcv_wnd;
  
- 	if (after64(ack_seq, READ_ONCE(msk->rcv_wnd_sent)))
- 		WRITE_ONCE(msk->rcv_wnd_sent, ack_seq);
+ 		/* Make sure we do not exceed the maximum possible
+ 		 * scaled window.
+ 		 */
+ 		if (unlikely(th->syn))
+ 			new_win = min(new_win, 65535U) << tp->rx_opt.rcv_wscale;
+ 		if (!tp->rx_opt.rcv_wscale &&
+ 		    sock_net(ssk)->ipv4.sysctl_tcp_workaround_signed_windows)
+ 			new_win = min(new_win, MAX_TCP_WINDOW);
+ 		else
+ 			new_win = min(new_win, (65535U << tp->rx_opt.rcv_wscale));
+ 
+ 		/* RFC1323 scaling applied */
+ 		new_win >>= tp->rx_opt.rcv_wscale;
+ 		th->window = htons(new_win);
+ 		MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_RCVWNDSHARED);
+ 	}
  }
  
 -u16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)
 +__sum16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)
  {
  	struct csum_pseudo_header header;
  	__wsum csum;
@@@ -1265,17 -1307,7 +1307,17 @@@ static __sum16 mptcp_make_csum(const st
  				 ~csum_unfold(mpext->csum));
  }
  
 +static void put_len_csum(u16 len, __sum16 csum, void *data)
 +{
 +	__sum16 *sumptr = data + 2;
 +	__be16 *ptr = data;
 +
 +	put_unaligned_be16(len, ptr);
 +
 +	put_unaligned(csum, sumptr);
 +}
 +
- void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
+ void mptcp_write_options(struct tcphdr *th, __be32 *ptr, struct tcp_sock *tp,
  			 struct mptcp_out_options *opts)
  {
  	const struct sock *ssk = (const struct sock *)tp;
@@@ -1350,9 -1382,12 +1392,12 @@@
  			put_unaligned_be32(mpext->subflow_seq, ptr);
  			ptr += 1;
  			if (opts->csum_reqd) {
+ 				/* data_len == 0 is reserved for the infinite mapping,
+ 				 * the checksum will also be set to 0.
+ 				 */
 -				put_unaligned_be32(mpext->data_len << 16 |
 -						   (mpext->data_len ? mptcp_make_csum(mpext) : 0),
 -						   ptr);
 +				put_len_csum(mpext->data_len,
- 					     mptcp_make_csum(mpext),
++					     (mpext->data_len ? mptcp_make_csum(mpext) : 0),
 +					     ptr);
  			} else {
  				put_unaligned_be32(mpext->data_len << 16 |
  						   TCPOPT_NOP << 8 | TCPOPT_NOP, ptr);

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

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  16d42d313350 ("net/mlx5: Drain fw_reset when removing device")

from the net tree and commit:

  8324a02c342a ("net/mlx5: Add exit route when waiting for FW")

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/main.c
index e5871fdd5c08,87f1552b5d73..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@@ -1612,10 -1608,7 +1617,11 @@@ static void remove_one(struct pci_dev *
  	struct mlx5_core_dev *dev  = pci_get_drvdata(pdev);
  	struct devlink *devlink = priv_to_devlink(dev);
  
 +	/* mlx5_drain_fw_reset() is using devlink APIs. Hence, we must drain
 +	 * fw_reset before unregistering the devlink.
 +	 */
 +	mlx5_drain_fw_reset(dev);
+ 	set_bit(MLX5_BREAK_FW_WAIT, &dev->intf_state);
  	devlink_unregister(devlink);
  	mlx5_sriov_disable(pdev);
  	mlx5_crdump_disable(dev);

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/mptcp/mptcp_join.sh

between commit:

  e274f7154008 ("selftests: mptcp: add subflow limits test-cases")

from the net tree and commits:

  b6e074e171bc ("selftests: mptcp: add infinite map testcase")
  5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type")

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/mptcp/mptcp_join.sh
index 48ef112f42c2,d1de1e7702fb..000000000000
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@@ -2583,7 -2690,91 +2717,91 @@@ fastclose_tests(
  	fi
  }
  
+ pedit_action_pkts()
+ {
+ 	tc -n $ns2 -j -s action show action pedit index 100 | \
+ 		sed 's/.*"packets":\([0-9]\+\),.*/\1/'
+ }
+ 
+ fail_tests()
+ {
+ 	# single subflow
+ 	if reset_with_fail "Infinite map" 1; then
+ 		run_tests $ns1 $ns2 10.0.1.1 128
+ 		chk_join_nr 0 0 0 +1 +0 1 0 1 "$(pedit_action_pkts)"
+ 		chk_fail_nr 1 -1 invert
+ 	fi
+ }
+ 
+ userspace_tests()
+ {
+ 	# userspace pm type prevents add_addr
+ 	if reset "userspace pm type prevents add_addr"; then
+ 		set_userspace_pm $ns1
+ 		pm_nl_set_limits $ns1 0 2
+ 		pm_nl_set_limits $ns2 0 2
+ 		pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
+ 		run_tests $ns1 $ns2 10.0.1.1
+ 		chk_join_nr 0 0 0
+ 		chk_add_nr 0 0
+ 	fi
+ 
+ 	# userspace pm type does not echo add_addr without daemon
+ 	if reset "userspace pm no echo w/o daemon"; then
+ 		set_userspace_pm $ns2
+ 		pm_nl_set_limits $ns1 0 2
+ 		pm_nl_set_limits $ns2 0 2
+ 		pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
+ 		run_tests $ns1 $ns2 10.0.1.1
+ 		chk_join_nr 0 0 0
+ 		chk_add_nr 1 0
+ 	fi
+ 
+ 	# userspace pm type rejects join
+ 	if reset "userspace pm type rejects join"; then
+ 		set_userspace_pm $ns1
+ 		pm_nl_set_limits $ns1 1 1
+ 		pm_nl_set_limits $ns2 1 1
+ 		pm_nl_add_endpoint $ns2 10.0.3.2 flags subflow
+ 		run_tests $ns1 $ns2 10.0.1.1
+ 		chk_join_nr 1 1 0
+ 	fi
+ 
+ 	# userspace pm type does not send join
+ 	if reset "userspace pm type does not send join"; then
+ 		set_userspace_pm $ns2
+ 		pm_nl_set_limits $ns1 1 1
+ 		pm_nl_set_limits $ns2 1 1
+ 		pm_nl_add_endpoint $ns2 10.0.3.2 flags subflow
+ 		run_tests $ns1 $ns2 10.0.1.1
+ 		chk_join_nr 0 0 0
+ 	fi
+ 
+ 	# userspace pm type prevents mp_prio
+ 	if reset "userspace pm type prevents mp_prio"; then
+ 		set_userspace_pm $ns1
+ 		pm_nl_set_limits $ns1 1 1
+ 		pm_nl_set_limits $ns2 1 1
+ 		pm_nl_add_endpoint $ns2 10.0.3.2 flags subflow
+ 		run_tests $ns1 $ns2 10.0.1.1 0 0 0 slow backup
+ 		chk_join_nr 1 1 0
+ 		chk_prio_nr 0 0
+ 	fi
+ 
+ 	# userspace pm type prevents rm_addr
+ 	if reset "userspace pm type prevents rm_addr"; then
+ 		set_userspace_pm $ns1
+ 		set_userspace_pm $ns2
+ 		pm_nl_set_limits $ns1 0 1
+ 		pm_nl_set_limits $ns2 0 1
+ 		pm_nl_add_endpoint $ns2 10.0.3.2 flags subflow
+ 		run_tests $ns1 $ns2 10.0.1.1 0 0 -1 slow
+ 		chk_join_nr 0 0 0
+ 		chk_rm_nr 0 0
+ 	fi
+ }
+ 
 -implicit_tests()
 +endpoint_tests()
  {
  	# userspace pm type prevents add_addr
  	if reset "implicit EP"; then
@@@ -2668,7 -2842,9 +2886,9 @@@ all_tests_sorted=
  	d@deny_join_id0_tests
  	m@fullmesh_tests
  	z@fastclose_tests
+ 	F@fail_tests
+ 	u@userspace_tests
 -	I@implicit_tests
 +	I@endpoint_tests
  )
  
  all_tests_args=""

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/pm.c

between commit:

  95d686517884 ("mptcp: fix subflow accounting on close")

from the net tree and commit:

  4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs")

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/mptcp/pm.c
index aa51b100e033,cdc2d79071f8..000000000000
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@@ -178,7 -181,9 +181,8 @@@ void mptcp_pm_subflow_check_next(struc
  	struct mptcp_pm_data *pm = &msk->pm;
  	bool update_subflows;
  
- 	update_subflows = subflow->request_join || subflow->mp_join;
 -	update_subflows = (ssk->sk_state == TCP_CLOSE) &&
 -			  (subflow->request_join || subflow->mp_join) &&
++	update_subflows = (subflow->request_join || subflow->mp_join) &&
+ 			  mptcp_pm_is_kernel(msk);
  	if (!READ_ONCE(pm->work_pending) && !update_subflows)
  		return;
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/forwarding/Makefile

between commit:

  f62c5acc800e ("selftests/net/forwarding: add missing tests to Makefile")

from the net tree and commit:

  50fe062c806e ("selftests: forwarding: new test, verify host mdb entries")

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/forwarding/Makefile
index c87e674b61b1,ae80c2aef577..000000000000
--- a/tools/testing/selftests/net/forwarding/Makefile
+++ b/tools/testing/selftests/net/forwarding/Makefile
@@@ -2,7 -2,7 +2,8 @@@
  
  TEST_PROGS = bridge_igmp.sh \
  	bridge_locked_port.sh \
+ 	bridge_mdb.sh \
 +	bridge_mld.sh \
  	bridge_port_isolation.sh \
  	bridge_sticky_fdb.sh \
  	bridge_vlan_aware.sh \

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

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

[Stephen Rothwell]

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

Hi all,

On Thu, 28 Apr 2022 11:19:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> diff --cc net/core/dev.c
> index 1461c2d9dec8,611bd7197064..000000000000
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@@ -10352,9 -10409,10 +10405,10 @@@ struct rtnl_link_stats64 *dev_get_stats
>   
>   		for_each_possible_cpu(i) {
>   			core_stats = per_cpu_ptr(p, i);
>  -			storage->rx_dropped += local_read(&core_stats->rx_dropped);
>  -			storage->tx_dropped += local_read(&core_stats->tx_dropped);
>  -			storage->rx_nohandler += local_read(&core_stats->rx_nohandler);
>  -			storage->rx_otherhost_dropped += local_read(&core_stats->rx_otherhost_dropped);
>  +			storage->rx_dropped += READ_ONCE(core_stats->rx_dropped);
>  +			storage->tx_dropped += READ_ONCE(core_stats->tx_dropped);
>  +			storage->rx_nohandler += READ_ONCE(core_stats->rx_nohandler);
> ++			storage->rx_otherhost_dropped += READ_ONCE(&core_stats->rx_otherhost_dropped);
                                                                   ^
I failed to remove the '&'.  I have done that now to fix up my merge
resolution.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/wan/cosa.c

between commit:

  d48fea8401cf ("net: cosa: fix error check return value of register_chrdev()")

from the net tree and commit:

  89fbca3307d4 ("net: wan: remove support for COSA and SRP synchronous serial boards")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

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:

  6510ea973d8d ("net: Use this_cpu_inc() to increment net->core_stats")

from the net tree and commit:

  794c24e9921f ("net-core: rx_otherhost_dropped to core_stats")

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 include/linux/netdevice.h
index b1fbe21650bb,ac8a5f71220a..000000000000
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@@ -199,10 -200,11 +200,11 @@@ struct net_device_stats 
   * Try to fit them in a single cache line, for dev_get_stats() sake.
   */
  struct net_device_core_stats {
 -	local_t		rx_dropped;
 -	local_t		tx_dropped;
 -	local_t		rx_nohandler;
 -	local_t		rx_otherhost_dropped;
 -} __aligned(4 * sizeof(local_t));
 +	unsigned long	rx_dropped;
 +	unsigned long	tx_dropped;
 +	unsigned long	rx_nohandler;
++	unsigned long	rx_otherhost_dropped;
 +} __aligned(4 * sizeof(unsigned long));
  
  #include <linux/cache.h>
  #include <linux/skbuff.h>
diff --cc net/core/dev.c
index 1461c2d9dec8,611bd7197064..000000000000
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@@ -10352,9 -10409,10 +10405,10 @@@ struct rtnl_link_stats64 *dev_get_stats
  
  		for_each_possible_cpu(i) {
  			core_stats = per_cpu_ptr(p, i);
 -			storage->rx_dropped += local_read(&core_stats->rx_dropped);
 -			storage->tx_dropped += local_read(&core_stats->tx_dropped);
 -			storage->rx_nohandler += local_read(&core_stats->rx_nohandler);
 -			storage->rx_otherhost_dropped += local_read(&core_stats->rx_otherhost_dropped);
 +			storage->rx_dropped += READ_ONCE(core_stats->rx_dropped);
 +			storage->tx_dropped += READ_ONCE(core_stats->tx_dropped);
 +			storage->rx_nohandler += READ_ONCE(core_stats->rx_nohandler);
++			storage->rx_otherhost_dropped += READ_ONCE(&core_stats->rx_otherhost_dropped);
  		}
  	}
  	return storage;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/microchip/lan966x/lan966x_main.c

between commit:

  d08ed852560e ("net: lan966x: Make sure to release ptp interrupt")

from the net tree and commit:

  c8349639324a ("net: lan966x: Add FDMA functionality")

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/microchip/lan966x/lan966x_main.c
index 95830e3e2b1f,106d8c83544d..000000000000
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@@ -672,8 -687,8 +687,10 @@@ static void lan966x_cleanup_ports(struc
  		lan966x->ana_irq = -ENXIO;
  	}
  
 +	if (lan966x->ptp_irq)
 +		devm_free_irq(lan966x->dev, lan966x->ptp_irq, lan966x);
+ 	if (lan966x->fdma)
+ 		devm_free_irq(lan966x->dev, lan966x->fdma_irq, lan966x);
  }
  
  static int lan966x_probe_port(struct lan966x *lan966x, u32 p,

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice.h

between commit:

  97b0129146b1 ("ice: Fix error with handling of bonding MTU")

from the net tree and commit:

  43113ff73453 ("ice: add TTY for GNSS module for E810T device")

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/ice/ice.h
index 3121f9b04f59,dc42ff92dbad..000000000000
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@@ -481,9 -484,10 +484,11 @@@ enum ice_pf_flags 
  	ICE_FLAG_LEGACY_RX,
  	ICE_FLAG_VF_TRUE_PROMISC_ENA,
  	ICE_FLAG_MDD_AUTO_RESET_VF,
+ 	ICE_FLAG_VF_VLAN_PRUNING,
  	ICE_FLAG_LINK_LENIENT_MODE_ENA,
  	ICE_FLAG_PLUG_AUX_DEV,
 +	ICE_FLAG_MTU_CHANGED,
+ 	ICE_FLAG_GNSS,			/* GNSS successfully initialized */
  	ICE_PF_FLAGS_NBITS		/* must be last */
  };
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/dsa/dsa2.c

between commit:

  afb3cc1a397d ("net: dsa: unlock the rtnl_mutex when dsa_master_setup() fails")

from the net tree and commit:

  e83d56537859 ("net: dsa: replay master state events in dsa_tree_{setup,teardown}_master")

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/dsa2.c
index 074e4a69a728,d5f21a770689..000000000000
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@@ -1064,9 -1078,18 +1078,18 @@@ static int dsa_tree_setup_master(struc
  
  	list_for_each_entry(dp, &dst->ports, list) {
  		if (dsa_port_is_cpu(dp)) {
- 			err = dsa_master_setup(dp->master, dp);
+ 			struct net_device *master = dp->master;
+ 			bool admin_up = (master->flags & IFF_UP) &&
+ 					!qdisc_tx_is_noop(master);
+ 
+ 			err = dsa_master_setup(master, dp);
  			if (err)
 -				return err;
 +				break;
+ 
+ 			/* Replay master state event */
+ 			dsa_tree_master_admin_state_change(dst, master, admin_up);
+ 			dsa_tree_master_oper_state_change(dst, master,
+ 							  netif_oper_up(master));
  		}
  	}
  

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

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

[Tony Lu]

On Wed, Mar 02, 2022 at 11:22:09AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/smc/af_smc.c
> 
> between commit:
> 
>   4d08b7b57ece ("net/smc: Fix cleanup when register ULP fails")
> 
> from the net tree and commit:
> 
>   462791bbfa35 ("net/smc: add sysctl interface for SMC")
> 
> 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 for solving these conflicts. This looks good to me.

Tony Lu

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

[Stephen Rothwell]

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

Hi all,

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

  net/smc/af_smc.c

between commit:

  4d08b7b57ece ("net/smc: Fix cleanup when register ULP fails")

from the net tree and commit:

  462791bbfa35 ("net/smc: add sysctl interface for SMC")

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 284befa90967,6447607675fa..000000000000
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@@ -3087,14 -3287,20 +3293,22 @@@ static int __init smc_init(void
  	rc = tcp_register_ulp(&smc_ulp_ops);
  	if (rc) {
  		pr_err("%s: tcp_ulp_register fails with %d\n", __func__, rc);
 -		goto out_sock;
 +		goto out_ib;
  	}
  
+ 	rc = smc_sysctl_init();
+ 	if (rc) {
+ 		pr_err("%s: sysctl_init fails with %d\n", __func__, rc);
+ 		goto out_ulp;
+ 	}
+ 
  	static_branch_enable(&tcp_have_smc);
  	return 0;
  
+ out_ulp:
+ 	tcp_unregister_ulp(&smc_ulp_ops);
 +out_ib:
 +	smc_ib_unregister_client();
  out_sock:
  	sock_unregister(PF_SMC);
  out_proto6:

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

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

[broonie]

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/act.h
  drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/ct.c

between commits:

  fb7e76ea3f3b6 ("net/mlx5e: TC, Skip redundant ct clear actions")
  c63741b426e11 ("net/mlx5e: Fix MPLSoUDP encap to use MPLS action information")

from the net tree and commits:

  09bf97923224f ("net/mlx5e: TC, Move pedit_headers_action to parse_attr")
  09bf97923224f ("net/mlx5e: TC, Move pedit_headers_action to parse_attr")
  3b49a7edec1df ("net/mlx5e: TC, Reject rules with multiple CT 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.

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/act.h b/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/act.h
index 9cc844bd00f59..9f6a3b7620321 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/act.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/act.h
@@ -17,13 +17,14 @@ struct mlx5e_tc_act_parse_state {
 	struct mlx5e_tc_flow *flow;
 	struct netlink_ext_ack *extack;
 	bool ct_clear;
+	u32 actions;
+	bool ct;
 	bool encap;
 	bool decap;
 	bool mpls_push;
 	bool ptype_host;
 	const struct ip_tunnel_info *tun_info;
 	struct mlx5e_mpls_info mpls_info;
-	struct pedit_headers_action hdrs[__PEDIT_CMD_MAX];
 	int ifindexes[MLX5_MAX_FLOW_FWD_VPORTS];
 	int if_count;
 	struct mlx5_tc_ct_priv *ct_priv;
@@ -32,7 +33,8 @@ struct mlx5e_tc_act_parse_state {
 struct mlx5e_tc_act {
 	bool (*can_offload)(struct mlx5e_tc_act_parse_state *parse_state,
 			    const struct flow_action_entry *act,
-			    int act_index);
+			    int act_index,
+			    struct mlx5_flow_attr *attr);
 
 	int (*parse_action)(struct mlx5e_tc_act_parse_state *parse_state,
 			    const struct flow_action_entry *act,
@@ -42,6 +44,15 @@ struct mlx5e_tc_act {
 	int (*post_parse)(struct mlx5e_tc_act_parse_state *parse_state,
 			  struct mlx5e_priv *priv,
 			  struct mlx5_flow_attr *attr);
+
+	bool (*is_multi_table_act)(struct mlx5e_priv *priv,
+				   const struct flow_action_entry *act,
+				   struct mlx5_flow_attr *attr);
+};
+
+struct mlx5e_tc_flow_action {
+	unsigned int num_entries;
+	struct flow_action_entry **entries;
 };
 
 extern struct mlx5e_tc_act mlx5e_tc_act_drop;
@@ -74,4 +85,19 @@ mlx5e_tc_act_init_parse_state(struct mlx5e_tc_act_parse_state *parse_state,
 			      struct flow_action *flow_action,
 			      struct netlink_ext_ack *extack);
 
+void
+mlx5e_tc_act_reorder_flow_actions(struct flow_action *flow_action,
+				  struct mlx5e_tc_flow_action *flow_action_reorder);
+
+int
+mlx5e_tc_act_post_parse(struct mlx5e_tc_act_parse_state *parse_state,
+			struct flow_action *flow_action,
+			struct mlx5_flow_attr *attr,
+			enum mlx5_flow_namespace_type ns_type);
+
+int
+mlx5e_tc_act_set_next_post_act(struct mlx5e_tc_flow *flow,
+			       struct mlx5_flow_attr *attr,
+			       struct mlx5_flow_attr *next_attr);
+
 #endif /* __MLX5_EN_TC_ACT_H__ */
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/ct.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/ct.c
index 58cc33f1363d2..6e63d898d3d53 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/ct.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc/act/ct.c
@@ -8,13 +8,14 @@
 static bool
 tc_act_can_offload_ct(struct mlx5e_tc_act_parse_state *parse_state,
 		      const struct flow_action_entry *act,
-		      int act_index)
+		      int act_index,
+		      struct mlx5_flow_attr *attr)
 {
+	bool clear_action = act->ct.action & TCA_CT_ACT_CLEAR;
 	struct netlink_ext_ack *extack = parse_state->extack;
 
-	if (flow_flag_test(parse_state->flow, SAMPLE)) {
-		NL_SET_ERR_MSG_MOD(extack,
-				   "Sample action with connection tracking is not supported");
+	if (parse_state->ct && !clear_action) {
+		NL_SET_ERR_MSG_MOD(extack, "Multiple CT actions are not supported");
 		return false;
 	}
 
@@ -40,18 +41,34 @@ tc_act_parse_ct(struct mlx5e_tc_act_parse_state *parse_state,
 	if (err)
 		return err;
 
-	flow_flag_set(parse_state->flow, CT);
 
 	if (mlx5e_is_eswitch_flow(parse_state->flow))
 		attr->esw_attr->split_count = attr->esw_attr->out_count;
 
 	parse_state->ct_clear = clear_action;
+	if (!clear_action) {
+		attr->flags |= MLX5_ATTR_FLAG_CT;
+		flow_flag_set(parse_state->flow, CT);
+		parse_state->ct = true;
+	}
 
 	return 0;
 }
 
+static bool
+tc_act_is_multi_table_act_ct(struct mlx5e_priv *priv,
+			     const struct flow_action_entry *act,
+			     struct mlx5_flow_attr *attr)
+{
+	if (act->ct.action & TCA_CT_ACT_CLEAR)
+		return false;
+
+	return true;
+}
+
 struct mlx5e_tc_act mlx5e_tc_act_ct = {
 	.can_offload = tc_act_can_offload_ct,
 	.parse_action = tc_act_parse_ct,
+	.is_multi_table_act = tc_act_is_multi_table_act_ct,
 };
 

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

[broonie]

Hi all,

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

  tools/testing/selftests/net/mptcp/mptcp_join.sh

between commit:

  6ef84b1517e08 ("selftests: mptcp: more robust signal race test")

from the net tree and commit:

  34aa6e3bccd86 ("selftests: mptcp: add ip mptcp wrappers")

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/net/mptcp/mptcp_join.sh
index 0c8a2a20b96cf,725924012b412..0000000000000
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@@ -1163,20 -1287,17 +1302,21 @@@ signal_address_tests(
  
  	# signal addresses race test
  	reset
- 	ip netns exec $ns1 ./pm_nl_ctl limits 4 4
- 	ip netns exec $ns2 ./pm_nl_ctl limits 4 4
- 	ip netns exec $ns1 ./pm_nl_ctl add 10.0.1.1 flags signal
- 	ip netns exec $ns1 ./pm_nl_ctl add 10.0.2.1 flags signal
- 	ip netns exec $ns1 ./pm_nl_ctl add 10.0.3.1 flags signal
- 	ip netns exec $ns1 ./pm_nl_ctl add 10.0.4.1 flags signal
- 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.1.2 flags signal
- 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.2.2 flags signal
- 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.3.2 flags signal
- 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.4.2 flags signal
++
+ 	pm_nl_set_limits $ns1 4 4
+ 	pm_nl_set_limits $ns2 4 4
+ 	pm_nl_add_endpoint $ns1 10.0.1.1 flags signal
+ 	pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
+ 	pm_nl_add_endpoint $ns1 10.0.3.1 flags signal
+ 	pm_nl_add_endpoint $ns1 10.0.4.1 flags signal
+ 	pm_nl_add_endpoint $ns2 10.0.1.2 flags signal
+ 	pm_nl_add_endpoint $ns2 10.0.2.2 flags signal
+ 	pm_nl_add_endpoint $ns2 10.0.3.2 flags signal
+ 	pm_nl_add_endpoint $ns2 10.0.4.2 flags signal
 -	run_tests $ns1 $ns2 10.0.1.1
 +
 +	# the peer could possibly miss some addr notification, allow retransmission
 +	ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=1
 +	run_tests $ns1 $ns2 10.0.1.1 0 0 0 slow
  	chk_join_nr "signal addresses race test" 3 3 3
  
  	# the server will not signal the address terminating

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

[Stephen Rothwell]

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

Hi all,

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

  include/net/sock.h

between commit:

  8f905c0e7354 ("inet: fully convert sk->sk_rx_dst to RCU rules")

from the net tree and commit:

  43f51df41729 ("net: move early demux fields close to sk_refcnt")

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/sock.h
index d47e9658da28,37f878564d25..000000000000
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -391,6 -392,11 +392,11 @@@ struct sock 
  #define sk_flags		__sk_common.skc_flags
  #define sk_rxhash		__sk_common.skc_rxhash
  
+ 	/* early demux fields */
 -	struct dst_entry	*sk_rx_dst;
++	struct dst_entry __rcu	*sk_rx_dst;
+ 	int			sk_rx_dst_ifindex;
+ 	u32			sk_rx_dst_cookie;
+ 
  	socket_lock_t		sk_lock;
  	atomic_t		sk_drops;
  	int			sk_rcvlowat;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice_devids.h

between commit:

  7dcf78b870be ("ice: Add missing E810 device ids")

from the net tree and commit:

  885fe6932a11 ("ice: Add support for SMA control multiplexer")

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/ice/ice_devids.h
index ef4392e6e244,8d2c39ee775b..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_devids.h
+++ b/drivers/net/ethernet/intel/ice/ice_devids.h
@@@ -21,10 -21,8 +21,12 @@@
  #define ICE_DEV_ID_E810C_QSFP		0x1592
  /* Intel(R) Ethernet Controller E810-C for SFP */
  #define ICE_DEV_ID_E810C_SFP		0x1593
+ #define ICE_SUBDEV_ID_E810T		0x000E
+ #define ICE_SUBDEV_ID_E810T2		0x000F
 +/* Intel(R) Ethernet Controller E810-XXV for backplane */
 +#define ICE_DEV_ID_E810_XXV_BACKPLANE	0x1599
 +/* Intel(R) Ethernet Controller E810-XXV for QSFP */
 +#define ICE_DEV_ID_E810_XXV_QSFP	0x159A
  /* Intel(R) Ethernet Controller E810-XXV for SFP */
  #define ICE_DEV_ID_E810_XXV_SFP		0x159B
  /* Intel(R) Ethernet Connection E823-C for backplane */

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

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

[Ido Schimmel]

On Mon, Oct 18, 2021 at 10:51:51AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/net/forwarding/forwarding.config.sample
> 
> between commit:
> 
>   0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")
> 
> from the net tree and commit:
> 
>   45d45e5323a9 ("testing: selftests: forwarding.config.sample: Add tc flag")
> 
> 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!

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice_devlink.c

between commit:

  b726ddf984a5 ("ice: Print the api_patch as part of the fw.mgmt.api")

from the net tree and commit:

  0128cc6e928d ("ice: refactor devlink getter/fallback functions to void")

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/ice/ice_devlink.c
index da7288bdc9a3,55353bf4cbef..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_devlink.c
+++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
@@@ -63,13 -60,11 +60,11 @@@ static void ice_info_fw_api(struct ice_
  {
  	struct ice_hw *hw = &pf->hw;
  
 -	snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u",
 -		 hw->api_maj_ver, hw->api_min_ver);
 +	snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u", hw->api_maj_ver,
 +		 hw->api_min_ver, hw->api_patch);
- 
- 	return 0;
  }
  
- static int ice_info_fw_build(struct ice_pf *pf, struct ice_info_ctx *ctx)
+ static void ice_info_fw_build(struct ice_pf *pf, struct ice_info_ctx *ctx)
  {
  	struct ice_hw *hw = &pf->hw;
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/forwarding/forwarding.config.sample

between commit:

  0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")

from the net tree and commit:

  45d45e5323a9 ("testing: selftests: forwarding.config.sample: Add tc flag")

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/forwarding/forwarding.config.sample
index e5e2fbeca22e,10ce3720aa6f..000000000000
--- a/tools/testing/selftests/net/forwarding/forwarding.config.sample
+++ b/tools/testing/selftests/net/forwarding/forwarding.config.sample
@@@ -39,5 -39,6 +39,8 @@@ NETIF_CREATE=ye
  # Timeout (in seconds) before ping exits regardless of how many packets have
  # been sent or received
  PING_TIMEOUT=5
 +# IPv6 traceroute utility name.
 +TROUTE6=traceroute6
+ # Flag for tc match, supposed to be skip_sw/skip_hw which means do not process
+ # filter by software/hardware
+ TC_FLAG=skip_hw

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/ioam6.sh

between commit:

  7b1700e009cc ("selftests: net: modify IOAM tests for undef bits")

from the net tree and commit:

  bf77b1400a56 ("selftests: net: Test for the IOAM encapsulation with IPv6")

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/ioam6.sh
index a2489ec398fe,90700303d8a9..000000000000
--- a/tools/testing/selftests/net/ioam6.sh
+++ b/tools/testing/selftests/net/ioam6.sh
@@@ -465,31 -529,21 +529,36 @@@ out_bits(
    local tmp=${bit2size[22]}
    bit2size[22]=$(( $tmp + ${#ALPHA[9]} + ((4 - (${#ALPHA[9]} % 4)) % 4) ))
  
+   [ "$1" = "encap" ] && mode="$1 tundst db01::1" || mode="$1"
+   [ "$1" = "encap" ] && ip -netns ioam-node-beta link set ip6tnl0 up
+ 
    for i in {0..22}
    do
-     ip -netns ioam-node-alpha route change db01::/64 encap ioam6 trace \
-            prealloc type ${bit2type[$i]} ns 123 size ${bit2size[$i]} \
+     ip -netns ioam-node-alpha route change db01::/64 encap ioam6 mode $mode \
+            trace prealloc type ${bit2type[$i]} ns 123 size ${bit2size[$i]} \
 -           dev veth0
 +           dev veth0 &>/dev/null
 +
 +    local cmd_res=$?
 +    local descr="${desc/<n>/$i}"
  
 -    run_test "out_bit$i" "${desc/<n>/$i} ($1 mode)" ioam-node-alpha \
 +    if [[ $i -ge 12 && $i -le 21 ]]
 +    then
 +      if [ $cmd_res != 0 ]
 +      then
 +        npassed=$((npassed+1))
 +        log_test_passed "$descr"
 +      else
 +        nfailed=$((nfailed+1))
 +        log_test_failed "$descr"
 +      fi
 +    else
-       run_test "out_bit$i" "$descr" ioam-node-alpha ioam-node-beta \
-              db01::2 db01::1 veth0 ${bit2type[$i]} 123
++      run_test "out_bit$i" "$descr ($1 mode)" ioam-node-alpha \
+            ioam-node-beta db01::2 db01::1 veth0 ${bit2type[$i]} 123
 +    fi
    done
  
+   [ "$1" = "encap" ] && ip -netns ioam-node-beta link set ip6tnl0 down
+ 
    bit2size[22]=$tmp
  }
  
@@@ -560,15 -629,21 +644,21 @@@ in_bits(
    local tmp=${bit2size[22]}
    bit2size[22]=$(( $tmp + ${#BETA[9]} + ((4 - (${#BETA[9]} % 4)) % 4) ))
  
+   [ "$1" = "encap" ] && mode="$1 tundst db01::1" || mode="$1"
+   [ "$1" = "encap" ] && ip -netns ioam-node-beta link set ip6tnl0 up
+ 
 -  for i in {0..22}
 +  for i in {0..11} {22..22}
    do
-     ip -netns ioam-node-alpha route change db01::/64 encap ioam6 trace \
-            prealloc type ${bit2type[$i]} ns 123 size ${bit2size[$i]} dev veth0
+     ip -netns ioam-node-alpha route change db01::/64 encap ioam6 mode $mode \
+            trace prealloc type ${bit2type[$i]} ns 123 size ${bit2size[$i]} \
+            dev veth0
  
-     run_test "in_bit$i" "${desc/<n>/$i}" ioam-node-alpha ioam-node-beta \
-            db01::2 db01::1 veth0 ${bit2type[$i]} 123
+     run_test "in_bit$i" "${desc/<n>/$i} ($1 mode)" ioam-node-alpha \
+            ioam-node-beta db01::2 db01::1 veth0 ${bit2type[$i]} 123
    done
  
+   [ "$1" = "encap" ] && ip -netns ioam-node-beta link set ip6tnl0 down
+ 
    bit2size[22]=$tmp
  }
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/phy/bcm7xxx.c

between commit:

  d88fd1b546ff ("net: phy: bcm7xxx: Fixed indirect MMD operations")

from the net tree and commit:

  f68d08c437f9 ("net: phy: bcm7xxx: Add EPHY entry for 72165")

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/bcm7xxx.c
index 27b6a3f507ae,3a29a1493ff1..000000000000
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@@ -415,93 -398,190 +415,277 @@@ static int bcm7xxx_28nm_ephy_config_ini
  	return bcm7xxx_28nm_ephy_apd_enable(phydev);
  }
  
 +#define MII_BCM7XXX_REG_INVALID	0xff
 +
 +static u8 bcm7xxx_28nm_ephy_regnum_to_shd(u16 regnum)
 +{
 +	switch (regnum) {
 +	case MDIO_CTRL1:
 +		return MII_BCM7XXX_SHD_3_PCS_CTRL;
 +	case MDIO_STAT1:
 +		return MII_BCM7XXX_SHD_3_PCS_STATUS;
 +	case MDIO_PCS_EEE_ABLE:
 +		return MII_BCM7XXX_SHD_3_EEE_CAP;
 +	case MDIO_AN_EEE_ADV:
 +		return MII_BCM7XXX_SHD_3_AN_EEE_ADV;
 +	case MDIO_AN_EEE_LPABLE:
 +		return MII_BCM7XXX_SHD_3_EEE_LP;
 +	case MDIO_PCS_EEE_WK_ERR:
 +		return MII_BCM7XXX_SHD_3_EEE_WK_ERR;
 +	default:
 +		return MII_BCM7XXX_REG_INVALID;
 +	}
 +}
 +
 +static bool bcm7xxx_28nm_ephy_dev_valid(int devnum)
 +{
 +	return devnum == MDIO_MMD_AN || devnum == MDIO_MMD_PCS;
 +}
 +
 +static int bcm7xxx_28nm_ephy_read_mmd(struct phy_device *phydev,
 +				      int devnum, u16 regnum)
 +{
 +	u8 shd = bcm7xxx_28nm_ephy_regnum_to_shd(regnum);
 +	int ret;
 +
 +	if (!bcm7xxx_28nm_ephy_dev_valid(devnum) ||
 +	    shd == MII_BCM7XXX_REG_INVALID)
 +		return -EOPNOTSUPP;
 +
 +	/* set shadow mode 2 */
 +	ret = __phy_set_clr_bits(phydev, MII_BCM7XXX_TEST,
 +				 MII_BCM7XXX_SHD_MODE_2, 0);
 +	if (ret < 0)
 +		return ret;
 +
 +	/* Access the desired shadow register address */
 +	ret = __phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, shd);
 +	if (ret < 0)
 +		goto reset_shadow_mode;
 +
 +	ret = __phy_read(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT);
 +
 +reset_shadow_mode:
 +	/* reset shadow mode 2 */
 +	__phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, 0,
 +			   MII_BCM7XXX_SHD_MODE_2);
 +	return ret;
 +}
 +
 +static int bcm7xxx_28nm_ephy_write_mmd(struct phy_device *phydev,
 +				       int devnum, u16 regnum, u16 val)
 +{
 +	u8 shd = bcm7xxx_28nm_ephy_regnum_to_shd(regnum);
 +	int ret;
 +
 +	if (!bcm7xxx_28nm_ephy_dev_valid(devnum) ||
 +	    shd == MII_BCM7XXX_REG_INVALID)
 +		return -EOPNOTSUPP;
 +
 +	/* set shadow mode 2 */
 +	ret = __phy_set_clr_bits(phydev, MII_BCM7XXX_TEST,
 +				 MII_BCM7XXX_SHD_MODE_2, 0);
 +	if (ret < 0)
 +		return ret;
 +
 +	/* Access the desired shadow register address */
 +	ret = __phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, shd);
 +	if (ret < 0)
 +		goto reset_shadow_mode;
 +
 +	/* Write the desired value in the shadow register */
 +	__phy_write(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT, val);
 +
 +reset_shadow_mode:
 +	/* reset shadow mode 2 */
 +	return __phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, 0,
 +				  MII_BCM7XXX_SHD_MODE_2);
 +}
 +
+ static int bcm7xxx_16nm_ephy_afe_config(struct phy_device *phydev)
+ {
+ 	int tmp, rcalcode, rcalnewcodelp, rcalnewcode11, rcalnewcode11d2;
+ 
+ 	/* Reset PHY */
+ 	tmp = genphy_soft_reset(phydev);
+ 	if (tmp)
+ 		return tmp;
+ 
+ 	/* Reset AFE and PLL */
+ 	bcm_phy_write_exp_sel(phydev, 0x0003, 0x0006);
+ 	/* Clear reset */
+ 	bcm_phy_write_exp_sel(phydev, 0x0003, 0x0000);
+ 
+ 	/* Write PLL/AFE control register to select 54MHz crystal */
+ 	bcm_phy_write_misc(phydev, 0x0030, 0x0001, 0x0000);
+ 	bcm_phy_write_misc(phydev, 0x0031, 0x0000, 0x044a);
+ 
+ 	/* Change Ka,Kp,Ki to pdiv=1 */
+ 	bcm_phy_write_misc(phydev, 0x0033, 0x0002, 0x71a1);
+ 	/* Configuration override */
+ 	bcm_phy_write_misc(phydev, 0x0033, 0x0001, 0x8000);
+ 
+ 	/* Change PLL_NDIV and PLL_NUDGE */
+ 	bcm_phy_write_misc(phydev, 0x0031, 0x0001, 0x2f68);
+ 	bcm_phy_write_misc(phydev, 0x0031, 0x0002, 0x0000);
+ 
+ 	/* Reference frequency is 54Mhz, config_mode[15:14] = 3 (low
+ 	 * phase)
+ 	 */
+ 	bcm_phy_write_misc(phydev, 0x0030, 0x0003, 0xc036);
+ 
+ 	/* Initialize bypass mode */
+ 	bcm_phy_write_misc(phydev, 0x0032, 0x0003, 0x0000);
+ 	/* Bypass code, default: VCOCLK enabled */
+ 	bcm_phy_write_misc(phydev, 0x0033, 0x0000, 0x0002);
+ 	/* LDOs at default setting */
+ 	bcm_phy_write_misc(phydev, 0x0030, 0x0002, 0x01c0);
+ 	/* Release PLL reset */
+ 	bcm_phy_write_misc(phydev, 0x0030, 0x0001, 0x0001);
+ 
+ 	/* Bandgap curvature correction to correct default */
+ 	bcm_phy_write_misc(phydev, 0x0038, 0x0000, 0x0010);
+ 
+ 	/* Run RCAL */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0003, 0x0038);
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0003, 0x003b);
+ 	udelay(2);
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0003, 0x003f);
+ 	mdelay(5);
+ 
+ 	/* AFE_CAL_CONFIG_0, Vref=1000, Target=10, averaging enabled */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0001, 0x1c82);
+ 	/* AFE_CAL_CONFIG_0, no reset and analog powerup */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0001, 0x9e82);
+ 	udelay(2);
+ 	/* AFE_CAL_CONFIG_0, start calibration */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0001, 0x9f82);
+ 	udelay(100);
+ 	/* AFE_CAL_CONFIG_0, clear start calibration, set HiBW */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0001, 0x9e86);
+ 	udelay(2);
+ 	/* AFE_CAL_CONFIG_0, start calibration with hi BW mode set */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0001, 0x9f86);
+ 	udelay(100);
+ 
+ 	/* Adjust 10BT amplitude additional +7% and 100BT +2% */
+ 	bcm_phy_write_misc(phydev, 0x0038, 0x0001, 0xe7ea);
+ 	/* Adjust 1G mode amplitude and 1G testmode1 */
+ 	bcm_phy_write_misc(phydev, 0x0038, 0x0002, 0xede0);
+ 
+ 	/* Read CORE_EXPA9 */
+ 	tmp = bcm_phy_read_exp(phydev, 0x00a9);
+ 	/* CORE_EXPA9[6:1] is rcalcode[5:0] */
+ 	rcalcode = (tmp & 0x7e) / 2;
+ 	/* Correct RCAL code + 1 is -1% rprogr, LP: +16 */
+ 	rcalnewcodelp = rcalcode + 16;
+ 	/* Correct RCAL code + 1 is -15 rprogr, 11: +10 */
+ 	rcalnewcode11 = rcalcode + 10;
+ 	/* Saturate if necessary */
+ 	if (rcalnewcodelp > 0x3f)
+ 		rcalnewcodelp = 0x3f;
+ 	if (rcalnewcode11 > 0x3f)
+ 		rcalnewcode11 = 0x3f;
+ 	/* REXT=1 BYP=1 RCAL_st1<5:0>=new rcal code */
+ 	tmp = 0x00f8 + rcalnewcodelp * 256;
+ 	/* Program into AFE_CAL_CONFIG_2 */
+ 	bcm_phy_write_misc(phydev, 0x0039, 0x0003, tmp);
+ 	/* AFE_BIAS_CONFIG_0 10BT bias code (Bias: E4) */
+ 	bcm_phy_write_misc(phydev, 0x0038, 0x0001, 0xe7e4);
+ 	/* invert adc clock output and 'adc refp ldo current To correct
+ 	 * default
+ 	 */
+ 	bcm_phy_write_misc(phydev, 0x003b, 0x0000, 0x8002);
+ 	/* 100BT stair case, high BW, 1G stair case, alternate encode */
+ 	bcm_phy_write_misc(phydev, 0x003c, 0x0003, 0xf882);
+ 	/* 1000BT DAC transition method per Erol, bits[32], DAC Shuffle
+ 	 * sequence 1 + 10BT imp adjust bits
+ 	 */
+ 	bcm_phy_write_misc(phydev, 0x003d, 0x0000, 0x3201);
+ 	/* Non-overlap fix */
+ 	bcm_phy_write_misc(phydev, 0x003a, 0x0002, 0x0c00);
+ 
+ 	/* pwdb override (rxconfig<5>) to turn on RX LDO indpendent of
+ 	 * pwdb controls from DSP_TAP10
+ 	 */
+ 	bcm_phy_write_misc(phydev, 0x003a, 0x0001, 0x0020);
+ 
+ 	/* Remove references to channel 2 and 3 */
+ 	bcm_phy_write_misc(phydev, 0x003b, 0x0002, 0x0000);
+ 	bcm_phy_write_misc(phydev, 0x003b, 0x0003, 0x0000);
+ 
+ 	/* Set cal_bypassb bit rxconfig<43> */
+ 	bcm_phy_write_misc(phydev, 0x003a, 0x0003, 0x0800);
+ 	udelay(2);
+ 
+ 	/* Revert pwdb_override (rxconfig<5>) to 0 so that the RX pwr
+ 	 * is controlled by DSP.
+ 	 */
+ 	bcm_phy_write_misc(phydev, 0x003a, 0x0001, 0x0000);
+ 
+ 	/* Drop LSB */
+ 	rcalnewcode11d2 = (rcalnewcode11 & 0xfffe) / 2;
+ 	tmp = bcm_phy_read_misc(phydev, 0x003d, 0x0001);
+ 	/* Clear bits [11:5] */
+ 	tmp &= ~0xfe0;
+ 	/* set txcfg_ch0<5>=1 (enable + set local rcal) */
+ 	tmp |= 0x0020 | (rcalnewcode11d2 * 64);
+ 	bcm_phy_write_misc(phydev, 0x003d, 0x0001, tmp);
+ 	bcm_phy_write_misc(phydev, 0x003d, 0x0002, tmp);
+ 
+ 	tmp = bcm_phy_read_misc(phydev, 0x003d, 0x0000);
+ 	/* set txcfg<45:44>=11 (enable Rextra + invert fullscaledetect)
+ 	 */
+ 	tmp &= ~0x3000;
+ 	tmp |= 0x3000;
+ 	bcm_phy_write_misc(phydev, 0x003d, 0x0000, tmp);
+ 
+ 	return 0;
+ }
+ 
+ static int bcm7xxx_16nm_ephy_config_init(struct phy_device *phydev)
+ {
+ 	int ret, val;
+ 
+ 	ret = bcm7xxx_16nm_ephy_afe_config(phydev);
+ 	if (ret)
+ 		return ret;
+ 
+ 	ret = bcm_phy_set_eee(phydev, true);
+ 	if (ret)
+ 		return ret;
+ 
+ 	ret = bcm_phy_read_shadow(phydev, BCM54XX_SHD_SCR3);
+ 	if (ret < 0)
+ 		return ret;
+ 
+ 	val = ret;
+ 
+ 	/* Auto power down of DLL enabled,
+ 	 * TXC/RXC disabled during auto power down.
+ 	 */
+ 	val &= ~BCM54XX_SHD_SCR3_DLLAPD_DIS;
+ 	val |= BIT(8);
+ 
+ 	ret = bcm_phy_write_shadow(phydev, BCM54XX_SHD_SCR3, val);
+ 	if (ret < 0)
+ 		return ret;
+ 
+ 	return bcm_phy_enable_apd(phydev, true);
+ }
+ 
+ static int bcm7xxx_16nm_ephy_resume(struct phy_device *phydev)
+ {
+ 	int ret;
+ 
+ 	/* Re-apply workarounds coming out suspend/resume */
+ 	ret = bcm7xxx_16nm_ephy_config_init(phydev);
+ 	if (ret)
+ 		return ret;
+ 
+ 	return genphy_config_aneg(phydev);
+ }
+ 
  static int bcm7xxx_28nm_ephy_resume(struct phy_device *phydev)
  {
  	int ret;

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/netdevice.h
  net/socket.c

between commit:

  d0efb16294d1 ("net: don't unconditionally copy_from_user a struct ifreq for socket ioctls")

from the net tree and commits:

  876f0bf9d0d5 ("net: socket: simplify dev_ifconf handling")
  29c4964822aa ("net: socket: rework compat_ifreq_ioctl()")

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 d65ce093e5a7,6fd3a4d42668..000000000000
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@@ -4012,14 -4027,12 +4027,16 @@@ int netdev_rx_handler_register(struct n
  void netdev_rx_handler_unregister(struct net_device *dev);
  
  bool dev_valid_name(const char *name);
 +static inline bool is_socket_ioctl_cmd(unsigned int cmd)
 +{
 +	return _IOC_TYPE(cmd) == SOCK_IOC_TYPE;
 +}
+ int get_user_ifreq(struct ifreq *ifr, void __user **ifrdata, void __user *arg);
+ int put_user_ifreq(struct ifreq *ifr, void __user *arg);
  int dev_ioctl(struct net *net, unsigned int cmd, struct ifreq *ifr,
- 		bool *need_copyout);
- int dev_ifconf(struct net *net, struct ifconf *, int);
- int dev_ethtool(struct net *net, struct ifreq *);
+ 		void __user *data, bool *need_copyout);
+ int dev_ifconf(struct net *net, struct ifconf __user *ifc);
+ int dev_ethtool(struct net *net, struct ifreq *ifr, void __user *userdata);
  unsigned int dev_get_flags(const struct net_device *);
  int __dev_change_flags(struct net_device *dev, unsigned int flags,
  		       struct netlink_ext_ack *extack);
diff --cc net/socket.c
index 8808b3617dac,3c10504e46d9..000000000000
--- a/net/socket.c
+++ b/net/socket.c
@@@ -1100,27 -1124,13 +1124,16 @@@ static long sock_do_ioctl(struct net *n
  	if (err != -ENOIOCTLCMD)
  		return err;
  
- 	if (cmd == SIOCGIFCONF) {
- 		struct ifconf ifc;
- 		if (copy_from_user(&ifc, argp, sizeof(struct ifconf)))
- 			return -EFAULT;
- 		rtnl_lock();
- 		err = dev_ifconf(net, &ifc, sizeof(struct ifreq));
- 		rtnl_unlock();
- 		if (!err && copy_to_user(argp, &ifc, sizeof(struct ifconf)))
- 			err = -EFAULT;
- 	} else if (is_socket_ioctl_cmd(cmd)) {
- 		struct ifreq ifr;
- 		bool need_copyout;
- 		if (copy_from_user(&ifr, argp, sizeof(struct ifreq)))
++	if (!is_socket_ioctl_cmd(cmd))
++		return -ENOTTY;
++
+ 	if (get_user_ifreq(&ifr, &data, argp))
+ 		return -EFAULT;
+ 	err = dev_ioctl(net, cmd, &ifr, data, &need_copyout);
+ 	if (!err && need_copyout)
+ 		if (put_user_ifreq(&ifr, argp))
  			return -EFAULT;
- 		err = dev_ioctl(net, cmd, &ifr, &need_copyout);
- 		if (!err && need_copyout)
- 			if (copy_to_user(argp, &ifr, sizeof(struct ifreq)))
- 				return -EFAULT;
- 	} else {
- 		err = -ENOTTY;
- 	}
+ 
  	return err;
  }
  
@@@ -3306,99 -3216,13 +3219,15 @@@ static int compat_ifr_data_ioctl(struc
  				 struct compat_ifreq __user *u_ifreq32)
  {
  	struct ifreq ifreq;
- 	u32 data32;
+ 	void __user *data;
  
 +	if (!is_socket_ioctl_cmd(cmd))
 +		return -ENOTTY;
- 	if (copy_from_user(ifreq.ifr_name, u_ifreq32->ifr_name, IFNAMSIZ))
- 		return -EFAULT;
- 	if (get_user(data32, &u_ifreq32->ifr_data))
- 		return -EFAULT;
- 	ifreq.ifr_data = compat_ptr(data32);
- 
- 	return dev_ioctl(net, cmd, &ifreq, NULL);
- }
- 
- static int compat_ifreq_ioctl(struct net *net, struct socket *sock,
- 			      unsigned int cmd,
- 			      struct compat_ifreq __user *uifr32)
- {
- 	struct ifreq __user *uifr;
- 	int err;
- 
- 	/* Handle the fact that while struct ifreq has the same *layout* on
- 	 * 32/64 for everything but ifreq::ifru_ifmap and ifreq::ifru_data,
- 	 * which are handled elsewhere, it still has different *size* due to
- 	 * ifreq::ifru_ifmap (which is 16 bytes on 32 bit, 24 bytes on 64-bit,
- 	 * resulting in struct ifreq being 32 and 40 bytes respectively).
- 	 * As a result, if the struct happens to be at the end of a page and
- 	 * the next page isn't readable/writable, we get a fault. To prevent
- 	 * that, copy back and forth to the full size.
- 	 */
- 
- 	uifr = compat_alloc_user_space(sizeof(*uifr));
- 	if (copy_in_user(uifr, uifr32, sizeof(*uifr32)))
- 		return -EFAULT;
- 
- 	err = sock_do_ioctl(net, sock, cmd, (unsigned long)uifr);
- 
- 	if (!err) {
- 		switch (cmd) {
- 		case SIOCGIFFLAGS:
- 		case SIOCGIFMETRIC:
- 		case SIOCGIFMTU:
- 		case SIOCGIFMEM:
- 		case SIOCGIFHWADDR:
- 		case SIOCGIFINDEX:
- 		case SIOCGIFADDR:
- 		case SIOCGIFBRDADDR:
- 		case SIOCGIFDSTADDR:
- 		case SIOCGIFNETMASK:
- 		case SIOCGIFPFLAGS:
- 		case SIOCGIFTXQLEN:
- 		case SIOCGMIIPHY:
- 		case SIOCGMIIREG:
- 		case SIOCGIFNAME:
- 			if (copy_in_user(uifr32, uifr, sizeof(*uifr32)))
- 				err = -EFAULT;
- 			break;
- 		}
- 	}
- 	return err;
- }
- 
- static int compat_sioc_ifmap(struct net *net, unsigned int cmd,
- 			struct compat_ifreq __user *uifr32)
- {
- 	struct ifreq ifr;
- 	struct compat_ifmap __user *uifmap32;
- 	int err;
- 
- 	uifmap32 = &uifr32->ifr_ifru.ifru_map;
- 	err = copy_from_user(&ifr, uifr32, sizeof(ifr.ifr_name));
- 	err |= get_user(ifr.ifr_map.mem_start, &uifmap32->mem_start);
- 	err |= get_user(ifr.ifr_map.mem_end, &uifmap32->mem_end);
- 	err |= get_user(ifr.ifr_map.base_addr, &uifmap32->base_addr);
- 	err |= get_user(ifr.ifr_map.irq, &uifmap32->irq);
- 	err |= get_user(ifr.ifr_map.dma, &uifmap32->dma);
- 	err |= get_user(ifr.ifr_map.port, &uifmap32->port);
- 	if (err)
+ 	if (get_user_ifreq(&ifreq, &data, u_ifreq32))
  		return -EFAULT;
+ 	ifreq.ifr_data = data;
  
- 	err = dev_ioctl(net, cmd, &ifr, NULL);
- 
- 	if (cmd == SIOCGIFMAP && !err) {
- 		err = copy_to_user(uifr32, &ifr, sizeof(ifr.ifr_name));
- 		err |= put_user(ifr.ifr_map.mem_start, &uifmap32->mem_start);
- 		err |= put_user(ifr.ifr_map.mem_end, &uifmap32->mem_end);
- 		err |= put_user(ifr.ifr_map.base_addr, &uifmap32->base_addr);
- 		err |= put_user(ifr.ifr_map.irq, &uifmap32->irq);
- 		err |= put_user(ifr.ifr_map.dma, &uifmap32->dma);
- 		err |= put_user(ifr.ifr_map.port, &uifmap32->port);
- 		if (err)
- 			err = -EFAULT;
- 	}
- 	return err;
+ 	return dev_ioctl(net, cmd, &ifreq, data, NULL);
  }
  
  /* Since old style bridge ioctl's endup using SIOCDEVPRIVATE

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

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

[Andy Shevchenko]

On Tue, Aug 17, 2021 at 02:16:43PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/ptp/Kconfig
> 
> between commit:
> 
>   55c8fca1dae1 ("ptp_pch: Restore dependency on PCI")
> 
> from the net tree and commit:
> 
>   e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies")
> 
> 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, the result is correct.

> diff --cc drivers/ptp/Kconfig
> index e085c255da0c,823eae1b4b53..000000000000
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@@ -90,9 -103,8 +103,9 @@@ config PTP_1588_CLOCK_INE
>   config PTP_1588_CLOCK_PCH
>   	tristate "Intel PCH EG20T as PTP clock"
>   	depends on X86_32 || COMPILE_TEST
>  -	depends on HAS_IOMEM && NET
>  +	depends on HAS_IOMEM && PCI
>  +	depends on NET
> - 	imply PTP_1588_CLOCK
> + 	depends on PTP_1588_CLOCK
>   	help
>   	  This driver adds support for using the PCH EG20T as a PTP
>   	  clock. The hardware supports time stamping of PTP packets



-- 
With Best Regards,
Andy Shevchenko

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/ptp/Kconfig

between commit:

  55c8fca1dae1 ("ptp_pch: Restore dependency on PCI")

from the net tree and commit:

  e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies")

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/ptp/Kconfig
index e085c255da0c,823eae1b4b53..000000000000
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@@ -90,9 -103,8 +103,9 @@@ config PTP_1588_CLOCK_INE
  config PTP_1588_CLOCK_PCH
  	tristate "Intel PCH EG20T as PTP clock"
  	depends on X86_32 || COMPILE_TEST
 -	depends on HAS_IOMEM && NET
 +	depends on HAS_IOMEM && PCI
 +	depends on NET
- 	imply PTP_1588_CLOCK
+ 	depends on PTP_1588_CLOCK
  	help
  	  This driver adds support for using the PCH EG20T as a PTP
  	  clock. The hardware supports time stamping of PTP packets

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

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  5957cc557dc5 ("net/mlx5: Set all field of mlx5_irq before inserting it to the xarray")

from the net tree and commit:

  2d0b41a37679 ("net/mlx5: Refcount mlx5_irq with integer")

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/pci_irq.c
index 3465b363fc2f,60bfcad1873c..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c
@@@ -214,8 -234,7 +234,8 @@@ static struct mlx5_irq *irq_request(str
  		err = -ENOMEM;
  		goto err_cpumask;
  	}
 +	irq->pool = pool;
- 	kref_init(&irq->kref);
+ 	irq->refcount = 1;
  	irq->index = i;
  	err = xa_err(xa_store(&pool->irqs, irq->index, irq, GFP_KERNEL));
  	if (err) {
@@@ -459,10 -475,13 +478,14 @@@ static void irq_pool_free(struct mlx5_i
  	struct mlx5_irq *irq;
  	unsigned long index;
  
+ 	/* There are cases in which we are destrying the irq_table before
+ 	 * freeing all the IRQs, fast teardown for example. Hence, free the irqs
+ 	 * which might not have been freed.
+ 	 */
  	xa_for_each(&pool->irqs, index, irq)
- 		irq_release(&irq->kref);
+ 		irq_release(irq);
  	xa_destroy(&pool->irqs);
 +	mutex_destroy(&pool->lock);
  	kvfree(pool);
  }
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  MAINTAINERS

between commit:

  7b637cd52f02 ("MAINTAINERS: fix Microchip CAN BUS Analyzer Tool entry typo")

from the net tree and commit:

  7d901a1e878a ("net: phy: add Maxlinear GPY115/21x/24x driver")

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 MAINTAINERS
index 9d7bc544a49d,41fcfdb24a81..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -11339,7 -11341,13 +11353,13 @@@ W:	https://linuxtv.or
  T:	git git://linuxtv.org/media_tree.git
  F:	drivers/media/radio/radio-maxiradio*
  
+ MAXLINEAR ETHERNET PHY DRIVER
+ M:	Xu Liang <lxu@maxlinear.com>
+ L:	netdev@vger.kernel.org
+ S:	Supported
+ F:	drivers/net/phy/mxl-gpy.c
+ 
 -MCAB MICROCHIP CAN BUS ANALYZER TOOL DRIVER
 +MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
  R:	Yasushi SHOJI <yashi@spacecubics.com>
  L:	linux-can@vger.kernel.org
  S:	Maintained

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/bpf-cgroup.h
  kernel/bpf/helpers.c

between commit:

  a2baf4e8bb0f ("bpf: Fix potentially incorrect results with bpf_get_local_storage()")

from the net tree and commit:

  c7603cfa04e7 ("bpf: Add ambient BPF runtime context stored in current")

from the net-next tree.

The latter removed the code that the former modified.

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h

between commit:

  9e26680733d5 ("bnxt_en: Update firmware call to retrieve TX PTP timestamp")

from the net tree and commits:

  9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins")
  099fdeda659d ("bnxt_en: Event handler for PPS events")

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/broadcom/bnxt/bnxt_ptp.h
index 524f1c272054,cc3cdbaab6cf..000000000000
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h
@@@ -19,9 -19,58 +19,59 @@@
  
  #define BNXT_PTP_QTS_TIMEOUT	1000
  #define BNXT_PTP_QTS_TX_ENABLES	(PORT_TS_QUERY_REQ_ENABLES_PTP_SEQ_ID |	\
 -				 PORT_TS_QUERY_REQ_ENABLES_TS_REQ_TIMEOUT)
 +				 PORT_TS_QUERY_REQ_ENABLES_TS_REQ_TIMEOUT | \
 +				 PORT_TS_QUERY_REQ_ENABLES_PTP_HDR_OFFSET)
  
+ struct pps_pin {
+ 	u8 event;
+ 	u8 usage;
+ 	u8 state;
+ };
+ 
+ #define TSIO_PIN_VALID(pin) ((pin) < (BNXT_MAX_TSIO_PINS))
+ 
+ #define EVENT_DATA2_PPS_EVENT_TYPE(data2)				\
+ 	((data2) & ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA2_EVENT_TYPE)
+ 
+ #define EVENT_DATA2_PPS_PIN_NUM(data2)					\
+ 	(((data2) &							\
+ 	  ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA2_PIN_NUMBER_MASK) >>\
+ 	 ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA2_PIN_NUMBER_SFT)
+ 
+ #define BNXT_DATA2_UPPER_MSK						\
+ 	ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA2_PPS_TIMESTAMP_UPPER_MASK
+ 
+ #define BNXT_DATA2_UPPER_SFT						\
+ 	(32 -								\
+ 	 ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA2_PPS_TIMESTAMP_UPPER_SFT)
+ 
+ #define BNXT_DATA1_LOWER_MSK						\
+ 	ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA1_PPS_TIMESTAMP_LOWER_MASK
+ 
+ #define BNXT_DATA1_LOWER_SFT						\
+ 	  ASYNC_EVENT_CMPL_PPS_TIMESTAMP_EVENT_DATA1_PPS_TIMESTAMP_LOWER_SFT
+ 
+ #define EVENT_PPS_TS(data2, data1)					\
+ 	(((u64)((data2) & BNXT_DATA2_UPPER_MSK) << BNXT_DATA2_UPPER_SFT) |\
+ 	 (((data1) & BNXT_DATA1_LOWER_MSK) >> BNXT_DATA1_LOWER_SFT))
+ 
+ #define BNXT_PPS_PIN_DISABLE	0
+ #define BNXT_PPS_PIN_ENABLE	1
+ #define BNXT_PPS_PIN_NONE	0
+ #define BNXT_PPS_PIN_PPS_IN	1
+ #define BNXT_PPS_PIN_PPS_OUT	2
+ #define BNXT_PPS_PIN_SYNC_IN	3
+ #define BNXT_PPS_PIN_SYNC_OUT	4
+ 
+ #define BNXT_PPS_EVENT_INTERNAL	1
+ #define BNXT_PPS_EVENT_EXTERNAL	2
+ 
+ struct bnxt_pps {
+ 	u8 num_pins;
+ #define BNXT_MAX_TSIO_PINS	4
+ 	struct pps_pin pins[BNXT_MAX_TSIO_PINS];
+ };
+ 
  struct bnxt_ptp_cfg {
  	struct ptp_clock_info	ptp_info;
  	struct ptp_clock	*ptp_clock;
@@@ -76,7 -125,9 +127,9 @@@ do {						
  	((dst) = READ_ONCE(src))
  #endif
  
 -int bnxt_ptp_parse(struct sk_buff *skb, u16 *seq_id);
 +int bnxt_ptp_parse(struct sk_buff *skb, u16 *seq_id, u16 *hdr_off);
+ void bnxt_ptp_pps_event(struct bnxt *bp, u32 data1, u32 data2);
+ void bnxt_ptp_reapply_pps(struct bnxt *bp);
  int bnxt_hwtstamp_set(struct net_device *dev, struct ifreq *ifr);
  int bnxt_hwtstamp_get(struct net_device *dev, struct ifreq *ifr);
  int bnxt_get_tx_ts_p5(struct bnxt *bp, struct sk_buff *skb);

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

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

[Vladimir Oltean]

Hello Mark,

On Mon, Aug 02, 2021 at 09:25:31PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/dsa/sja1105/sja1105_main.c
>
> between commit:
>
>   589918df9322 ("net: dsa: sja1105: be stateless with FDB entries on SJA1105P/Q/R/S/SJA1110 too")
>
> from the net tree and commit:
>
>   0fac6aa098ed ("net: dsa: sja1105: delete the best_effort_vlan_filtering mode")
>
> from the net-next tree.

The conflict resolution I intended (not the one you came up with) is
described in the commit message of patch 589918df9322 ("net: dsa:
sja1105: be stateless with FDB entries on SJA1105P/Q/R/S/SJA1110 too").

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

[Mark Brown]

Hi all,

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

  drivers/net/dsa/sja1105/sja1105_main.c

between commit:

  589918df9322 ("net: dsa: sja1105: be stateless with FDB entries on SJA1105P/Q/R/S/SJA1110 too")

from the net tree and commit:

  0fac6aa098ed ("net: dsa: sja1105: delete the best_effort_vlan_filtering mode")

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 drivers/net/dsa/sja1105/sja1105_main.c
index 8667c9754330,5ab1676a7448..000000000000
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@@ -1445,23 -1474,25 +1499,29 @@@ int sja1105pqrs_fdb_add(struct dsa_swit
  	/* Search for an existing entry in the FDB table */
  	l2_lookup.macaddr = ether_addr_to_u64(addr);
  	l2_lookup.vlanid = vid;
 -	l2_lookup.iotag = SJA1105_S_TAG;
  	l2_lookup.mask_macaddr = GENMASK_ULL(ETH_ALEN * 8 - 1, 0);
- 	l2_lookup.mask_vlanid = VLAN_VID_MASK;
+ 	if (priv->vlan_aware) {
+ 		l2_lookup.mask_vlanid = VLAN_VID_MASK;
+ 		l2_lookup.mask_iotag = BIT(0);
+ 	} else {
+ 		l2_lookup.mask_vlanid = 0;
+ 		l2_lookup.mask_iotag = 0;
+ 	}
  	l2_lookup.destports = BIT(port);
  
 +	tmp = l2_lookup;
 +
  	rc = sja1105_dynamic_config_read(priv, BLK_IDX_L2_LOOKUP,
 -					 SJA1105_SEARCH, &l2_lookup);
 -	if (rc == 0) {
 -		/* Found and this port is already in the entry's
 +					 SJA1105_SEARCH, &tmp);
 +	if (rc == 0 && tmp.index != SJA1105_MAX_L2_LOOKUP_COUNT - 1) {
 +		/* Found a static entry and this port is already in the entry's
  		 * port mask => job done
  		 */
 -		if (l2_lookup.destports & BIT(port))
 +		if ((tmp.destports & BIT(port)) && tmp.lockeds)
  			return 0;
 +
 +		l2_lookup = tmp;
 +
  		/* l2_lookup.index is populated by the switch in case it
  		 * found something.
  		 */
@@@ -1536,8 -1537,15 +1596,14 @@@ int sja1105pqrs_fdb_del(struct dsa_swit
  
  	l2_lookup.macaddr = ether_addr_to_u64(addr);
  	l2_lookup.vlanid = vid;
 -	l2_lookup.iotag = SJA1105_S_TAG;
  	l2_lookup.mask_macaddr = GENMASK_ULL(ETH_ALEN * 8 - 1, 0);
- 	l2_lookup.mask_vlanid = VLAN_VID_MASK;
+ 	if (priv->vlan_aware) {
+ 		l2_lookup.mask_vlanid = VLAN_VID_MASK;
+ 		l2_lookup.mask_iotag = BIT(0);
+ 	} else {
+ 		l2_lookup.mask_vlanid = 0;
+ 		l2_lookup.mask_iotag = 0;
+ 	}
  	l2_lookup.destports = BIT(port);
  
  	rc = sja1105_dynamic_config_read(priv, BLK_IDX_L2_LOOKUP,

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

[tangbin]

Hi, Mark:

On 2021/7/28 18:54, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    drivers/nfc/s3fwrn5/firmware.c
>
> between commit:
>
>    801e541c79bb ("nfc: s3fwrn5: fix undefined parameter values in dev_err()")

Yesterday, I have send this patch to fix the problem.

And nathan proposed another way to fix this problem, so I send v2 for 
maintainer today. And waiting for the result.

Thanks

Tang Bin

>
> from the net tree and commit:
>
>    a0302ff5906a ("nfc: s3fwrn5: remove unnecessary label")
>
> 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 drivers/nfc/s3fwrn5/firmware.c
> index 1340fab9565e,1421ffd46d9a..000000000000
> --- a/drivers/nfc/s3fwrn5/firmware.c
> +++ b/drivers/nfc/s3fwrn5/firmware.c
> @@@ -421,10 -421,9 +421,9 @@@ int s3fwrn5_fw_download(struct s3fwrn5_
>    
>    	tfm = crypto_alloc_shash("sha1", 0, 0);
>    	if (IS_ERR(tfm)) {
> - 		ret = PTR_ERR(tfm);
>    		dev_err(&fw_info->ndev->nfc_dev->dev,
>   -			"Cannot allocate shash (code=%d)\n", ret);
>   +			"Cannot allocate shash (code=%ld)\n", PTR_ERR(tfm));
> - 		goto out;
> + 		return PTR_ERR(tfm);
>    	}
>    
>    	ret = crypto_shash_tfm_digest(tfm, fw->image, image_size, hash_data);

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

[wengjianfeng]

> > Hi all,
> >
> >Today's linux-next merge of the net-next tree got a conflict in:
> >
> >  drivers/nfc/s3fwrn5/firmware.c
> >
> >between commit:
> >
> >  801e541c79bb ("nfc: s3fwrn5: fix undefined parameter values in
> >  dev_err()")
> >
> > from the net tree and commit:

> >  a0302ff5906a ("nfc: s3fwrn5: remove unnecessary label")

> > 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 drivers/nfc/s3fwrn5/firmware.c
> > index 1340fab9565e,1421ffd46d9a..000000000000
> > --- a/drivers/nfc/s3fwrn5/firmware.c
> > +++ b/drivers/nfc/s3fwrn5/firmware.c
> > @@@ -421,10 -421,9 +421,9 @@@ int s3fwrn5_fw_download(struct
> > s3fwrn5_
> > 
> >  tfm = crypto_alloc_shash("sha1", 0, 0);
> >  if (IS_ERR(tfm)) {
> >- ret = PTR_ERR(tfm);
 > > dev_err(&fw_info->ndev->nfc_dev->dev,
> >-	"Cannot allocate shash (code=%d)\n", ret);
> >+	"Cannot allocate shash (code=%ld)\n", PTR_ERR(tfm));
> >- goto out;
> >+ return PTR_ERR(tfm);
> >  }
> > 
> >  ret = crypto_shash_tfm_digest(tfm, fw->image, image_size,
> > hash_data);

Hi Mark,  
  Thanks for you fix the issue, I'll pay attention to this later.

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

[Mark Brown]

Hi all,

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

  drivers/nfc/s3fwrn5/firmware.c

between commit:

  801e541c79bb ("nfc: s3fwrn5: fix undefined parameter values in dev_err()")

from the net tree and commit:

  a0302ff5906a ("nfc: s3fwrn5: remove unnecessary label")

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 drivers/nfc/s3fwrn5/firmware.c
index 1340fab9565e,1421ffd46d9a..000000000000
--- a/drivers/nfc/s3fwrn5/firmware.c
+++ b/drivers/nfc/s3fwrn5/firmware.c
@@@ -421,10 -421,9 +421,9 @@@ int s3fwrn5_fw_download(struct s3fwrn5_
  
  	tfm = crypto_alloc_shash("sha1", 0, 0);
  	if (IS_ERR(tfm)) {
- 		ret = PTR_ERR(tfm);
  		dev_err(&fw_info->ndev->nfc_dev->dev,
 -			"Cannot allocate shash (code=%d)\n", ret);
 +			"Cannot allocate shash (code=%ld)\n", PTR_ERR(tfm));
- 		goto out;
+ 		return PTR_ERR(tfm);
  	}
  
  	ret = crypto_shash_tfm_digest(tfm, fw->image, image_size, hash_data);

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

[Stephen Rothwell]

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

Hi all,

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

  net/bpf/test_run.c

between commit:

  5e21bb4e8125 ("bpf, test: fix NULL pointer dereference on invalid expected_attach_type")

from the net tree and commit:

  47316f4a3053 ("bpf: Support input xdp_md context in BPF_PROG_TEST_RUN")

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/bpf/test_run.c
index 1cc75c811e24,cda8375bbbaf..000000000000
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@@ -697,15 -756,24 +756,27 @@@ int bpf_prog_test_run_xdp(struct bpf_pr
  	struct netdev_rx_queue *rxqueue;
  	struct xdp_buff xdp = {};
  	u32 retval, duration;
+ 	struct xdp_md *ctx;
  	u32 max_data_sz;
  	void *data;
- 	int ret;
+ 	int ret = -EINVAL;
  
 +	if (prog->expected_attach_type == BPF_XDP_DEVMAP ||
 +	    prog->expected_attach_type == BPF_XDP_CPUMAP)
 +		return -EINVAL;
- 	if (kattr->test.ctx_in || kattr->test.ctx_out)
- 		return -EINVAL;
+ 	ctx = bpf_ctx_init(kattr, sizeof(struct xdp_md));
+ 	if (IS_ERR(ctx))
+ 		return PTR_ERR(ctx);
+ 
+ 	if (ctx) {
+ 		/* There can't be user provided data before the meta data */
+ 		if (ctx->data_meta || ctx->data_end != size ||
+ 		    ctx->data > ctx->data_end ||
+ 		    unlikely(xdp_metalen_invalid(ctx->data)))
+ 			goto free_ctx;
+ 		/* Meta data is allocated from the headroom */
+ 		headroom -= ctx->data;
+ 	}
  
  	/* XDP have extra tailroom as (most) drivers use full page */
  	max_data_sz = 4096 - headroom - tailroom;

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/netfilter/nf_tables_api.c

between commit:

  3c5e44622011 ("netfilter: nf_tables: memleak in hw offload abort path")

from the net tree and commit:

  ef4b65e53cc7 ("netfilter: nfnetlink: add struct nfgenmsg to struct nfnl_info and use it")

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_tables_api.c
index fcb15b8904e8,d6214242fe7f..000000000000
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@@ -3249,9 -3236,9 +3242,9 @@@ static int nf_tables_newrule(struct sk_
  	u8 genmask = nft_genmask_next(info->net);
  	struct nft_rule *rule, *old_rule = NULL;
  	struct nft_expr_info *expr_info = NULL;
+ 	u8 family = info->nfmsg->nfgen_family;
 +	struct nft_flow_rule *flow = NULL;
- 	int family = nfmsg->nfgen_family;
  	struct net *net = info->net;
 -	struct nft_flow_rule *flow;
  	struct nft_userdata *udata;
  	struct nft_table *table;
  	struct nft_chain *chain;

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/can/isotp.c

between commit:

  8d0caedb7596 ("can: bcm/raw/isotp: use per module netdevice notifier")

from the net tree and commit:

  6a5ddae57884 ("can: isotp: add symbolic error message to isotp_module_init()")

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/can/isotp.c
index be6183f8ca11,f995eaef5d7b..000000000000
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@@ -1482,9 -1452,7 +1484,9 @@@ static __init int isotp_module_init(voi
  
  	err = can_proto_register(&isotp_can_proto);
  	if (err < 0)
- 		pr_err("can: registration of isotp protocol failed\n");
+ 		pr_err("can: registration of isotp protocol failed %pe\n", ERR_PTR(err));
 +	else
 +		register_netdevice_notifier(&canisotp_notifier);
  
  	return err;
  }

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/ptp/ptp_clock.c
  include/linux/ptp_clock_kernel.h

between commit:

  475b92f93216 ("ptp: improve max_adj check against unreasonable values")

from the net tree and commit:

  9d9d415f0048 ("ptp: ptp_clock: make scaled_ppm_to_ppb static inline")

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/ptp/ptp_clock.c
index 21c4c34c52d8,a780435331c8..000000000000
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
diff --cc include/linux/ptp_clock_kernel.h
index 51d7f1b8b32a,a311bddd9e85..000000000000
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@@ -186,6 -186,32 +186,32 @@@ struct ptp_clock_event 
  	};
  };
  
+ /**
+  * scaled_ppm_to_ppb() - convert scaled ppm to ppb
+  *
+  * @ppm:    Parts per million, but with a 16 bit binary fractional field
+  */
 -static inline s32 scaled_ppm_to_ppb(long ppm)
++static inline long scaled_ppm_to_ppb(long ppm)
+ {
+ 	/*
+ 	 * The 'freq' field in the 'struct timex' is in parts per
+ 	 * million, but with a 16 bit binary fractional field.
+ 	 *
+ 	 * We want to calculate
+ 	 *
+ 	 *    ppb = scaled_ppm * 1000 / 2^16
+ 	 *
+ 	 * which simplifies to
+ 	 *
+ 	 *    ppb = scaled_ppm * 125 / 2^13
+ 	 */
+ 	s64 ppb = 1 + ppm;
+ 
+ 	ppb *= 125;
+ 	ppb >>= 13;
 -	return (s32)ppb;
++	return (long)ppb;
+ }
+ 
  #if IS_REACHABLE(CONFIG_PTP_1588_CLOCK)
  
  /**

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

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

[Vladimir Oltean]

Hi Stephen,

On Fri, Jun 04, 2021 at 11:28:25AM +1000, Stephen Rothwell wrote:
> 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:
>
>   593f555fbc60 ("net: stmmac: fix kernel panic due to NULL pointer dereference of mdio_bus_data")
>
> from the net tree and commit:
>
>   11059740e616 ("net: pcs: xpcs: convert to phylink_pcs_ops")
>
> 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 c87202cbd3d6,6d41dd6f9f7a..000000000000
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@@ -1240,9 -1222,7 +1222,9 @@@ static int stmmac_phy_setup(struct stmm
>   	priv->phylink_config.dev = &priv->dev->dev;
>   	priv->phylink_config.type = PHYLINK_NETDEV;
>   	priv->phylink_config.pcs_poll = true;
> - 	if (priv->plat->mdio_bus_data)
>  -	priv->phylink_config.ovr_an_inband = mdio_bus_data->xpcs_an_inband;
> ++	if (mdio_bus_data)
>  +		priv->phylink_config.ovr_an_inband =
> - 			priv->plat->mdio_bus_data->xpcs_an_inband;
> ++			mdio_bus_data->xpcs_an_inband;
>
>   	if (!fwnode)
>   		fwnode = dev_fwnode(priv->device);

Your conflict resolution looks fine. I touched that area minimally (only
to keep priv->plat_mdio_bus_data in a variable), it should still be
checked against NULL.

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

[Stephen Rothwell]

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

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:

  593f555fbc60 ("net: stmmac: fix kernel panic due to NULL pointer dereference of mdio_bus_data")

from the net tree and commit:

  11059740e616 ("net: pcs: xpcs: convert to phylink_pcs_ops")

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 c87202cbd3d6,6d41dd6f9f7a..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -1240,9 -1222,7 +1222,9 @@@ static int stmmac_phy_setup(struct stmm
  	priv->phylink_config.dev = &priv->dev->dev;
  	priv->phylink_config.type = PHYLINK_NETDEV;
  	priv->phylink_config.pcs_poll = true;
- 	if (priv->plat->mdio_bus_data)
 -	priv->phylink_config.ovr_an_inband = mdio_bus_data->xpcs_an_inband;
++	if (mdio_bus_data)
 +		priv->phylink_config.ovr_an_inband =
- 			priv->plat->mdio_bus_data->xpcs_an_inband;
++			mdio_bus_data->xpcs_an_inband;
  
  	if (!fwnode)
  		fwnode = dev_fwnode(priv->device);

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/igc/igc_main.c

between commit:

  45ce08594ec3 ("igc: add correct exception tracing for XDP")

from the net tree and commit:

  73a6e3721261 ("igc: Refactor __igc_xdp_run_prog()")

from the net-next tree.

I fixed it up (I am not sure, but 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 --]

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/virtio_net.c

between commits:

  5c37711d9f27 ("virtio-net: fix for unable to handle page fault for address")
  8fb7da9e9907 ("virtio_net: get build_skb() buf by data ptr")

from the net tree and commits:

  6c66c147b9a4 ("virtio-net: fix for unable to handle page fault for address")
  7bf64460e3b2 ("virtio-net: get build_skb() buf by data ptr")

from the net-next tree.

These patches are different version of the same idea.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/core/devlink.c

between commit:

  b28d8f0c25a9 ("devlink: Correct VIRTUAL port to not have phys_port attributes")

from the net tree and commit:

  f285f37cb1e6 ("devlink: append split port number to the port name")

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/devlink.c
index 051432ea4f69,69681f19388e..000000000000
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@@ -8630,12 -8631,11 +8630,10 @@@ static int __devlink_port_phys_port_nam
  
  	switch (attrs->flavour) {
  	case DEVLINK_PORT_FLAVOUR_PHYSICAL:
- 		if (!attrs->split)
- 			n = snprintf(name, len, "p%u", attrs->phys.port_number);
- 		else
- 			n = snprintf(name, len, "p%us%u",
- 				     attrs->phys.port_number,
- 				     attrs->phys.split_subport_number);
 -	case DEVLINK_PORT_FLAVOUR_VIRTUAL:
+ 		n = snprintf(name, len, "p%u", attrs->phys.port_number);
+ 		if (n < len && attrs->split)
+ 			n += snprintf(name + n, len - n, "s%u",
+ 				      attrs->phys.split_subport_number);
  		break;
  	case DEVLINK_PORT_FLAVOUR_CPU:
  	case DEVLINK_PORT_FLAVOUR_DSA:

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

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

[Stephen Rothwell]

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

Hi all,

On Thu, 15 Apr 2021 14:00:16 +0000 "Ong, Boon Leong" <boon.leong.ong@intel.com> wrote:
>
> I check linux-next merge fix above and spotted an additional fix needed.
> Please see below. 
> 
> >+ /**
> >+  * dma_recycle_rx_skbufs - recycle RX dma buffers
> >+  * @priv: private structure
> >+  * @queue: RX queue index
> >+  */
> >+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
> >+ {
> >+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
> >+ 	int i;
> >+
> >+ 	for (i = 0; i < priv->dma_rx_size; i++) {
> >+ 		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
> >+
> >+ 		if (buf->page) {
> >+ 			page_pool_recycle_direct(rx_q->page_pool, buf-  
> >>page);  
> >+ 			buf->page = NULL;
> >+ 		}
> >+
> >+ 		if (priv->sph && buf->sec_page) {
> >+ 			page_pool_recycle_direct(rx_q->page_pool, buf-  
> >>sec_page);  
> >+ 			buf->sec_page = NULL;
> >+ 		}
> >+ 	}
> >+ }  
> 
> With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
> stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
> is no longer needed when net-next is sent for merge. 

Thanks.  I have added removal of that (now unused) function to my merge
resolution.

-- 
Cheers,
Stephen Rothwell

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

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

[Ong, Boon Leong]

>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:
>
>  00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume
>back"")
>
>from the net tree and commits:
>
>  bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
>  de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue
>basis")
>
>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.

I check linux-next merge fix above and spotted an additional fix needed.
Please see below. 


>+ /**
>+  * dma_recycle_rx_skbufs - recycle RX dma buffers
>+  * @priv: private structure
>+  * @queue: RX queue index
>+  */
>+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
>+ {
>+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
>+ 	int i;
>+
>+ 	for (i = 0; i < priv->dma_rx_size; i++) {
>+ 		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
>+
>+ 		if (buf->page) {
>+ 			page_pool_recycle_direct(rx_q->page_pool, buf-
>>page);
>+ 			buf->page = NULL;
>+ 		}
>+
>+ 		if (priv->sph && buf->sec_page) {
>+ 			page_pool_recycle_direct(rx_q->page_pool, buf-
>>sec_page);
>+ 			buf->sec_page = NULL;
>+ 		}
>+ 	}
>+ }

With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
is no longer needed when net-next is sent for merge.  


> -/**
> - * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
> - * @priv: driver private structure
> - * Description: this function is called to re-allocate a receive buffer, perform
> - * the DMA mapping and init the descriptor.
> - */
> -static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
> -{
> -	u32 rx_count = priv->plat->rx_queues_to_use;
> -	u32 queue;
> -
> -	for (queue = 0; queue < rx_count; queue++) {
> -		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
> -
> -		if (rx_q->xsk_pool)
> -			dma_free_rx_xskbufs(priv, queue);

dma_recycle_rx_skbufs() is only called here. 

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

[Stephen Rothwell]

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

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:

  00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume back"")

from the net tree and commits:

  bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
  de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue basis")

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 4749bd0af160,3a5ca5833ce1..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -1380,8 -1519,182 +1519,131 @@@ static void stmmac_free_tx_buffer(struc
  }
  
  /**
-  * init_dma_rx_desc_rings - init the RX descriptor rings
-  * @dev: net device structure
+  * dma_free_rx_skbufs - free RX dma buffers
+  * @priv: private structure
+  * @queue: RX queue index
+  */
+ static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ 	int i;
+ 
+ 	for (i = 0; i < priv->dma_rx_size; i++)
+ 		stmmac_free_rx_buffer(priv, queue, i);
+ }
+ 
+ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
+ 				   gfp_t flags)
+ {
+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ 	int i;
+ 
+ 	for (i = 0; i < priv->dma_rx_size; i++) {
+ 		struct dma_desc *p;
+ 		int ret;
+ 
+ 		if (priv->extend_desc)
+ 			p = &((rx_q->dma_erx + i)->basic);
+ 		else
+ 			p = rx_q->dma_rx + i;
+ 
+ 		ret = stmmac_init_rx_buffers(priv, p, i, flags,
+ 					     queue);
+ 		if (ret)
+ 			return ret;
+ 
+ 		rx_q->buf_alloc_num++;
+ 	}
+ 
+ 	return 0;
+ }
+ 
+ /**
+  * dma_recycle_rx_skbufs - recycle RX dma buffers
+  * @priv: private structure
+  * @queue: RX queue index
+  */
+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ 	int i;
+ 
+ 	for (i = 0; i < priv->dma_rx_size; i++) {
+ 		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+ 
+ 		if (buf->page) {
+ 			page_pool_recycle_direct(rx_q->page_pool, buf->page);
+ 			buf->page = NULL;
+ 		}
+ 
+ 		if (priv->sph && buf->sec_page) {
+ 			page_pool_recycle_direct(rx_q->page_pool, buf->sec_page);
+ 			buf->sec_page = NULL;
+ 		}
+ 	}
+ }
+ 
+ /**
+  * dma_free_rx_xskbufs - free RX dma buffers from XSK pool
+  * @priv: private structure
+  * @queue: RX queue index
+  */
+ static void dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ 	int i;
+ 
+ 	for (i = 0; i < priv->dma_rx_size; i++) {
+ 		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+ 
+ 		if (!buf->xdp)
+ 			continue;
+ 
+ 		xsk_buff_free(buf->xdp);
+ 		buf->xdp = NULL;
+ 	}
+ }
+ 
+ static int stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
+ {
+ 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+ 	int i;
+ 
+ 	for (i = 0; i < priv->dma_rx_size; i++) {
+ 		struct stmmac_rx_buffer *buf;
+ 		dma_addr_t dma_addr;
+ 		struct dma_desc *p;
+ 
+ 		if (priv->extend_desc)
+ 			p = (struct dma_desc *)(rx_q->dma_erx + i);
+ 		else
+ 			p = rx_q->dma_rx + i;
+ 
+ 		buf = &rx_q->buf_pool[i];
+ 
+ 		buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+ 		if (!buf->xdp)
+ 			return -ENOMEM;
+ 
+ 		dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+ 		stmmac_set_desc_addr(priv, p, dma_addr);
+ 		rx_q->buf_alloc_num++;
+ 	}
+ 
+ 	return 0;
+ }
+ 
 -/**
 - * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
 - * @priv: driver private structure
 - * Description: this function is called to re-allocate a receive buffer, perform
 - * the DMA mapping and init the descriptor.
 - */
 -static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 -{
 -	u32 rx_count = priv->plat->rx_queues_to_use;
 -	u32 queue;
 -
 -	for (queue = 0; queue < rx_count; queue++) {
 -		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 -
 -		if (rx_q->xsk_pool)
 -			dma_free_rx_xskbufs(priv, queue);
 -		else
 -			dma_recycle_rx_skbufs(priv, queue);
 -
 -		rx_q->buf_alloc_num = 0;
 -	}
 -
 -	for (queue = 0; queue < rx_count; queue++) {
 -		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 -		int ret;
 -
 -		if (rx_q->xsk_pool) {
 -			/* RX XDP ZC buffer pool may not be populated, e.g.
 -			 * xdpsock TX-only.
 -			 */
 -			stmmac_alloc_rx_buffers_zc(priv, queue);
 -		} else {
 -			ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
 -			if (ret < 0)
 -				goto err_reinit_rx_buffers;
 -		}
 -	}
 -
 -	return;
 -
 -err_reinit_rx_buffers:
 -	while (queue >= 0) {
 -		dma_free_rx_skbufs(priv, queue);
 -
 -		if (queue == 0)
 -			break;
 -
 -		queue--;
 -	}
 -}
 -
+ static struct xsk_buff_pool *stmmac_get_xsk_pool(struct stmmac_priv *priv, u32 queue)
+ {
+ 	if (!stmmac_xdp_is_enabled(priv) || !test_bit(queue, priv->af_xdp_zc_qps))
+ 		return NULL;
+ 
+ 	return xsk_get_pool_from_qid(priv->dev, queue);
+ }
+ 
+ /**
+  * __init_dma_rx_desc_rings - init the RX descriptor ring (per queue)
+  * @priv: driver private structure
+  * @queue: RX queue index
   * @flags: gfp flag.
   * Description: this function initializes the DMA RX descriptors
   * and allocates the socket buffers. It supports the chained and ring

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/tipc/crypto.c

between commit:

  2a2403ca3add ("tipc: increment the tmp aead refcnt before attaching it")

from the net tree and commit:

  97bc84bbd4de ("tipc: clean up warnings detected by sparse")

from the net-next tree.

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/ethtool.h

between commit:

  a975d7d8a356 ("ethtool: Remove link_mode param and derive link params from driver")

from the net tree and commit:

  7888fe53b706 ("ethtool: Add common function for filling out strings")

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/ethtool.h
index cdca84e6dd6b,5c631a298994..000000000000
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@@ -573,12 -573,13 +575,22 @@@ struct ethtool_phy_ops 
   */
  void ethtool_set_ethtool_phy_ops(const struct ethtool_phy_ops *ops);
  
 +/*
 + * ethtool_params_from_link_mode - Derive link parameters from a given link mode
 + * @link_ksettings: Link parameters to be derived from the link mode
 + * @link_mode: Link mode
 + */
 +void
 +ethtool_params_from_link_mode(struct ethtool_link_ksettings *link_ksettings,
 +			      enum ethtool_link_mode_bit_indices link_mode);
++
+ /**
+  * ethtool_sprintf - Write formatted string to ethtool string data
+  * @data: Pointer to start of string to update
+  * @fmt: Format of string to write
+  *
+  * Write formatted string to data. Update data to point at start of
+  * next string.
+  */
+ extern __printf(2, 3) void ethtool_sprintf(u8 **data, const char *fmt, ...);
  #endif /* _LINUX_ETHTOOL_H */

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

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

[Stephen Rothwell]

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

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:

  3ff3874fa0b2 ("net/mlx5e: Guarantee room for XSK wakeup NOP on async ICOSQ")

from the net tree and commits:

  c276aae8c19d ("net/mlx5: Move mlx5e hw resources into a sub object")
  b3a131c2a160 ("net/mlx5e: Move params logic into its dedicated file")

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 5db63b9f3b70,773449c1424b..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -1090,8 -1040,7 +1040,8 @@@ static int mlx5e_alloc_icosq(struct mlx
  	int err;
  
  	sq->channel   = c;
- 	sq->uar_map   = mdev->mlx5e_res.bfreg.map;
+ 	sq->uar_map   = mdev->mlx5e_res.hw_objs.bfreg.map;
 +	sq->reserved_room = param->stop_room;
  
  	param->wq.db_numa_node = cpu_to_node(c->cpu);
  	err = mlx5_wq_cyc_create(mdev, &param->wq, sqc_wq, wq, &sq->wq_ctrl);

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c

between commit:

  7c1ef1959b6f ("net/mlx5: SF, do not use ecpu bit for vhca state processing")

from the net tree and commit:

  4c94fe88cde4 ("net: ethernet: Remove duplicate include of vhca_event.h")

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/sf/hw_table.c
index a5a0f60bef66,3c8a00dd573a..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c
@@@ -5,8 -5,7 +5,7 @@@
  #include "priv.h"
  #include "sf.h"
  #include "mlx5_ifc_vhca_event.h"
- #include "vhca_event.h"
 -#include "ecpf.h"
 +#include "mlx5_core.h"
  
  struct mlx5_sf_hw {
  	u32 usr_sfnum;

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

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

[Stephen Rothwell]

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

  7d6c86e3ccb5 ("net/mlx5e: Allow to match on MPLS parameters only for MPLS over UDP")

from the net tree and commit:

  a3222a2da0a2 ("net/mlx5e: Allow to match on ICMP parameters")

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 df2a0af854bb,730f33ada90a..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -2295,17 -2314,49 +2314,60 @@@ static int __parse_cls_flower(struct ml
  		if (match.mask->flags)
  			*match_level = MLX5_MATCH_L4;
  	}
 +
 +	/* Currenlty supported only for MPLS over UDP */
 +	if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_MPLS) &&
 +	    !netif_is_bareudp(filter_dev)) {
 +		NL_SET_ERR_MSG_MOD(extack,
 +				   "Matching on MPLS is supported only for MPLS over UDP");
 +		netdev_err(priv->netdev,
 +			   "Matching on MPLS is supported only for MPLS over UDP\n");
 +		return -EOPNOTSUPP;
 +	}
 +
+ 	if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ICMP)) {
+ 		struct flow_match_icmp match;
+ 
+ 		flow_rule_match_icmp(rule, &match);
+ 		switch (ip_proto) {
+ 		case IPPROTO_ICMP:
+ 			if (!(MLX5_CAP_GEN(priv->mdev, flex_parser_protocols) &
+ 			      MLX5_FLEX_PROTO_ICMP))
+ 				return -EOPNOTSUPP;
+ 			MLX5_SET(fte_match_set_misc3, misc_c_3, icmp_type,
+ 				 match.mask->type);
+ 			MLX5_SET(fte_match_set_misc3, misc_v_3, icmp_type,
+ 				 match.key->type);
+ 			MLX5_SET(fte_match_set_misc3, misc_c_3, icmp_code,
+ 				 match.mask->code);
+ 			MLX5_SET(fte_match_set_misc3, misc_v_3, icmp_code,
+ 				 match.key->code);
+ 			break;
+ 		case IPPROTO_ICMPV6:
+ 			if (!(MLX5_CAP_GEN(priv->mdev, flex_parser_protocols) &
+ 			      MLX5_FLEX_PROTO_ICMPV6))
+ 				return -EOPNOTSUPP;
+ 			MLX5_SET(fte_match_set_misc3, misc_c_3, icmpv6_type,
+ 				 match.mask->type);
+ 			MLX5_SET(fte_match_set_misc3, misc_v_3, icmpv6_type,
+ 				 match.key->type);
+ 			MLX5_SET(fte_match_set_misc3, misc_c_3, icmpv6_code,
+ 				 match.mask->code);
+ 			MLX5_SET(fte_match_set_misc3, misc_v_3, icmpv6_code,
+ 				 match.key->code);
+ 			break;
+ 		default:
+ 			NL_SET_ERR_MSG_MOD(extack,
+ 					   "Code and type matching only with ICMP and ICMPv6");
+ 			netdev_err(priv->netdev,
+ 				   "Code and type matching only with ICMP and ICMPv6\n");
+ 			return -EINVAL;
+ 		}
+ 		if (match.mask->code || match.mask->type) {
+ 			*match_level = MLX5_MATCH_L4;
+ 			spec->match_criteria_enable |= MLX5_MATCH_MISC_PARAMETERS_3;
+ 		}
+ 	}
  	return 0;
  }
  

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

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

[Daniel Borkmann]

On 3/19/21 4:33 PM, Alexei Starovoitov wrote:
> On Fri, Mar 19, 2021 at 8:17 AM Yonghong Song <yhs@fb.com> wrote:
>> On 3/19/21 12:21 AM, Daniel Borkmann wrote:
>>> On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
>>>> Hi Daniel,
>>>>
>>>> On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell <sfr@canb.auug.org.au>
>>>> wrote:
>>>>
>>>>> diff --cc kernel/bpf/verifier.c
>>>>> index 44e4ec1640f1,f9096b049cd6..000000000000
>>>>> --- a/kernel/bpf/verifier.c
>>>>> +++ b/kernel/bpf/verifier.c
>>>>> @@@ -5876,10 -6056,22 +6060,23 @@@ static int
>>>>> retrieve_ptr_limit(const str
>>>>>                   if (mask_to_left)
>>>>>                           *ptr_limit = MAX_BPF_STACK + off;
>>>>>                   else
>>>>>    -                      *ptr_limit = -off;
>>>>>    -              return 0;
>>>>>    +                      *ptr_limit = -off - 1;
>>>>>    +              return *ptr_limit >= max ? -ERANGE : 0;
>>>>> +       case PTR_TO_MAP_KEY:
>>>>> +               /* Currently, this code is not exercised as the only use
>>>>> +                * is bpf_for_each_map_elem() helper which requires
>>>>> +                * bpf_capble. The code has been tested manually for
>>>>> +                * future use.
>>>>> +                */
>>>>> +               if (mask_to_left) {
>>>>> +                       *ptr_limit = ptr_reg->umax_value + ptr_reg->off;
>>>>> +               } else {
>>>>> +                       off = ptr_reg->smin_value + ptr_reg->off;
>>>>> +                       *ptr_limit = ptr_reg->map_ptr->key_size - off;
>>>>> +               }
>>>>> +               return 0;
>>>>
>>>> PTR_TO_MAP_VALUE logic above looks like copy-paste of old
>>>> PTR_TO_MAP_VALUE
>>>> code from before "bpf: Fix off-by-one for area size in creating mask to
>>>> left" and is apparently affected by the same off-by-one, except this time
>>>> on "key_size" area and not "value_size".
>>>>
>>>> This needs to be fixed in the same way as we did with PTR_TO_MAP_VALUE.
>>>> What is the best way to proceed?
>>>
>>> Hm, not sure why PTR_TO_MAP_KEY was added by 69c087ba6225 in the first
>>> place, I
>>> presume noone expects this to be used from unprivileged as the comment
>>> says.
>>> Resolution should be to remove the PTR_TO_MAP_KEY case entirely from
>>> that switch
>>> until we have an actual user.
>>
>> Alexei suggested so that we don't forget it in the future if
>> bpf_capable() requirement is removed.
>>      https://lore.kernel.org/bpf/c837ae55-2487-2f39-47f6-a18781dc6fcc@fb.com/
>>
>> I am okay with either way, fix it or remove it.
> 
> I prefer to fix it.

If the bpf_capable() is removed, the verifier would bail out on PTR_TO_MAP_KEY
if not covered in the switch given the recent fixes we did. I can fix it up after
merge if we think bpf_for_each_map_elem() will be used by unpriv in future..

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

[Alexei Starovoitov]

On Fri, Mar 19, 2021 at 8:17 AM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 3/19/21 12:21 AM, Daniel Borkmann wrote:
> > On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
> >> Hi Daniel,
> >>
> >> On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell <sfr@canb.auug.org.au>
> >> wrote:
> >>
> >>> diff --cc kernel/bpf/verifier.c
> >>> index 44e4ec1640f1,f9096b049cd6..000000000000
> >>> --- a/kernel/bpf/verifier.c
> >>> +++ b/kernel/bpf/verifier.c
> >>> @@@ -5876,10 -6056,22 +6060,23 @@@ static int
> >>> retrieve_ptr_limit(const str
> >>>                  if (mask_to_left)
> >>>                          *ptr_limit = MAX_BPF_STACK + off;
> >>>                  else
> >>>   -                      *ptr_limit = -off;
> >>>   -              return 0;
> >>>   +                      *ptr_limit = -off - 1;
> >>>   +              return *ptr_limit >= max ? -ERANGE : 0;
> >>> +       case PTR_TO_MAP_KEY:
> >>> +               /* Currently, this code is not exercised as the only use
> >>> +                * is bpf_for_each_map_elem() helper which requires
> >>> +                * bpf_capble. The code has been tested manually for
> >>> +                * future use.
> >>> +                */
> >>> +               if (mask_to_left) {
> >>> +                       *ptr_limit = ptr_reg->umax_value + ptr_reg->off;
> >>> +               } else {
> >>> +                       off = ptr_reg->smin_value + ptr_reg->off;
> >>> +                       *ptr_limit = ptr_reg->map_ptr->key_size - off;
> >>> +               }
> >>> +               return 0;
> >>>
> >>
> >> PTR_TO_MAP_VALUE logic above looks like copy-paste of old
> >> PTR_TO_MAP_VALUE
> >> code from before "bpf: Fix off-by-one for area size in creating mask to
> >> left" and is apparently affected by the same off-by-one, except this time
> >> on "key_size" area and not "value_size".
> >>
> >> This needs to be fixed in the same way as we did with PTR_TO_MAP_VALUE.
> >> What is the best way to proceed?
> >
> > Hm, not sure why PTR_TO_MAP_KEY was added by 69c087ba6225 in the first
> > place, I
> > presume noone expects this to be used from unprivileged as the comment
> > says.
> > Resolution should be to remove the PTR_TO_MAP_KEY case entirely from
> > that switch
> > until we have an actual user.
>
> Alexei suggested so that we don't forget it in the future if
> bpf_capable() requirement is removed.
>     https://lore.kernel.org/bpf/c837ae55-2487-2f39-47f6-a18781dc6fcc@fb.com/
>
> I am okay with either way, fix it or remove it.

I prefer to fix it.

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

[Yonghong Song]

On 3/19/21 12:21 AM, Daniel Borkmann wrote:
> On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
>> Hi Daniel,
>>
>> On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell <sfr@canb.auug.org.au>
>> wrote:
>>
>>> diff --cc kernel/bpf/verifier.c
>>> index 44e4ec1640f1,f9096b049cd6..000000000000
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@@ -5876,10 -6056,22 +6060,23 @@@ static int 
>>> retrieve_ptr_limit(const str
>>>                  if (mask_to_left)
>>>                          *ptr_limit = MAX_BPF_STACK + off;
>>>                  else
>>>   -                      *ptr_limit = -off;
>>>   -              return 0;
>>>   +                      *ptr_limit = -off - 1;
>>>   +              return *ptr_limit >= max ? -ERANGE : 0;
>>> +       case PTR_TO_MAP_KEY:
>>> +               /* Currently, this code is not exercised as the only use
>>> +                * is bpf_for_each_map_elem() helper which requires
>>> +                * bpf_capble. The code has been tested manually for
>>> +                * future use.
>>> +                */
>>> +               if (mask_to_left) {
>>> +                       *ptr_limit = ptr_reg->umax_value + ptr_reg->off;
>>> +               } else {
>>> +                       off = ptr_reg->smin_value + ptr_reg->off;
>>> +                       *ptr_limit = ptr_reg->map_ptr->key_size - off;
>>> +               }
>>> +               return 0;
>>>
>>
>> PTR_TO_MAP_VALUE logic above looks like copy-paste of old 
>> PTR_TO_MAP_VALUE
>> code from before "bpf: Fix off-by-one for area size in creating mask to
>> left" and is apparently affected by the same off-by-one, except this time
>> on "key_size" area and not "value_size".
>>
>> This needs to be fixed in the same way as we did with PTR_TO_MAP_VALUE.
>> What is the best way to proceed?
> 
> Hm, not sure why PTR_TO_MAP_KEY was added by 69c087ba6225 in the first 
> place, I
> presume noone expects this to be used from unprivileged as the comment 
> says.
> Resolution should be to remove the PTR_TO_MAP_KEY case entirely from 
> that switch
> until we have an actual user.

Alexei suggested so that we don't forget it in the future if
bpf_capable() requirement is removed.
    https://lore.kernel.org/bpf/c837ae55-2487-2f39-47f6-a18781dc6fcc@fb.com/

I am okay with either way, fix it or remove it.

> 
> Thanks,
> Daniel

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

[Daniel Borkmann]

On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
> Hi Daniel,
> 
> On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> 
>> diff --cc kernel/bpf/verifier.c
>> index 44e4ec1640f1,f9096b049cd6..000000000000
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@@ -5876,10 -6056,22 +6060,23 @@@ static int retrieve_ptr_limit(const str
>>                  if (mask_to_left)
>>                          *ptr_limit = MAX_BPF_STACK + off;
>>                  else
>>   -                      *ptr_limit = -off;
>>   -              return 0;
>>   +                      *ptr_limit = -off - 1;
>>   +              return *ptr_limit >= max ? -ERANGE : 0;
>> +       case PTR_TO_MAP_KEY:
>> +               /* Currently, this code is not exercised as the only use
>> +                * is bpf_for_each_map_elem() helper which requires
>> +                * bpf_capble. The code has been tested manually for
>> +                * future use.
>> +                */
>> +               if (mask_to_left) {
>> +                       *ptr_limit = ptr_reg->umax_value + ptr_reg->off;
>> +               } else {
>> +                       off = ptr_reg->smin_value + ptr_reg->off;
>> +                       *ptr_limit = ptr_reg->map_ptr->key_size - off;
>> +               }
>> +               return 0;
>>
> 
> PTR_TO_MAP_VALUE logic above looks like copy-paste of old PTR_TO_MAP_VALUE
> code from before "bpf: Fix off-by-one for area size in creating mask to
> left" and is apparently affected by the same off-by-one, except this time
> on "key_size" area and not "value_size".
> 
> This needs to be fixed in the same way as we did with PTR_TO_MAP_VALUE.
> What is the best way to proceed?

Hm, not sure why PTR_TO_MAP_KEY was added by 69c087ba6225 in the first place, I
presume noone expects this to be used from unprivileged as the comment says.
Resolution should be to remove the PTR_TO_MAP_KEY case entirely from that switch
until we have an actual user.

Thanks,
Daniel

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

[Stephen Rothwell]

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

Hi all,

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

  kernel/bpf/verifier.c

between commits:

  b5871dca250c ("bpf: Simplify alu_limit masking for pointer arithmetic")
  1b1597e64e1a ("bpf: Add sanity check for upper ptr_limit")

from the net tree and commit:

  69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")

from the net-next tree.

I fixed it up (see below - but it may need more work on the new
"return" starement from the latter 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

diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -5876,10 -6056,22 +6060,23 @@@ static int retrieve_ptr_limit(const str
  		if (mask_to_left)
  			*ptr_limit = MAX_BPF_STACK + off;
  		else
 -			*ptr_limit = -off;
 -		return 0;
 +			*ptr_limit = -off - 1;
 +		return *ptr_limit >= max ? -ERANGE : 0;
+ 	case PTR_TO_MAP_KEY:
+ 		/* Currently, this code is not exercised as the only use
+ 		 * is bpf_for_each_map_elem() helper which requires
+ 		 * bpf_capble. The code has been tested manually for
+ 		 * future use.
+ 		 */
+ 		if (mask_to_left) {
+ 			*ptr_limit = ptr_reg->umax_value + ptr_reg->off;
+ 		} else {
+ 			off = ptr_reg->smin_value + ptr_reg->off;
+ 			*ptr_limit = ptr_reg->map_ptr->key_size - off;
+ 		}
+ 		return 0;
  	case PTR_TO_MAP_VALUE:
 +		max = ptr_reg->map_ptr->value_size;
  		if (mask_to_left) {
  			*ptr_limit = ptr_reg->umax_value + ptr_reg->off;
  		} else {

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/pensando/ionic/ionic_txrx.c

between commit:

  d2c21422323b ("ionic: linearize tso skb with too many frags")

from the net tree and commit:

  f37bc3462e80 ("ionic: optimize fastpath struct usage")

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/pensando/ionic/ionic_txrx.c
index 4087311f7082,03e00a6c413a..000000000000
--- a/drivers/net/ethernet/pensando/ionic/ionic_txrx.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_txrx.c
@@@ -1077,19 -1082,16 +1082,18 @@@ static int ionic_tx(struct ionic_queue 
  
  static int ionic_tx_descs_needed(struct ionic_queue *q, struct sk_buff *skb)
  {
- 	int sg_elems = q->lif->qtype_info[IONIC_QTYPE_TXQ].max_sg_elems;
  	struct ionic_tx_stats *stats = q_to_tx_stats(q);
 +	int ndescs;
  	int err;
  
 -	/* If TSO, need roundup(skb->len/mss) descs */
 +	/* Each desc is mss long max, so a descriptor for each gso_seg */
  	if (skb_is_gso(skb))
 -		return (skb->len / skb_shinfo(skb)->gso_size) + 1;
 +		ndescs = skb_shinfo(skb)->gso_segs;
 +	else
 +		ndescs = 1;
  
- 	if (skb_shinfo(skb)->nr_frags <= sg_elems)
 -	/* If non-TSO, just need 1 desc and nr_frags sg elems */
+ 	if (skb_shinfo(skb)->nr_frags <= q->max_sg_elems)
 -		return 1;
 +		return ndescs;
  
  	/* Too many frags, so linearize */
  	err = skb_linearize(skb);

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

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

[Sukadev Bhattiprolu]

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/ibm/ibmvnic.c
>   drivers/net/ethernet/ibm/ibmvnic.h
> 
> between commit:
> 
>   4a41c421f367 ("ibmvnic: serialize access to work queue on remove")
> 
> from the net tree and commits:
> 
>   bab08bedcdc3 ("ibmvnic: fix block comments")
>   a369d96ca554 ("ibmvnic: add comments for spinlock_t definitions")
> 
> 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 changes look good to me. Thanks.

Sukadev

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c
  drivers/net/ethernet/ibm/ibmvnic.h

between commit:

  4a41c421f367 ("ibmvnic: serialize access to work queue on remove")

from the net tree and commits:

  bab08bedcdc3 ("ibmvnic: fix block comments")
  a369d96ca554 ("ibmvnic: add comments for spinlock_t definitions")

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 13ae7eee7ef5,927d5f36d308..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -2395,10 -2288,7 +2294,9 @@@ static int ibmvnic_reset(struct ibmvnic
  	unsigned long flags;
  	int ret;
  
 +	spin_lock_irqsave(&adapter->rwi_lock, flags);
 +
- 	/*
- 	 * If failover is pending don't schedule any other reset.
+ 	/* If failover is pending don't schedule any other reset.
  	 * Instead let the failover complete. If there is already a
  	 * a failover reset scheduled, we will detect and drop the
  	 * duplicate reset when walking the ->rwi_list below.
diff --cc drivers/net/ethernet/ibm/ibmvnic.h
index 72fea3b1c87d,270d1cac86a4..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@@ -1080,10 -1081,12 +1081,16 @@@ struct ibmvnic_adapter 
  
  	struct tasklet_struct tasklet;
  	enum vnic_state state;
 -	/* Used for serializatin of state field */
++	/* Used for serialization of state field. When taking both state
++	 * and rwi locks, take state lock first.
++	 */
+ 	spinlock_t state_lock;
  	enum ibmvnic_reset_reason reset_reason;
- 	/* when taking both state and rwi locks, take state lock first */
- 	spinlock_t rwi_lock;
  	struct list_head rwi_list;
 -	/* Used for serialization of rwi_list */
++	/* Used for serialization of rwi_list. When taking both state
++	 * and rwi locks, take state lock first
++	 */
+ 	spinlock_t rwi_lock;
  	struct work_struct ibmvnic_reset;
  	struct delayed_work ibmvnic_delayed_reset;
  	unsigned long resetting;

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

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

[Saeed Mahameed]

On Mon, 2021-02-15 at 11:52 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>   drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> 
> between commit:
> 
>   e4484d9df500 ("net/mlx5e: Enable striding RQ for Connect-X IPsec
> capable devices")
> 
> from the net tree and commits:
> 
>   224169d2a32b ("net/mlx5e: IPsec, Remove unnecessary config flag
> usage")
>   70038b73e40e ("net/mlx5e: Add listener to trap event")
>   214baf22870c ("net/mlx5e: Support HTB 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.
> 

Resolution looks correct.

Thanks,
Saeed.

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

[Stephen Rothwell]

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

Hi Davide,

On Mon, 15 Feb 2021 12:35:37 +0100 Davide Caratti <dcaratti@redhat.com> wrote:
>
> On Mon, 2021-02-15 at 12:01 +0100, Guillaume Nault wrote:
> > Before these commits, ALL_TESTS listed the tests in the order they were
> > implemented in the rest of the file. So I'd rather continue following
> > this implicit rule, if at all possible. Also it makes sense to keep
> > grouping all match_ip_*_test together.  
> 
> yes, it makes sense. I can follow-up with a commit for net-next (when
> tree re-opens), where the "ordering" in ALL_TESTS is restored. Ok?

The ordering is not set in stone yet (I have only done the merge in the
linux-next tree), just make sure that Dave knows what it should look
like when he merges the net and net-next trees.

-- 
Cheers,
Stephen Rothwell

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

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

[Davide Caratti]

On Mon, 2021-02-15 at 12:01 +0100, Guillaume Nault wrote:
> Before these commits, ALL_TESTS listed the tests in the order they were
> implemented in the rest of the file. So I'd rather continue following
> this implicit rule, if at all possible. Also it makes sense to keep
> grouping all match_ip_*_test together.

yes, it makes sense. I can follow-up with a commit for net-next (when
tree re-opens), where the "ordering" in ALL_TESTS is restored. Ok?

thanks,
-- 
davide

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

[Guillaume Nault]

On Mon, Feb 15, 2021 at 11:43:54AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/net/forwarding/tc_flower.sh
> 
> between commit:
> 
>   d2126838050c ("flow_dissector: fix TTL and TOS dissection on IPv4 fragments")
> 
> from the net tree and commits:
> 
>   203ee5cd7235 ("selftests: tc: Add basic mpls_* matching support for tc-flower")
>   c09bfd9a5df9 ("selftests: tc: Add generic mpls matching support for tc-flower")
> 
> 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/forwarding/tc_flower.sh
> index b11d8e6b5bc1,a554838666c4..000000000000
> --- a/tools/testing/selftests/net/forwarding/tc_flower.sh
> +++ b/tools/testing/selftests/net/forwarding/tc_flower.sh
> @@@ -3,7 -3,9 +3,9 @@@
>   
>   ALL_TESTS="match_dst_mac_test match_src_mac_test match_dst_ip_test \
>   	match_src_ip_test match_ip_flags_test match_pcp_test match_vlan_test \
> - 	match_ip_tos_test match_indev_test match_ip_ttl_test"
> + 	match_ip_tos_test match_indev_test match_mpls_label_test \
> + 	match_mpls_tc_test match_mpls_bos_test match_mpls_ttl_test \
>  -	match_mpls_lse_test"
> ++	match_mpls_lse_test match_ip_ttl_test"

That's technically right. But I think it'd be nicer to have
"match_ip_ttl_test" appear between "match_ip_tos_test" and
"match_indev_test", rather than at the end of the list.

Before these commits, ALL_TESTS listed the tests in the order they were
implemented in the rest of the file. So I'd rather continue following
this implicit rule, if at all possible. Also it makes sense to keep
grouping all match_ip_*_test together.

>   NUM_NETIFS=2
>   source tc_common.sh
>   source lib.sh

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c
  drivers/net/ethernet/mellanox/mlx5/core/en_rx.c

between commit:

  e4484d9df500 ("net/mlx5e: Enable striding RQ for Connect-X IPsec capable devices")

from the net tree and commits:

  224169d2a32b ("net/mlx5e: IPsec, Remove unnecessary config flag usage")
  70038b73e40e ("net/mlx5e: Add listener to trap event")
  214baf22870c ("net/mlx5e: Support HTB 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/mellanox/mlx5/core/en_main.c
index a2e0b548bf57,d3534b657b98..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -65,7 -65,8 +65,9 @@@
  #include "en/devlink.h"
  #include "lib/mlx5.h"
  #include "en/ptp.h"
 +#include "fpga/ipsec.h"
+ #include "qos.h"
+ #include "en/trap.h"
  
  bool mlx5e_check_fragmented_striding_rq_cap(struct mlx5_core_dev *mdev)
  {
@@@ -2069,10 -2106,8 +2107,8 @@@ static void mlx5e_build_rq_frags_info(s
  	u32 buf_size = 0;
  	int i;
  
- #ifdef CONFIG_MLX5_EN_IPSEC
 -	if (MLX5_IPSEC_DEV(mdev))
 +	if (mlx5_fpga_is_ipsec_device(mdev))
  		byte_count += MLX5E_METADATA_ETHER_LEN;
- #endif
  
  	if (mlx5e_rx_is_linear_skb(params, xsk)) {
  		int frag_stride;
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 4864deed9dc9,4de5a97ceac6..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@@ -1794,12 -1786,10 +1786,10 @@@ int mlx5e_rq_set_handlers(struct mlx5e_
  		rq->dealloc_wqe = mlx5e_dealloc_rx_mpwqe;
  
  		rq->handle_rx_cqe = priv->profile->rx_handlers->handle_rx_cqe_mpwqe;
- #ifdef CONFIG_MLX5_EN_IPSEC
 -		if (MLX5_IPSEC_DEV(mdev)) {
 -			netdev_err(netdev, "MPWQE RQ with IPSec offload not supported\n");
 +		if (mlx5_fpga_is_ipsec_device(mdev)) {
 +			netdev_err(netdev, "MPWQE RQ with Innova IPSec offload not supported\n");
  			return -EINVAL;
  		}
- #endif
  		if (!rq->handle_rx_cqe) {
  			netdev_err(netdev, "RX handler of MPWQE RQ is not set\n");
  			return -EINVAL;

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/forwarding/tc_flower.sh

between commit:

  d2126838050c ("flow_dissector: fix TTL and TOS dissection on IPv4 fragments")

from the net tree and commits:

  203ee5cd7235 ("selftests: tc: Add basic mpls_* matching support for tc-flower")
  c09bfd9a5df9 ("selftests: tc: Add generic mpls matching support for tc-flower")

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/forwarding/tc_flower.sh
index b11d8e6b5bc1,a554838666c4..000000000000
--- a/tools/testing/selftests/net/forwarding/tc_flower.sh
+++ b/tools/testing/selftests/net/forwarding/tc_flower.sh
@@@ -3,7 -3,9 +3,9 @@@
  
  ALL_TESTS="match_dst_mac_test match_src_mac_test match_dst_ip_test \
  	match_src_ip_test match_ip_flags_test match_pcp_test match_vlan_test \
- 	match_ip_tos_test match_indev_test match_ip_ttl_test"
+ 	match_ip_tos_test match_indev_test match_mpls_label_test \
+ 	match_mpls_tc_test match_mpls_bos_test match_mpls_ttl_test \
 -	match_mpls_lse_test"
++	match_mpls_lse_test match_ip_ttl_test"
  NUM_NETIFS=2
  source tc_common.sh
  source lib.sh

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/uapi/linux/pkt_cls.h

between commit:

  1bcc51ac0731 ("net/sched: cls_flower: Reject invalid ct_state flags rules")

from the net tree and commits:

  7baf2429a1a9 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support")
  8c85d18ce647 ("net/sched: cls_flower: Add match on the ct_state reply flag")

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/pkt_cls.h
index 88f4bf0047e7,afe6836e44b1..000000000000
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@@ -591,8 -591,8 +591,10 @@@ enum 
  	TCA_FLOWER_KEY_CT_FLAGS_ESTABLISHED = 1 << 1, /* Part of an existing connection. */
  	TCA_FLOWER_KEY_CT_FLAGS_RELATED = 1 << 2, /* Related to an established connection. */
  	TCA_FLOWER_KEY_CT_FLAGS_TRACKED = 1 << 3, /* Conntrack has occurred. */
+ 	TCA_FLOWER_KEY_CT_FLAGS_INVALID = 1 << 4, /* Conntrack is invalid. */
+ 	TCA_FLOWER_KEY_CT_FLAGS_REPLY = 1 << 5, /* Packet is in the reply direction. */
 +
 +	__TCA_FLOWER_KEY_CT_FLAGS_MAX,
  };
  
  enum {

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/can/m_can/tcan4x5x-core.c

between commit:

  aee2b3ccc8a6 ("can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver")

from the net tree and commit:

  7813887ea972 ("can: tcan4x5x: rename tcan4x5x.c -> tcan4x5x-core.c")

from the net-next tree.

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

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

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

[Thomas Falcon]

On 12/1/20 7:20 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>    drivers/net/ethernet/ibm/ibmvnic.c
>
> between commit:
>
>    b71ec9522346 ("ibmvnic: Ensure that SCRQ entry reads are correctly ordered")
>
> from the net tree and commit:
>
>    ec20f36bb41a ("ibmvnic: Correctly re-enable interrupts in NAPI polling routine")
>
> 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.
>
Hi, Stephen, thank you for fixing that conflict. Sorry for the 
inconvenience.

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  b71ec9522346 ("ibmvnic: Ensure that SCRQ entry reads are correctly ordered")

from the net tree and commit:

  ec20f36bb41a ("ibmvnic: Correctly re-enable interrupts in NAPI polling routine")

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  9281cf2d5840 ("ibmvnic: avoid memset null scrq msgs")

from the net tree and commit:

  f019fb6392e5 ("ibmvnic: Introduce indirect subordinate Command Response Queue buffer")

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 bca1becd33f0,cdd1ff9aa9c4..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -2874,14 -2959,11 +2968,15 @@@ static int reset_one_sub_crq_queue(stru
  		irq_dispose_mapping(scrq->irq);
  		scrq->irq = 0;
  	}
 -
 -	memset(scrq->msgs, 0, 4 * PAGE_SIZE);
 -	atomic_set(&scrq->used, 0);
 -	scrq->cur = 0;
 -	scrq->ind_buf.index = 0;
 +	if (scrq->msgs) {
 +		memset(scrq->msgs, 0, 4 * PAGE_SIZE);
 +		atomic_set(&scrq->used, 0);
 +		scrq->cur = 0;
++		scrq->ind_buf.index = 0;
 +	} else {
 +		netdev_dbg(adapter->netdev, "Invalid scrq reset\n");
 +		return -EINVAL;
 +	}
  
  	rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
  			   4 * PAGE_SIZE, &scrq->crq_num, &scrq->hw_irq);

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

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

[ljp]

On 2020-11-03 18:43, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/ibm/ibmvnic.c
> 
> between commit:
> 
>   1d8504937478 ("powerpc/vnic: Extend "failover pending" window")
> 
> from the net tree and commit:
> 
>   16b5f5ce351f ("ibmvnic: merge do_change_param_reset into do_reset")
> 
> 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 I missed this email.
The fix is correct.
Thank you Stephen.

> --
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/net/ethernet/ibm/ibmvnic.c
> index da15913879f8,f4167de30461..000000000000
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@@ -1930,17 -1841,12 +1850,20 @@@ static int do_reset(struct 
> ibmvnic_adap
>   	netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
>   		   rwi->reset_reason);
> 
> - 	rtnl_lock();
> + 	adapter->reset_reason = rwi->reset_reason;
> + 	/* requestor of VNIC_RESET_CHANGE_PARAM already has the rtnl lock */
> + 	if (!(adapter->reset_reason == VNIC_RESET_CHANGE_PARAM))
> + 		rtnl_lock();
> +
>  +	/*
>  +	 * Now that we have the rtnl lock, clear any pending failover.
>  +	 * This will ensure ibmvnic_open() has either completed or will
>  +	 * block until failover is complete.
>  +	 */
>  +	if (rwi->reset_reason == VNIC_RESET_FAILOVER)
>  +		adapter->failover_pending = false;
>  +
>   	netif_carrier_off(netdev);
> - 	adapter->reset_reason = rwi->reset_reason;
> 
>   	old_num_rx_queues = adapter->req_rx_queues;
>   	old_num_tx_queues = adapter->req_tx_queues;
> @@@ -2214,17 -2140,7 +2157,14 @@@ static void __ibmvnic_reset(struct 
> work
>   		}
>   		spin_unlock_irqrestore(&adapter->state_lock, flags);
> 
> - 		if (rwi->reset_reason == VNIC_RESET_CHANGE_PARAM) {
> - 			/* CHANGE_PARAM requestor holds rtnl_lock */
> - 			rc = do_change_param_reset(adapter, rwi, reset_state);
> - 		} else if (adapter->force_reset_recovery) {
> + 		if (adapter->force_reset_recovery) {
>  +			/*
>  +			 * Since we are doing a hard reset now, clear the
>  +			 * failover_pending flag so we don't ignore any
>  +			 * future MOBILITY or other resets.
>  +			 */
>  +			adapter->failover_pending = false;
>  +
>   			/* Transport event occurred during previous reset */
>   			if (adapter->wait_for_reset) {
>   				/* Previous was CHANGE_PARAM; caller locked */

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  1d8504937478 ("powerpc/vnic: Extend "failover pending" window")

from the net tree and commit:

  16b5f5ce351f ("ibmvnic: merge do_change_param_reset into do_reset")

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 da15913879f8,f4167de30461..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -1930,17 -1841,12 +1850,20 @@@ static int do_reset(struct ibmvnic_adap
  	netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
  		   rwi->reset_reason);
  
- 	rtnl_lock();
+ 	adapter->reset_reason = rwi->reset_reason;
+ 	/* requestor of VNIC_RESET_CHANGE_PARAM already has the rtnl lock */
+ 	if (!(adapter->reset_reason == VNIC_RESET_CHANGE_PARAM))
+ 		rtnl_lock();
+ 
 +	/*
 +	 * Now that we have the rtnl lock, clear any pending failover.
 +	 * This will ensure ibmvnic_open() has either completed or will
 +	 * block until failover is complete.
 +	 */
 +	if (rwi->reset_reason == VNIC_RESET_FAILOVER)
 +		adapter->failover_pending = false;
 +
  	netif_carrier_off(netdev);
- 	adapter->reset_reason = rwi->reset_reason;
  
  	old_num_rx_queues = adapter->req_rx_queues;
  	old_num_tx_queues = adapter->req_tx_queues;
@@@ -2214,17 -2140,7 +2157,14 @@@ static void __ibmvnic_reset(struct work
  		}
  		spin_unlock_irqrestore(&adapter->state_lock, flags);
  
- 		if (rwi->reset_reason == VNIC_RESET_CHANGE_PARAM) {
- 			/* CHANGE_PARAM requestor holds rtnl_lock */
- 			rc = do_change_param_reset(adapter, rwi, reset_state);
- 		} else if (adapter->force_reset_recovery) {
+ 		if (adapter->force_reset_recovery) {
 +			/*
 +			 * Since we are doing a hard reset now, clear the
 +			 * failover_pending flag so we don't ignore any
 +			 * future MOBILITY or other resets.
 +			 */
 +			adapter->failover_pending = false;
 +
  			/* Transport event occurred during previous reset */
  			if (adapter->wait_for_reset) {
  				/* Previous was CHANGE_PARAM; caller locked */

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/protocol.h

between commit:

  d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows")

from the net tree and commit:

  d0876b2284cf ("mptcp: add the incoming RM_ADDR 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 net/mptcp/protocol.h
index 972463642690,aa0ab18d2e57..000000000000
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@@ -203,9 -211,10 +212,11 @@@ struct mptcp_sock 
  	bool		fully_established;
  	bool		rcv_data_fin;
  	bool		snd_data_fin_enable;
 +	bool		use_64bit_ack; /* Set when we received a 64-bit DSN */
  	spinlock_t	join_list_lock;
  	struct work_struct work;
+ 	struct sk_buff  *ooo_last_skb;
+ 	struct rb_root  out_of_order_queue;
  	struct list_head conn_list;
  	struct list_head rtx_queue;
  	struct list_head join_list;
@@@ -294,9 -309,10 +311,9 @@@ struct mptcp_subflow_context 
  		map_valid : 1,
  		mpc_map : 1,
  		backup : 1,
- 		data_avail : 1,
  		rx_eof : 1,
 -		use_64bit_ack : 1, /* Set when we received a 64-bit DSN */
  		can_ack : 1;	    /* only after processing the remote a key */
+ 	enum mptcp_data_avail data_avail;
  	u32	remote_nonce;
  	u64	thmac;
  	u32	local_nonce;
@@@ -349,11 -365,13 +366,14 @@@ void mptcp_subflow_fully_established(st
  				     struct mptcp_options_received *mp_opt);
  bool mptcp_subflow_data_available(struct sock *sk);
  void __init mptcp_subflow_init(void);
 +void mptcp_subflow_reset(struct sock *ssk);
+ void mptcp_subflow_shutdown(struct sock *sk, struct sock *ssk, int how);
+ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
+ 		       struct mptcp_subflow_context *subflow,
+ 		       long timeout);
  
  /* called with sk socket lock held */
- int __mptcp_subflow_connect(struct sock *sk, int ifindex,
- 			    const struct mptcp_addr_info *loc,
+ int __mptcp_subflow_connect(struct sock *sk, const struct mptcp_addr_info *loc,
  			    const struct mptcp_addr_info *remote);
  int mptcp_subflow_create_socket(struct sock *sk, struct socket **new_sock);
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/rxrpc/conn_event.c

between commit:

  fa1d113a0f96 ("rxrpc: Fix some missing _bh annotations on locking conn->state_lock")

from the net tree and commit:

  245500d853e9 ("rxrpc: Rewrite the client connection manager")

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/rxrpc/conn_event.c
index 64ace2960ecc,0628dad2bdea..000000000000
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@@ -339,8 -341,8 +341,8 @@@ static int rxrpc_process_event(struct r
  		if (ret < 0)
  			return ret;
  
- 		spin_lock(&conn->channel_lock);
+ 		spin_lock(&conn->bundle->channel_lock);
 -		spin_lock(&conn->state_lock);
 +		spin_lock_bh(&conn->state_lock);
  
  		if (conn->state == RXRPC_CONN_SERVICE_CHALLENGING) {
  			conn->state = RXRPC_CONN_SERVICE;
@@@ -349,12 -351,12 +351,12 @@@
  				rxrpc_call_is_secure(
  					rcu_dereference_protected(
  						conn->channels[loop].call,
- 						lockdep_is_held(&conn->channel_lock)));
+ 						lockdep_is_held(&conn->bundle->channel_lock)));
  		} else {
 -			spin_unlock(&conn->state_lock);
 +			spin_unlock_bh(&conn->state_lock);
  		}
  
- 		spin_unlock(&conn->channel_lock);
+ 		spin_unlock(&conn->bundle->channel_lock);
  		return 0;
  
  	default:

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

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

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Oct 2, 2020 at 5:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   Documentation/devicetree/bindings/net/renesas,ravb.txt
>
> between commit:
>
>   307eea32b202 ("dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC")
>
> from the net tree and commit:
>
>   d7adf6331189 ("dt-bindings: net: renesas,etheravb: Convert to json-schema")
>
> from the net-next tree.
>
> I fixed it up (I deleted the file and added the following 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: Fri, 2 Oct 2020 12:57:33 +1000
> Subject: [PATCH] fix up for "dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thank you, that resolution looks good to me!

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> @@ -31,6 +31,7 @@ properties:
>                - renesas,etheravb-r8a774a1     # RZ/G2M
>                - renesas,etheravb-r8a774b1     # RZ/G2N
>                - renesas,etheravb-r8a774c0     # RZ/G2E
> +              - renesas,etheravb-r8a774e1     # RZ/G2H
>                - renesas,etheravb-r8a7795      # R-Car H3
>                - renesas,etheravb-r8a7796      # R-Car M3-W
>                - renesas,etheravb-r8a77961     # R-Car M3-W+
> --
> 2.28.0

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/devicetree/bindings/net/renesas,ravb.txt

between commit:

  307eea32b202 ("dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC")

from the net tree and commit:

  d7adf6331189 ("dt-bindings: net: renesas,etheravb: Convert to json-schema")

from the net-next tree.

I fixed it up (I deleted the file and added the following 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: Fri, 2 Oct 2020 12:57:33 +1000
Subject: [PATCH] fix up for "dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index e13653051b23..244befb6402a 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -31,6 +31,7 @@ properties:
               - renesas,etheravb-r8a774a1     # RZ/G2M
               - renesas,etheravb-r8a774b1     # RZ/G2N
               - renesas,etheravb-r8a774c0     # RZ/G2E
+              - renesas,etheravb-r8a774e1     # RZ/G2H
               - renesas,etheravb-r8a7795      # R-Car H3
               - renesas,etheravb-r8a7796      # R-Car M3-W
               - renesas,etheravb-r8a77961     # R-Car M3-W+
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Mat Martineau]

On Thu, 1 Oct 2020, Stephen Rothwell wrote:

> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/mptcp/protocol.h
>
> between commit:
>
>  1a49b2c2a501 ("mptcp: Handle incoming 32-bit DATA_FIN values")
>
> from the net tree and commit:
>
>  5c8c1640956e ("mptcp: add mptcp_destroy_common 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 net/mptcp/protocol.h
> index 20f04ac85409,7cfe52aeb2b8..000000000000
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@@ -387,7 -407,8 +407,8 @@@ void mptcp_data_ready(struct sock *sk,
>  bool mptcp_finish_join(struct sock *sk);
>  void mptcp_data_acked(struct sock *sk);
>  void mptcp_subflow_eof(struct sock *sk);
> -bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq);
> +bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq, bool use_64bit);
> + void mptcp_destroy_common(struct mptcp_sock *msk);
>

Yes, this is the appropriate conflict resolution. Thanks!


--
Mat Martineau
Intel

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

[Mat Martineau]

On Thu, 1 Oct 2020, Stephen Rothwell wrote:

> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/mptcp/protocol.c
>
> between commit:
>
>  917944da3bfc ("mptcp: Consistently use READ_ONCE/WRITE_ONCE with msk->ack_seq")
>
> from the net tree and commit:
>
>  8268ed4c9d19 ("mptcp: introduce and use mptcp_try_coalesce()")
>  ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")
>
> 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.
>

Hi Stephen,

I am fine with introducing the WRITE_ONCE() in __mptcp_move_skb() as your 
conflict resolution does, or I can submit a patch later to add the 
WRITE_ONCE() in that location. The latter is what I suggested to David 
when submitting the patch to the net tree.

Thanks,

Mat


>
> diff --cc net/mptcp/protocol.c
> index 5d747c6a610e,34c037731f35..000000000000
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@@ -112,64 -112,205 +112,205 @@@ static int __mptcp_socket_create(struc
>  	return 0;
>  }
>
> - static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
> - 			     struct sk_buff *skb,
> - 			     unsigned int offset, size_t copy_len)
> + static void mptcp_drop(struct sock *sk, struct sk_buff *skb)
> + {
> + 	sk_drops_add(sk, skb);
> + 	__kfree_skb(skb);
> + }
> +
> + static bool mptcp_try_coalesce(struct sock *sk, struct sk_buff *to,
> + 			       struct sk_buff *from)
> + {
> + 	bool fragstolen;
> + 	int delta;
> +
> + 	if (MPTCP_SKB_CB(from)->offset ||
> + 	    !skb_try_coalesce(to, from, &fragstolen, &delta))
> + 		return false;
> +
> + 	pr_debug("colesced seq %llx into %llx new len %d new end seq %llx",
> + 		 MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
> + 		 to->len, MPTCP_SKB_CB(from)->end_seq);
> + 	MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
> + 	kfree_skb_partial(from, fragstolen);
> + 	atomic_add(delta, &sk->sk_rmem_alloc);
> + 	sk_mem_charge(sk, delta);
> + 	return true;
> + }
> +
> + static bool mptcp_ooo_try_coalesce(struct mptcp_sock *msk, struct sk_buff *to,
> + 				   struct sk_buff *from)
> + {
> + 	if (MPTCP_SKB_CB(from)->map_seq != MPTCP_SKB_CB(to)->end_seq)
> + 		return false;
> +
> + 	return mptcp_try_coalesce((struct sock *)msk, to, from);
> + }
> +
> + /* "inspired" by tcp_data_queue_ofo(), main differences:
> +  * - use mptcp seqs
> +  * - don't cope with sacks
> +  */
> + static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
>  {
>  	struct sock *sk = (struct sock *)msk;
> - 	struct sk_buff *tail;
> + 	struct rb_node **p, *parent;
> + 	u64 seq, end_seq, max_seq;
> + 	struct sk_buff *skb1;
> + 	int space;
> +
> + 	seq = MPTCP_SKB_CB(skb)->map_seq;
> + 	end_seq = MPTCP_SKB_CB(skb)->end_seq;
> + 	space = tcp_space(sk);
> + 	max_seq = space > 0 ? space + msk->ack_seq : msk->ack_seq;
> +
> + 	pr_debug("msk=%p seq=%llx limit=%llx empty=%d", msk, seq, max_seq,
> + 		 RB_EMPTY_ROOT(&msk->out_of_order_queue));
> + 	if (after64(seq, max_seq)) {
> + 		/* out of window */
> + 		mptcp_drop(sk, skb);
> + 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_NODSSWINDOW);
> + 		return;
> + 	}
>
> - 	__skb_unlink(skb, &ssk->sk_receive_queue);
> + 	p = &msk->out_of_order_queue.rb_node;
> + 	MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
> + 	if (RB_EMPTY_ROOT(&msk->out_of_order_queue)) {
> + 		rb_link_node(&skb->rbnode, NULL, p);
> + 		rb_insert_color(&skb->rbnode, &msk->out_of_order_queue);
> + 		msk->ooo_last_skb = skb;
> + 		goto end;
> + 	}
>
> - 	skb_ext_reset(skb);
> - 	skb_orphan(skb);
> - 	WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
> + 	/* with 2 subflows, adding at end of ooo queue is quite likely
> + 	 * Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
> + 	 */
> + 	if (mptcp_ooo_try_coalesce(msk, msk->ooo_last_skb, skb)) {
> + 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
> + 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
> + 		return;
> + 	}
>
> - 	tail = skb_peek_tail(&sk->sk_receive_queue);
> - 	if (offset == 0 && tail) {
> - 		bool fragstolen;
> - 		int delta;
> + 	/* Can avoid an rbtree lookup if we are adding skb after ooo_last_skb */
> + 	if (!before64(seq, MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq)) {
> + 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
> + 		parent = &msk->ooo_last_skb->rbnode;
> + 		p = &parent->rb_right;
> + 		goto insert;
> + 	}
>
> - 		if (skb_try_coalesce(tail, skb, &fragstolen, &delta)) {
> - 			kfree_skb_partial(skb, fragstolen);
> - 			atomic_add(delta, &sk->sk_rmem_alloc);
> - 			sk_mem_charge(sk, delta);
> + 	/* Find place to insert this segment. Handle overlaps on the way. */
> + 	parent = NULL;
> + 	while (*p) {
> + 		parent = *p;
> + 		skb1 = rb_to_skb(parent);
> + 		if (before64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
> + 			p = &parent->rb_left;
> + 			continue;
> + 		}
> + 		if (before64(seq, MPTCP_SKB_CB(skb1)->end_seq)) {
> + 			if (!after64(end_seq, MPTCP_SKB_CB(skb1)->end_seq)) {
> + 				/* All the bits are present. Drop. */
> + 				mptcp_drop(sk, skb);
> + 				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + 				return;
> + 			}
> + 			if (after64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
> + 				/* partial overlap:
> + 				 *     |     skb      |
> + 				 *  |     skb1    |
> + 				 * continue traversing
> + 				 */
> + 			} else {
> + 				/* skb's seq == skb1's seq and skb covers skb1.
> + 				 * Replace skb1 with skb.
> + 				 */
> + 				rb_replace_node(&skb1->rbnode, &skb->rbnode,
> + 						&msk->out_of_order_queue);
> + 				mptcp_drop(sk, skb1);
> + 				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + 				goto merge_right;
> + 			}
> + 		} else if (mptcp_ooo_try_coalesce(msk, skb1, skb)) {
> + 			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
>  			return;
>  		}
> + 		p = &parent->rb_right;
>  	}
>
> - 	skb_set_owner_r(skb, sk);
> - 	__skb_queue_tail(&sk->sk_receive_queue, skb);
> - 	MPTCP_SKB_CB(skb)->offset = offset;
> - }
> + insert:
> + 	/* Insert segment into RB tree. */
> + 	rb_link_node(&skb->rbnode, parent, p);
> + 	rb_insert_color(&skb->rbnode, &msk->out_of_order_queue);
>
> - static void mptcp_stop_timer(struct sock *sk)
> - {
> - 	struct inet_connection_sock *icsk = inet_csk(sk);
> + merge_right:
> + 	/* Remove other segments covered by skb. */
> + 	while ((skb1 = skb_rb_next(skb)) != NULL) {
> + 		if (before64(end_seq, MPTCP_SKB_CB(skb1)->end_seq))
> + 			break;
> + 		rb_erase(&skb1->rbnode, &msk->out_of_order_queue);
> + 		mptcp_drop(sk, skb1);
> + 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + 	}
> + 	/* If there is no skb after us, we are the last_skb ! */
> + 	if (!skb1)
> + 		msk->ooo_last_skb = skb;
>
> - 	sk_stop_timer(sk, &icsk->icsk_retransmit_timer);
> - 	mptcp_sk(sk)->timer_ival = 0;
> + end:
> + 	skb_condense(skb);
> + 	skb_set_owner_r(skb, sk);
>  }
>
> - /* both sockets must be locked */
> - static bool mptcp_subflow_dsn_valid(const struct mptcp_sock *msk,
> - 				    struct sock *ssk)
> + static bool __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
> + 			     struct sk_buff *skb, unsigned int offset,
> + 			     size_t copy_len)
>  {
>  	struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
> - 	u64 dsn = mptcp_subflow_get_mapped_dsn(subflow);
> + 	struct sock *sk = (struct sock *)msk;
> + 	struct sk_buff *tail;
>
> - 	/* revalidate data sequence number.
> - 	 *
> - 	 * mptcp_subflow_data_available() is usually called
> - 	 * without msk lock.  Its unlikely (but possible)
> - 	 * that msk->ack_seq has been advanced since the last
> - 	 * call found in-sequence data.
> + 	__skb_unlink(skb, &ssk->sk_receive_queue);
> +
> + 	skb_ext_reset(skb);
> + 	skb_orphan(skb);
> +
> + 	/* the skb map_seq accounts for the skb offset:
> + 	 * mptcp_subflow_get_mapped_dsn() is based on the current tp->copied_seq
> + 	 * value
>  	 */
> - 	if (likely(dsn == msk->ack_seq))
> + 	MPTCP_SKB_CB(skb)->map_seq = mptcp_subflow_get_mapped_dsn(subflow);
> + 	MPTCP_SKB_CB(skb)->end_seq = MPTCP_SKB_CB(skb)->map_seq + copy_len;
> + 	MPTCP_SKB_CB(skb)->offset = offset;
> +
> + 	if (MPTCP_SKB_CB(skb)->map_seq == msk->ack_seq) {
> + 		/* in sequence */
> -		msk->ack_seq += copy_len;
> ++		WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
> + 		tail = skb_peek_tail(&sk->sk_receive_queue);
> + 		if (tail && mptcp_try_coalesce(sk, tail, skb))
> + 			return true;
> +
> + 		skb_set_owner_r(skb, sk);
> + 		__skb_queue_tail(&sk->sk_receive_queue, skb);
>  		return true;
> + 	} else if (after64(MPTCP_SKB_CB(skb)->map_seq, msk->ack_seq)) {
> + 		mptcp_data_queue_ofo(msk, skb);
> + 		return false;
> + 	}
>
> - 	subflow->data_avail = 0;
> - 	return mptcp_subflow_data_available(ssk);
> + 	/* old data, keep it simple and drop the whole pkt, sender
> + 	 * will retransmit as needed, if needed.
> + 	 */
> + 	MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + 	mptcp_drop(sk, skb);
> + 	return false;
> + }
> +
> + static void mptcp_stop_timer(struct sock *sk)
> + {
> + 	struct inet_connection_sock *icsk = inet_csk(sk);
> +
> + 	sk_stop_timer(sk, &icsk->icsk_retransmit_timer);
> + 	mptcp_sk(sk)->timer_ival = 0;
>  }
>
>  static void mptcp_check_data_fin_ack(struct sock *sk)
>

--
Mat Martineau
Intel

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/protocol.h

between commit:

  1a49b2c2a501 ("mptcp: Handle incoming 32-bit DATA_FIN values")

from the net tree and commit:

  5c8c1640956e ("mptcp: add mptcp_destroy_common 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 net/mptcp/protocol.h
index 20f04ac85409,7cfe52aeb2b8..000000000000
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@@ -387,7 -407,8 +407,8 @@@ void mptcp_data_ready(struct sock *sk, 
  bool mptcp_finish_join(struct sock *sk);
  void mptcp_data_acked(struct sock *sk);
  void mptcp_subflow_eof(struct sock *sk);
 -bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq);
 +bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq, bool use_64bit);
+ void mptcp_destroy_common(struct mptcp_sock *msk);
  
  void __init mptcp_token_init(void);
  static inline void mptcp_token_init_request(struct request_sock *req)

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mptcp/protocol.c

between commit:

  917944da3bfc ("mptcp: Consistently use READ_ONCE/WRITE_ONCE with msk->ack_seq")

from the net tree and commit:

  8268ed4c9d19 ("mptcp: introduce and use mptcp_try_coalesce()")
  ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")

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/mptcp/protocol.c
index 5d747c6a610e,34c037731f35..000000000000
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@@ -112,64 -112,205 +112,205 @@@ static int __mptcp_socket_create(struc
  	return 0;
  }
  
- static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
- 			     struct sk_buff *skb,
- 			     unsigned int offset, size_t copy_len)
+ static void mptcp_drop(struct sock *sk, struct sk_buff *skb)
+ {
+ 	sk_drops_add(sk, skb);
+ 	__kfree_skb(skb);
+ }
+ 
+ static bool mptcp_try_coalesce(struct sock *sk, struct sk_buff *to,
+ 			       struct sk_buff *from)
+ {
+ 	bool fragstolen;
+ 	int delta;
+ 
+ 	if (MPTCP_SKB_CB(from)->offset ||
+ 	    !skb_try_coalesce(to, from, &fragstolen, &delta))
+ 		return false;
+ 
+ 	pr_debug("colesced seq %llx into %llx new len %d new end seq %llx",
+ 		 MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
+ 		 to->len, MPTCP_SKB_CB(from)->end_seq);
+ 	MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
+ 	kfree_skb_partial(from, fragstolen);
+ 	atomic_add(delta, &sk->sk_rmem_alloc);
+ 	sk_mem_charge(sk, delta);
+ 	return true;
+ }
+ 
+ static bool mptcp_ooo_try_coalesce(struct mptcp_sock *msk, struct sk_buff *to,
+ 				   struct sk_buff *from)
+ {
+ 	if (MPTCP_SKB_CB(from)->map_seq != MPTCP_SKB_CB(to)->end_seq)
+ 		return false;
+ 
+ 	return mptcp_try_coalesce((struct sock *)msk, to, from);
+ }
+ 
+ /* "inspired" by tcp_data_queue_ofo(), main differences:
+  * - use mptcp seqs
+  * - don't cope with sacks
+  */
+ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
  {
  	struct sock *sk = (struct sock *)msk;
- 	struct sk_buff *tail;
+ 	struct rb_node **p, *parent;
+ 	u64 seq, end_seq, max_seq;
+ 	struct sk_buff *skb1;
+ 	int space;
+ 
+ 	seq = MPTCP_SKB_CB(skb)->map_seq;
+ 	end_seq = MPTCP_SKB_CB(skb)->end_seq;
+ 	space = tcp_space(sk);
+ 	max_seq = space > 0 ? space + msk->ack_seq : msk->ack_seq;
+ 
+ 	pr_debug("msk=%p seq=%llx limit=%llx empty=%d", msk, seq, max_seq,
+ 		 RB_EMPTY_ROOT(&msk->out_of_order_queue));
+ 	if (after64(seq, max_seq)) {
+ 		/* out of window */
+ 		mptcp_drop(sk, skb);
+ 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_NODSSWINDOW);
+ 		return;
+ 	}
  
- 	__skb_unlink(skb, &ssk->sk_receive_queue);
+ 	p = &msk->out_of_order_queue.rb_node;
+ 	MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
+ 	if (RB_EMPTY_ROOT(&msk->out_of_order_queue)) {
+ 		rb_link_node(&skb->rbnode, NULL, p);
+ 		rb_insert_color(&skb->rbnode, &msk->out_of_order_queue);
+ 		msk->ooo_last_skb = skb;
+ 		goto end;
+ 	}
  
- 	skb_ext_reset(skb);
- 	skb_orphan(skb);
- 	WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+ 	/* with 2 subflows, adding at end of ooo queue is quite likely
+ 	 * Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
+ 	 */
+ 	if (mptcp_ooo_try_coalesce(msk, msk->ooo_last_skb, skb)) {
+ 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
+ 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ 		return;
+ 	}
  
- 	tail = skb_peek_tail(&sk->sk_receive_queue);
- 	if (offset == 0 && tail) {
- 		bool fragstolen;
- 		int delta;
+ 	/* Can avoid an rbtree lookup if we are adding skb after ooo_last_skb */
+ 	if (!before64(seq, MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq)) {
+ 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ 		parent = &msk->ooo_last_skb->rbnode;
+ 		p = &parent->rb_right;
+ 		goto insert;
+ 	}
  
- 		if (skb_try_coalesce(tail, skb, &fragstolen, &delta)) {
- 			kfree_skb_partial(skb, fragstolen);
- 			atomic_add(delta, &sk->sk_rmem_alloc);
- 			sk_mem_charge(sk, delta);
+ 	/* Find place to insert this segment. Handle overlaps on the way. */
+ 	parent = NULL;
+ 	while (*p) {
+ 		parent = *p;
+ 		skb1 = rb_to_skb(parent);
+ 		if (before64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
+ 			p = &parent->rb_left;
+ 			continue;
+ 		}
+ 		if (before64(seq, MPTCP_SKB_CB(skb1)->end_seq)) {
+ 			if (!after64(end_seq, MPTCP_SKB_CB(skb1)->end_seq)) {
+ 				/* All the bits are present. Drop. */
+ 				mptcp_drop(sk, skb);
+ 				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ 				return;
+ 			}
+ 			if (after64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
+ 				/* partial overlap:
+ 				 *     |     skb      |
+ 				 *  |     skb1    |
+ 				 * continue traversing
+ 				 */
+ 			} else {
+ 				/* skb's seq == skb1's seq and skb covers skb1.
+ 				 * Replace skb1 with skb.
+ 				 */
+ 				rb_replace_node(&skb1->rbnode, &skb->rbnode,
+ 						&msk->out_of_order_queue);
+ 				mptcp_drop(sk, skb1);
+ 				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ 				goto merge_right;
+ 			}
+ 		} else if (mptcp_ooo_try_coalesce(msk, skb1, skb)) {
+ 			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
  			return;
  		}
+ 		p = &parent->rb_right;
  	}
  
- 	skb_set_owner_r(skb, sk);
- 	__skb_queue_tail(&sk->sk_receive_queue, skb);
- 	MPTCP_SKB_CB(skb)->offset = offset;
- }
+ insert:
+ 	/* Insert segment into RB tree. */
+ 	rb_link_node(&skb->rbnode, parent, p);
+ 	rb_insert_color(&skb->rbnode, &msk->out_of_order_queue);
  
- static void mptcp_stop_timer(struct sock *sk)
- {
- 	struct inet_connection_sock *icsk = inet_csk(sk);
+ merge_right:
+ 	/* Remove other segments covered by skb. */
+ 	while ((skb1 = skb_rb_next(skb)) != NULL) {
+ 		if (before64(end_seq, MPTCP_SKB_CB(skb1)->end_seq))
+ 			break;
+ 		rb_erase(&skb1->rbnode, &msk->out_of_order_queue);
+ 		mptcp_drop(sk, skb1);
+ 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ 	}
+ 	/* If there is no skb after us, we are the last_skb ! */
+ 	if (!skb1)
+ 		msk->ooo_last_skb = skb;
  
- 	sk_stop_timer(sk, &icsk->icsk_retransmit_timer);
- 	mptcp_sk(sk)->timer_ival = 0;
+ end:
+ 	skb_condense(skb);
+ 	skb_set_owner_r(skb, sk);
  }
  
- /* both sockets must be locked */
- static bool mptcp_subflow_dsn_valid(const struct mptcp_sock *msk,
- 				    struct sock *ssk)
+ static bool __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
+ 			     struct sk_buff *skb, unsigned int offset,
+ 			     size_t copy_len)
  {
  	struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
- 	u64 dsn = mptcp_subflow_get_mapped_dsn(subflow);
+ 	struct sock *sk = (struct sock *)msk;
+ 	struct sk_buff *tail;
  
- 	/* revalidate data sequence number.
- 	 *
- 	 * mptcp_subflow_data_available() is usually called
- 	 * without msk lock.  Its unlikely (but possible)
- 	 * that msk->ack_seq has been advanced since the last
- 	 * call found in-sequence data.
+ 	__skb_unlink(skb, &ssk->sk_receive_queue);
+ 
+ 	skb_ext_reset(skb);
+ 	skb_orphan(skb);
+ 
+ 	/* the skb map_seq accounts for the skb offset:
+ 	 * mptcp_subflow_get_mapped_dsn() is based on the current tp->copied_seq
+ 	 * value
  	 */
- 	if (likely(dsn == msk->ack_seq))
+ 	MPTCP_SKB_CB(skb)->map_seq = mptcp_subflow_get_mapped_dsn(subflow);
+ 	MPTCP_SKB_CB(skb)->end_seq = MPTCP_SKB_CB(skb)->map_seq + copy_len;
+ 	MPTCP_SKB_CB(skb)->offset = offset;
+ 
+ 	if (MPTCP_SKB_CB(skb)->map_seq == msk->ack_seq) {
+ 		/* in sequence */
 -		msk->ack_seq += copy_len;
++		WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+ 		tail = skb_peek_tail(&sk->sk_receive_queue);
+ 		if (tail && mptcp_try_coalesce(sk, tail, skb))
+ 			return true;
+ 
+ 		skb_set_owner_r(skb, sk);
+ 		__skb_queue_tail(&sk->sk_receive_queue, skb);
  		return true;
+ 	} else if (after64(MPTCP_SKB_CB(skb)->map_seq, msk->ack_seq)) {
+ 		mptcp_data_queue_ofo(msk, skb);
+ 		return false;
+ 	}
  
- 	subflow->data_avail = 0;
- 	return mptcp_subflow_data_available(ssk);
+ 	/* old data, keep it simple and drop the whole pkt, sender
+ 	 * will retransmit as needed, if needed.
+ 	 */
+ 	MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ 	mptcp_drop(sk, skb);
+ 	return false;
+ }
+ 
+ static void mptcp_stop_timer(struct sock *sk)
+ {
+ 	struct inet_connection_sock *icsk = inet_csk(sk);
+ 
+ 	sk_stop_timer(sk, &icsk->icsk_retransmit_timer);
+ 	mptcp_sk(sk)->timer_ival = 0;
  }
  
  static void mptcp_check_data_fin_ack(struct sock *sk)

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/phy/realtek.c

between commit:

  bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")

from the net tree and commit:

  66e22932eb79 ("net: phy: realtek: enable ALDPS to save power for RTL8211F")

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/realtek.c
index 0f0960971800,4bf54cded48a..000000000000
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@@ -31,9 -33,13 +32,13 @@@
  #define RTL8211F_TX_DELAY			BIT(8)
  #define RTL8211F_RX_DELAY			BIT(3)
  
+ #define RTL8211F_ALDPS_PLL_OFF			BIT(1)
+ #define RTL8211F_ALDPS_ENABLE			BIT(2)
+ #define RTL8211F_ALDPS_XTAL_OFF			BIT(12)
+ 
 -#define RTL8211E_TX_DELAY			BIT(1)
 -#define RTL8211E_RX_DELAY			BIT(2)
 -#define RTL8211E_MODE_MII_GMII			BIT(3)
 +#define RTL8211E_CTRL_DELAY			BIT(13)
 +#define RTL8211E_TX_DELAY			BIT(12)
 +#define RTL8211E_RX_DELAY			BIT(11)
  
  #define RTL8201F_ISR				0x1e
  #define RTL8201F_IER				0x13

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

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

[Andrew Lunn]

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 28 Sep 2020 12:42:10 +1000
> Subject: [PATCH] merge fix for "mdio: fix mdio-thunder.c dependency & build error"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/net/mdio/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
> index 840727cc9499..27a2a4a3d943 100644
> --- a/drivers/net/mdio/Kconfig
> +++ b/drivers/net/mdio/Kconfig
> @@ -164,6 +164,7 @@ config MDIO_THUNDER
>  	depends on 64BIT
>  	depends on PCI
>  	select MDIO_CAVIUM
> +	select MDIO_DEVRES
>  	help
>  	  This driver supports the MDIO interfaces found on Cavium
>  	  ThunderX SoCs when the MDIO bus device appears as a PCI
> -- 
> 2.28.0

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/phy/Kconfig

between commit:

  7dbbcf496f2a ("mdio: fix mdio-thunder.c dependency & build error")

from the net tree and commit:

  a9770eac511a ("net: mdio: Move MDIO drivers into a new subdirectory")

from the net-next tree.

I fixed it up (I used the latter and applied the following 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: Mon, 28 Sep 2020 12:42:10 +1000
Subject: [PATCH] merge fix for "mdio: fix mdio-thunder.c dependency & build error"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/mdio/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 840727cc9499..27a2a4a3d943 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -164,6 +164,7 @@ config MDIO_THUNDER
 	depends on 64BIT
 	depends on PCI
 	select MDIO_CAVIUM
+	select MDIO_DEVRES
 	help
 	  This driver supports the MDIO interfaces found on Cavium
 	  ThunderX SoCs when the MDIO bus device appears as a PCI
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/ipv4/route.c

between commit:

  2fbc6e89b2f1 ("ipv4: Update exception handling for multipath routes via same device")

from the net tree and commit:

  8b4510d76cde ("net: gain ipv4 mtu when mtu is not locked")

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/route.c
index 58642b29a499,2c05b863ae43..000000000000
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@@ -1015,10 -1013,9 +1015,10 @@@ out:	kfree_skb(skb)
  static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu)
  {
  	struct dst_entry *dst = &rt->dst;
 +	struct net *net = dev_net(dst->dev);
- 	u32 old_mtu = ipv4_mtu(dst);
  	struct fib_result res;
  	bool lock = false;
+ 	u32 old_mtu;
  
  	if (ip_mtu_locked(dst))
  		return;

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

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

[Paul Barker]

On Fri, 11 Sep 2020 at 02:17, 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/dsa/microchip/ksz9477.c
>
> between commit:
>
>   edecfa98f602 ("net: dsa: microchip: look for phy-mode in port nodes")
>
> from the net tree and commit:
>
>   805a7e6f5388 ("net: dsa: microchip: Improve phy mode message")
>
> 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/microchip/ksz9477.c
> index 2f5506ac7d19,b62dd64470a8..000000000000
> --- a/drivers/net/dsa/microchip/ksz9477.c
> +++ b/drivers/net/dsa/microchip/ksz9477.c
> @@@ -1229,12 -1229,15 +1229,15 @@@ static void ksz9477_port_setup(struct k
>                         ksz9477_set_gbit(dev, true, &data8);
>                         data8 &= ~PORT_RGMII_ID_IG_ENABLE;
>                         data8 &= ~PORT_RGMII_ID_EG_ENABLE;
>  -                      if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>  -                          dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
>  +                      if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>  +                          p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
>                                 data8 |= PORT_RGMII_ID_IG_ENABLE;
>  -                      if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>  -                          dev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
>  +                      if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>  +                          p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
>                                 data8 |= PORT_RGMII_ID_EG_ENABLE;
> +                       /* On KSZ9893, disable RGMII in-band status support */
> +                       if (dev->features & IS_9893)
> +                               data8 &= ~PORT_MII_MAC_MODE;
>                         p->phydev.speed = SPEED_1000;
>                         break;
>                 }
> @@@ -1276,22 -1280,21 +1281,30 @@@ static void ksz9477_config_cpu_port(str
>                          * note the difference to help debugging.
>                          */
>                         interface = ksz9477_get_interface(dev, i);
>  -                      if (!dev->interface)
>  -                              dev->interface = interface;
>  -                      if (interface && interface != dev->interface) {
>  +                      if (!p->interface) {
>  +                              if (dev->compat_interface) {
>  +                                      dev_warn(dev->dev,
>  +                                               "Using legacy switch \"phy-mode\" property, because it is missing on port %d node. "
>  +                                               "Please update your device tree.\n",
>  +                                               i);
>  +                                      p->interface = dev->compat_interface;
>  +                              } else {
>  +                                      p->interface = interface;
>  +                              }
>  +                      }
> -                       if (interface && interface != p->interface)
> -                               dev_info(dev->dev,
> -                                        "use %s instead of %s\n",
> -                                         phy_modes(p->interface),
> -                                         phy_modes(interface));
> ++                      if (interface && interface != p->interface) {
> +                               prev_msg = " instead of ";
> +                               prev_mode = phy_modes(interface);
> +                       } else {
> +                               prev_msg = "";
> +                               prev_mode = "";
> +                       }
> +                       dev_info(dev->dev,
> +                                "Port%d: using phy mode %s%s%s\n",
> +                                i,
>  -                               phy_modes(dev->interface),
> ++                               phy_modes(p->interface),
> +                                prev_msg,
> +                                prev_mode);
>
>                         /* enable cpu port */
>                         ksz9477_port_setup(dev, i, true);

Looks good to me wrt my patch "net: dsa: microchip: Improve phy mode message".

Thanks,

-- 
Paul Barker
Konsulko Group

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/dsa/microchip/ksz9477.c

between commit:

  edecfa98f602 ("net: dsa: microchip: look for phy-mode in port nodes")

from the net tree and commit:

  805a7e6f5388 ("net: dsa: microchip: Improve phy mode message")

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/microchip/ksz9477.c
index 2f5506ac7d19,b62dd64470a8..000000000000
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@@ -1229,12 -1229,15 +1229,15 @@@ static void ksz9477_port_setup(struct k
  			ksz9477_set_gbit(dev, true, &data8);
  			data8 &= ~PORT_RGMII_ID_IG_ENABLE;
  			data8 &= ~PORT_RGMII_ID_EG_ENABLE;
 -			if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 -			    dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
 +			if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 +			    p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
  				data8 |= PORT_RGMII_ID_IG_ENABLE;
 -			if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 -			    dev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
 +			if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 +			    p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
  				data8 |= PORT_RGMII_ID_EG_ENABLE;
+ 			/* On KSZ9893, disable RGMII in-band status support */
+ 			if (dev->features & IS_9893)
+ 				data8 &= ~PORT_MII_MAC_MODE;
  			p->phydev.speed = SPEED_1000;
  			break;
  		}
@@@ -1276,22 -1280,21 +1281,30 @@@ static void ksz9477_config_cpu_port(str
  			 * note the difference to help debugging.
  			 */
  			interface = ksz9477_get_interface(dev, i);
 -			if (!dev->interface)
 -				dev->interface = interface;
 -			if (interface && interface != dev->interface) {
 +			if (!p->interface) {
 +				if (dev->compat_interface) {
 +					dev_warn(dev->dev,
 +						 "Using legacy switch \"phy-mode\" property, because it is missing on port %d node. "
 +						 "Please update your device tree.\n",
 +						 i);
 +					p->interface = dev->compat_interface;
 +				} else {
 +					p->interface = interface;
 +				}
 +			}
- 			if (interface && interface != p->interface)
- 				dev_info(dev->dev,
- 					 "use %s instead of %s\n",
- 					  phy_modes(p->interface),
- 					  phy_modes(interface));
++			if (interface && interface != p->interface) {
+ 				prev_msg = " instead of ";
+ 				prev_mode = phy_modes(interface);
+ 			} else {
+ 				prev_msg = "";
+ 				prev_mode = "";
+ 			}
+ 			dev_info(dev->dev,
+ 				 "Port%d: using phy mode %s%s%s\n",
+ 				 i,
 -				 phy_modes(dev->interface),
++				 phy_modes(p->interface),
+ 				 prev_msg,
+ 				 prev_mode);
  
  			/* enable cpu port */
  			ksz9477_port_setup(dev, i, true);

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/ipv4/raw.c

between commit:

  645f08975f49 ("net: Fix some comments")

from the net tree and commit:

  2bdcc73c88d2 ("net: ipv4: delete repeated words")

from the net-next tree.

I fixed it up (they each removed a different "and" - I kept 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 --]

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  9f1345737790 ("ibmvnic fix NULL tx_pools and rx_tools issue at do_reset")

from the net tree and commit:

  507ebe6444a4 ("ibmvnic: Fix use-after-free of VNIC login response buffer")

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 d3a774331afc,86a83e53dce5..000000000000
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -475,17 -467,12 +467,15 @@@ static int init_stats_token(struct ibmv
  static int reset_rx_pools(struct ibmvnic_adapter *adapter)
  {
  	struct ibmvnic_rx_pool *rx_pool;
+ 	u64 buff_size;
  	int rx_scrqs;
  	int i, j, rc;
- 	u64 *size_array;
  
 +	if (!adapter->rx_pool)
 +		return -1;
 +
- 	size_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
- 		be32_to_cpu(adapter->login_rsp_buf->off_rxadd_buff_size));
- 
- 	rx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_rxadd_subcrqs);
+ 	buff_size = adapter->cur_rx_buf_sz;
+ 	rx_scrqs = adapter->num_active_rx_pools;
  	for (i = 0; i < rx_scrqs; i++) {
  		rx_pool = &adapter->rx_pool[i];
  
@@@ -652,10 -637,7 +640,10 @@@ static int reset_tx_pools(struct ibmvni
  	int tx_scrqs;
  	int i, rc;
  
 +	if (!adapter->tx_pool)
 +		return -1;
 +
- 	tx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_txsubm_subcrqs);
+ 	tx_scrqs = adapter->num_active_tx_pools;
  	for (i = 0; i < tx_scrqs; i++) {
  		rc = reset_one_tx_pool(adapter, &adapter->tso_pool[i]);
  		if (rc)

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

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

[Claudiu Manoil]

>-----Original Message-----
>From: Stephen Rothwell <sfr@canb.auug.org.au>
>Sent: Friday, July 24, 2020 5:24 AM
[...]
>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/freescale/enetc/enetc_pf.c
>
>between commit:
>
>  26cb7085c898 ("enetc: Remove the mdio bus on PF probe bailout")
>
>from the net tree and commits:
>
>  07095c025ac2 ("net: enetc: Use DT protocol information to set up the ports")
>  c6dd6488acd1 ("enetc: Remove the imdio bus on PF probe bailout")
>
>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.
>

It's unfortunate, but I think the conflict was unavoidable at this stage.
The net-next commit 07095c025ac2 uncovers an older bug making it worse
by modifying code around it, introducing a regression for a use case that worked
before. That prompted the 'net' tree fix 26cb7085c898, which inevitably got into conflict
with 'net-next'.  The conflict is simple AFAIC, it's about one line, one function call on the
bailout path.

If you're asking me, you can go on with the resolution you consider to be the safest.
Then I can send a follow up patch after 'net-next' gets merged into 'net',
to make the necessary corrections if needed.
Fyi,
The bailout path after merging the patches should be as below, the tricky line
being marked as "==>":

err_reg_netdev:
	enetc_teardown_serdes(priv);
	enetc_free_msix(priv);
err_alloc_msix:
[...]
err_alloc_netdev:
==>	enetc_mdio_remove(pf);
	enetc_of_put_phy(pf);
err_map_pf_space:
[...]

Thanks.
Claudiu

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/geneve.c

between commit:

  32818c075c54 ("geneve: fix an uninitialized value in geneve_changelink()")

from the net tree and commit:

  9e06e8596bc8 ("geneve: move all configuration under struct geneve_config")

from the net-next tree.

I fixed it up (the latter removed the code moved 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

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/freescale/enetc/enetc_pf.c

between commit:

  26cb7085c898 ("enetc: Remove the mdio bus on PF probe bailout")

from the net tree and commits:

  07095c025ac2 ("net: enetc: Use DT protocol information to set up the ports")
  c6dd6488acd1 ("enetc: Remove the imdio bus on PF probe bailout")

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/netdevsim/netdev.c

between commit:

  2c9d8e01f0c6 ("netdevsim: fix unbalaced locking in nsim_create()")

from the net tree and commit:

  424be63ad831 ("netdevsim: add UDP tunnel port offload 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/netdevsim/netdev.c
index 23950e7a0f81,9d0d18026434..000000000000
--- a/drivers/net/netdevsim/netdev.c
+++ b/drivers/net/netdevsim/netdev.c
@@@ -316,8 -323,10 +323,10 @@@ nsim_create(struct nsim_dev *nsim_dev, 
  err_ipsec_teardown:
  	nsim_ipsec_teardown(ns);
  	nsim_bpf_uninit(ns);
 +err_rtnl_unlock:
  	rtnl_unlock();
 -err_utn_destroy:
+ 	nsim_udp_tunnels_info_destroy(dev);
+ err_free_netdev:
  	free_netdev(dev);
  	return ERR_PTR(err);
  }

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

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

[Stephen Rothwell]

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

  23e500e88723 ("net: atlantic: disable PTP on AQC111, AQC112")

from the net tree and commit:

  1e41b3fee795 ("net: atlantic: add support for 64-bit reads/writes")

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 992fedbe4ce3,95ee1336ac79..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
@@@ -64,7 -67,7 +67,8 @@@ struct aq_hw_caps_s 
  	u8 rx_rings;
  	bool flow_control;
  	bool is_64_dma;
+ 	bool op64bit;
 +	u32 quirks;
  	u32 priv_data_len;
  };
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/xfrm/xfrm_device.c

between commit:

  94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion in IPsec crypto offload.")

from the net tree and commit:

  272c2330adc9 ("xfrm: bail early on slave pass over skb")

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/xfrm/xfrm_device.c
index 626096bd0d29,b8918fc5248b..000000000000
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@@ -106,9 -106,10 +106,10 @@@ struct sk_buff *validate_xmit_xfrm(stru
  	struct sk_buff *skb2, *nskb, *pskb = NULL;
  	netdev_features_t esp_features = features;
  	struct xfrm_offload *xo = xfrm_offload(skb);
+ 	struct net_device *dev = skb->dev;
  	struct sec_path *sp;
  
 -	if (!xo)
 +	if (!xo || (xo->flags & XFRM_XMIT))
  		return skb;
  
  	if (!(features & NETIF_F_HW_ESP))
@@@ -129,27 -134,20 +134,22 @@@
  		return skb;
  	}
  
 +	xo->flags |= XFRM_XMIT;
 +
- 	if (skb_is_gso(skb)) {
- 		struct net_device *dev = skb->dev;
- 
- 		if (unlikely(x->xso.dev != dev)) {
- 			struct sk_buff *segs;
+ 	if (skb_is_gso(skb) && unlikely(x->xso.dev != dev)) {
+ 		struct sk_buff *segs;
  
- 			/* Packet got rerouted, fixup features and segment it. */
- 			esp_features = esp_features & ~(NETIF_F_HW_ESP
- 							| NETIF_F_GSO_ESP);
+ 		/* Packet got rerouted, fixup features and segment it. */
+ 		esp_features = esp_features & ~(NETIF_F_HW_ESP | NETIF_F_GSO_ESP);
  
- 			segs = skb_gso_segment(skb, esp_features);
- 			if (IS_ERR(segs)) {
- 				kfree_skb(skb);
- 				atomic_long_inc(&dev->tx_dropped);
- 				return NULL;
- 			} else {
- 				consume_skb(skb);
- 				skb = segs;
- 			}
+ 		segs = skb_gso_segment(skb, esp_features);
+ 		if (IS_ERR(segs)) {
+ 			kfree_skb(skb);
+ 			atomic_long_inc(&dev->tx_dropped);
+ 			return NULL;
+ 		} else {
+ 			consume_skb(skb);
+ 			skb = segs;
  		}
  	}
  

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

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

[luobin (L)]

On 2020/5/13 0:47, Jakub Kicinski wrote:

> On Tue, 12 May 2020 13:30:51 +1000 Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the net-next tree got conflicts in:
>>
>>    drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
>>    drivers/net/ethernet/huawei/hinic/hinic_main.c
>>
>> between commit:
>>
>>    e8a1b0efd632 ("hinic: fix a bug of ndo_stop")
>>
>> from the net tree and commit:
>>
>>    7dd29ee12865 ("hinic: add sriov feature support")
>>
>> 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.
> I had a feeling this was gonna happen :(
>
> Resolution looks correct, thank you!
>
> Luo bin, if you want to adjust the timeouts (you had slightly different
> ones depending on the command in the first version of the fix) - you can
> follow up with a patch to net-next once Dave merges net into net-next
> (usually happens every two weeks).

> OK. Thanks.
> .

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

[Jakub Kicinski]

On Tue, 12 May 2020 13:30:51 +1000 Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
>   drivers/net/ethernet/huawei/hinic/hinic_main.c
> 
> between commit:
> 
>   e8a1b0efd632 ("hinic: fix a bug of ndo_stop")
> 
> from the net tree and commit:
> 
>   7dd29ee12865 ("hinic: add sriov feature support")
> 
> 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.

I had a feeling this was gonna happen :(

Resolution looks correct, thank you!

Luo bin, if you want to adjust the timeouts (you had slightly different
ones depending on the command in the first version of the fix) - you can
follow up with a patch to net-next once Dave merges net into net-next
(usually happens every two weeks).

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
  drivers/net/ethernet/huawei/hinic/hinic_main.c

between commit:

  e8a1b0efd632 ("hinic: fix a bug of ndo_stop")

from the net tree and commit:

  7dd29ee12865 ("hinic: add sriov feature support")

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/huawei/hinic/hinic_hw_mgmt.c
index 992908e6eebf,eef855f11a01..000000000000
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
@@@ -358,12 -353,13 +358,16 @@@ int hinic_msg_to_mgmt(struct hinic_pf_t
  		return -EINVAL;
  	}
  
 +	if (cmd == HINIC_PORT_CMD_SET_FUNC_STATE)
 +		timeout = SET_FUNC_PORT_MGMT_TIMEOUT;
 +
- 	return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
+ 	if (HINIC_IS_VF(hwif))
+ 		return hinic_mbox_to_pf(pf_to_mgmt->hwdev, mod, cmd, buf_in,
+ 					in_size, buf_out, out_size, 0);
+ 	else
+ 		return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
  				buf_out, out_size, MGMT_DIRECT_SEND,
 -				MSG_NOT_RESP);
 +				MSG_NOT_RESP, timeout);
  }
  
  /**
diff --cc drivers/net/ethernet/huawei/hinic/hinic_main.c
index 63b92f6cc856,3d6569d7bac8..000000000000
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@@ -496,9 -501,23 +500,12 @@@ static int hinic_close(struct net_devic
  
  	up(&nic_dev->mgmt_lock);
  
+ 	if (!HINIC_IS_VF(nic_dev->hwdev->hwif))
+ 		hinic_notify_all_vfs_link_changed(nic_dev->hwdev, 0);
+ 
 -	err = hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
 -	if (err) {
 -		netif_err(nic_dev, drv, netdev,
 -			  "Failed to set func port state\n");
 -		nic_dev->flags |= (flags & HINIC_INTF_UP);
 -		return err;
 -	}
 +	hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
  
 -	err = hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
 -	if (err) {
 -		netif_err(nic_dev, drv, netdev, "Failed to set port state\n");
 -		nic_dev->flags |= (flags & HINIC_INTF_UP);
 -		return err;
 -	}
 +	hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
  
  	if (nic_dev->flags & HINIC_RSS_ENABLE) {
  		hinic_rss_deinit(nic_dev);

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

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

[Leon Romanovsky]

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

On Fri, May 01, 2020 at 12:48:36PM +1000, 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/steering/dr_send.c
>
> between commit:
>
>   8075411d93b6 ("net/mlx5: DR, On creation set CQ's arm_db member to right value")
>
> from the net tree and commit:
>
>   73a75b96fc9a ("net/mlx5: Remove empty QP and CQ events handlers")
>
> 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

Thanks for the resolution.

>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> index 18719acb7e54,c4ed25bb9ac8..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> @@@ -689,18 -693,6 +693,12 @@@ static int dr_prepare_qp_to_rts(struct
>   	return 0;
>   }
>
> - static void dr_cq_event(struct mlx5_core_cq *mcq,
> - 			enum mlx5_event event)
> - {
> - 	pr_info("CQ event %u on CQ #%u\n", event, mcq->cqn);
> - }
> -
>  +static void dr_cq_complete(struct mlx5_core_cq *mcq,
>  +			   struct mlx5_eqe *eqe)
>  +{
>  +	pr_err("CQ completion CQ: #%u\n", mcq->cqn);
>  +}
>  +

Saeed,

Please pay attention that commit 8075411d93b6
("net/mlx5: DR, On creation set CQ's arm_db member to right value")
mentioned by Stephen is not accurate. ".comp" callback shouldn't be
called if it is NULL, so unclear what you get by adding such pr_err().

Thanks

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c

between commit:

  8075411d93b6 ("net/mlx5: DR, On creation set CQ's arm_db member to right value")

from the net tree and commit:

  73a75b96fc9a ("net/mlx5: Remove empty QP and CQ events handlers")

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/steering/dr_send.c
index 18719acb7e54,c4ed25bb9ac8..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
@@@ -689,18 -693,6 +693,12 @@@ static int dr_prepare_qp_to_rts(struct 
  	return 0;
  }
  
- static void dr_cq_event(struct mlx5_core_cq *mcq,
- 			enum mlx5_event event)
- {
- 	pr_info("CQ event %u on CQ #%u\n", event, mcq->cqn);
- }
- 
 +static void dr_cq_complete(struct mlx5_core_cq *mcq,
 +			   struct mlx5_eqe *eqe)
 +{
 +	pr_err("CQ completion CQ: #%u\n", mcq->cqn);
 +}
 +
  static struct mlx5dr_cq *dr_create_cq(struct mlx5_core_dev *mdev,
  				      struct mlx5_uars_page *uar,
  				      size_t ncqe)
@@@ -761,9 -753,6 +759,8 @@@
  	pas = (__be64 *)MLX5_ADDR_OF(create_cq_in, in, pas);
  	mlx5_fill_page_frag_array(&cq->wq_ctrl.buf, pas);
  
- 	cq->mcq.event = dr_cq_event;
 +	cq->mcq.comp  = dr_cq_complete;
 +
  	err = mlx5_core_create_cq(mdev, &cq->mcq, in, inlen, out, sizeof(out));
  	kvfree(in);
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/net/mptcp.h

between commit:

  cfde141ea3fa ("mptcp: move option parsing into mptcp_incoming_options()")

from the net tree and commit:

  071c8ed6e88d ("tcp: mptcp: use mptcp receive buffer space to select rcv window")

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/mptcp.h
index 3bce2019e4da,5288fba56e55..000000000000
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@@ -68,8 -68,13 +68,10 @@@ static inline bool rsk_is_mptcp(const s
  	return tcp_rsk(req)->is_mptcp;
  }
  
+ void mptcp_space(const struct sock *ssk, int *space, int *full_space);
+ 
 -void mptcp_parse_option(const struct sk_buff *skb, const unsigned char *ptr,
 -			int opsize, struct tcp_options_received *opt_rx);
  bool mptcp_syn_options(struct sock *sk, const struct sk_buff *skb,
  		       unsigned int *size, struct mptcp_out_options *opts);
 -void mptcp_rcv_synsent(struct sock *sk);
  bool mptcp_synack_options(const struct request_sock *req, unsigned int *size,
  			  struct mptcp_out_options *opts);
  bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  919a23e9d6cc ("selftests/net: add missing tests to Makefile")

from the net tree and commit:

  7f204a7de8b0 ("selftests: net: Add SO_REUSEADDR test to check if 4-tuples are fully utilized.")

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 4c1bd03ffa1c,48063fd69924..000000000000
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -11,9 -11,8 +11,10 @@@ TEST_PROGS += udpgso_bench.sh fib_rule_
  TEST_PROGS += udpgro_bench.sh udpgro.sh test_vxlan_under_vrf.sh reuseport_addr_any.sh
  TEST_PROGS += test_vxlan_fdb_changelink.sh so_txtime.sh ipv6_flowlabel.sh
  TEST_PROGS += tcp_fastopen_backup_key.sh fcnal-test.sh l2tp.sh traceroute.sh
 -TEST_PROGS += fin_ack_lat.sh
 +TEST_PROGS += fin_ack_lat.sh fib_nexthop_multiprefix.sh fib_nexthops.sh
 +TEST_PROGS += altnames.sh icmp_redirect.sh ip6_gre_headroom.sh
 +TEST_PROGS += route_localnet.sh
+ TEST_PROGS += reuseaddr_ports_exhausted.sh
  TEST_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket nettest
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/macsec.c

between commit:

  b06d072ccc4b ("macsec: restrict to ethernet devices")

from the net tree and commit:

  a21ecf0e0338 ("macsec: Support XPN frame handling - IEEE 802.1AEbw")

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 92bc2b2df660,49b138e7aeac..000000000000
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@@ -19,7 -19,7 +19,8 @@@
  #include <net/gro_cells.h>
  #include <net/macsec.h>
  #include <linux/phy.h>
 +#include <linux/if_arp.h>
+ #include <linux/byteorder/generic.h>
  
  #include <uapi/linux/if_macsec.h>
  

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

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

[Stephen Rothwell]

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

Hi Vladimir,

[Sorry fr the slow response]

On Wed, 11 Mar 2020 11:50:17 +0200 Vladimir Oltean <olteanv@gmail.com> wrote:
>
> What would be the takeaway here? I did bring the fact that it will
> conflict to David's attention here, not sure what else should have
> been done:
> https://www.spinics.net/lists/netdev/msg636207.html
> The conflict resolution looks fine btw, I've tested linux-next and it
> also works.

David has now merged the two trees and resolved this.  My notification
is just so that people are aware of conflicts in separate trees that
usually only come together in Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Kiyanovski, Arthur]

> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Thursday, March 19, 2020 2:11 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>; Dagan, Noam <ndagan@amazon.com>; Leon
> Romanovsky <leonro@mellanox.com>
> Subject: [EXTERNAL] 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_netdev.c
> 
> between commit:
> 
>   dfdde1345bc1 ("net: ena: fix continuous keep-alive resets")
> 
> from the net tree and commit:
> 
>   1a63443afd70 ("net/amazon: Ensure that driver version is aligned to the linux
> kernel")
> 
> 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_netdev.c
> index 4647d7656761,555c7273d712..000000000000
> --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> @@@ -3486,10 -3473,7 +3483,8 @@@ static int ena_restore_device(struct en
>   		netif_carrier_on(adapter->netdev);
> 
>   	mod_timer(&adapter->timer_service, round_jiffies(jiffies + HZ));
>  +	adapter->last_keep_alive_jiffies = jiffies;
> - 	dev_err(&pdev->dev,
> - 		"Device reset completed successfully, Driver info: %s\n",
> - 		version);
> + 	dev_err(&pdev->dev, "Device reset completed successfully\n");
> 
>   	return rc;
>   err_disable_msix:

Acked-by: Arthur Kiyanovski <akiyano@amazon.com>

Thanks!

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  dfdde1345bc1 ("net: ena: fix continuous keep-alive resets")

from the net tree and commit:

  1a63443afd70 ("net/amazon: Ensure that driver version is aligned to the linux kernel")

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_netdev.c
index 4647d7656761,555c7273d712..000000000000
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@@ -3486,10 -3473,7 +3483,8 @@@ static int ena_restore_device(struct en
  		netif_carrier_on(adapter->netdev);
  
  	mod_timer(&adapter->timer_service, round_jiffies(jiffies + HZ));
 +	adapter->last_keep_alive_jiffies = jiffies;
- 	dev_err(&pdev->dev,
- 		"Device reset completed successfully, Driver info: %s\n",
- 		version);
+ 	dev_err(&pdev->dev, "Device reset completed successfully\n");
  
  	return rc;
  err_disable_msix:

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

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

[Vladimir Oltean]

Hi Stephen,

On Wed, 11 Mar 2020 at 03:34, 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/mscc/ocelot.c
>
> between commit:
>
>   a8015ded89ad ("net: mscc: ocelot: properly account for VLAN header length when setting MRU")
>
> from the net tree and commit:
>
>   69df578c5f4b ("net: mscc: ocelot: eliminate confusion between CPU and NPI port")
>
> 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/mscc/ocelot.c
> index d3b7373c5961,06f9d013f807..000000000000
> --- a/drivers/net/ethernet/mscc/ocelot.c
> +++ b/drivers/net/ethernet/mscc/ocelot.c
> @@@ -2310,27 -2323,34 +2329,34 @@@ void ocelot_configure_cpu(struct ocelo
>                          ANA_PORT_PORT_CFG_PORTID_VAL(cpu),
>                          ANA_PORT_PORT_CFG, cpu);
>
> -       /* If the CPU port is a physical port, set up the port in Node
> -        * Processor Interface (NPI) mode. This is the mode through which
> -        * frames can be injected from and extracted to an external CPU.
> -        * Only one port can be an NPI at the same time.
> -        */
> -       if (cpu < ocelot->num_phys_ports) {
> +       if (npi >= 0 && npi < ocelot->num_phys_ports) {
>  -              int mtu = VLAN_ETH_FRAME_LEN + OCELOT_TAG_LEN;
>  +              int sdu = ETH_DATA_LEN + OCELOT_TAG_LEN;
>
>                 ocelot_write(ocelot, QSYS_EXT_CPU_CFG_EXT_CPUQ_MSK_M |
> -                            QSYS_EXT_CPU_CFG_EXT_CPU_PORT(cpu),
> +                            QSYS_EXT_CPU_CFG_EXT_CPU_PORT(npi),
>                              QSYS_EXT_CPU_CFG);
>
>                 if (injection == OCELOT_TAG_PREFIX_SHORT)
>  -                      mtu += OCELOT_SHORT_PREFIX_LEN;
>  +                      sdu += OCELOT_SHORT_PREFIX_LEN;
>                 else if (injection == OCELOT_TAG_PREFIX_LONG)
>  -                      mtu += OCELOT_LONG_PREFIX_LEN;
>  +                      sdu += OCELOT_LONG_PREFIX_LEN;
>
> -               ocelot_port_set_maxlen(ocelot, cpu, sdu);
>  -              ocelot_port_set_mtu(ocelot, npi, mtu);
> ++              ocelot_port_set_maxlen(ocelot, npi, sdu);
> +
> +               /* Enable NPI port */
> +               ocelot_write_rix(ocelot,
> +                                QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
> +                                QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
> +                                QSYS_SWITCH_PORT_MODE_PORT_ENA,
> +                                QSYS_SWITCH_PORT_MODE, npi);
> +               /* NPI port Injection/Extraction configuration */
> +               ocelot_write_rix(ocelot,
> +                                SYS_PORT_MODE_INCL_XTR_HDR(extraction) |
> +                                SYS_PORT_MODE_INCL_INJ_HDR(injection),
> +                                SYS_PORT_MODE, npi);
>         }
>
> -       /* CPU port Injection/Extraction configuration */
> +       /* Enable CPU port module */
>         ocelot_write_rix(ocelot, QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
>                          QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
>                          QSYS_SWITCH_PORT_MODE_PORT_ENA,

What would be the takeaway here? I did bring the fact that it will
conflict to David's attention here, not sure what else should have
been done:
https://www.spinics.net/lists/netdev/msg636207.html
The conflict resolution looks fine btw, I've tested linux-next and it
also works.

Thanks,
-Vladimir

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/mscc/ocelot.c

between commit:

  a8015ded89ad ("net: mscc: ocelot: properly account for VLAN header length when setting MRU")

from the net tree and commit:

  69df578c5f4b ("net: mscc: ocelot: eliminate confusion between CPU and NPI port")

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/mscc/ocelot.c
index d3b7373c5961,06f9d013f807..000000000000
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@@ -2310,27 -2323,34 +2329,34 @@@ void ocelot_configure_cpu(struct ocelo
  			 ANA_PORT_PORT_CFG_PORTID_VAL(cpu),
  			 ANA_PORT_PORT_CFG, cpu);
  
- 	/* If the CPU port is a physical port, set up the port in Node
- 	 * Processor Interface (NPI) mode. This is the mode through which
- 	 * frames can be injected from and extracted to an external CPU.
- 	 * Only one port can be an NPI at the same time.
- 	 */
- 	if (cpu < ocelot->num_phys_ports) {
+ 	if (npi >= 0 && npi < ocelot->num_phys_ports) {
 -		int mtu = VLAN_ETH_FRAME_LEN + OCELOT_TAG_LEN;
 +		int sdu = ETH_DATA_LEN + OCELOT_TAG_LEN;
  
  		ocelot_write(ocelot, QSYS_EXT_CPU_CFG_EXT_CPUQ_MSK_M |
- 			     QSYS_EXT_CPU_CFG_EXT_CPU_PORT(cpu),
+ 			     QSYS_EXT_CPU_CFG_EXT_CPU_PORT(npi),
  			     QSYS_EXT_CPU_CFG);
  
  		if (injection == OCELOT_TAG_PREFIX_SHORT)
 -			mtu += OCELOT_SHORT_PREFIX_LEN;
 +			sdu += OCELOT_SHORT_PREFIX_LEN;
  		else if (injection == OCELOT_TAG_PREFIX_LONG)
 -			mtu += OCELOT_LONG_PREFIX_LEN;
 +			sdu += OCELOT_LONG_PREFIX_LEN;
  
- 		ocelot_port_set_maxlen(ocelot, cpu, sdu);
 -		ocelot_port_set_mtu(ocelot, npi, mtu);
++		ocelot_port_set_maxlen(ocelot, npi, sdu);
+ 
+ 		/* Enable NPI port */
+ 		ocelot_write_rix(ocelot,
+ 				 QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
+ 				 QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
+ 				 QSYS_SWITCH_PORT_MODE_PORT_ENA,
+ 				 QSYS_SWITCH_PORT_MODE, npi);
+ 		/* NPI port Injection/Extraction configuration */
+ 		ocelot_write_rix(ocelot,
+ 				 SYS_PORT_MODE_INCL_XTR_HDR(extraction) |
+ 				 SYS_PORT_MODE_INCL_INJ_HDR(injection),
+ 				 SYS_PORT_MODE, npi);
  	}
  
- 	/* CPU port Injection/Extraction configuration */
+ 	/* Enable CPU port module */
  	ocelot_write_rix(ocelot, QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
  			 QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
  			 QSYS_SWITCH_PORT_MODE_PORT_ENA,

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/ipv4/inet_diag.c

between commit:

  83f73c5bb7b9 ("inet_diag: return classid for all socket types")

from the net tree and commit:

  085c20cacf2b ("bpf: inet_diag: Dump bpf_sk_storages in inet_diag_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/ipv4/inet_diag.c
index 8c8377568a78,e1cad25909df..000000000000
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@@ -298,6 -289,66 +303,48 @@@ int inet_sk_diag_fill(struct sock *sk, 
  			goto errout;
  	}
  
 -	if (ext & (1 << (INET_DIAG_CLASS_ID - 1)) ||
 -	    ext & (1 << (INET_DIAG_TCLASS - 1))) {
 -		u32 classid = 0;
 -
 -#ifdef CONFIG_SOCK_CGROUP_DATA
 -		classid = sock_cgroup_classid(&sk->sk_cgrp_data);
 -#endif
 -		/* Fallback to socket priority if class id isn't set.
 -		 * Classful qdiscs use it as direct reference to class.
 -		 * For cgroup2 classid is always zero.
 -		 */
 -		if (!classid)
 -			classid = sk->sk_priority;
 -
 -		if (nla_put_u32(skb, INET_DIAG_CLASS_ID, classid))
 -			goto errout;
 -	}
 -
+ 	/* Keep it at the end for potential retry with a larger skb,
+ 	 * or else do best-effort fitting, which is only done for the
+ 	 * first_nlmsg.
+ 	 */
+ 	if (cb_data->bpf_stg_diag) {
+ 		bool first_nlmsg = ((unsigned char *)nlh == skb->data);
+ 		unsigned int prev_min_dump_alloc;
+ 		unsigned int total_nla_size = 0;
+ 		unsigned int msg_len;
+ 		int err;
+ 
+ 		msg_len = skb_tail_pointer(skb) - (unsigned char *)nlh;
+ 		err = bpf_sk_storage_diag_put(cb_data->bpf_stg_diag, sk, skb,
+ 					      INET_DIAG_SK_BPF_STORAGES,
+ 					      &total_nla_size);
+ 
+ 		if (!err)
+ 			goto out;
+ 
+ 		total_nla_size += msg_len;
+ 		prev_min_dump_alloc = cb->min_dump_alloc;
+ 		if (total_nla_size > prev_min_dump_alloc)
+ 			cb->min_dump_alloc = min_t(u32, total_nla_size,
+ 						   MAX_DUMP_ALLOC_SIZE);
+ 
+ 		if (!first_nlmsg)
+ 			goto errout;
+ 
+ 		if (cb->min_dump_alloc > prev_min_dump_alloc)
+ 			/* Retry with pskb_expand_head() with
+ 			 * __GFP_DIRECT_RECLAIM
+ 			 */
+ 			goto errout;
+ 
+ 		WARN_ON_ONCE(total_nla_size <= prev_min_dump_alloc);
+ 
+ 		/* Send what we have for this sk
+ 		 * and move on to the next sk in the following
+ 		 * dump()
+ 		 */
+ 	}
+ 
  out:
  	nlmsg_end(skb, nlh);
  	return 0;

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

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

[Paolo Abeni]

On Fri, 2020-02-28 at 10:24 +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/mptcp/protocol.c
> 
> between commit:
> 
>   dc24f8b4ecd3 ("mptcp: add dummy icsk_sync_mss()")
> 
> from the net tree and commit:
> 
>   80992017150b ("mptcp: add work queue skeleton")
> 
> 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.

Thank you, the conflict resolution looks good to me.

I did not notice the conflict beforehands, sorry.

Cheers,

Paolo

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

[Stephen Rothwell]

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

Hi all,

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

  net/smc/smc_core.h

between commit:

  51e3dfa8906a ("net/smc: fix cleanup for linkgroup setup failures")

from the net tree and commits:

  ba9520604209 ("net/smc: remove unused parameter of smc_lgr_terminate()")
  5f78fe968d76 ("net/smc: simplify normal link termination")

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/smc_core.h
index 234ae25f0025,5695c7bc639e..000000000000
--- a/net/smc/smc_core.h
+++ b/net/smc/smc_core.h
@@@ -296,8 -290,7 +290,8 @@@ struct smc_clc_msg_accept_confirm
  struct smc_clc_msg_local;
  
  void smc_lgr_forget(struct smc_link_group *lgr);
 +void smc_lgr_cleanup_early(struct smc_connection *conn);
- void smc_lgr_terminate(struct smc_link_group *lgr, bool soft);
+ void smc_lgr_terminate_sched(struct smc_link_group *lgr);
  void smc_port_terminate(struct smc_ib_device *smcibdev, u8 ibport);
  void smc_smcd_terminate(struct smcd_dev *dev, u64 peer_gid,
  			unsigned short vlan);

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

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

[Stephen Rothwell]

[-- 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/mptcp/protocol.c

between commit:

  dc24f8b4ecd3 ("mptcp: add dummy icsk_sync_mss()")

from the net tree and commit:

  80992017150b ("mptcp: add work queue skeleton")

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/mptcp/protocol.c
index 3c19a8efdcea,044295707bbf..000000000000
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@@ -543,20 -666,26 +666,32 @@@ static void __mptcp_close_ssk(struct so
  	}
  }
  
 +static unsigned int mptcp_sync_mss(struct sock *sk, u32 pmtu)
 +{
 +	return 0;
 +}
 +
+ static void mptcp_worker(struct work_struct *work)
+ {
+ 	struct mptcp_sock *msk = container_of(work, struct mptcp_sock, work);
+ 	struct sock *sk = &msk->sk.icsk_inet.sk;
+ 
+ 	lock_sock(sk);
+ 	__mptcp_move_skbs(msk);
+ 	release_sock(sk);
+ 	sock_put(sk);
+ }
+ 
  static int __mptcp_init_sock(struct sock *sk)
  {
  	struct mptcp_sock *msk = mptcp_sk(sk);
  
  	INIT_LIST_HEAD(&msk->conn_list);
  	__set_bit(MPTCP_SEND_SPACE, &msk->flags);
+ 	INIT_WORK(&msk->work, mptcp_worker);
  
  	msk->first = NULL;
 +	inet_csk(sk)->icsk_sync_mss = mptcp_sync_mss;
  
  	return 0;
  }

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c

between commit:

  c54d209c78b8 ("ice: Wait for VF to be reset/ready before configuration")

from the net tree and commits:

  b093841f9ac9 ("ice: Refactor port vlan configuration for the VF")
  61c9ce86a6f5 ("ice: Fix Port VLAN priority bits")

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/ice/ice_virtchnl_pf.c
index 75c70d432c72,a21f9d2edbbb..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@@ -2738,7 -2786,8 +2828,8 @@@ ice_set_vf_port_vlan(struct net_device 
  	struct ice_vsi *vsi;
  	struct device *dev;
  	struct ice_vf *vf;
+ 	u16 vlanprio;
 -	int ret = 0;
 +	int ret;
  
  	dev = ice_pf_to_dev(pf);
  	if (ice_validate_vf_id(pf, vf_id))
@@@ -2756,47 -2806,58 +2848,59 @@@
  
  	vf = &pf->vf[vf_id];
  	vsi = pf->vsi[vf->lan_vsi_idx];
 -	if (ice_check_vf_init(pf, vf))
 -		return -EBUSY;
 +
 +	ret = ice_check_vf_ready_for_cfg(vf);
 +	if (ret)
 +		return ret;
  
- 	if (le16_to_cpu(vsi->info.pvid) == vlanprio) {
+ 	vlanprio = vlan_id | (qos << VLAN_PRIO_SHIFT);
+ 
+ 	if (vf->port_vlan_info == vlanprio) {
  		/* duplicate request, so just return success */
  		dev_dbg(dev, "Duplicate pvid %d request\n", vlanprio);
 -		return ret;
 +		return 0;
  	}
  
- 	/* If PVID, then remove all filters on the old VLAN */
- 	if (vsi->info.pvid)
- 		ice_vsi_kill_vlan(vsi, (le16_to_cpu(vsi->info.pvid) &
- 				  VLAN_VID_MASK));
- 
  	if (vlan_id || qos) {
+ 		/* remove VLAN 0 filter set by default when transitioning from
+ 		 * no port VLAN to a port VLAN. No change to old port VLAN on
+ 		 * failure.
+ 		 */
+ 		ret = ice_vsi_kill_vlan(vsi, 0);
+ 		if (ret)
+ 			return ret;
  		ret = ice_vsi_manage_pvid(vsi, vlanprio, true);
  		if (ret)
  			return ret;
  	} else {
- 		ice_vsi_manage_pvid(vsi, 0, false);
- 		vsi->info.pvid = 0;
+ 		/* add VLAN 0 filter back when transitioning from port VLAN to
+ 		 * no port VLAN. No change to old port VLAN on failure.
+ 		 */
+ 		ret = ice_vsi_add_vlan(vsi, 0);
+ 		if (ret)
+ 			return ret;
+ 		ret = ice_vsi_manage_pvid(vsi, 0, false);
+ 		if (ret)
 -			goto error_manage_pvid;
++			return ret;
  	}
  
  	if (vlan_id) {
  		dev_info(dev, "Setting VLAN %d, QoS 0x%x on VF %d\n",
  			 vlan_id, qos, vf_id);
  
- 		/* add new VLAN filter for each MAC */
+ 		/* add VLAN filter for the port VLAN */
  		ret = ice_vsi_add_vlan(vsi, vlan_id);
  		if (ret)
 -			goto error_manage_pvid;
 +			return ret;
  	}
+ 	/* remove old port VLAN filter with valid VLAN ID or QoS fields */
+ 	if (vf->port_vlan_info)
+ 		ice_vsi_kill_vlan(vsi, vf->port_vlan_info & VLAN_VID_MASK);
  
- 	/* The Port VLAN needs to be saved across resets the same as the
- 	 * default LAN MAC address.
- 	 */
- 	vf->port_vlan_id = le16_to_cpu(vsi->info.pvid);
+ 	/* keep port VLAN information persistent on resets */
+ 	vf->port_vlan_info = le16_to_cpu(vsi->info.pvid);
  
 -error_manage_pvid:
 -	return ret;
 +	return 0;
  }
  
  /**

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

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

[Jubran, Samih]

> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Monday, December 16, 2019 1:05 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>; Belgazal, Netanel
> <netanel@amazon.com>; Jubran, Samih <sameehj@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_netdev.c
> 
> between commit:
> 
>   24dee0c7478d ("net: ena: fix napi handler misbehavior when the napi
> budget is zero")
> 
> from the net tree and commit:
> 
>   548c4940b9f1 ("net: ena: Implement XDP_TX action")
> 
> 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_netdev.c
> index 948583fdcc28,26954fde4766..000000000000
> --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> @@@ -1237,9 -1861,8 +1861,8 @@@ static int ena_io_poll(struct napi_stru
>   {
>   	struct ena_napi *ena_napi = container_of(napi, struct ena_napi,
> napi);
>   	struct ena_ring *tx_ring, *rx_ring;
> -
>  -	u32 tx_work_done;
>  -	u32 rx_work_done;
>  +	int tx_work_done;
>  +	int rx_work_done = 0;
>   	int tx_budget;
>   	int napi_comp_call = 0;
>   	int ret;

Thanks, looks good to me. Sorry for the inconvenience.

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

[Russell King - ARM Linux admin]

On Mon, Dec 16, 2019 at 10:12:50AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/phy/phylink.c
> 
> between commit:
> 
>   9b2079c046a9 ("net: phylink: fix interface passed to mac_link_up")
> 
> from the net tree and commit:
> 
>   24cf0e693bb5 ("net: phylink: split link_an_mode configured and current settings")
> 
> 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 1585eebb73fe,1e0e32c466ee..000000000000
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@@ -441,8 -445,9 +445,8 @@@ static void phylink_mac_link_up(struct 
>   	struct net_device *ndev = pl->netdev;
>   
>   	pl->cur_interface = link_state.interface;
> - 	pl->ops->mac_link_up(pl->config, pl->link_an_mode,
> + 	pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
>  -			     pl->phy_state.interface,
>  -			     pl->phydev);
>  +			     pl->cur_interface, pl->phydev);
>   
>   	if (ndev)
>   		netif_carrier_on(ndev);

Yep, that's correct.  Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/phy/phylink.c

between commit:

  9b2079c046a9 ("net: phylink: fix interface passed to mac_link_up")

from the net tree and commit:

  24cf0e693bb5 ("net: phylink: split link_an_mode configured and current settings")

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 1585eebb73fe,1e0e32c466ee..000000000000
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@@ -441,8 -445,9 +445,8 @@@ static void phylink_mac_link_up(struct 
  	struct net_device *ndev = pl->netdev;
  
  	pl->cur_interface = link_state.interface;
- 	pl->ops->mac_link_up(pl->config, pl->link_an_mode,
+ 	pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
 -			     pl->phy_state.interface,
 -			     pl->phydev);
 +			     pl->cur_interface, pl->phydev);
  
  	if (ndev)
  		netif_carrier_on(ndev);

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

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  24dee0c7478d ("net: ena: fix napi handler misbehavior when the napi budget is zero")

from the net tree and commit:

  548c4940b9f1 ("net: ena: Implement XDP_TX action")

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_netdev.c
index 948583fdcc28,26954fde4766..000000000000
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@@ -1237,9 -1861,8 +1861,8 @@@ static int ena_io_poll(struct napi_stru
  {
  	struct ena_napi *ena_napi = container_of(napi, struct ena_napi, napi);
  	struct ena_ring *tx_ring, *rx_ring;
- 
 -	u32 tx_work_done;
 -	u32 rx_work_done;
 +	int tx_work_done;
 +	int rx_work_done = 0;
  	int tx_budget;
  	int napi_comp_call = 0;
  	int ret;

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Jeff Kirsher]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Heiner Kallweit]

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!

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[David Miller]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Maxim Uvarov]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Saeed Mahameed]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Pablo Neira Ayuso]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Petr Machata]

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!

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

[Or Gerlitz]

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!

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Or Gerlitz]

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

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

[Saeed Mahameed]

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.

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

[Eric Dumazet]

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.

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

[Ido Schimmel]

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!

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Nambiar, Amritha]

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!

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

[Or Gerlitz]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Kiyanovski, Arthur]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Jamal Hadi Salim]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[David Miller]

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.

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

[Daniel Borkmann]

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

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

[Stephen Rothwell]

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

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

[Vakul Garg]

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

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

[Daniel Borkmann]

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

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

[Daniel Borkmann]

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

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

[Vakul Garg]

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

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

[Daniel Borkmann]

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

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

[Vakul Garg]

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

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

[Daniel Borkmann]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stefano Brivio]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Mark Brown]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Anders Roxell]

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
>

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Petr Machata]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Petr Machata]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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)

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

[Stephen Rothwell]

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;
  

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

[Stephen Rothwell]

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

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

[Eran Ben Elisha]

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