Re: linux-next: manual merge of the net-next tree with the net tree
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 = &priv->rx_queue[queue];
> >+int i;
> >+
> >+for (i = 0; i < priv->dma_rx_size; i++) {
> >+struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
> >+
> >+if (buf->page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>page);
> >+buf->page = NULL;
> >+}
> >+
> >+if (priv->sph && buf->sec_page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>sec_page);
> >+buf->sec_page = NULL;
> >+}
> >+}
> >+ }
>
> With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
> stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
> is no longer needed when net-next is sent for merge.
Thanks. I have added removal of that (now unused) function to my merge
resolution.
--
Cheers,
Stephen Rothwell
pgpp8OZv02pLH.pgp
Description: OpenPGP digital signature
RE: 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/stmicro/stmmac/stmmac_main.c
>
>between commit:
>
> 00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume
>back"")
>
>from the net tree and commits:
>
> bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
> de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue
>basis")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your tree
>is submitted for merging. You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any particularly
>complex conflicts.
I check linux-next merge fix above and spotted an additional fix needed.
Please see below.
>+ /**
>+ * dma_recycle_rx_skbufs - recycle RX dma buffers
>+ * @priv: private structure
>+ * @queue: RX queue index
>+ */
>+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
>+ {
>+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
>+ int i;
>+
>+ for (i = 0; i < priv->dma_rx_size; i++) {
>+ struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
>+
>+ if (buf->page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>page);
>+ buf->page = NULL;
>+ }
>+
>+ if (priv->sph && buf->sec_page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>sec_page);
>+ buf->sec_page = NULL;
>+ }
>+ }
>+ }
With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
is no longer needed when net-next is sent for merge.
> -/**
> - * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
> - * @priv: driver private structure
> - * Description: this function is called to re-allocate a receive buffer,
> perform
> - * the DMA mapping and init the descriptor.
> - */
> -static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
> -{
> - u32 rx_count = priv->plat->rx_queues_to_use;
> - u32 queue;
> -
> - for (queue = 0; queue < rx_count; queue++) {
> - struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
> -
> - if (rx_q->xsk_pool)
> - dma_free_rx_xskbufs(priv, queue);
dma_recycle_rx_skbufs() is only called here.
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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
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
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
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
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 pgpN6LBT4u1D7.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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
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(&adapter->state_lock, flags);
- if (rwi->reset_reason == VNIC_RESET_CHANGE_PARAM) {
- /* CHANGE_PARAM requestor holds rtnl_lock */
- rc = do_change_param_reset(adapter, rwi, reset_state);
- } else if (adapter->force_reset_recovery) {
+ if (adapter->force_reset_recovery) {
+ /*
+ * Since we are doing a hard reset now, clear the
+ * failover_pending flag so we don't ignore any
+ * future MOBILITY or other resets.
+ */
+ adapter->failover_pending = false;
+
/* Transport event occurred during previous reset */
if (adapter->wait_for_reset) {
/* Previous was CHANGE_PARAM; caller locked */
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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, &fragstolen, &delta))
+ return false;
+
+ pr_debug("colesced seq %llx into %llx new len %d new end seq %llx",
+MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
+to->len, MPTCP_SKB_CB(from)->end_seq);
+ MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
+ kfree_skb_partial(from, fragstolen);
+ atomic_add(delta, &sk->sk_rmem_alloc);
+ sk_mem_charge(sk, delta);
+ return true;
+ }
+
+ static bool mptcp_ooo_try_coalesce(struct mptcp_sock *msk, struct sk_buff *to,
+ struct sk_buff *from)
+ {
+ if (MPTCP_SKB_CB(from)->map_seq != MPTCP_SKB_CB(to)->end_seq)
+ return false;
+
+ return mptcp_try_coalesce((struct sock *)msk, to, from);
+ }
+
+ /* "inspired" by tcp_data_queue_ofo(), main differences:
+ * - use mptcp seqs
+ * - don't cope with sacks
+ */
+ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
{
struct sock *sk = (struct sock *)msk;
- struct sk_buff *tail;
+ struct rb_node **p, *parent;
+ u64 seq, end_seq, max_seq;
+ struct sk_buff *skb1;
+ int space;
+
+ seq = MPTCP_SKB_CB(skb)->map_seq;
+ end_seq = MPTCP_SKB_CB(skb)->end_seq;
+ space = tcp_space(sk);
+ max_seq = space > 0 ? space + msk->ack_seq : msk->ack_seq;
+
+ pr_debug("msk=%p seq=%llx limit=%llx empty=%d", msk, seq, max_seq,
+RB_EMPTY_ROOT(&msk->out_of_order_queue));
+ if (after64(seq, max_seq)) {
+ /* out of window */
+ mptcp_drop(sk, skb);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_NODSSWINDOW);
+ return;
+ }
- __skb_unlink(skb, &ssk->sk_receive_queue);
+ p = &msk->out_of_order_queue.rb_node;
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
+ if (RB_EMPTY_ROOT(&msk->out_of_order_queue)) {
+ rb_link_node(&skb->rbnode, NULL, p);
+ rb_insert_color(&skb->rbnode, &msk->out_of_order_queue);
+ msk->ooo_last_skb = skb;
+ goto end;
+ }
- skb_ext_reset(skb);
- skb_orphan(skb);
- WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+ /* with 2 subflows, adding at end of ooo queue is quite likely
+* Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
+*/
+ if (mptcp_ooo_try_coalesce(msk, msk->ooo_last_skb, skb)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ return;
+ }
- tail = skb_peek_tail(&sk->sk_receive_queue);
- if (offset == 0 && tail) {
- bool fragstolen;
- int delta;
+ /* Can avoid an rbtree lookup if we are adding skb after ooo_last_skb */
+ if (!before64(seq, MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ parent = &msk->ooo_last_skb->rbnode;
+ p = &p
Re: linux-next: manual merge of the net-next tree with the net tree
> 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
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);
> 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
>-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
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
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
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
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, &walker, true);
- call_rcu(&p->rcu, __tcindex_destroy);
+ if (p->perfect) {
+ for (i = 0; i < p->hash; i++) {
+ struct tcindex_filter_result *r = p->perfect + i;
+
+ tcf_unbind_filter(tp, &r->res);
+ if (tcf_exts_get_net(&r->exts))
+ tcf_queue_work(&r->rwork,
+ tcindex_destroy_rexts_work);
+ else
+ __tcindex_destroy_rexts(r);
+ }
+ }
+
+ for (i = 0; p->h && i < p->hash; i++) {
+ struct tcindex_filter *f, *next;
+ bool last;
+
+ for (f = rtnl_dereference(p->h[i]); f; f = next) {
+ next = rtnl_dereference(f->next);
- tcindex_delete(tp, &f->result, &last, NULL);
++ tcindex_delete(tp, &f->result, &last, false, NULL);
+ }
+ }
+
+ tcf_queue_work(&p->rwork, tcindex_destroy_work);
}
pgpNyus1SwOgo.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
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
Stephen Rothwell writes:
> diff --cc drivers/net/vxlan.c
> index 0565f8880199,71c3b7b6b1ab..
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@@ -3297,16 -3483,9 +3484,16 @@@ static int __vxlan_dev_create(struct ne
>
> list_add(&vxlan->next, &vn->vxlan_list);
> return 0;
> +
> errout:
> +/* unregister_netdevice() destroys the default FDB entry with deletion
> + * notification. But the addition notification was not sent yet, so
> + * destroy the entry by hand here.
> + */
> if (f)
> - vxlan_fdb_destroy(vxlan, f, false);
> + vxlan_fdb_destroy(vxlan, f, false, false);
> +if (unregister)
> +unregister_netdevice(dev);
> return err;
> }
>
> @@@ -3540,8 -3719,10 +3727,9 @@@ static int vxlan_changelink(struct net_
> {
> struct vxlan_dev *vxlan = netdev_priv(dev);
> struct vxlan_rdst *dst = &vxlan->default_dst;
> + unsigned long old_age_interval;
> struct vxlan_rdst old_dst;
> struct vxlan_config conf;
> -struct vxlan_fdb *f = NULL;
> int err;
>
> err = vxlan_nl2conf(tb, data,
> @@@ -3564,13 -3749,13 +3756,14 @@@
> vxlan->cfg.dst_port,
> old_dst.remote_vni,
> old_dst.remote_vni,
> -old_dst.remote_ifindex, 0);
> +old_dst.remote_ifindex,
> +true);
>
> if (!vxlan_addr_any(&dst->remote_ip)) {
> -err = vxlan_fdb_create(vxlan, all_zeros_mac,
> +err = vxlan_fdb_update(vxlan, all_zeros_mac,
> &dst->remote_ip,
> NUD_REACHABLE | NUD_PERMANENT,
> + NLM_F_APPEND | NLM_F_CREATE,
> vxlan->cfg.dst_port,
> dst->remote_vni,
> dst->remote_vni,
The above looks correct, but the last hunk has one non-conflicting line
that nonetheless needs fixing up:
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index efd709a5e3a8..5209ee9aac47 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3768,7 +3768,7 @@ static int vxlan_changelink(struct net_device *dev,
struct nlattr *tb[],
dst->remote_vni,
dst->remote_vni,
dst->remote_ifindex,
- NTF_SELF);
+ NTF_SELF, true);
if (err) {
spin_unlock_bh(&vxlan->hash_lock);
return err;
Thanks!
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
pgpTaRVKg5TN6.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
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&q=mlx5
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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
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
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
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 pgp_5MyqFFpLy.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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
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
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
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
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
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
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
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
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
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
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(&health->wq_lock);
> + spin_lock_irqsave(&health->wq_lock, flags);
> - if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags))
> + if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags))
> schedule_delayed_work(&health->recover_work, recover_delay);
> else
> dev_err(&dev->pdev->dev,
> @@@ -334,11 -341,11 +343,12 @@@ void mlx5_stop_health_poll(struct mlx5_
> void mlx5_drain_health_wq(struct mlx5_core_dev *dev)
> {
> struct mlx5_core_health *health = &dev->priv.health;
> + unsigned long flags;
>
> - spin_lock(&health->wq_lock);
> + spin_lock_irqsave(&health->wq_lock, flags);
> set_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
> + set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
> - spin_unlock(&health->wq_lock);
> + spin_unlock_irqrestore(&health->wq_lock, flags);
> cancel_delayed_work_sync(&health->recover_work);
> cancel_work_sync(&health->work);
> }
> diff --cc include/linux/mlx5/driver.h
> index ba260330ce5e,2ab4ae3e3a1a..
> --- 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
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
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 != &noop_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
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
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
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, &tc);
> }
>
> +static void fl_destroy_sleepable(struct work_struct *work)
> +{
> + struct cls_fl_head *head = container_of(work, struct cls_fl_head,
> + work);
> + if (head->mask_assigned)
> + rhashtable_destroy(&head->ht);
> + kfree(head);
> + module_put(THIS_MODULE);
> +}
> +
> +static void fl_destroy_rcu(struct rcu_head *rcu)
> +{
> + struct cls_fl_head *head = container_of(rcu, struct cls_fl_head, rcu);
> +
> + INIT_WORK(&head->work, fl_destroy_sleepable);
> + schedule_work(&head->work);
> +}
> +
>+ static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
>+ {
>+ list_del_rcu(&f->list);
>+ fl_hw_destroy_filter(tp, (unsigned long)f);
>+ tcf_unbind_filter(tp, &f->res);
>+ call_rcu(&f->rcu, fl_destroy_filter);
>+ }
>+
> static bool fl_destroy(struct tcf_proto *tp, bool force)
> {
> struct cls_fl_head *head = rtnl_dereference(tp->root);
>@@@ -299,14 -288,12 +310,11 @@@
> if (!force && !list_empty(&head->filters))
> return false;
>
>- list_for_each_entry_safe(f, next, &head->filters, list) {
>- fl_hw_destroy_filter(tp, (unsigned long)f);
>- list_del_rcu(&f->list);
>- call_rcu(&f->rcu, fl_destroy_filter);
>- }
>+ list_for_each_entry_safe(f, next, &head->filters, list)
>+ __fl_delete(tp, f);
> - RCU_INIT_POINTER(tp->root, NULL);
> - if (head->mask_assigned)
> - rhashtable_destroy(&head->ht);
> - kfree_rcu(head, rcu);
> +
> + __module_get(THIS_MODULE);
> + call_rcu(&head->rcu, fl_destroy_rcu);
> return true;
> }
>
>@@@ -761,13 -782,9 +804,10 @@@ static int fl_delete(struct tcf_proto *
> struct cls_fl_head *head = rtnl_dereference(tp->root);
> struct cls_fl_filter *f = (struct cls_fl_filter *) arg;
>
> - rhashtable_remove_fast(&head->ht, &f->ht_node,
> -head->ht_params);
> + if (!tc_skip_sw(f->flags))
> + rhashtable_remove_fast(&head->ht, &f->ht_node,
> +head->ht_params);
>- list_del_rcu(&f->list);
>- fl_hw_destroy_filter(tp, (unsigned long)f);
>- tcf_unbind_filter(tp, &f->res);
>- call_rcu(&f->rcu, fl_destroy_filter);
>+ __fl_delete(tp, f);
> return 0;
> }
>
Re: linux-next: manual merge of the net-next tree with the net tree
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
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
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
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
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
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
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
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(&rq->channel->napi);
>
> + cancel_work_sync(&rq->am.work);
> +
> mlx5e_disable_rq(rq);
> + mlx5e_free_rx_descs(rq);
> mlx5e_destroy_rq(rq);
> }
>
> @@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e
> if (mlx5e_sq_has_room_for(sq, 1))
> mlx5e_send_nop(sq, true);
>
> - mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR,
> - false, 0);
> + err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY,
> - MLX5_SQC_STATE_ERR);
> ++MLX5_SQC_STATE_ERR, false, 0);
> + if (err)
> + set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state);
> }
Thanks Stephen, the fixup looks good.
I already notified Dave on those issues and how to fix, see mail
thread "Mellanox 100G mlx5 resiliency and xmit path fixes"
Thanks,
Saeed.
Re: linux-next: manual merge of the net-next tree with the net tree
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
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(&priv->set_rx_mode_work);
> mlx5e_disable_async_events(priv);
> flush_scheduled_work();
> - unregister_netdev(netdev);
> + if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) {
> + netif_device_detach(netdev);
> + mutex_lock(&priv->state_lock);
> + if (test_bit(MLX5E_STATE_OPENED, &priv->state))
> + mlx5e_close_locked(netdev);
> + mutex_unlock(&priv->state_lock);
> + } else {
> + unregister_netdev(netdev);
> + }
> +
> mlx5e_tc_cleanup(priv);
> mlx5e_vxlan_cleanup(priv);
> + mlx5e_destroy_q_counter(priv);
> mlx5e_destroy_flow_tables(priv);
> mlx5e_destroy_tirs(priv);
> mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);
Looks good, and it is pretty straightforward.
Dave will have to take all hunks from both patches, same as you did.
Thank you Stephen.
Saeed.
Re: linux-next: manual merge of the net-next tree with the net tree
Hi David,
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/dsa/mv88e6xxx.c
>
> between commit:
>
> 207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")
>
> from the net tree and commit:
>
> 009a2b9843bf ("net: dsa: mv88e6xxx: add number of ports to info")
>
> from the net-next tree.
>
> I fixed it up (the former removed some of the code updated by the latter)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
I have another series to send to net-next which will also conflict with this
fix from net. As it is also required in net-next, can the fix be merged
in net-next as well?
This fix is the 3 commits:
65fa40276ac1 ("net: dsa: mv88e6xxx: unlock DSA and CPU ports")
996ecb824667 ("net: dsa: mv88e6xxx: enable SA learning on DSA ports")
207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")
For the merge commit:
cf6b5fb2514d ("Merge branch 'dsa-mv88e6xxx-fix-cross-chip-bridging'")
Regards,
Vivien
Re: linux-next: manual merge of the net-next tree with the net tree
On Mon, 2016-04-18 at 11:31 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/ipv4/udp.c
>
> between commit:
>
> d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets")
>
> from the net tree and commit:
>
> ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")
>
> from the net-next tree.
>
> I tried to fixed it up (see below). Unfortunately,
> hlist_add_tail_rcu() does not exist. So instead I have reverted commit
> d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets") for
> today.
Hi Stephen
Craig warned that this would happen indeed, and provided a net-next
patch, to help David with this conflict.
https://patchwork.ozlabs.org/patch/611093/
Thanks
Re: linux-next: manual merge of the net-next tree with the net tree
On 03/04/2016 03:09 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/vxlan.c
between commit:
4024fcf70556 ("vxlan: fix missing options_len update on RX with collect
metadata")
from the net tree and commit:
3288af0892e3 ("vxlan: move GBP header parsing to a separate function")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Looks good, thanks!
Re: linux-next: manual merge of the net-next tree with the net tree
On 02/26/2016 01:13 AM, Stephen Rothwell wrote: [...] I fixed it up (see below) and can carry the fix as necessary (no action is required). Looks good to me, thanks Stephen! Best, Daniel
Re: linux-next: manual merge of the net-next tree with the net tree
On 11/26/2015 01:01 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
kernel/bpf/syscall.c
between commit:
c9da161c6517 ("bpf: fix clearing on persistent program array maps")
from the net tree and commit:
f99bf205dab0 ("bpf: add show_fdinfo handler for maps")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Seems fine, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the net-next tree with the net tree
On 07/30/2015 04:10 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/bridge/br_multicast.c
>
> between commit:
>
> 544586f742b4 ("bridge: mcast: give fast leave precedence over multicast
> router and querier")
>
> from the net tree and commit:
>
> 09cf0211f970 ("bridge: mdb: fill state in br_mdb_notify")
>
> from the net-next tree.
>
> I fixed it up (hopefully - see below) and can carry the fix as necessary
> (no action is required).
>
Right, looks good. Thank you!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the net-next tree with the net tree
2015-05-20 19:59 GMT-07:00 Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
> phy_start() always re-enables the phy interrupts") from the net tree
> and commit 3e2186e02112 ("net: phy: Add state machine state transitions
> debug prints") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks correct to me, thanks Stephen!
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/net/phy/phy.c
> index 47cd578052fc,1457ecf75dcc..
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@@ -783,7 -794,8 +808,8 @@@ void phy_state_machine(struct work_stru
> struct delayed_work *dwork = to_delayed_work(work);
> struct phy_device *phydev =
> container_of(dwork, struct phy_device, state_queue);
> - bool needs_aneg = false, do_suspend = false, do_resume = false;
> + bool needs_aneg = false, do_suspend = false;
> + enum phy_state old_state;
> int err = 0;
>
> mutex_lock(&phydev->lock);
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
