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

[Stephen Rothwell]

Hi all,

On Thu, 15 Apr 2021 14:00:16 + "Ong, Boon Leong"  
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 = >rx_queue[queue];
> >+int i;
> >+
> >+for (i = 0; i < priv->dma_rx_size; i++) {
> >+struct stmmac_rx_buffer *buf = _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


pgp7tmTAfcDCC.pgp
Description: OpenPGP digital signature

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 = >rx_queue[queue];
>+  int i;
>+
>+  for (i = 0; i < priv->dma_rx_size; i++) {
>+  struct stmmac_rx_buffer *buf = _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 = >rx_queue[queue];
> -
> - if (rx_q->xsk_pool)
> - dma_free_rx_xskbufs(priv, queue);

dma_recycle_rx_skbufs() is only called here. 

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


diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- 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-a18781dc6...@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  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 
> >> wrote:
> >>
> >>> diff --cc kernel/bpf/verifier.c
> >>> index 44e4ec1640f1,f9096b049cd6..
> >>> --- 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-a18781dc6...@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 
wrote:


diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- 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-a18781dc6...@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 
wrote:


diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- 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

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

[Sukadev Bhattiprolu]

Stephen Rothwell [s...@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

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]

Hi Davide,

On Mon, 15 Feb 2021 12:35:37 +0100 Davide Caratti  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


pgp2Bll3CeKtr.pgp
Description: OpenPGP digital signature

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

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.

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..
--- 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(>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 */

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

Thank you, that resolution looks good to me!

Reviewed-by: Geert Uytterhoeven 

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

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..
--- 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..
--- 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, , ))
+   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_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(>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, >sk_receive_queue);
+   p = >out_of_order_queue.rb_node;
+   MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
+   if (RB_EMPTY_ROOT(>out_of_order_queue)) {
+   rb_link_node(>rbnode, NULL, p);
+   rb_insert_color(>rbnode, >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_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 = >ooo_last_skb->rbnode;
+   p = >rb_right;
+   goto insert;
+   }

-   

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

[Andrew Lunn]

> From: Stephen Rothwell 
> 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 
> ---
>  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

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  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..
> --- 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 &= ~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

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

[Claudiu Manoil]

>-Original Message-
>From: Stephen Rothwell 
>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

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

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

[Leon Romanovsky]

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


signature.asc
Description: PGP signature

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

[Jeff Kirsher]

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 

On how you fixed up the conflict.


signature.asc
Description: This is a digitally signed message part

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!

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

[David Miller]

From: Stephen Rothwell 
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]

Hi all,

On Tue, 2 Jul 2019 12:13:57 +1000 Stephen Rothwell  
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..
> --- 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 = _dev->ifa_list;
>   
>  +/* Don't set IPv6 only flags to IPv4 addresses */
>  +ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
>  +
> - for (ifap = _dev->ifa_list; (ifa1 = *ifap) != NULL;
> -  ifap = >ifa_next) {
> + ifap = _dev->ifa_list;
> + ifa1 = rtnl_dereference(*ifap);
> + 
> + while (ifa1) {
>   if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>   ifa->ifa_scope <= ifa1->ifa_scope)
>   last_primary = >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


pgp8lRiYeHTZF.pgp
Description: OpenPGP digital signature

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 :
>
> 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..
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@@ -26,18 -26,11 +26,19 @@@
>
>   /* Extended Registers */
>   #define DP83867_CFG40x0031
>  +#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_STS10x006E
> + #define DP83867_STRAP_STS20x006f
>   #define DP83867_RGMIIDCTL 0x0086
>   #define DP83867_IO_MUX_CFG0x0170
>  +#define DP83867_10M_SGMII_CFG   0x016F
>  +#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
>
>   #define DP83867_SW_RESET  BIT(15)
>   #define DP83867_SW_RESTARTBIT(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;
>  

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.

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

[Stephen Rothwell]

Hi all,

On Wed, 13 Feb 2019 11:13:25 +1100 Stephen Rothwell  
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, , true);
  
 -  call_rcu(>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, >res);
 +  if (tcf_exts_get_net(>exts))
 +  tcf_queue_work(>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, >result, , NULL);
++  tcindex_delete(tp, >result, , false, NULL);
 +  }
 +  }
 +
 +  tcf_queue_work(>rwork, tcindex_destroy_work);
  }
  
  


pgp6iOF4fhyxF.pgp
Description: OpenPGP digital signature

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.

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

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

[Stephen Rothwell]

Hi,

On Tue, 18 Dec 2018 00:01:57 +0200 Or Gerlitz  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


pgpYqakizo_6s.pgp
Description: OpenPGP digital signature

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
 wrote:
> On Sun, Dec 16, 2018 at 4:25 PM Stephen Rothwell  
> 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=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  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..
> --- 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  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!

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

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

[Jamal Hadi Salim]

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

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

[Jamal Hadi Salim]

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

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

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

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

[Stephen Rothwell]

Hi Anders,

On Wed, 9 May 2018 10:24:49 +0200 Anders Roxell  
wrote:
>
> On 9 May 2018 at 06:19, Stephen Rothwell  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


pgpSTkHkFHubZ.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Anders,

On Wed, 9 May 2018 10:24:49 +0200 Anders Roxell  
wrote:
>
> On 9 May 2018 at 06:19, Stephen Rothwell  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


pgpSTkHkFHubZ.pgp
Description: OpenPGP digital signature

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

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

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

[Petr Machata]

Stephen Rothwell  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

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

[Petr Machata]

Stephen Rothwell  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

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

[Petr Machata]

Stephen Rothwell  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

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

[Petr Machata]

Stephen Rothwell  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

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

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

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

[Cong Wang]

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

Seems good.

Thanks!

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

[Cong Wang]

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

Seems good.

Thanks!

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

[Daniel Borkmann]

On 10/19/2017 03:05 PM, Mark Brown wrote:

Hi all,

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

   tools/testing/selftests/bpf/test_verifier.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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


LGTM, thanks.

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

[Daniel Borkmann]

On 10/19/2017 03:05 PM, Mark Brown wrote:

Hi all,

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

   tools/testing/selftests/bpf/test_verifier.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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


LGTM, thanks.

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

[Mark Brown]

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

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

>Your mail ends here.

Yes, that's the resulting diff.


signature.asc
Description: PGP signature

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

[Mark Brown]

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

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

>Your mail ends here.

Yes, that's the resulting diff.


signature.asc
Description: PGP signature

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

[Sergei Shtylyov]

Hello!

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


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

   drivers/net/dsa/mv88e6060.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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

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


   Your mail ends here.

MBR, Sergei

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

[Sergei Shtylyov]

Hello!

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


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

   drivers/net/dsa/mv88e6060.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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

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


   Your mail ends here.

MBR, Sergei

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

[Ido Schimmel]

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

Looks good to me.

Thanks!

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

[Ido Schimmel]

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

Looks good to me.

Thanks!

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

[Stephen Rothwell]

Hi Neal,

On Sun, 6 Aug 2017 22:21:43 -0400 Neal Cardwell  wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.  
> 
> Sorry about that. Will try to follow that procedure in the future.

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Neal,

On Sun, 6 Aug 2017 22:21:43 -0400 Neal Cardwell  wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.  
> 
> Sorry about that. Will try to follow that procedure in the future.

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

-- 
Cheers,
Stephen Rothwell

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

[Neal Cardwell]

On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/ipv4/tcp_output.c
>
> between commit:
>
>   a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO 
> should fire")
>
> from the net tree and commit:
>
>   bb4d991a28cc ("tcp: adjust tail loss probe timeout")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Sorry about that. Will try to follow that procedure in the future.

thanks,
neal

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

[Neal Cardwell]

On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   net/ipv4/tcp_output.c
>
> between commit:
>
>   a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO 
> should fire")
>
> from the net tree and commit:
>
>   bb4d991a28cc ("tcp: adjust tail loss probe timeout")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Sorry about that. Will try to follow that procedure in the future.

thanks,
neal

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

[Stephen Hemminger]

On Thu, 3 Aug 2017 12:01:37 +1000
Stephen Rothwell  wrote:

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/hyperv/netvsc.c
> 
> between commit:
> 
>   4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")
> 
> from the net tree and commit:
> 
>   35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel 
> table")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks, that looks right.

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

[Stephen Hemminger]

On Thu, 3 Aug 2017 12:01:37 +1000
Stephen Rothwell  wrote:

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/hyperv/netvsc.c
> 
> between commit:
> 
>   4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")
> 
> from the net tree and commit:
> 
>   35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel 
> table")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks, that looks right.

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

[Saeed Mahameed]

On Mon, Jul 3, 2017 at 4:43 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/health.c
>   include/linux/mlx5/driver.h
>
> between commit:
>
>   2a0165a034ac ("net/mlx5: Cancel delayed recovery work when unloading the 
> driver")
>
> from the net tree and commit:
>
>   0179720d6be2 ("Introduce new function for entering bad-health state.")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/health.c
> index 8a8b5f0e497c,0648a659b21d..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@@ -193,8 -193,8 +194,8 @@@ static void health_care(struct work_str
> mlx5_core_warn(dev, "handling bad device here\n");
> mlx5_handle_bad_state(dev);
>
> -   spin_lock(>wq_lock);
> +   spin_lock_irqsave(>wq_lock, flags);
>  -  if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, >flags))
>  +  if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, >flags))
> schedule_delayed_work(>recover_work, recover_delay);
> else
> dev_err(>pdev->dev,
> @@@ -334,11 -341,11 +343,12 @@@ void mlx5_stop_health_poll(struct mlx5_
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev)
>   {
> struct mlx5_core_health *health = >priv.health;
> +   unsigned long flags;
>
> -   spin_lock(>wq_lock);
> +   spin_lock_irqsave(>wq_lock, flags);
> set_bit(MLX5_DROP_NEW_HEALTH_WORK, >flags);
>  +  set_bit(MLX5_DROP_NEW_RECOVERY_WORK, >flags);
> -   spin_unlock(>wq_lock);
> +   spin_unlock_irqrestore(>wq_lock, flags);
> cancel_delayed_work_sync(>recover_work);
> cancel_work_sync(>work);
>   }
> diff --cc include/linux/mlx5/driver.h
> index ba260330ce5e,2ab4ae3e3a1a..
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@@ -925,7 -945,7 +945,8 @@@ int mlx5_health_init(struct mlx5_core_d
>   void mlx5_start_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
>  +void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
> + void mlx5_trigger_health_work(struct mlx5_core_dev *dev);
>   int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,
> struct mlx5_buf *buf, int node);
>   int mlx5_buf_alloc(struct mlx5_core_dev *dev, int size, struct mlx5_buf 
> *buf);

Hi Stephen,

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

Thanks,
Saeed.

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

[Saeed Mahameed]

On Mon, Jul 3, 2017 at 4:43 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   drivers/net/ethernet/mellanox/mlx5/core/health.c
>   include/linux/mlx5/driver.h
>
> between commit:
>
>   2a0165a034ac ("net/mlx5: Cancel delayed recovery work when unloading the 
> driver")
>
> from the net tree and commit:
>
>   0179720d6be2 ("Introduce new function for entering bad-health state.")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/health.c
> index 8a8b5f0e497c,0648a659b21d..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@@ -193,8 -193,8 +194,8 @@@ static void health_care(struct work_str
> mlx5_core_warn(dev, "handling bad device here\n");
> mlx5_handle_bad_state(dev);
>
> -   spin_lock(>wq_lock);
> +   spin_lock_irqsave(>wq_lock, flags);
>  -  if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, >flags))
>  +  if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, >flags))
> schedule_delayed_work(>recover_work, recover_delay);
> else
> dev_err(>pdev->dev,
> @@@ -334,11 -341,11 +343,12 @@@ void mlx5_stop_health_poll(struct mlx5_
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev)
>   {
> struct mlx5_core_health *health = >priv.health;
> +   unsigned long flags;
>
> -   spin_lock(>wq_lock);
> +   spin_lock_irqsave(>wq_lock, flags);
> set_bit(MLX5_DROP_NEW_HEALTH_WORK, >flags);
>  +  set_bit(MLX5_DROP_NEW_RECOVERY_WORK, >flags);
> -   spin_unlock(>wq_lock);
> +   spin_unlock_irqrestore(>wq_lock, flags);
> cancel_delayed_work_sync(>recover_work);
> cancel_work_sync(>work);
>   }
> diff --cc include/linux/mlx5/driver.h
> index ba260330ce5e,2ab4ae3e3a1a..
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@@ -925,7 -945,7 +945,8 @@@ int mlx5_health_init(struct mlx5_core_d
>   void mlx5_start_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
>   void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
>  +void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
> + void mlx5_trigger_health_work(struct mlx5_core_dev *dev);
>   int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,
> struct mlx5_buf *buf, int node);
>   int mlx5_buf_alloc(struct mlx5_core_dev *dev, int size, struct mlx5_buf 
> *buf);

Hi Stephen,

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

Thanks,
Saeed.

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

[Daniel Borkmann]

On 04/18/2017 02:18 AM, Stephen Rothwell wrote:

Hi all,

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

   kernel/bpf/syscall.c

between commits:

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

from the net tree and commit:

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

from the net-next tree.

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

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 10:16:03 +1000
Subject: [PATCH] bpf: merge fix for move of fixup_bpf_calls()

Signed-off-by: Stephen Rothwell 
---
  kernel/bpf/verifier.c | 8 
  1 file changed, 8 insertions(+)

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



Looks good, thanks.

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

[Daniel Borkmann]

On 04/18/2017 02:18 AM, Stephen Rothwell wrote:

Hi all,

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

   kernel/bpf/syscall.c

between commits:

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

from the net tree and commit:

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

from the net-next tree.

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

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 10:16:03 +1000
Subject: [PATCH] bpf: merge fix for move of fixup_bpf_calls()

Signed-off-by: Stephen Rothwell 
---
  kernel/bpf/verifier.c | 8 
  1 file changed, 8 insertions(+)

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



Looks good, thanks.

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

[Cong Wang]

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


Looks good to me.

Thanks.

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

[Cong Wang]

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


Looks good to me.

Thanks.

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

[Simon Horman]

On Tue, Apr 04, 2017 at 11:13:57AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/core/flow_dissector.c
> 
> between commit:
> 
>   ac6a3722fed6 ("flow dissector: correct size of storage for ARP")
> 
> from the net tree and commit:
> 
>   9bf881ffc5c0 ("flow_dissector: Move ARP dissection into a separate 
> function")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen, the fix looks correct to me.

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

[Simon Horman]

On Tue, Apr 04, 2017 at 11:13:57AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/core/flow_dissector.c
> 
> between commit:
> 
>   ac6a3722fed6 ("flow dissector: correct size of storage for ARP")
> 
> from the net tree and commit:
> 
>   9bf881ffc5c0 ("flow_dissector: Move ARP dissection into a separate 
> function")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen, the fix looks correct to me.

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

[Daniel Borkmann]

On 04/03/2017 04:07 AM, Stephen Rothwell wrote:

Hi all,

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

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

between commit:

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

from the net tree and commits:

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

from the net-next tree.

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


Looks fine, thanks Stephen!

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

[Daniel Borkmann]

On 04/03/2017 04:07 AM, Stephen Rothwell wrote:

Hi all,

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

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

between commit:

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

from the net tree and commits:

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

from the net-next tree.

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


Looks fine, thanks Stephen!

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

[Jiri Pirko]

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

Looks fine to me. Thanks.

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

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

[Jiri Pirko]

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

Looks fine to me. Thanks.

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

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

[Borislav Petkov]

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

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

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

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

to

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

so that it doesn't fire again.

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

-- 
Regards/Gruss,
Boris.

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

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

[Borislav Petkov]

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

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

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

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

to

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

so that it doesn't fire again.

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

-- 
Regards/Gruss,
Boris.

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

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

[Daniel Borkmann]

On 11/29/2016 01:31 AM, Stephen Rothwell wrote:

Hi all,

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

   net/sched/cls_flower.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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


Looks good to me, thanks!

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

[Daniel Borkmann]

On 11/29/2016 01:31 AM, Stephen Rothwell wrote:

Hi all,

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

   net/sched/cls_flower.c

between commit:

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

from the net tree and commit:

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

from the net-next tree.

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


Looks good to me, thanks!

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

[Or Gerlitz]

On Thu, Nov 10, 2016 at 1:50 AM, 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/eswitch_offloads.c
>
> between commit:
>   ee39fbc4447d ("net/mlx5: E-Switch, Set the actions for offloaded rules 
> properly")
> from the net tree and commit:
>   66958ed906b8 ("net/mlx5: Support encap id when setting new steering entry")
> from the net-next tree.

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

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

Or.

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

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

[Or Gerlitz]

On Thu, Nov 10, 2016 at 1:50 AM, 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/eswitch_offloads.c
>
> between commit:
>   ee39fbc4447d ("net/mlx5: E-Switch, Set the actions for offloaded rules 
> properly")
> from the net tree and commit:
>   66958ed906b8 ("net/mlx5: Support encap id when setting new steering entry")
> from the net-next tree.

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

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

Or.

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

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

[Cong Wang]

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

Looks good to me.

Thanks!

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

[Cong Wang]

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

Looks good to me.

Thanks!

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

[Ido Schimmel]

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

Yes, net-next is correct. Thanks Stephen!

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

[Ido Schimmel]

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

Yes, net-next is correct. Thanks Stephen!

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

[Daniel Borkmann]

On 08/15/2016 02:35 AM, Stephen Rothwell wrote:

Hi all,

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

   kernel/bpf/verifier.c

between commit:

   747ea55e4f78 ("bpf: fix bpf_skb_in_cgroup helper naming")

from the net tree and commit:

   60d20f9195b2 ("bpf: Add bpf_current_task_under_cgroup helper")

from the net-next tree.

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


Looks good to me, thanks!

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

[Daniel Borkmann]

On 08/15/2016 02:35 AM, Stephen Rothwell wrote:

Hi all,

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

   kernel/bpf/verifier.c

between commit:

   747ea55e4f78 ("bpf: fix bpf_skb_in_cgroup helper naming")

from the net tree and commit:

   60d20f9195b2 ("bpf: Add bpf_current_task_under_cgroup helper")

from the net-next tree.

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


Looks good to me, thanks!

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

[Saeed Mahameed]

On Mon, Jul 4, 2016 at 6:07 AM, 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_main.c
>
> between commit:
>
>   29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")
>
> from the net tree and commit:
>
>   507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 7a0dca29c642,96ec53a6a595..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -39,16 -39,10 +39,17 @@@
>   #include "eswitch.h"
>   #include "vxlan.h"
>
>  +enum {
>  +  MLX5_EN_QP_FLUSH_TIMEOUT_MS = 5000,
>  +  MLX5_EN_QP_FLUSH_MSLEEP_QUANT   = 20,
>  +  MLX5_EN_QP_FLUSH_MAX_ITER   = MLX5_EN_QP_FLUSH_TIMEOUT_MS /
>  +MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
>  +};
>  +
>   struct mlx5e_rq_param {
> -   u32rqc[MLX5_ST_SZ_DW(rqc)];
> -   struct mlx5_wq_param   wq;
> +   u32 rqc[MLX5_ST_SZ_DW(rqc)];
> +   struct mlx5_wq_paramwq;
> +   boolam_enabled;
>   };
>
>   struct mlx5e_sq_param {
> @@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
> /* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
> napi_synchronize(>channel->napi);
>
> +   cancel_work_sync(>am.work);
> +
> mlx5e_disable_rq(rq);
>  +  mlx5e_free_rx_descs(rq);
> mlx5e_destroy_rq(rq);
>   }
>
> @@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
> if (mlx5e_sq_has_room_for(sq, 1))
> mlx5e_send_nop(sq, true);
>
>  -  mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
>  -  false, 0);
>  +  err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
> - MLX5_SQC_STATE_ERR);
> ++MLX5_SQC_STATE_ERR, false, 0);
>  +  if (err)
>  +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
> }


Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

[Saeed Mahameed]

On Mon, Jul 4, 2016 at 6:07 AM, 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_main.c
>
> between commit:
>
>   29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")
>
> from the net tree and commit:
>
>   507f0c817f7a ("net/mlx5e: Add TXQ set max rate support")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 7a0dca29c642,96ec53a6a595..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -39,16 -39,10 +39,17 @@@
>   #include "eswitch.h"
>   #include "vxlan.h"
>
>  +enum {
>  +  MLX5_EN_QP_FLUSH_TIMEOUT_MS = 5000,
>  +  MLX5_EN_QP_FLUSH_MSLEEP_QUANT   = 20,
>  +  MLX5_EN_QP_FLUSH_MAX_ITER   = MLX5_EN_QP_FLUSH_TIMEOUT_MS /
>  +MLX5_EN_QP_FLUSH_MSLEEP_QUANT,
>  +};
>  +
>   struct mlx5e_rq_param {
> -   u32rqc[MLX5_ST_SZ_DW(rqc)];
> -   struct mlx5_wq_param   wq;
> +   u32 rqc[MLX5_ST_SZ_DW(rqc)];
> +   struct mlx5_wq_paramwq;
> +   boolam_enabled;
>   };
>
>   struct mlx5e_sq_param {
> @@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e
> /* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */
> napi_synchronize(>channel->napi);
>
> +   cancel_work_sync(>am.work);
> +
> mlx5e_disable_rq(rq);
>  +  mlx5e_free_rx_descs(rq);
> mlx5e_destroy_rq(rq);
>   }
>
> @@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
> if (mlx5e_sq_has_room_for(sq, 1))
> mlx5e_send_nop(sq, true);
>
>  -  mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
>  -  false, 0);
>  +  err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
> - MLX5_SQC_STATE_ERR);
> ++MLX5_SQC_STATE_ERR, false, 0);
>  +  if (err)
>  +  set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, >state);
> }


Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

[Saeed Mahameed]

On Mon, Jul 4, 2016 at 6:02 AM, 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.h
>
> between commit:
>
>   6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")
>
> from the net tree and commit:
>
>   cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en.h
> index 943b1bd434bf,00643a116492..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe
> struct mlx5_wqe_data_seg   data;
>   };
>
> + static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
> +   "rx_cqe_moder",
> + };
> +
> + enum mlx5e_priv_flag {
> +   MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
> + };
> +
> + #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)\
> +   do {\
> +   if (enable) \
> +   priv->pflags |= pflag;  \
> +   else\
> +   priv->pflags &= ~pflag; \
> +   } while (0)
> +
>   #ifdef CONFIG_MLX5_CORE_EN_DCB
>   #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
>  -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
>   #endif
>
> + struct mlx5e_cq_moder {
> +   u16 usec;
> +   u16 pkts;
> + };
> +
>   struct mlx5e_params {
> u8  log_sq_size;
> u8  rq_wq_type;
> @@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp
>   enum {
> MLX5E_RQ_STATE_POST_WQES_ENABLE,
> MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
>  +  MLX5E_RQ_STATE_FLUSH_TIMEOUT,
> +   MLX5E_RQ_STATE_AM,
>   };
>

Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

[Saeed Mahameed]

On Mon, Jul 4, 2016 at 6:02 AM, 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.h
>
> between commit:
>
>   6cd392a082de ("net/mlx5e: Handle RQ flush in error cases")
>
> from the net tree and commit:
>
>   cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en.h
> index 943b1bd434bf,00643a116492..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@@ -143,10 -146,32 +146,31 @@@ struct mlx5e_umr_wqe
> struct mlx5_wqe_data_seg   data;
>   };
>
> + static const char mlx5e_priv_flags[][ETH_GSTRING_LEN] = {
> +   "rx_cqe_moder",
> + };
> +
> + enum mlx5e_priv_flag {
> +   MLX5E_PFLAG_RX_CQE_BASED_MODER = (1 << 0),
> + };
> +
> + #define MLX5E_SET_PRIV_FLAG(priv, pflag, enable)\
> +   do {\
> +   if (enable) \
> +   priv->pflags |= pflag;  \
> +   else\
> +   priv->pflags &= ~pflag; \
> +   } while (0)
> +
>   #ifdef CONFIG_MLX5_CORE_EN_DCB
>   #define MLX5E_MAX_BW_ALLOC 100 /* Max percentage of BW allocation */
>  -#define MLX5E_MIN_BW_ALLOC 1   /* Min percentage of BW allocation */
>   #endif
>
> + struct mlx5e_cq_moder {
> +   u16 usec;
> +   u16 pkts;
> + };
> +
>   struct mlx5e_params {
> u8  log_sq_size;
> u8  rq_wq_type;
> @@@ -190,7 -215,7 +214,8 @@@ struct mlx5e_tstamp
>   enum {
> MLX5E_RQ_STATE_POST_WQES_ENABLE,
> MLX5E_RQ_STATE_UMR_WQE_IN_PROGRESS,
>  +  MLX5E_RQ_STATE_FLUSH_TIMEOUT,
> +   MLX5E_RQ_STATE_AM,
>   };
>

Thanks Stephen, the fixup looks good.

I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"

Thanks,
Saeed.

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

[Eric Dumazet]

On Mon, 2016-06-27 at 11:46 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/sch_netem.c
> 
> between commit:
> 
>   21de12ee5568 ("netem: fix a use after free")
> 
> from the net tree and commit:
> 
>   520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Looks good, although the 'use after free' does not happen anymore on
net-next since we defer skb freeing.

I spotted the bug in stable tree when cooking the net-next patch
actually ;)

Thanks.

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

[Eric Dumazet]

On Mon, 2016-06-27 at 11:46 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/sch_netem.c
> 
> between commit:
> 
>   21de12ee5568 ("netem: fix a use after free")
> 
> from the net tree and commit:
> 
>   520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Looks good, although the 'use after free' does not happen anymore on
net-next since we defer skb freeing.

I spotted the bug in stable tree when cooking the net-next patch
actually ;)

Thanks.

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

[Saeed Mahameed]

On Wed, Apr 27, 2016 at 5:01 AM, 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_main.c
>
> between commit:
>
>   d8edd2469ace ("et/mlx5e: Fix minimum MTU")
>
> from the net tree and commit:
>
>   0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 67d548b70e14,5bad17d37d7b..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -2025,9 -2214,49 +2240,52 @@@ static int set_feature_rx_vlan(struct n
> return err;
>   }
>
> + static int mlx5e_handle_feature(struct net_device *netdev,
> +   netdev_features_t wanted_features,
> +   netdev_features_t feature,
> +   mlx5e_feature_handler feature_handler)
> + {
> +   netdev_features_t changes = wanted_features ^ netdev->features;
> +   bool enable = !!(wanted_features & feature);
> +   int err;
> +
> +   if (!(changes & feature))
> +   return 0;
> +
> +   err = feature_handler(netdev, enable);
> +   if (err) {
> +   netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
> +  enable ? "Enable" : "Disable", feature, err);
> +   return err;
> +   }
> +
> +   MLX5E_SET_FEATURE(netdev, feature, enable);
> +   return 0;
> + }
> +
> + static int mlx5e_set_features(struct net_device *netdev,
> + netdev_features_t features)
> + {
> +   int err;
> +
> +   err  = mlx5e_handle_feature(netdev, features, NETIF_F_LRO,
> +   set_feature_lro);
> +   err |= mlx5e_handle_feature(netdev, features,
> +   NETIF_F_HW_VLAN_CTAG_FILTER,
> +   set_feature_vlan_filter);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_TC,
> +   set_feature_tc_num_filters);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_RXALL,
> +   set_feature_rx_all);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_VLAN_CTAG_RX,
> +   set_feature_rx_vlan);
> +
> +   return err ? -EINVAL : 0;
> + }
> +
>  +#define MXL5_HW_MIN_MTU 64
>  +#define MXL5E_MIN_MTU (MXL5_HW_MIN_MTU + ETH_FCS_LEN)
>  +
>   static int mlx5e_change_mtu(struct net_device *netdev, int new_mtu)
>   {
> struct mlx5e_priv *priv = netdev_priv(netdev);
> @@@ -2633,18 -2966,10 +2997,19 @@@ static void mlx5e_destroy_netdev(struc
> schedule_work(>set_rx_mode_work);
> mlx5e_disable_async_events(priv);
> flush_scheduled_work();
>  -  unregister_netdev(netdev);
>  +  if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, >intf_state)) {
>  +  netif_device_detach(netdev);
>  +  mutex_lock(>state_lock);
>  +  if (test_bit(MLX5E_STATE_OPENED, >state))
>  +  mlx5e_close_locked(netdev);
>  +  mutex_unlock(>state_lock);
>  +  } else {
>  +  unregister_netdev(netdev);
>  +  }
>  +
> mlx5e_tc_cleanup(priv);
> mlx5e_vxlan_cleanup(priv);
> +   mlx5e_destroy_q_counter(priv);
> mlx5e_destroy_flow_tables(priv);
> mlx5e_destroy_tirs(priv);
> mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);

Looks good, and it is pretty straightforward.
Dave will have to take all hunks from both patches, same as you did.

Thank you Stephen.

Saeed.

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

[Saeed Mahameed]

On Wed, Apr 27, 2016 at 5:01 AM, 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_main.c
>
> between commit:
>
>   d8edd2469ace ("et/mlx5e: Fix minimum MTU")
>
> from the net tree and commit:
>
>   0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 67d548b70e14,5bad17d37d7b..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -2025,9 -2214,49 +2240,52 @@@ static int set_feature_rx_vlan(struct n
> return err;
>   }
>
> + static int mlx5e_handle_feature(struct net_device *netdev,
> +   netdev_features_t wanted_features,
> +   netdev_features_t feature,
> +   mlx5e_feature_handler feature_handler)
> + {
> +   netdev_features_t changes = wanted_features ^ netdev->features;
> +   bool enable = !!(wanted_features & feature);
> +   int err;
> +
> +   if (!(changes & feature))
> +   return 0;
> +
> +   err = feature_handler(netdev, enable);
> +   if (err) {
> +   netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
> +  enable ? "Enable" : "Disable", feature, err);
> +   return err;
> +   }
> +
> +   MLX5E_SET_FEATURE(netdev, feature, enable);
> +   return 0;
> + }
> +
> + static int mlx5e_set_features(struct net_device *netdev,
> + netdev_features_t features)
> + {
> +   int err;
> +
> +   err  = mlx5e_handle_feature(netdev, features, NETIF_F_LRO,
> +   set_feature_lro);
> +   err |= mlx5e_handle_feature(netdev, features,
> +   NETIF_F_HW_VLAN_CTAG_FILTER,
> +   set_feature_vlan_filter);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_TC,
> +   set_feature_tc_num_filters);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_RXALL,
> +   set_feature_rx_all);
> +   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_VLAN_CTAG_RX,
> +   set_feature_rx_vlan);
> +
> +   return err ? -EINVAL : 0;
> + }
> +
>  +#define MXL5_HW_MIN_MTU 64
>  +#define MXL5E_MIN_MTU (MXL5_HW_MIN_MTU + ETH_FCS_LEN)
>  +
>   static int mlx5e_change_mtu(struct net_device *netdev, int new_mtu)
>   {
> struct mlx5e_priv *priv = netdev_priv(netdev);
> @@@ -2633,18 -2966,10 +2997,19 @@@ static void mlx5e_destroy_netdev(struc
> schedule_work(>set_rx_mode_work);
> mlx5e_disable_async_events(priv);
> flush_scheduled_work();
>  -  unregister_netdev(netdev);
>  +  if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, >intf_state)) {
>  +  netif_device_detach(netdev);
>  +  mutex_lock(>state_lock);
>  +  if (test_bit(MLX5E_STATE_OPENED, >state))
>  +  mlx5e_close_locked(netdev);
>  +  mutex_unlock(>state_lock);
>  +  } else {
>  +  unregister_netdev(netdev);
>  +  }
>  +
> mlx5e_tc_cleanup(priv);
> mlx5e_vxlan_cleanup(priv);
> +   mlx5e_destroy_q_counter(priv);
> mlx5e_destroy_flow_tables(priv);
> mlx5e_destroy_tirs(priv);
> mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);

Looks good, and it is pretty straightforward.
Dave will have to take all hunks from both patches, same as you did.

Thank you Stephen.

Saeed.