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 = >rx_queue[queue];
> >+int i;
> >+
> >+for (i = 0; i < priv->dma_rx_size; i++) {
> >+struct stmmac_rx_buffer *buf = _q->buf_pool[i];
> >+
> >+if (buf->page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>page);
> >+buf->page = NULL;
> >+}
> >+
> >+if (priv->sph && buf->sec_page) {
> >+page_pool_recycle_direct(rx_q->page_pool, buf-
> >>sec_page);
> >+buf->sec_page = NULL;
> >+}
> >+}
> >+ }
>
> With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
> stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
> is no longer needed when net-next is sent for merge.
Thanks. I have added removal of that (now unused) function to my merge
resolution.
--
Cheers,
Stephen Rothwell
pgp7tmTAfcDCC.pgp
Description: OpenPGP digital signature
RE: linux-next: manual merge of the net-next tree with the net tree
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
>between commit:
>
> 00423969d806 ("Revert "net: stmmac: re-init rx buffers when mac resume
>back"")
>
>from the net tree and commits:
>
> bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
> de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue
>basis")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your tree
>is submitted for merging. You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any particularly
>complex conflicts.
I check linux-next merge fix above and spotted an additional fix needed.
Please see below.
>+ /**
>+ * dma_recycle_rx_skbufs - recycle RX dma buffers
>+ * @priv: private structure
>+ * @queue: RX queue index
>+ */
>+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
>+ {
>+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
>+ int i;
>+
>+ for (i = 0; i < priv->dma_rx_size; i++) {
>+ struct stmmac_rx_buffer *buf = _q->buf_pool[i];
>+
>+ if (buf->page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>page);
>+ buf->page = NULL;
>+ }
>+
>+ if (priv->sph && buf->sec_page) {
>+ page_pool_recycle_direct(rx_q->page_pool, buf-
>>sec_page);
>+ buf->sec_page = NULL;
>+ }
>+ }
>+ }
With https://git.kernel.org/netdev/net/c/00423969d806 that reverts
stmmac_reinit_rx_buffers(), then the above dma_recycle_rx_skbufs()
is no longer needed when net-next is sent for merge.
> -/**
> - * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
> - * @priv: driver private structure
> - * Description: this function is called to re-allocate a receive buffer,
> perform
> - * the DMA mapping and init the descriptor.
> - */
> -static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
> -{
> - u32 rx_count = priv->plat->rx_queues_to_use;
> - u32 queue;
> -
> - for (queue = 0; queue < rx_count; queue++) {
> - struct stmmac_rx_queue *rx_q = >rx_queue[queue];
> -
> - if (rx_q->xsk_pool)
> - dma_free_rx_xskbufs(priv, queue);
dma_recycle_rx_skbufs() is only called here.
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.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160,3a5ca5833ce1..
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -1380,8 -1519,182 +1519,131 @@@ static void stmmac_free_tx_buffer(struc
}
/**
- * init_dma_rx_desc_rings - init the RX descriptor rings
- * @dev: net device structure
+ * dma_free_rx_skbufs - free RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++)
+ stmmac_free_rx_buffer(priv, queue, i);
+ }
+
+ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
+ gfp_t flags)
+ {
+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct dma_desc *p;
+ int ret;
+
+ if (priv->extend_desc)
+ p = &((rx_q->dma_erx + i)->basic);
+ else
+ p = rx_q->dma_rx + i;
+
+ ret = stmmac_init_rx_buffers(priv, p, i, flags,
+queue);
+ if (ret)
+ return ret;
+
+ rx_q->buf_alloc_num++;
+ }
+
+ return 0;
+ }
+
+ /**
+ * dma_recycle_rx_skbufs - recycle RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf = _q->buf_pool[i];
+
+ if (buf->page) {
+ page_pool_recycle_direct(rx_q->page_pool, buf->page);
+ buf->page = NULL;
+ }
+
+ if (priv->sph && buf->sec_page) {
+ page_pool_recycle_direct(rx_q->page_pool,
buf->sec_page);
+ buf->sec_page = NULL;
+ }
+ }
+ }
+
+ /**
+ * dma_free_rx_xskbufs - free RX dma buffers from XSK pool
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+ static void dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf = _q->buf_pool[i];
+
+ if (!buf->xdp)
+ continue;
+
+ xsk_buff_free(buf->xdp);
+ buf->xdp = NULL;
+ }
+ }
+
+ static int stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
+ {
+ struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+ int i;
+
+ for (i = 0; i < priv->dma_rx_size; i++) {
+ struct stmmac_rx_buffer *buf;
+ dma_addr_t dma_addr;
+ struct dma_desc *p;
+
+ if (priv->extend_desc)
+ p = (struct dma_desc *)(rx_q->dma_erx + i);
+ else
+ p = rx_q->dma_rx + i;
+
+ buf = _q->buf_pool[i];
+
+ buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+ if (!buf->xdp)
+ return -ENOMEM;
+
+ dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+ stmmac_set_desc_addr(priv, p, dma_addr);
+ rx_q->buf_alloc_num++;
+ }
+
+ return 0;
+ }
+
-/**
- * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
- * @priv: driver private structure
- * Description: this function is called to re-allocate a receive buffer,
perform
- * the DMA mapping and init the descriptor.
- */
-static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
-{
- u32 rx_count = priv->plat->rx_queues_to_use;
- u32 queue;
-
- for (queue = 0; queue < rx_count; queue++) {
- struct stmmac_rx_queue *rx_q = >rx_queue[queue];
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:
net/tipc/crypto.c
between commit:
2a2403ca3add ("tipc: increment the tmp aead refcnt before attaching it")
from the net tree and commit:
97bc84bbd4de ("tipc: clean up warnings detected by sparse")
from the net-next tree.
I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp3UqR42C5pN.pgp
Description: OpenPGP digital signature
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:
include/linux/ethtool.h
between commit:
a975d7d8a356 ("ethtool: Remove link_mode param and derive link params from
driver")
from the net tree and commit:
7888fe53b706 ("ethtool: Add common function for filling out strings")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/ethtool.h
index cdca84e6dd6b,5c631a298994..
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@@ -573,12 -573,13 +575,22 @@@ struct ethtool_phy_ops
*/
void ethtool_set_ethtool_phy_ops(const struct ethtool_phy_ops *ops);
+/*
+ * ethtool_params_from_link_mode - Derive link parameters from a given link
mode
+ * @link_ksettings: Link parameters to be derived from the link mode
+ * @link_mode: Link mode
+ */
+void
+ethtool_params_from_link_mode(struct ethtool_link_ksettings *link_ksettings,
+enum ethtool_link_mode_bit_indices link_mode);
++
+ /**
+ * ethtool_sprintf - Write formatted string to ethtool string data
+ * @data: Pointer to start of string to update
+ * @fmt: Format of string to write
+ *
+ * Write formatted string to data. Update data to point at start of
+ * next string.
+ */
+ extern __printf(2, 3) void ethtool_sprintf(u8 **data, const char *fmt, ...);
#endif /* _LINUX_ETHTOOL_H */
pgpQXT1TusKn0.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/en_main.c
between commit:
3ff3874fa0b2 ("net/mlx5e: Guarantee room for XSK wakeup NOP on async ICOSQ")
from the net tree and commits:
c276aae8c19d ("net/mlx5: Move mlx5e hw resources into a sub object")
b3a131c2a160 ("net/mlx5e: Move params logic into its dedicated file")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 5db63b9f3b70,773449c1424b..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -1090,8 -1040,7 +1040,8 @@@ static int mlx5e_alloc_icosq(struct mlx
int err;
sq->channel = c;
- sq->uar_map = mdev->mlx5e_res.bfreg.map;
+ sq->uar_map = mdev->mlx5e_res.hw_objs.bfreg.map;
+ sq->reserved_room = param->stop_room;
param->wq.db_numa_node = cpu_to_node(c->cpu);
err = mlx5_wq_cyc_create(mdev, >wq, sqc_wq, wq, >wq_ctrl);
pgpM0u5y6b34C.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/sf/hw_table.c
between commit:
7c1ef1959b6f ("net/mlx5: SF, do not use ecpu bit for vhca state processing")
from the net tree and commit:
4c94fe88cde4 ("net: ethernet: Remove duplicate include of vhca_event.h")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c
index a5a0f60bef66,3c8a00dd573a..
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/hw_table.c
@@@ -5,8 -5,7 +5,7 @@@
#include "priv.h"
#include "sf.h"
#include "mlx5_ifc_vhca_event.h"
- #include "vhca_event.h"
-#include "ecpf.h"
+#include "mlx5_core.h"
struct mlx5_sf_hw {
u32 usr_sfnum;
pgpZb2ZkhTgE_.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/en_tc.c
between commit:
7d6c86e3ccb5 ("net/mlx5e: Allow to match on MPLS parameters only for MPLS
over UDP")
from the net tree and commit:
a3222a2da0a2 ("net/mlx5e: Allow to match on ICMP parameters")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index df2a0af854bb,730f33ada90a..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -2295,17 -2314,49 +2314,60 @@@ static int __parse_cls_flower(struct ml
if (match.mask->flags)
*match_level = MLX5_MATCH_L4;
}
+
+ /* Currenlty supported only for MPLS over UDP */
+ if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_MPLS) &&
+ !netif_is_bareudp(filter_dev)) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Matching on MPLS is supported only for MPLS
over UDP");
+ netdev_err(priv->netdev,
+ "Matching on MPLS is supported only for MPLS over
UDP\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ICMP)) {
+ struct flow_match_icmp match;
+
+ flow_rule_match_icmp(rule, );
+ switch (ip_proto) {
+ case IPPROTO_ICMP:
+ if (!(MLX5_CAP_GEN(priv->mdev, flex_parser_protocols) &
+ MLX5_FLEX_PROTO_ICMP))
+ return -EOPNOTSUPP;
+ MLX5_SET(fte_match_set_misc3, misc_c_3, icmp_type,
+match.mask->type);
+ MLX5_SET(fte_match_set_misc3, misc_v_3, icmp_type,
+match.key->type);
+ MLX5_SET(fte_match_set_misc3, misc_c_3, icmp_code,
+match.mask->code);
+ MLX5_SET(fte_match_set_misc3, misc_v_3, icmp_code,
+match.key->code);
+ break;
+ case IPPROTO_ICMPV6:
+ if (!(MLX5_CAP_GEN(priv->mdev, flex_parser_protocols) &
+ MLX5_FLEX_PROTO_ICMPV6))
+ return -EOPNOTSUPP;
+ MLX5_SET(fte_match_set_misc3, misc_c_3, icmpv6_type,
+match.mask->type);
+ MLX5_SET(fte_match_set_misc3, misc_v_3, icmpv6_type,
+match.key->type);
+ MLX5_SET(fte_match_set_misc3, misc_c_3, icmpv6_code,
+match.mask->code);
+ MLX5_SET(fte_match_set_misc3, misc_v_3, icmpv6_code,
+match.key->code);
+ break;
+ default:
+ NL_SET_ERR_MSG_MOD(extack,
+ "Code and type matching only with
ICMP and ICMPv6");
+ netdev_err(priv->netdev,
+ "Code and type matching only with ICMP and
ICMPv6\n");
+ return -EINVAL;
+ }
+ if (match.mask->code || match.mask->type) {
+ *match_level = MLX5_MATCH_L4;
+ spec->match_criteria_enable |=
MLX5_MATCH_MISC_PARAMETERS_3;
+ }
+ }
return 0;
}
pgpnlsaPsANd0.pgp
Description: OpenPGP digital signature
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
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:
kernel/bpf/verifier.c
between commits:
b5871dca250c ("bpf: Simplify alu_limit masking for pointer arithmetic")
1b1597e64e1a ("bpf: Add sanity check for upper ptr_limit")
from the net tree and commit:
69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
from the net-next tree.
I fixed it up (see below - but it may need more work on the new
"return" starement from the latter commit) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -5876,10 -6056,22 +6060,23 @@@ static int retrieve_ptr_limit(const str
if (mask_to_left)
*ptr_limit = MAX_BPF_STACK + off;
else
- *ptr_limit = -off;
- return 0;
+ *ptr_limit = -off - 1;
+ return *ptr_limit >= max ? -ERANGE : 0;
+ case PTR_TO_MAP_KEY:
+ /* Currently, this code is not exercised as the only use
+* is bpf_for_each_map_elem() helper which requires
+* bpf_capble. The code has been tested manually for
+* future use.
+*/
+ if (mask_to_left) {
+ *ptr_limit = ptr_reg->umax_value + ptr_reg->off;
+ } else {
+ off = ptr_reg->smin_value + ptr_reg->off;
+ *ptr_limit = ptr_reg->map_ptr->key_size - off;
+ }
+ return 0;
case PTR_TO_MAP_VALUE:
+ max = ptr_reg->map_ptr->value_size;
if (mask_to_left) {
*ptr_limit = ptr_reg->umax_value + ptr_reg->off;
} else {
pgpj_oPAA32jU.pgp
Description: OpenPGP digital signature
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/pensando/ionic/ionic_txrx.c
between commit:
d2c21422323b ("ionic: linearize tso skb with too many frags")
from the net tree and commit:
f37bc3462e80 ("ionic: optimize fastpath struct usage")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/pensando/ionic/ionic_txrx.c
index 4087311f7082,03e00a6c413a..
--- a/drivers/net/ethernet/pensando/ionic/ionic_txrx.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_txrx.c
@@@ -1077,19 -1082,16 +1082,18 @@@ static int ionic_tx(struct ionic_queue
static int ionic_tx_descs_needed(struct ionic_queue *q, struct sk_buff *skb)
{
- int sg_elems = q->lif->qtype_info[IONIC_QTYPE_TXQ].max_sg_elems;
struct ionic_tx_stats *stats = q_to_tx_stats(q);
+ int ndescs;
int err;
- /* If TSO, need roundup(skb->len/mss) descs */
+ /* Each desc is mss long max, so a descriptor for each gso_seg */
if (skb_is_gso(skb))
- return (skb->len / skb_shinfo(skb)->gso_size) + 1;
+ ndescs = skb_shinfo(skb)->gso_segs;
+ else
+ ndescs = 1;
- if (skb_shinfo(skb)->nr_frags <= sg_elems)
- /* If non-TSO, just need 1 desc and nr_frags sg elems */
+ if (skb_shinfo(skb)->nr_frags <= q->max_sg_elems)
- return 1;
+ return ndescs;
/* Too many frags, so linearize */
err = skb_linearize(skb);
pgpED6xpqdu3F.pgp
Description: OpenPGP digital signature
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
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 conflicts in:
drivers/net/ethernet/ibm/ibmvnic.c
drivers/net/ethernet/ibm/ibmvnic.h
between commit:
4a41c421f367 ("ibmvnic: serialize access to work queue on remove")
from the net tree and commits:
bab08bedcdc3 ("ibmvnic: fix block comments")
a369d96ca554 ("ibmvnic: add comments for spinlock_t definitions")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index 13ae7eee7ef5,927d5f36d308..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -2395,10 -2288,7 +2294,9 @@@ static int ibmvnic_reset(struct ibmvnic
unsigned long flags;
int ret;
+ spin_lock_irqsave(>rwi_lock, flags);
+
- /*
-* If failover is pending don't schedule any other reset.
+ /* If failover is pending don't schedule any other reset.
* Instead let the failover complete. If there is already a
* a failover reset scheduled, we will detect and drop the
* duplicate reset when walking the ->rwi_list below.
diff --cc drivers/net/ethernet/ibm/ibmvnic.h
index 72fea3b1c87d,270d1cac86a4..
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@@ -1080,10 -1081,12 +1081,16 @@@ struct ibmvnic_adapter
struct tasklet_struct tasklet;
enum vnic_state state;
- /* Used for serializatin of state field */
++ /* Used for serialization of state field. When taking both state
++ * and rwi locks, take state lock first.
++ */
+ spinlock_t state_lock;
enum ibmvnic_reset_reason reset_reason;
- /* when taking both state and rwi locks, take state lock first */
- spinlock_t rwi_lock;
struct list_head rwi_list;
- /* Used for serialization of rwi_list */
++ /* Used for serialization of rwi_list. When taking both state
++ * and rwi locks, take state lock first
++ */
+ spinlock_t rwi_lock;
struct work_struct ibmvnic_reset;
struct delayed_work ibmvnic_delayed_reset;
unsigned long resetting;
pgpjmTjtXri7M.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 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 pgp2Bll3CeKtr.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
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 conflicts in:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
between commit:
e4484d9df500 ("net/mlx5e: Enable striding RQ for Connect-X IPsec capable
devices")
from the net tree and commits:
224169d2a32b ("net/mlx5e: IPsec, Remove unnecessary config flag usage")
70038b73e40e ("net/mlx5e: Add listener to trap event")
214baf22870c ("net/mlx5e: Support HTB offload")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index a2e0b548bf57,d3534b657b98..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -65,7 -65,8 +65,9 @@@
#include "en/devlink.h"
#include "lib/mlx5.h"
#include "en/ptp.h"
+#include "fpga/ipsec.h"
+ #include "qos.h"
+ #include "en/trap.h"
bool mlx5e_check_fragmented_striding_rq_cap(struct mlx5_core_dev *mdev)
{
@@@ -2069,10 -2106,8 +2107,8 @@@ static void mlx5e_build_rq_frags_info(s
u32 buf_size = 0;
int i;
- #ifdef CONFIG_MLX5_EN_IPSEC
- if (MLX5_IPSEC_DEV(mdev))
+ if (mlx5_fpga_is_ipsec_device(mdev))
byte_count += MLX5E_METADATA_ETHER_LEN;
- #endif
if (mlx5e_rx_is_linear_skb(params, xsk)) {
int frag_stride;
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 4864deed9dc9,4de5a97ceac6..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@@ -1794,12 -1786,10 +1786,10 @@@ int mlx5e_rq_set_handlers(struct mlx5e_
rq->dealloc_wqe = mlx5e_dealloc_rx_mpwqe;
rq->handle_rx_cqe =
priv->profile->rx_handlers->handle_rx_cqe_mpwqe;
- #ifdef CONFIG_MLX5_EN_IPSEC
- if (MLX5_IPSEC_DEV(mdev)) {
- netdev_err(netdev, "MPWQE RQ with IPSec offload not
supported\n");
+ if (mlx5_fpga_is_ipsec_device(mdev)) {
+ netdev_err(netdev, "MPWQE RQ with Innova IPSec offload
not supported\n");
return -EINVAL;
}
- #endif
if (!rq->handle_rx_cqe) {
netdev_err(netdev, "RX handler of MPWQE RQ is not
set\n");
return -EINVAL;
pgpu3GCjH27Mp.pgp
Description: OpenPGP digital signature
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:
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"
NUM_NETIFS=2
source tc_common.sh
source lib.sh
pgpmMuGAaTuc2.pgp
Description: OpenPGP digital signature
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:
include/uapi/linux/pkt_cls.h
between commit:
1bcc51ac0731 ("net/sched: cls_flower: Reject invalid ct_state flags rules")
from the net tree and commits:
7baf2429a1a9 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support")
8c85d18ce647 ("net/sched: cls_flower: Add match on the ct_state reply flag")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/pkt_cls.h
index 88f4bf0047e7,afe6836e44b1..
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@@ -591,8 -591,8 +591,10 @@@ enum
TCA_FLOWER_KEY_CT_FLAGS_ESTABLISHED = 1 << 1, /* Part of an existing
connection. */
TCA_FLOWER_KEY_CT_FLAGS_RELATED = 1 << 2, /* Related to an established
connection. */
TCA_FLOWER_KEY_CT_FLAGS_TRACKED = 1 << 3, /* Conntrack has occurred. */
+ TCA_FLOWER_KEY_CT_FLAGS_INVALID = 1 << 4, /* Conntrack is invalid. */
+ TCA_FLOWER_KEY_CT_FLAGS_REPLY = 1 << 5, /* Packet is in the reply
direction. */
+
+ __TCA_FLOWER_KEY_CT_FLAGS_MAX,
};
enum {
pgpOvPAkHVd6_.pgp
Description: OpenPGP digital signature
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/can/m_can/tcan4x5x-core.c
between commit:
aee2b3ccc8a6 ("can: tcan4x5x: fix bittiming const, use common bittiming from
m_can driver")
from the net tree and commit:
7813887ea972 ("can: tcan4x5x: rename tcan4x5x.c -> tcan4x5x-core.c")
from the net-next tree.
I fixed it up (just removed the struct instances removed by the former)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpuskbEf7Fel.pgp
Description: OpenPGP digital signature
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.
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/ibm/ibmvnic.c
between commit:
b71ec9522346 ("ibmvnic: Ensure that SCRQ entry reads are correctly ordered")
from the net tree and commit:
ec20f36bb41a ("ibmvnic: Correctly re-enable interrupts in NAPI polling
routine")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpSeYacgibZJ.pgp
Description: OpenPGP digital signature
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/ibm/ibmvnic.c
between commit:
9281cf2d5840 ("ibmvnic: avoid memset null scrq msgs")
from the net tree and commit:
f019fb6392e5 ("ibmvnic: Introduce indirect subordinate Command Response Queue
buffer")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index bca1becd33f0,cdd1ff9aa9c4..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -2874,14 -2959,11 +2968,15 @@@ static int reset_one_sub_crq_queue(stru
irq_dispose_mapping(scrq->irq);
scrq->irq = 0;
}
-
- memset(scrq->msgs, 0, 4 * PAGE_SIZE);
- atomic_set(>used, 0);
- scrq->cur = 0;
- scrq->ind_buf.index = 0;
+ if (scrq->msgs) {
+ memset(scrq->msgs, 0, 4 * PAGE_SIZE);
+ atomic_set(>used, 0);
+ scrq->cur = 0;
++ scrq->ind_buf.index = 0;
+ } else {
+ netdev_dbg(adapter->netdev, "Invalid scrq reset\n");
+ return -EINVAL;
+ }
rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
4 * PAGE_SIZE, >crq_num, >hw_irq);
pgpTQRulbhg0E.pgp
Description: OpenPGP digital signature
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(>state_lock, flags);
- if (rwi->reset_reason == VNIC_RESET_CHANGE_PARAM) {
- /* CHANGE_PARAM requestor holds rtnl_lock */
- rc = do_change_param_reset(adapter, rwi, reset_state);
- } else if (adapter->force_reset_recovery) {
+ if (adapter->force_reset_recovery) {
+ /*
+ * Since we are doing a hard reset now, clear the
+ * failover_pending flag so we don't ignore any
+ * future MOBILITY or other resets.
+ */
+ adapter->failover_pending = false;
+
/* Transport event occurred during previous reset */
if (adapter->wait_for_reset) {
/* Previous was CHANGE_PARAM; caller locked */
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/ibm/ibmvnic.c
between commit:
1d8504937478 ("powerpc/vnic: Extend "failover pending" window")
from the net tree and commit:
16b5f5ce351f ("ibmvnic: merge do_change_param_reset into do_reset")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index da15913879f8,f4167de30461..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -1930,17 -1841,12 +1850,20 @@@ static int do_reset(struct ibmvnic_adap
netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
rwi->reset_reason);
- rtnl_lock();
+ adapter->reset_reason = rwi->reset_reason;
+ /* requestor of VNIC_RESET_CHANGE_PARAM already has the rtnl lock */
+ if (!(adapter->reset_reason == VNIC_RESET_CHANGE_PARAM))
+ rtnl_lock();
+
+ /*
+ * Now that we have the rtnl lock, clear any pending failover.
+ * This will ensure ibmvnic_open() has either completed or will
+ * block until failover is complete.
+ */
+ if (rwi->reset_reason == VNIC_RESET_FAILOVER)
+ adapter->failover_pending = false;
+
netif_carrier_off(netdev);
- adapter->reset_reason = rwi->reset_reason;
old_num_rx_queues = adapter->req_rx_queues;
old_num_tx_queues = adapter->req_tx_queues;
@@@ -2214,17 -2140,7 +2157,14 @@@ static void __ibmvnic_reset(struct work
}
spin_unlock_irqrestore(>state_lock, flags);
- if (rwi->reset_reason == VNIC_RESET_CHANGE_PARAM) {
- /* CHANGE_PARAM requestor holds rtnl_lock */
- rc = do_change_param_reset(adapter, rwi, reset_state);
- } else if (adapter->force_reset_recovery) {
+ if (adapter->force_reset_recovery) {
+ /*
+ * Since we are doing a hard reset now, clear the
+ * failover_pending flag so we don't ignore any
+ * future MOBILITY or other resets.
+ */
+ adapter->failover_pending = false;
+
/* Transport event occurred during previous reset */
if (adapter->wait_for_reset) {
/* Previous was CHANGE_PARAM; caller locked */
pgpaWIZdImorV.pgp
Description: OpenPGP digital signature
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:
net/mptcp/protocol.h
between commit:
d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows")
from the net tree and commit:
d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/mptcp/protocol.h
index 972463642690,aa0ab18d2e57..
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@@ -203,9 -211,10 +212,11 @@@ struct mptcp_sock
boolfully_established;
boolrcv_data_fin;
boolsnd_data_fin_enable;
+ booluse_64bit_ack; /* Set when we received a 64-bit DSN */
spinlock_t join_list_lock;
struct work_struct work;
+ struct sk_buff *ooo_last_skb;
+ struct rb_root out_of_order_queue;
struct list_head conn_list;
struct list_head rtx_queue;
struct list_head join_list;
@@@ -294,9 -309,10 +311,9 @@@ struct mptcp_subflow_context
map_valid : 1,
mpc_map : 1,
backup : 1,
- data_avail : 1,
rx_eof : 1,
- use_64bit_ack : 1, /* Set when we received a 64-bit DSN */
can_ack : 1;/* only after processing the remote a key */
+ enum mptcp_data_avail data_avail;
u32 remote_nonce;
u64 thmac;
u32 local_nonce;
@@@ -349,11 -365,13 +366,14 @@@ void mptcp_subflow_fully_established(st
struct mptcp_options_received *mp_opt);
bool mptcp_subflow_data_available(struct sock *sk);
void __init mptcp_subflow_init(void);
+void mptcp_subflow_reset(struct sock *ssk);
+ void mptcp_subflow_shutdown(struct sock *sk, struct sock *ssk, int how);
+ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
+ struct mptcp_subflow_context *subflow,
+ long timeout);
/* called with sk socket lock held */
- int __mptcp_subflow_connect(struct sock *sk, int ifindex,
- const struct mptcp_addr_info *loc,
+ int __mptcp_subflow_connect(struct sock *sk, const struct mptcp_addr_info
*loc,
const struct mptcp_addr_info *remote);
int mptcp_subflow_create_socket(struct sock *sk, struct socket **new_sock);
pgp6LfMOus4Tf.pgp
Description: OpenPGP digital signature
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:
net/rxrpc/conn_event.c
between commit:
fa1d113a0f96 ("rxrpc: Fix some missing _bh annotations on locking
conn->state_lock")
from the net tree and commit:
245500d853e9 ("rxrpc: Rewrite the client connection manager")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/rxrpc/conn_event.c
index 64ace2960ecc,0628dad2bdea..
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@@ -339,8 -341,8 +341,8 @@@ static int rxrpc_process_event(struct r
if (ret < 0)
return ret;
- spin_lock(>channel_lock);
+ spin_lock(>bundle->channel_lock);
- spin_lock(>state_lock);
+ spin_lock_bh(>state_lock);
if (conn->state == RXRPC_CONN_SERVICE_CHALLENGING) {
conn->state = RXRPC_CONN_SERVICE;
@@@ -349,12 -351,12 +351,12 @@@
rxrpc_call_is_secure(
rcu_dereference_protected(
conn->channels[loop].call,
-
lockdep_is_held(>channel_lock)));
+
lockdep_is_held(>bundle->channel_lock)));
} else {
- spin_unlock(>state_lock);
+ spin_unlock_bh(>state_lock);
}
- spin_unlock(>channel_lock);
+ spin_unlock(>bundle->channel_lock);
return 0;
default:
pgpM5KUC70v1H.pgp
Description: OpenPGP digital signature
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
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:
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
---
Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index e13653051b23..244befb6402a 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -31,6 +31,7 @@ properties:
- renesas,etheravb-r8a774a1 # RZ/G2M
- renesas,etheravb-r8a774b1 # RZ/G2N
- renesas,etheravb-r8a774c0 # RZ/G2E
+ - renesas,etheravb-r8a774e1 # RZ/G2H
- renesas,etheravb-r8a7795 # R-Car H3
- renesas,etheravb-r8a7796 # R-Car M3-W
- renesas,etheravb-r8a77961 # R-Car M3-W+
--
2.28.0
--
Cheers,
Stephen Rothwell
pgpPrsixnGiQ6.pgp
Description: OpenPGP digital signature
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, , ))
+ return false;
+
+ pr_debug("colesced seq %llx into %llx new len %d new end seq %llx",
+MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
+to->len, MPTCP_SKB_CB(from)->end_seq);
+ MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
+ kfree_skb_partial(from, fragstolen);
+ atomic_add(delta, >sk_rmem_alloc);
+ sk_mem_charge(sk, delta);
+ return true;
+ }
+
+ static bool mptcp_ooo_try_coalesce(struct mptcp_sock *msk, struct sk_buff *to,
+ struct sk_buff *from)
+ {
+ if (MPTCP_SKB_CB(from)->map_seq != MPTCP_SKB_CB(to)->end_seq)
+ return false;
+
+ return mptcp_try_coalesce((struct sock *)msk, to, from);
+ }
+
+ /* "inspired" by tcp_data_queue_ofo(), main differences:
+ * - use mptcp seqs
+ * - don't cope with sacks
+ */
+ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
{
struct sock *sk = (struct sock *)msk;
- struct sk_buff *tail;
+ struct rb_node **p, *parent;
+ u64 seq, end_seq, max_seq;
+ struct sk_buff *skb1;
+ int space;
+
+ seq = MPTCP_SKB_CB(skb)->map_seq;
+ end_seq = MPTCP_SKB_CB(skb)->end_seq;
+ space = tcp_space(sk);
+ max_seq = space > 0 ? space + msk->ack_seq : msk->ack_seq;
+
+ pr_debug("msk=%p seq=%llx limit=%llx empty=%d", msk, seq, max_seq,
+RB_EMPTY_ROOT(>out_of_order_queue));
+ if (after64(seq, max_seq)) {
+ /* out of window */
+ mptcp_drop(sk, skb);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_NODSSWINDOW);
+ return;
+ }
- __skb_unlink(skb, >sk_receive_queue);
+ p = >out_of_order_queue.rb_node;
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
+ if (RB_EMPTY_ROOT(>out_of_order_queue)) {
+ rb_link_node(>rbnode, NULL, p);
+ rb_insert_color(>rbnode, >out_of_order_queue);
+ msk->ooo_last_skb = skb;
+ goto end;
+ }
- skb_ext_reset(skb);
- skb_orphan(skb);
- WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+ /* with 2 subflows, adding at end of ooo queue is quite likely
+* Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
+*/
+ if (mptcp_ooo_try_coalesce(msk, msk->ooo_last_skb, skb)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ return;
+ }
- tail = skb_peek_tail(>sk_receive_queue);
- if (offset == 0 && tail) {
- bool fragstolen;
- int delta;
+ /* Can avoid an rbtree lookup if we are adding skb after ooo_last_skb */
+ if (!before64(seq, MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ parent = >ooo_last_skb->rbnode;
+ p = >rb_right;
+ goto insert;
+ }
-
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:
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);
void __init mptcp_token_init(void);
static inline void mptcp_token_init_request(struct request_sock *req)
pgpYIEB09j2Gq.pgp
Description: OpenPGP digital signature
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:
net/mptcp/protocol.c
between commit:
917944da3bfc ("mptcp: Consistently use READ_ONCE/WRITE_ONCE with
msk->ack_seq")
from the net tree and commit:
8268ed4c9d19 ("mptcp: introduce and use mptcp_try_coalesce()")
ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/mptcp/protocol.c
index 5d747c6a610e,34c037731f35..
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@@ -112,64 -112,205 +112,205 @@@ static int __mptcp_socket_create(struc
return 0;
}
- static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
-struct sk_buff *skb,
-unsigned int offset, size_t copy_len)
+ static void mptcp_drop(struct sock *sk, struct sk_buff *skb)
+ {
+ sk_drops_add(sk, skb);
+ __kfree_skb(skb);
+ }
+
+ static bool mptcp_try_coalesce(struct sock *sk, struct sk_buff *to,
+ struct sk_buff *from)
+ {
+ bool fragstolen;
+ int delta;
+
+ if (MPTCP_SKB_CB(from)->offset ||
+ !skb_try_coalesce(to, from, , ))
+ return false;
+
+ pr_debug("colesced seq %llx into %llx new len %d new end seq %llx",
+MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
+to->len, MPTCP_SKB_CB(from)->end_seq);
+ MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
+ kfree_skb_partial(from, fragstolen);
+ atomic_add(delta, >sk_rmem_alloc);
+ sk_mem_charge(sk, delta);
+ return true;
+ }
+
+ static bool mptcp_ooo_try_coalesce(struct mptcp_sock *msk, struct sk_buff *to,
+ struct sk_buff *from)
+ {
+ if (MPTCP_SKB_CB(from)->map_seq != MPTCP_SKB_CB(to)->end_seq)
+ return false;
+
+ return mptcp_try_coalesce((struct sock *)msk, to, from);
+ }
+
+ /* "inspired" by tcp_data_queue_ofo(), main differences:
+ * - use mptcp seqs
+ * - don't cope with sacks
+ */
+ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
{
struct sock *sk = (struct sock *)msk;
- struct sk_buff *tail;
+ struct rb_node **p, *parent;
+ u64 seq, end_seq, max_seq;
+ struct sk_buff *skb1;
+ int space;
+
+ seq = MPTCP_SKB_CB(skb)->map_seq;
+ end_seq = MPTCP_SKB_CB(skb)->end_seq;
+ space = tcp_space(sk);
+ max_seq = space > 0 ? space + msk->ack_seq : msk->ack_seq;
+
+ pr_debug("msk=%p seq=%llx limit=%llx empty=%d", msk, seq, max_seq,
+RB_EMPTY_ROOT(>out_of_order_queue));
+ if (after64(seq, max_seq)) {
+ /* out of window */
+ mptcp_drop(sk, skb);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_NODSSWINDOW);
+ return;
+ }
- __skb_unlink(skb, >sk_receive_queue);
+ p = >out_of_order_queue.rb_node;
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE);
+ if (RB_EMPTY_ROOT(>out_of_order_queue)) {
+ rb_link_node(>rbnode, NULL, p);
+ rb_insert_color(>rbnode, >out_of_order_queue);
+ msk->ooo_last_skb = skb;
+ goto end;
+ }
- skb_ext_reset(skb);
- skb_orphan(skb);
- WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+ /* with 2 subflows, adding at end of ooo queue is quite likely
+* Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
+*/
+ if (mptcp_ooo_try_coalesce(msk, msk->ooo_last_skb, skb)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOMERGE);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ return;
+ }
- tail = skb_peek_tail(>sk_receive_queue);
- if (offset == 0 && tail) {
- bool fragstolen;
- int delta;
+ /* Can avoid an rbtree lookup if we are adding skb after ooo_last_skb */
+ if (!before64(seq, MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUETAIL);
+ parent = >ooo_last_skb->rbnode;
+ p = >rb_right;
+ goto insert;
+ }
- if (skb_try_coalesce(tail, skb, , )) {
- kfree_skb_partial(skb, fragstolen);
- atomic_add(delta, >sk_rmem_alloc);
- sk_mem_charge(sk, delta);
+ /* Find place to insert this segment. Handle overlaps on the way. */
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/phy/realtek.c
between commit:
bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
from the net tree and commit:
66e22932eb79 ("net: phy: realtek: enable ALDPS to save power for RTL8211F")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/phy/realtek.c
index 0f0960971800,4bf54cded48a..
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@@ -31,9 -33,13 +32,13 @@@
#define RTL8211F_TX_DELAY BIT(8)
#define RTL8211F_RX_DELAY BIT(3)
+ #define RTL8211F_ALDPS_PLL_OFFBIT(1)
+ #define RTL8211F_ALDPS_ENABLE BIT(2)
+ #define RTL8211F_ALDPS_XTAL_OFF BIT(12)
+
-#define RTL8211E_TX_DELAY BIT(1)
-#define RTL8211E_RX_DELAY BIT(2)
-#define RTL8211E_MODE_MII_GMIIBIT(3)
+#define RTL8211E_CTRL_DELAY BIT(13)
+#define RTL8211E_TX_DELAY BIT(12)
+#define RTL8211E_RX_DELAY BIT(11)
#define RTL8201F_ISR 0x1e
#define RTL8201F_IER 0x13
pgpH6ULAnInqQ.pgp
Description: OpenPGP digital signature
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
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/phy/Kconfig
between commit:
7dbbcf496f2a ("mdio: fix mdio-thunder.c dependency & build error")
from the net tree and commit:
a9770eac511a ("net: mdio: Move MDIO drivers into a new subdirectory")
from the net-next tree.
I fixed it up (I used the latter and applied the following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
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
--
Cheers,
Stephen Rothwell
pgph11VSuqeez.pgp
Description: OpenPGP digital signature
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:
net/ipv4/route.c
between commit:
2fbc6e89b2f1 ("ipv4: Update exception handling for multipath routes via same
device")
from the net tree and commit:
8b4510d76cde ("net: gain ipv4 mtu when mtu is not locked")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/route.c
index 58642b29a499,2c05b863ae43..
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@@ -1015,10 -1013,9 +1015,10 @@@ out: kfree_skb(skb)
static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32
mtu)
{
struct dst_entry *dst = >dst;
+ struct net *net = dev_net(dst->dev);
- u32 old_mtu = ipv4_mtu(dst);
struct fib_result res;
bool lock = false;
+ u32 old_mtu;
if (ip_mtu_locked(dst))
return;
pgpZojHF_yccX.pgp
Description: OpenPGP digital signature
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 &= ~PORT_RGMII_ID_IG_ENABLE;
> data8 &= ~PORT_RGMII_ID_EG_ENABLE;
> - if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> - dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
> + if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
> data8 |= PORT_RGMII_ID_IG_ENABLE;
> - if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> - dev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
> + if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
> data8 |= PORT_RGMII_ID_EG_ENABLE;
> + /* On KSZ9893, disable RGMII in-band status support */
> + if (dev->features & IS_9893)
> + data8 &= ~PORT_MII_MAC_MODE;
> p->phydev.speed = SPEED_1000;
> break;
> }
> @@@ -1276,22 -1280,21 +1281,30 @@@ static void ksz9477_config_cpu_port(str
> * note the difference to help debugging.
> */
> interface = ksz9477_get_interface(dev, i);
> - if (!dev->interface)
> - dev->interface = interface;
> - if (interface && interface != dev->interface) {
> + if (!p->interface) {
> + if (dev->compat_interface) {
> + dev_warn(dev->dev,
> + "Using legacy switch
> \"phy-mode\" property, because it is missing on port %d node. "
> + "Please update your device
> tree.\n",
> + i);
> + p->interface = dev->compat_interface;
> + } else {
> + p->interface = interface;
> + }
> + }
> - if (interface && interface != p->interface)
> - dev_info(dev->dev,
> -"use %s instead of %s\n",
> - phy_modes(p->interface),
> - phy_modes(interface));
> ++ if (interface && interface != p->interface) {
> + prev_msg = " instead of ";
> + prev_mode = phy_modes(interface);
> + } else {
> + prev_msg = "";
> + prev_mode = "";
> + }
> + dev_info(dev->dev,
> +"Port%d: using phy mode %s%s%s\n",
> +i,
> - phy_modes(dev->interface),
> ++ phy_modes(p->interface),
> +prev_msg,
> +prev_mode);
>
> /* enable cpu port */
> ksz9477_port_setup(dev, i, true);
Looks good to me wrt my patch "net: dsa: microchip: Improve phy mode message".
Thanks,
--
Paul Barker
Konsulko Group
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/dsa/microchip/ksz9477.c
between commit:
edecfa98f602 ("net: dsa: microchip: look for phy-mode in port nodes")
from the net tree and commit:
805a7e6f5388 ("net: dsa: microchip: Improve phy mode message")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/dsa/microchip/ksz9477.c
index 2f5506ac7d19,b62dd64470a8..
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@@ -1229,12 -1229,15 +1229,15 @@@ static void ksz9477_port_setup(struct k
ksz9477_set_gbit(dev, true, );
data8 &= ~PORT_RGMII_ID_IG_ENABLE;
data8 &= ~PORT_RGMII_ID_EG_ENABLE;
- if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
data8 |= PORT_RGMII_ID_IG_ENABLE;
- if (dev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- dev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
data8 |= PORT_RGMII_ID_EG_ENABLE;
+ /* On KSZ9893, disable RGMII in-band status support */
+ if (dev->features & IS_9893)
+ data8 &= ~PORT_MII_MAC_MODE;
p->phydev.speed = SPEED_1000;
break;
}
@@@ -1276,22 -1280,21 +1281,30 @@@ static void ksz9477_config_cpu_port(str
* note the difference to help debugging.
*/
interface = ksz9477_get_interface(dev, i);
- if (!dev->interface)
- dev->interface = interface;
- if (interface && interface != dev->interface) {
+ if (!p->interface) {
+ if (dev->compat_interface) {
+ dev_warn(dev->dev,
+ "Using legacy switch
\"phy-mode\" property, because it is missing on port %d node. "
+ "Please update your device
tree.\n",
+ i);
+ p->interface = dev->compat_interface;
+ } else {
+ p->interface = interface;
+ }
+ }
- if (interface && interface != p->interface)
- dev_info(dev->dev,
-"use %s instead of %s\n",
- phy_modes(p->interface),
- phy_modes(interface));
++ if (interface && interface != p->interface) {
+ prev_msg = " instead of ";
+ prev_mode = phy_modes(interface);
+ } else {
+ prev_msg = "";
+ prev_mode = "";
+ }
+ dev_info(dev->dev,
+"Port%d: using phy mode %s%s%s\n",
+i,
- phy_modes(dev->interface),
++ phy_modes(p->interface),
+prev_msg,
+prev_mode);
/* enable cpu port */
ksz9477_port_setup(dev, i, true);
pgpf3BNcnmN6v.pgp
Description: OpenPGP digital signature
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:
net/ipv4/raw.c
between commit:
645f08975f49 ("net: Fix some comments")
from the net tree and commit:
2bdcc73c88d2 ("net: ipv4: delete repeated words")
from the net-next tree.
I fixed it up (they each removed a different "and" - I kept the latter)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpZ_MeMOGXBc.pgp
Description: OpenPGP digital signature
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/ibm/ibmvnic.c
between commit:
9f1345737790 ("ibmvnic fix NULL tx_pools and rx_tools issue at do_reset")
from the net tree and commit:
507ebe6444a4 ("ibmvnic: Fix use-after-free of VNIC login response buffer")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index d3a774331afc,86a83e53dce5..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -475,17 -467,12 +467,15 @@@ static int init_stats_token(struct ibmv
static int reset_rx_pools(struct ibmvnic_adapter *adapter)
{
struct ibmvnic_rx_pool *rx_pool;
+ u64 buff_size;
int rx_scrqs;
int i, j, rc;
- u64 *size_array;
+ if (!adapter->rx_pool)
+ return -1;
+
- size_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
- be32_to_cpu(adapter->login_rsp_buf->off_rxadd_buff_size));
-
- rx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_rxadd_subcrqs);
+ buff_size = adapter->cur_rx_buf_sz;
+ rx_scrqs = adapter->num_active_rx_pools;
for (i = 0; i < rx_scrqs; i++) {
rx_pool = >rx_pool[i];
@@@ -652,10 -637,7 +640,10 @@@ static int reset_tx_pools(struct ibmvni
int tx_scrqs;
int i, rc;
+ if (!adapter->tx_pool)
+ return -1;
+
- tx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_txsubm_subcrqs);
+ tx_scrqs = adapter->num_active_tx_pools;
for (i = 0; i < tx_scrqs; i++) {
rc = reset_one_tx_pool(adapter, >tso_pool[i]);
if (rc)
pgpOn07Hll0jN.pgp
Description: OpenPGP digital signature
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
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/geneve.c
between commit:
32818c075c54 ("geneve: fix an uninitialized value in geneve_changelink()")
from the net tree and commit:
9e06e8596bc8 ("geneve: move all configuration under struct geneve_config")
from the net-next tree.
I fixed it up (the latter removed the code moved by the former) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpOS1GnCZIik.pgp
Description: OpenPGP digital signature
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.
--
Cheers,
Stephen Rothwell
pgpGaO2F3xwqO.pgp
Description: OpenPGP digital signature
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/netdevsim/netdev.c
between commit:
2c9d8e01f0c6 ("netdevsim: fix unbalaced locking in nsim_create()")
from the net tree and commit:
424be63ad831 ("netdevsim: add UDP tunnel port offload support")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/netdevsim/netdev.c
index 23950e7a0f81,9d0d18026434..
--- a/drivers/net/netdevsim/netdev.c
+++ b/drivers/net/netdevsim/netdev.c
@@@ -316,8 -323,10 +323,10 @@@ nsim_create(struct nsim_dev *nsim_dev,
err_ipsec_teardown:
nsim_ipsec_teardown(ns);
nsim_bpf_uninit(ns);
+err_rtnl_unlock:
rtnl_unlock();
-err_utn_destroy:
+ nsim_udp_tunnels_info_destroy(dev);
+ err_free_netdev:
free_netdev(dev);
return ERR_PTR(err);
}
pgpu4yrTfh2iB.pgp
Description: OpenPGP digital signature
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/aquantia/atlantic/aq_hw.h
between commit:
23e500e88723 ("net: atlantic: disable PTP on AQC111, AQC112")
from the net tree and commit:
1e41b3fee795 ("net: atlantic: add support for 64-bit reads/writes")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_hw.h
index 992fedbe4ce3,95ee1336ac79..
--- a/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_hw.h
@@@ -64,7 -67,7 +67,8 @@@ struct aq_hw_caps_s
u8 rx_rings;
bool flow_control;
bool is_64_dma;
+ bool op64bit;
+ u32 quirks;
u32 priv_data_len;
};
pgpbEBUJvAaA_.pgp
Description: OpenPGP digital signature
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:
net/xfrm/xfrm_device.c
between commit:
94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion in IPsec crypto
offload.")
from the net tree and commit:
272c2330adc9 ("xfrm: bail early on slave pass over skb")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/xfrm/xfrm_device.c
index 626096bd0d29,b8918fc5248b..
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@@ -106,9 -106,10 +106,10 @@@ struct sk_buff *validate_xmit_xfrm(stru
struct sk_buff *skb2, *nskb, *pskb = NULL;
netdev_features_t esp_features = features;
struct xfrm_offload *xo = xfrm_offload(skb);
+ struct net_device *dev = skb->dev;
struct sec_path *sp;
- if (!xo)
+ if (!xo || (xo->flags & XFRM_XMIT))
return skb;
if (!(features & NETIF_F_HW_ESP))
@@@ -129,27 -134,20 +134,22 @@@
return skb;
}
+ xo->flags |= XFRM_XMIT;
+
- if (skb_is_gso(skb)) {
- struct net_device *dev = skb->dev;
-
- if (unlikely(x->xso.dev != dev)) {
- struct sk_buff *segs;
+ if (skb_is_gso(skb) && unlikely(x->xso.dev != dev)) {
+ struct sk_buff *segs;
- /* Packet got rerouted, fixup features and segment it.
*/
- esp_features = esp_features & ~(NETIF_F_HW_ESP
- | NETIF_F_GSO_ESP);
+ /* Packet got rerouted, fixup features and segment it. */
+ esp_features = esp_features & ~(NETIF_F_HW_ESP |
NETIF_F_GSO_ESP);
- segs = skb_gso_segment(skb, esp_features);
- if (IS_ERR(segs)) {
- kfree_skb(skb);
- atomic_long_inc(>tx_dropped);
- return NULL;
- } else {
- consume_skb(skb);
- skb = segs;
- }
+ segs = skb_gso_segment(skb, esp_features);
+ if (IS_ERR(segs)) {
+ kfree_skb(skb);
+ atomic_long_inc(>tx_dropped);
+ return NULL;
+ } else {
+ consume_skb(skb);
+ skb = segs;
}
}
pgp71AZVsEuZC.pgp
Description: OpenPGP digital signature
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).
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 conflicts in:
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
drivers/net/ethernet/huawei/hinic/hinic_main.c
between commit:
e8a1b0efd632 ("hinic: fix a bug of ndo_stop")
from the net tree and commit:
7dd29ee12865 ("hinic: add sriov feature support")
from the net-next tree.
I fixed it up (I think, see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
index 992908e6eebf,eef855f11a01..
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
@@@ -358,12 -353,13 +358,16 @@@ int hinic_msg_to_mgmt(struct hinic_pf_t
return -EINVAL;
}
+ if (cmd == HINIC_PORT_CMD_SET_FUNC_STATE)
+ timeout = SET_FUNC_PORT_MGMT_TIMEOUT;
+
- return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
+ if (HINIC_IS_VF(hwif))
+ return hinic_mbox_to_pf(pf_to_mgmt->hwdev, mod, cmd, buf_in,
+ in_size, buf_out, out_size, 0);
+ else
+ return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
buf_out, out_size, MGMT_DIRECT_SEND,
- MSG_NOT_RESP);
+ MSG_NOT_RESP, timeout);
}
/**
diff --cc drivers/net/ethernet/huawei/hinic/hinic_main.c
index 63b92f6cc856,3d6569d7bac8..
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@@ -496,9 -501,23 +500,12 @@@ static int hinic_close(struct net_devic
up(_dev->mgmt_lock);
+ if (!HINIC_IS_VF(nic_dev->hwdev->hwif))
+ hinic_notify_all_vfs_link_changed(nic_dev->hwdev, 0);
+
- err = hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
- if (err) {
- netif_err(nic_dev, drv, netdev,
-"Failed to set func port state\n");
- nic_dev->flags |= (flags & HINIC_INTF_UP);
- return err;
- }
+ hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
- err = hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
- if (err) {
- netif_err(nic_dev, drv, netdev, "Failed to set port state\n");
- nic_dev->flags |= (flags & HINIC_INTF_UP);
- return err;
- }
+ hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
if (nic_dev->flags & HINIC_RSS_ENABLE) {
hinic_rss_deinit(nic_dev);
pgpLA0jUHIjqH.pgp
Description: OpenPGP digital signature
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
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/mellanox/mlx5/core/steering/dr_send.c
between commit:
8075411d93b6 ("net/mlx5: DR, On creation set CQ's arm_db member to right
value")
from the net tree and commit:
73a75b96fc9a ("net/mlx5: Remove empty QP and CQ events handlers")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
index 18719acb7e54,c4ed25bb9ac8..
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
@@@ -689,18 -693,6 +693,12 @@@ static int dr_prepare_qp_to_rts(struct
return 0;
}
- static void dr_cq_event(struct mlx5_core_cq *mcq,
- enum mlx5_event event)
- {
- pr_info("CQ event %u on CQ #%u\n", event, mcq->cqn);
- }
-
+static void dr_cq_complete(struct mlx5_core_cq *mcq,
+ struct mlx5_eqe *eqe)
+{
+ pr_err("CQ completion CQ: #%u\n", mcq->cqn);
+}
+
static struct mlx5dr_cq *dr_create_cq(struct mlx5_core_dev *mdev,
struct mlx5_uars_page *uar,
size_t ncqe)
@@@ -761,9 -753,6 +759,8 @@@
pas = (__be64 *)MLX5_ADDR_OF(create_cq_in, in, pas);
mlx5_fill_page_frag_array(>wq_ctrl.buf, pas);
- cq->mcq.event = dr_cq_event;
+ cq->mcq.comp = dr_cq_complete;
+
err = mlx5_core_create_cq(mdev, >mcq, in, inlen, out, sizeof(out));
kvfree(in);
pgpiirFWSlynZ.pgp
Description: OpenPGP digital signature
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:
include/net/mptcp.h
between commit:
cfde141ea3fa ("mptcp: move option parsing into mptcp_incoming_options()")
from the net tree and commit:
071c8ed6e88d ("tcp: mptcp: use mptcp receive buffer space to select rcv
window")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/net/mptcp.h
index 3bce2019e4da,5288fba56e55..
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@@ -68,8 -68,13 +68,10 @@@ static inline bool rsk_is_mptcp(const s
return tcp_rsk(req)->is_mptcp;
}
+ void mptcp_space(const struct sock *ssk, int *space, int *full_space);
+
-void mptcp_parse_option(const struct sk_buff *skb, const unsigned char *ptr,
- int opsize, struct tcp_options_received *opt_rx);
bool mptcp_syn_options(struct sock *sk, const struct sk_buff *skb,
unsigned int *size, struct mptcp_out_options *opts);
-void mptcp_rcv_synsent(struct sock *sk);
bool mptcp_synack_options(const struct request_sock *req, unsigned int *size,
struct mptcp_out_options *opts);
bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
pgpoAENNkOI1v.pgp
Description: OpenPGP digital signature
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/netdevsim/fib.c
between commit:
33902b4a4227 ("netdevsim: Fix error handling in nsim_fib_init and
nsim_fib_exit")
from the net tree and commit:
a5facc4cac4d ("netdevsim: change fib accounting and limitations to be
per-device")
from the net-next tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp8FDPi8JL_K.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
On Fri, 2019-09-13 at 02:25 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
>
> between commit:
>
> 5c129241e2de ("ixgbe: add support for AF_XDP need_wakeup feature")
>
> from the net tree and commit:
>
> bf280c0387eb ("ixgbe: fix double clean of Tx descriptors with xdp")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
>
Acked-by: Jeff Kirsher
On how you fixed up the conflict.
signature.asc
Description: This is a digitally signed message part
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/intel/ixgbe/ixgbe_xsk.c
between commit:
5c129241e2de ("ixgbe: add support for AF_XDP need_wakeup feature")
from the net tree and commit:
bf280c0387eb ("ixgbe: fix double clean of Tx descriptors with xdp")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index a3b6d8c89127,ad802a8909e0..
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@@ -682,10 -697,19 +691,17 @@@ bool ixgbe_clean_xdp_tx_irq(struct ixgb
if (xsk_frames)
xsk_umem_complete_tx(umem, xsk_frames);
+ if (xsk_umem_uses_need_wakeup(tx_ring->xsk_umem)) {
+ if (tx_ring->next_to_clean == tx_ring->next_to_use)
+ xsk_set_tx_need_wakeup(tx_ring->xsk_umem);
+ else
+ xsk_clear_tx_need_wakeup(tx_ring->xsk_umem);
+ }
+
- xmit_done = ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
-
- return budget > 0 && xmit_done;
+ return ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
}
- int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
+ int ixgbe_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags)
{
struct ixgbe_adapter *adapter = netdev_priv(dev);
struct ixgbe_ring *ring;
pgp0Z18FWEGPS.pgp
Description: OpenPGP digital signature
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/bluetooth/btusb.c
between commit:
1ffdb51f28e8 ("Revert "Bluetooth: btusb: driver to enable the usb-wakeup
feature"")
from the net tree and commit:
9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/bluetooth/btusb.c
index ba4149054304,ed455de598ea..
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@@ -1173,7 -1201,18 +1204,14 @@@ static int btusb_open(struct hci_dev *h
}
data->intf->needs_remote_wakeup = 1;
- /* device specific wakeup source enabled and required for USB
- * remote wakeup while host is suspended
- */
- device_wakeup_enable(>udev->dev);
+ /* Disable device remote wakeup when host is suspended
+* For Realtek chips, global suspend without
+* SET_FEATURE (DEVICE_REMOTE_WAKEUP) can save more power in device.
+*/
+ if (test_bit(BTUSB_WAKEUP_DISABLE, >flags))
+ device_wakeup_disable(>udev->dev);
+
if (test_and_set_bit(BTUSB_INTR_RUNNING, >flags))
goto done;
@@@ -1237,6 -1276,12 +1275,11 @@@ static int btusb_close(struct hci_dev *
goto failed;
data->intf->needs_remote_wakeup = 0;
+
+ /* Enable remote wake up for auto-suspend */
+ if (test_bit(BTUSB_WAKEUP_DISABLE, >flags))
+ data->intf->needs_remote_wakeup = 1;
+
- device_wakeup_disable(>udev->dev);
usb_autopm_put_interface(data->intf);
failed:
pgpsWwDtCAVdQ.pgp
Description: OpenPGP digital signature
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/usb/r8152.c
between commits:
49d4b14113ca ("Revert "r8152: napi hangup fix after disconnect"")
973dc6cfc0e2 ("r8152: remove calling netif_napi_del")
from the net tree and commit:
d2187f8e4454 ("r8152: divide the tx and rx bottom functions")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/usb/r8152.c
index 04137ac373b0,c6fa0c17c13d..
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -4021,7 -4214,9 +4214,8 @@@ static int rtl8152_close(struct net_dev
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(>pm_notifier);
#endif
+ tasklet_disable(>tx_tl);
- if (!test_bit(RTL8152_UNPLUG, >flags))
- napi_disable(>napi);
+ napi_disable(>napi);
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(>schedule);
@@@ -5352,6 -5604,8 +5603,7 @@@ static int rtl8152_probe(struct usb_int
return 0;
out1:
- netif_napi_del(>napi);
+ tasklet_kill(>tx_tl);
usb_set_intfdata(intf, NULL);
out:
free_netdev(netdev);
@@@ -5366,7 -5620,9 +5618,8 @@@ static void rtl8152_disconnect(struct u
if (tp) {
rtl_set_unplug(tp);
- netif_napi_del(>napi);
unregister_netdev(tp->netdev);
+ tasklet_kill(>tx_tl);
cancel_delayed_work_sync(>hw_phy_work);
tp->rtl_ops.unload(tp);
free_netdev(tp->netdev);
pgpwHbitcc0w0.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
On 26.08.2019 04:27, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/realtek/r8169_main.c
>
> between commit:
>
> 345b93265b3a ("Revert "r8169: remove not needed call to
> dma_sync_single_for_device"")
>
> from the net tree and commit:
>
> fcd4e60885af ("r8169: improve rtl_rx")
> d4ed7463d02a ("r8169: fix DMA issue on MIPS platform")
>
> from the net-next tree.
>
> I fixed it up (the latter seems to do the same as the net tree patch) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
Due to other changes there have been two versions of the fix, one for net
and one for net-next. Therefore ignoring the one from net when merging into
net-next was correct. Thanks!
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/realtek/r8169_main.c
between commit:
345b93265b3a ("Revert "r8169: remove not needed call to
dma_sync_single_for_device"")
from the net tree and commit:
fcd4e60885af ("r8169: improve rtl_rx")
d4ed7463d02a ("r8169: fix DMA issue on MIPS platform")
from the net-next tree.
I fixed it up (the latter seems to do the same as the net tree patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpd3kgzHInBx.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/en_tc.c
between commit:
93b3586e070b ("net/mlx5: Support inner header match criteria for non decap
flow action")
from the net tree and commit:
226f2ca3075a ("net/mlx5e: Change flow flags type to unsigned long")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index deeb65da99f3,5be3da621499..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1839,18 -2057,15 +2061,20 @@@ static int parse_cls_flower(struct mlx5
struct mlx5_core_dev *dev = priv->mdev;
struct mlx5_eswitch *esw = dev->priv.eswitch;
struct mlx5e_rep_priv *rpriv = priv->ppriv;
- u8 match_level, tunnel_match_level = MLX5_MATCH_NONE;
struct mlx5_eswitch_rep *rep;
+ bool is_eswitch_flow;
int err;
- err = __parse_cls_flower(priv, spec, f, filter_dev, _level,
_match_level);
+ inner_match_level = MLX5_MATCH_NONE;
+ outer_match_level = MLX5_MATCH_NONE;
+
+ err = __parse_cls_flower(priv, spec, f, filter_dev, _match_level,
+ _match_level);
+ non_tunnel_match_level = (inner_match_level == MLX5_MATCH_NONE) ?
+ outer_match_level : inner_match_level;
- if (!err && (flow->flags & MLX5E_TC_FLOW_ESWITCH)) {
+ is_eswitch_flow = mlx5e_is_eswitch_flow(flow);
+ if (!err && is_eswitch_flow) {
rep = rpriv->rep;
if (rep->vport != MLX5_VPORT_UPLINK &&
(esw->offloads.inline_mode != MLX5_INLINE_MODE_NONE &&
@@@ -1864,11 -2079,11 +2088,11 @@@
}
}
- if (flow->flags & MLX5E_TC_FLOW_ESWITCH) {
+ if (is_eswitch_flow) {
- flow->esw_attr->match_level = match_level;
- flow->esw_attr->tunnel_match_level = tunnel_match_level;
+ flow->esw_attr->inner_match_level = inner_match_level;
+ flow->esw_attr->outer_match_level = outer_match_level;
} else {
- flow->nic_attr->match_level = match_level;
+ flow->nic_attr->match_level = non_tunnel_match_level;
}
return err;
pgpF_BWLRI86L.pgp
Description: OpenPGP digital signature
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/can/flexcan.c
between commit:
e9f2a856e102 ("can: flexcan: fix an use-after-free in
flexcan_setup_stop_mode()")
from the net tree and commit:
915f9666421c ("can: flexcan: add support for DT property 'wakeup-source'")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/can/flexcan.c
index fcec8bcb53d6,09d8e623dcf6..
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -1473,9 -1473,10 +1491,12 @@@ static int flexcan_setup_stop_mode(stru
device_set_wakeup_capable(>dev, true);
+ if (of_property_read_bool(np, "wakeup-source"))
+ device_set_wakeup_enable(>dev, true);
+
- return 0;
+out_put_node:
+ of_node_put(gpr_np);
+ return ret;
}
static const struct of_device_id flexcan_of_match[] = {
pgpQwVD5iCsAr.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell Date: Tue, 9 Jul 2019 10:27:28 +1000 > I am still getting this conflict (the commit ids may have changed). > Just a reminder in case you think Linus may need to know. I'm resolving this right now, thanks Stephen.
Re: linux-next: manual merge of the net-next tree with the net tree
Hi all,
On Tue, 2 Jul 2019 12:13:57 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/ipv4/devinet.c
>
> between commit:
>
> 2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")
>
> from the net tree and commit:
>
> 2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc net/ipv4/devinet.c
> index c5ebfa199794,137d1892395d..
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
> ifa->ifa_flags &= ~IFA_F_SECONDARY;
> last_primary = _dev->ifa_list;
>
> +/* Don't set IPv6 only flags to IPv4 addresses */
> +ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
> +
> - for (ifap = _dev->ifa_list; (ifa1 = *ifap) != NULL;
> - ifap = >ifa_next) {
> + ifap = _dev->ifa_list;
> + ifa1 = rtnl_dereference(*ifap);
> +
> + while (ifa1) {
> if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
> ifa->ifa_scope <= ifa1->ifa_scope)
> last_primary = >ifa_next;
I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.
--
Cheers,
Stephen Rothwell
pgp8lRiYeHTZF.pgp
Description: OpenPGP digital signature
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:
tools/testing/selftests/net/config
between commit:
ff95bf28c234 ("selftests/net: skip psock_tpacket test if KALLSYMS was not
enabled")
from the net tree and commit:
af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
509e56b37cc3 ("blackhole_dev: add a selftest")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/config
index 3dea2cba2325,e4b878d95ba0..
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@@ -25,4 -25,6 +25,7 @@@ CONFIG_NF_TABLES_IPV6=
CONFIG_NF_TABLES_IPV4=y
CONFIG_NFT_CHAIN_NAT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
+CONFIG_KALLSYMS=y
+ CONFIG_NET_SCH_FQ=m
+ CONFIG_NET_SCH_ETF=m
+ CONFIG_TEST_BLACKHOLE_DEV=m
pgpDArhwaPWli.pgp
Description: OpenPGP digital signature
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:
net/ipv4/devinet.c
between commit:
2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")
from the net tree and commit:
2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/devinet.c
index c5ebfa199794,137d1892395d..
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
ifa->ifa_flags &= ~IFA_F_SECONDARY;
last_primary = _dev->ifa_list;
+ /* Don't set IPv6 only flags to IPv4 addresses */
+ ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
+
- for (ifap = _dev->ifa_list; (ifa1 = *ifap) != NULL;
-ifap = >ifa_next) {
+ ifap = _dev->ifa_list;
+ ifa1 = rtnl_dereference(*ifap);
+
+ while (ifa1) {
if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
ifa->ifa_scope <= ifa1->ifa_scope)
last_primary = >ifa_next;
pgp6nIWQCfDsJ.pgp
Description: OpenPGP digital signature
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 conflicts in:
drivers/net/ethernet/aquantia/atlantic/aq_nic.c
drivers/net/ethernet/aquantia/atlantic/aq_nic.h
between commit:
48dd73d08d4d ("net: aquantia: fix vlans not working over bridged network")
from the net tree and commit:
d3ed7c5cf79b ("net: aquantia: adding fields and device features for vlan
offload")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 41172fbebddd,746f85e6de13..
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@@ -126,7 -126,8 +126,9 @@@ void aq_nic_cfg_start(struct aq_nic_s *
cfg->link_speed_msk &= cfg->aq_hw_caps->link_speed_msk;
cfg->features = cfg->aq_hw_caps->hw_features;
+ cfg->is_vlan_force_promisc = true;
+ cfg->is_vlan_rx_strip = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_RX);
+ cfg->is_vlan_tx_insert = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_TX);
}
static int aq_nic_update_link_status(struct aq_nic_s *self)
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_nic.h
index 0f22f5d5691b,26c72f298684..
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
@@@ -35,7 -35,8 +35,9 @@@ struct aq_nic_cfg_s
u32 flow_control;
u32 link_speed_msk;
u32 wol;
+ bool is_vlan_force_promisc;
+ u8 is_vlan_rx_strip;
+ u8 is_vlan_tx_insert;
u16 is_mc_list_enabled;
u16 mc_list_count;
bool is_autoneg;
pgpDwdzSTFIIp.pgp
Description: OpenPGP digital signature
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:
net/ipv4/ip_output.c
between commit:
5b18f1289808 ("ipv4: reset rt_iif for recirculated mcast/bcast out pkts")
from the net tree and commit:
956fe2190820 ("bpf: Update BPF_CGROUP_RUN_PROG_INET_EGRESS calls")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ip_output.c
index 8c2ec35b6512,cdd6c3418b9e..
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -322,7 -330,12 +331,26 @@@ static int ip_mc_finish_output(struct n
int ret;
ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
- if (ret) {
+ switch (ret) {
++ case NET_XMIT_SUCCESS:
++ case NET_XMIT_CN:
++ /* Reset rt_iif so that inet_iif() will return skb->skb_iif.
++ * Setting this to non-zero causes ipi_ifindex in in_pktinfo
++ * to be overwritten, see ipv4_pktinfo_prepare().
++ */
++ new_rt = rt_dst_clone(net->loopback_dev, skb_rtable(skb));
++ if (new_rt) {
++ new_rt->rt_iif = 0;
++ skb_dst_drop(skb);
++ skb_dst_set(skb, _rt->dst);
++ }
++ }
++ switch (ret) {
+ case NET_XMIT_SUCCESS:
+ return dev_loopback_xmit(net, sk, skb);
+ case NET_XMIT_CN:
+ return dev_loopback_xmit(net, sk, skb) ? : ret;
+ default:
kfree_skb(skb);
return ret;
}
pgppQx0c1xDP0.pgp
Description: OpenPGP digital signature
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:
net/wireless/nl80211.c
between commit:
180aa422ef27 ("nl80211: fill all policy .type entries")
from the net tree and commit:
1a28ed213696 ("nl80211: fill all policy .type entries")
from the net-next tree.
I fixed it up (they were just formatted differently, so I used the latter)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgphZmoo04Fb9.pgp
Description: OpenPGP digital signature
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:
net/vmw_vsock/hyperv_transport.c
between commit:
d424a2afd7da ("hv_sock: Suppress bogus "may be used uninitialized" warnings")
from the net tree and commit:
ac383f58f3c9 ("hv_sock: perf: Allow the socket buffer size options to
influence the actual socket buffers")
from the net-next tree.
I fixed it up (the latter include the former fix) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpRf5fBv9GDR.pgp
Description: OpenPGP digital signature
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:
kernel/bpf/verifier.c
between commit:
983695fa6765 ("bpf: fix unconnected udp hooks")
from the net tree and commit:
5cf1e9145630 ("bpf: cgroup inet skb programs can return 0 to 3")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This is
now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/bpf/verifier.c
index a5c369e60343,5c2cb5bd84ce..
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -5353,12 -5513,13 +5505,16 @@@ static int check_return_code(struct bpf
struct tnum range = tnum_range(0, 1);
switch (env->prog->type) {
+ case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
+ if (env->prog->expected_attach_type == BPF_CGROUP_UDP4_RECVMSG
||
+ env->prog->expected_attach_type == BPF_CGROUP_UDP6_RECVMSG)
+ range = tnum_range(1, 1);
case BPF_PROG_TYPE_CGROUP_SKB:
+ if (env->prog->expected_attach_type == BPF_CGROUP_INET_EGRESS) {
+ range = tnum_range(0, 3);
+ enforce_attach_type_range = tnum_range(2, 3);
+ }
case BPF_PROG_TYPE_CGROUP_SOCK:
- case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
case BPF_PROG_TYPE_SOCK_OPS:
case BPF_PROG_TYPE_CGROUP_DEVICE:
case BPF_PROG_TYPE_CGROUP_SYSCTL:
@@@ -5385,9 -5546,13 +5541,13 @@@
verbose(env, "has unknown scalar value");
}
tnum_strn(tn_buf, sizeof(tn_buf), range);
- verbose(env, " should have been %s\n", tn_buf);
+ verbose(env, " should have been in %s\n", tn_buf);
return -EINVAL;
}
+
+ if (!tnum_is_unknown(enforce_attach_type_range) &&
+ tnum_in(enforce_attach_type_range, reg->var_off))
+ env->prog->enforce_expected_attach_type = 1;
return 0;
}
pgpkP0znEdajJ.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/cmd.c
between commit:
6a6fabbfa3e8 ("net/mlx5: Update pci error handler entries and command
translation")
from the net tree and commit:
cd56f929e6a5 ("net/mlx5: E-Switch, Replace host_params event with
functions_changed event")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index e94686c42000,30f7dffb5b1b..
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@@ -632,11 -628,7 +632,11 @@@ const char *mlx5_command_str(int comman
MLX5_COMMAND_STR_CASE(QUERY_MODIFY_HEADER_CONTEXT);
MLX5_COMMAND_STR_CASE(ALLOC_MEMIC);
MLX5_COMMAND_STR_CASE(DEALLOC_MEMIC);
- MLX5_COMMAND_STR_CASE(QUERY_HOST_PARAMS);
+ MLX5_COMMAND_STR_CASE(QUERY_ESW_FUNCTIONS);
+ MLX5_COMMAND_STR_CASE(CREATE_UCTX);
+ MLX5_COMMAND_STR_CASE(DESTROY_UCTX);
+ MLX5_COMMAND_STR_CASE(CREATE_UMEM);
+ MLX5_COMMAND_STR_CASE(DESTROY_UMEM);
default: return "unknown command opcode";
}
}
pgpgg6DOsDB8r.pgp
Description: OpenPGP digital signature
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/phy/phylink.c
between commit:
c678726305b9 ("net: phylink: ensure consistent phy interface mode")
from the net tree and commit:
27755ff88c0e ("net: phylink: Add phylink_mac_link_{up, down} wrapper
functions")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/phy/phylink.c
index 9044b95d2afe,68d0a89c52be..
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@@ -399,6 -414,36 +418,36 @@@ static const char *phylink_pause_to_str
}
}
+ static void phylink_mac_link_up(struct phylink *pl,
+ struct phylink_link_state link_state)
+ {
+ struct net_device *ndev = pl->netdev;
+
++ pl->cur_interface = link_state.interface;
+ pl->ops->mac_link_up(pl->config, pl->link_an_mode,
- pl->phy_state.interface,
- pl->phydev);
++ pl->cur_interface, pl->phydev);
+
+ if (ndev)
+ netif_carrier_on(ndev);
+
+ phylink_info(pl,
+"Link is Up - %s/%s - flow control %s\n",
+phy_speed_to_str(link_state.speed),
+phy_duplex_to_str(link_state.duplex),
+phylink_pause_to_str(link_state.pause));
+ }
+
+ static void phylink_mac_link_down(struct phylink *pl)
+ {
+ struct net_device *ndev = pl->netdev;
+
+ if (ndev)
+ netif_carrier_off(ndev);
+ pl->ops->mac_link_down(pl->config, pl->link_an_mode,
- pl->phy_state.interface);
++ pl->cur_interface);
+ phylink_info(pl, "Link is Down\n");
+ }
+
static void phylink_resolve(struct work_struct *w)
{
struct phylink *pl = container_of(w, struct phylink, resolve);
pgp4SBOyiV2n4.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the net tree
Merge fix looks like correct. Might be my fault I sent dp83867 patches
against linux.git, not linux-next.git. If you want I can resend
updated version for linux-next.
Max.
чт, 30 мая 2019 г. в 02:56, Stephen Rothwell :
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/phy/dp83867.c
>
> between commits:
>
> 2b892649254f ("net: phy: dp83867: Set up RGMII TX delay")
> 333061b92453 ("net: phy: dp83867: fix speed 10 in sgmii mode")
>
> from the net tree and commits:
>
> c11669a2757e ("net: phy: dp83867: Rework delay rgmii delay handling")
> 27708eb5481b ("net: phy: dp83867: IO impedance is not dependent on RGMII
> delay")
>
> from the net-next tree.
>
> I fixed it up (I took a guess - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/phy/dp83867.c
> index c71c7d0f53f0,3bdf94043693..
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@@ -26,18 -26,11 +26,19 @@@
>
> /* Extended Registers */
> #define DP83867_CFG40x0031
> +#define DP83867_CFG4_SGMII_ANEG_MASK (BIT(5) | BIT(6))
> +#define DP83867_CFG4_SGMII_ANEG_TIMER_11MS (3 << 5)
> +#define DP83867_CFG4_SGMII_ANEG_TIMER_800US (2 << 5)
> +#define DP83867_CFG4_SGMII_ANEG_TIMER_2US(1 << 5)
> +#define DP83867_CFG4_SGMII_ANEG_TIMER_16MS (0 << 5)
> +
> #define DP83867_RGMIICTL 0x0032
> #define DP83867_STRAP_STS10x006E
> + #define DP83867_STRAP_STS20x006f
> #define DP83867_RGMIIDCTL 0x0086
> #define DP83867_IO_MUX_CFG0x0170
> +#define DP83867_10M_SGMII_CFG 0x016F
> +#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
>
> #define DP83867_SW_RESET BIT(15)
> #define DP83867_SW_RESTARTBIT(14)
> @@@ -255,10 -321,18 +329,17 @@@ static int dp83867_config_init(struct p
> ret = phy_write(phydev, MII_DP83867_PHYCTRL, val);
> if (ret)
> return ret;
> - }
>
> - /* If rgmii mode with no internal delay is selected, we do NOT use
> - * aligned mode as one might expect. Instead we use the PHY's default
> - * based on pin strapping. And the "mode 0" default is to *use*
> - * internal delay with a value of 7 (2.00 ns).
> - */
> - if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
> - (phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
> + /* Set up RGMII delays */
> ++ /* If rgmii mode with no internal delay is selected,
> ++ * we do NOT use aligned mode as one might expect. Instead
> ++ * we use the PHY's default based on pin strapping. And the
> ++ * "mode 0" default is to *use* * internal delay with a
> ++ * value of 7 (2.00 ns).
> ++ */
> val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
>
> + val &= ~(DP83867_RGMII_TX_CLK_DELAY_EN |
> DP83867_RGMII_RX_CLK_DELAY_EN);
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> val |= (DP83867_RGMII_TX_CLK_DELAY_EN |
> DP83867_RGMII_RX_CLK_DELAY_EN);
>
> @@@ -275,41 -349,14 +356,41 @@@
>
> phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
> delay);
> -
> - if (dp83867->io_impedance >= 0)
> - phy_modify_mmd(phydev, DP83867_DEVADDR,
> DP83867_IO_MUX_CFG,
> - DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL,
> - dp83867->io_impedance &
> - DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL);
> }
>
> + /* If specified, set io impedance */
> + if (dp83867->io_impedance >= 0)
> + phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
> + DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
> + dp83867->io_impedance);
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> + /* For support SPEED_10 in SGMII mode
> + * DP83867_10M_SGMII_RATE_ADAPT bit
> + * has to be cleared by software. That
> + * does not affect SPEED_100 and
> + * SPEED_1000.
> + */
> + ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
> + DP83867_10M_SGMII_CFG,
> + DP83867_10M_SGMII_RATE_ADAPT_MASK,
> + 0);
> + if (ret)
> + return ret;
>
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/phy/dp83867.c
between commits:
2b892649254f ("net: phy: dp83867: Set up RGMII TX delay")
333061b92453 ("net: phy: dp83867: fix speed 10 in sgmii mode")
from the net tree and commits:
c11669a2757e ("net: phy: dp83867: Rework delay rgmii delay handling")
27708eb5481b ("net: phy: dp83867: IO impedance is not dependent on RGMII
delay")
from the net-next tree.
I fixed it up (I took a guess - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/phy/dp83867.c
index c71c7d0f53f0,3bdf94043693..
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@@ -26,18 -26,11 +26,19 @@@
/* Extended Registers */
#define DP83867_CFG40x0031
+#define DP83867_CFG4_SGMII_ANEG_MASK (BIT(5) | BIT(6))
+#define DP83867_CFG4_SGMII_ANEG_TIMER_11MS (3 << 5)
+#define DP83867_CFG4_SGMII_ANEG_TIMER_800US (2 << 5)
+#define DP83867_CFG4_SGMII_ANEG_TIMER_2US(1 << 5)
+#define DP83867_CFG4_SGMII_ANEG_TIMER_16MS (0 << 5)
+
#define DP83867_RGMIICTL 0x0032
#define DP83867_STRAP_STS10x006E
+ #define DP83867_STRAP_STS20x006f
#define DP83867_RGMIIDCTL 0x0086
#define DP83867_IO_MUX_CFG0x0170
+#define DP83867_10M_SGMII_CFG 0x016F
+#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTARTBIT(14)
@@@ -255,10 -321,18 +329,17 @@@ static int dp83867_config_init(struct p
ret = phy_write(phydev, MII_DP83867_PHYCTRL, val);
if (ret)
return ret;
- }
- /* If rgmii mode with no internal delay is selected, we do NOT use
- * aligned mode as one might expect. Instead we use the PHY's default
- * based on pin strapping. And the "mode 0" default is to *use*
- * internal delay with a value of 7 (2.00 ns).
- */
- if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
- (phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
+ /* Set up RGMII delays */
++ /* If rgmii mode with no internal delay is selected,
++ * we do NOT use aligned mode as one might expect. Instead
++ * we use the PHY's default based on pin strapping. And the
++ * "mode 0" default is to *use* * internal delay with a
++ * value of 7 (2.00 ns).
++ */
val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
+ val &= ~(DP83867_RGMII_TX_CLK_DELAY_EN |
DP83867_RGMII_RX_CLK_DELAY_EN);
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
val |= (DP83867_RGMII_TX_CLK_DELAY_EN |
DP83867_RGMII_RX_CLK_DELAY_EN);
@@@ -275,41 -349,14 +356,41 @@@
phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
delay);
-
- if (dp83867->io_impedance >= 0)
- phy_modify_mmd(phydev, DP83867_DEVADDR,
DP83867_IO_MUX_CFG,
- DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL,
- dp83867->io_impedance &
- DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL);
}
+ /* If specified, set io impedance */
+ if (dp83867->io_impedance >= 0)
+ phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
+ dp83867->io_impedance);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ /* For support SPEED_10 in SGMII mode
+ * DP83867_10M_SGMII_RATE_ADAPT bit
+ * has to be cleared by software. That
+ * does not affect SPEED_100 and
+ * SPEED_1000.
+ */
+ ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
+ DP83867_10M_SGMII_CFG,
+ DP83867_10M_SGMII_RATE_ADAPT_MASK,
+ 0);
+ if (ret)
+ return ret;
+
+ /* After reset SGMII Autoneg timer is set to 2us (bits 6 and 5
+ * are 01). That is not enough to finalize autoneg on some
+ * devices. Increase this timer duration to maximum 16ms.
+ */
+ ret = phy_modify_mmd(phydev, DP83867_DEVADDR,
+ DP83867_CFG4,
+
Re: linux-next: manual merge of the net-next tree with the net tree
On Mon, 2019-04-01 at 09:11 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
>
> between commit:
>
> e28408e98bce ("net/mlx5e: Update xon formula")
>
> from the net tree and commit:
>
> d3669ca9ff33 ("net/mlx5e: Fix port buffer function documentation
> format")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
>
Thanks Stephen, the resolution looks good,
Dave was already notified about this.
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/tcp.c
between commit:
04c03114be82 ("tcp: clear icsk_backoff in tcp_write_queue_purge()")
from the net tree and commit:
3a9a57f63794 ("tcp: move snd_cwnd & snd_cwnd_cnt init to tcp_disconnect()")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/tcp.c
index cf3c5095c10e,cab6b2f2f61d..
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@@ -2577,9 -2595,11 +2596,10 @@@ int tcp_disconnect(struct sock *sk, in
tp->write_seq += tp->max_window + 2;
if (tp->write_seq == 0)
tp->write_seq = 1;
- tp->snd_cwnd = 2;
- icsk->icsk_backoff = 0;
icsk->icsk_probes_out = 0;
+ icsk->icsk_rto = TCP_TIMEOUT_INIT;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
+ tp->snd_cwnd = TCP_INIT_CWND;
tp->snd_cwnd_cnt = 0;
tp->window_clamp = 0;
tp->delivered_ce = 0;
pgp55r9U5pSRo.pgp
Description: OpenPGP digital 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, , true);
- call_rcu(>rcu, __tcindex_destroy);
+ if (p->perfect) {
+ for (i = 0; i < p->hash; i++) {
+ struct tcindex_filter_result *r = p->perfect + i;
+
+ tcf_unbind_filter(tp, >res);
+ if (tcf_exts_get_net(>exts))
+ tcf_queue_work(>rwork,
+ tcindex_destroy_rexts_work);
+ else
+ __tcindex_destroy_rexts(r);
+ }
+ }
+
+ for (i = 0; p->h && i < p->hash; i++) {
+ struct tcindex_filter *f, *next;
+ bool last;
+
+ for (f = rtnl_dereference(p->h[i]); f; f = next) {
+ next = rtnl_dereference(f->next);
- tcindex_delete(tp, >result, , NULL);
++ tcindex_delete(tp, >result, , false, NULL);
+ }
+ }
+
+ tcf_queue_work(>rwork, tcindex_destroy_work);
}
pgp6iOF4fhyxF.pgp
Description: OpenPGP digital signature
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:
net/sched/cls_tcindex.c
between commits:
8015d93ebd27 ("net_sched: fix a race condition in tcindex_destroy()")
033b228e7f26 ("net_sched: fix a memory leak in cls_tcindex")
from the net tree and commit:
12db03b65c2b ("net: sched: extend proto ops to support unlocked classifiers")
from the net-next tree.
I fixed it up (see the final resolution when linux-next is published)
and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/sched/cls_tcindex.c
index 38bb882bb958,14d6b4058045..
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
pgpYAAj6ijlcP.pgp
Description: OpenPGP digital signature
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 conflicts in:
net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
between commit:
8303b7e8f018 ("netfilter: nat: fix spurious connection timeouts")
from the net tree and commit:
303e0c558959 ("netfilter: conntrack: avoid unneeded nf_conntrack_l4proto
lookups")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
index fa2ba7c500e4,e26165af45cb..
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@@ -214,8 -214,7 +214,8 @@@ int nf_nat_icmp_reply_translation(struc
}
/* Change outer to look like the reply to an incoming packet */
- nf_ct_invert_tuplepr(, >tuplehash[!dir].tuple);
+ nf_ct_invert_tuple(, >tuplehash[!dir].tuple);
+ target.dst.protonum = IPPROTO_ICMP;
if (!nf_nat_ipv4_manip_pkt(skb, 0, , manip))
return 0;
diff --cc net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
index 7a41ee3c11b4,9c914db44bec..
--- a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
@@@ -225,8 -225,7 +225,8 @@@ int nf_nat_icmpv6_reply_translation(str
skb->len - hdrlen, 0));
}
- nf_ct_invert_tuplepr(, >tuplehash[!dir].tuple);
+ nf_ct_invert_tuple(, >tuplehash[!dir].tuple);
+ target.dst.protonum = IPPROTO_ICMPV6;
if (!nf_nat_ipv6_manip_pkt(skb, 0, , manip))
return 0;
pgpH2Sn6s9ZCG.pgp
Description: OpenPGP digital signature
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/mellanox/mlx5/core/en_tc.c
between commit:
218d05ce326f ("net/mlx5e: Don't overwrite pedit action when multiple pedit
used")
from the net tree and commit:
c500c86b0c75 ("net/mlx5e: support for two independent packet edit actions")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index b5c1b039375a,85c5dd7fc2c7..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1310,15 -1308,12 +1309,12 @@@ static int parse_tunnel_attr(struct mlx
outer_headers);
void *headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
outer_headers);
-
- struct flow_dissector_key_control *enc_control =
- skb_flow_dissector_target(f->dissector,
- FLOW_DISSECTOR_KEY_ENC_CONTROL,
- f->key);
- int err = 0;
+ struct flow_rule *rule = tc_cls_flower_offload_flow_rule(f);
+ struct flow_match_control enc_control;
+ int err;
err = mlx5e_tc_tun_parse(filter_dev, priv, spec, f,
- headers_c, headers_v);
+ headers_c, headers_v, match_level);
if (err) {
NL_SET_ERR_MSG_MOD(extack,
"failed to parse tunnel attributes");
@@@ -1466,19 -1454,17 +1455,17 @@@ static int __parse_cls_flower(struct ml
return -EOPNOTSUPP;
}
- if ((dissector_uses_key(f->dissector,
- FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
-dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
-dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
- dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
- struct flow_dissector_key_control *key =
- skb_flow_dissector_target(f->dissector,
-
FLOW_DISSECTOR_KEY_ENC_CONTROL,
- f->key);
- switch (key->addr_type) {
+ if ((flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
+flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
+flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
+ flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
+ struct flow_match_control match;
+
+ flow_rule_match_enc_control(rule, );
+ switch (match.key->addr_type) {
case FLOW_DISSECTOR_KEY_IPV4_ADDRS:
case FLOW_DISSECTOR_KEY_IPV6_ADDRS:
- if (parse_tunnel_attr(priv, spec, f, filter_dev))
+ if (parse_tunnel_attr(priv, spec, f, filter_dev,
tunnel_match_level))
return -EOPNOTSUPP;
break;
default:
@@@ -1937,12 -1880,11 +1883,11 @@@ static struct mlx5_fields fields[] =
OFFLOAD(UDP_DPORT, 2, udp.dest, 0),
};
-/* On input attr->num_mod_hdr_actions tells how many HW actions can be parsed
at
- * max from the SW pedit action. On success, it says how many HW actions were
- * actually parsed.
+/* On input attr->max_mod_hdr_actions tells how many HW actions can be parsed
at
+ * max from the SW pedit action. On success, attr->num_mod_hdr_actions
+ * says how many HW actions were actually parsed.
*/
- static int offload_pedit_fields(struct pedit_headers *masks,
- struct pedit_headers *vals,
+ static int offload_pedit_fields(struct pedit_headers_action *hdrs,
struct mlx5e_tc_flow_parse_attr *parse_attr,
struct netlink_ext_ack *extack)
{
@@@ -1957,17 -1899,15 +1902,17 @@@
__be16 mask_be16;
void *action;
- set_masks = [TCA_PEDIT_KEY_EX_CMD_SET];
- add_masks = [TCA_PEDIT_KEY_EX_CMD_ADD];
- set_vals = [TCA_PEDIT_KEY_EX_CMD_SET];
- add_vals = [TCA_PEDIT_KEY_EX_CMD_ADD];
+ set_masks = [0].masks;
+ add_masks = [1].masks;
+ set_vals = [0].vals;
+ add_vals = [1].vals;
action_size = MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto);
- action = parse_attr->mod_hdr_actions;
- max_actions =
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.
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/mellanox/mlx5/core/en_tc.c
between commit:
1651925d403e ("net/mlx5e: Use the inner headers to determine tc/pedit offload
limitation on decap flows")
from the net tree and commit:
738678817573 ("drivers: net: use flow action infrastructure")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 1c3c9fa26b55,83522c926d7c..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1309,15 -1309,12 +1309,12 @@@ static int parse_tunnel_attr(struct mlx
outer_headers);
void *headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
outer_headers);
-
- struct flow_dissector_key_control *enc_control =
- skb_flow_dissector_target(f->dissector,
- FLOW_DISSECTOR_KEY_ENC_CONTROL,
- f->key);
- int err = 0;
+ struct flow_rule *rule = tc_cls_flower_offload_flow_rule(f);
+ struct flow_match_control enc_control;
+ int err;
err = mlx5e_tc_tun_parse(filter_dev, priv, spec, f,
- headers_c, headers_v);
+ headers_c, headers_v, match_level);
if (err) {
NL_SET_ERR_MSG_MOD(extack,
"failed to parse tunnel attributes");
@@@ -1465,19 -1455,17 +1455,17 @@@ static int __parse_cls_flower(struct ml
return -EOPNOTSUPP;
}
- if ((dissector_uses_key(f->dissector,
- FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
-dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
-dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
- dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
- struct flow_dissector_key_control *key =
- skb_flow_dissector_target(f->dissector,
-
FLOW_DISSECTOR_KEY_ENC_CONTROL,
- f->key);
- switch (key->addr_type) {
+ if ((flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) ||
+flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID) ||
+flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_PORTS)) &&
+ flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
+ struct flow_match_control match;
+
+ flow_rule_match_enc_control(rule, );
+ switch (match.key->addr_type) {
case FLOW_DISSECTOR_KEY_IPV4_ADDRS:
case FLOW_DISSECTOR_KEY_IPV6_ADDRS:
- if (parse_tunnel_attr(priv, spec, f, filter_dev))
+ if (parse_tunnel_attr(priv, spec, f, filter_dev,
tunnel_match_level))
return -EOPNOTSUPP;
break;
default:
@@@ -2180,22 -2129,17 +2131,22 @@@ static bool csum_offload_supported(stru
}
static bool modify_header_match_supported(struct mlx5_flow_spec *spec,
- struct tcf_exts *exts,
+ struct flow_action *flow_action,
+u32 actions,
struct netlink_ext_ack *extack)
{
- const struct tc_action *a;
+ const struct flow_action_entry *act;
bool modify_ip_header;
u8 htype, ip_proto;
void *headers_v;
u16 ethertype;
- int nkeys, i;
+ int i;
- headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
outer_headers);
+ if (actions & MLX5_FLOW_CONTEXT_ACTION_DECAP)
+ headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
inner_headers);
+ else
+ headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
outer_headers);
+
ethertype = MLX5_GET(fte_match_set_lyr_2_4, headers_v, ethertype);
/* for non-IP we only re-write MACs, so we're okay */
@@@ -2251,8 -2191,9 +2198,9 @@@ static bool actions_match_supported(str
return false;
if (actions & MLX5_FLOW_CONTEXT_ACTION_MOD_HDR)
- return modify_header_match_supported(_attr->spec, exts,
+ return
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:
Documentation/networking/snmp_counter.rst
between commit:
a6c7c7aac2de ("net: add document for several snmp counters")
from the net tree and commit:
ae5220c67218 ("networking: Documentation: fix snmp_counters.rst Sphinx
warnings")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/networking/snmp_counter.rst
index fe8f741193be,486ab33acc3a..
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@@ -336,27 -364,8 +364,27 @@@ time client replies ACK, this socket wi
to the accept queue.
-TCP Fast Open
+* TcpEstabResets
+Defined in `RFC1213 tcpEstabResets`_.
+
+.. _RFC1213 tcpEstabResets: https://tools.ietf.org/html/rfc1213#page-48
+
+* TcpAttemptFails
+Defined in `RFC1213 tcpAttemptFails`_.
+
+.. _RFC1213 tcpAttemptFails: https://tools.ietf.org/html/rfc1213#page-48
+
+* TcpOutRsts
+Defined in `RFC1213 tcpOutRsts`_. The RFC says this counter indicates
+the 'segments sent containing the RST flag', but in linux kernel, this
+couner indicates the segments kerenl tried to send. The sending
+process might be failed due to some errors (e.g. memory alloc failed).
+
+.. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52
+
+
+TCP Fast Path
-
+ =
When kernel receives a TCP packet, it has two paths to handler the
packet, one is fast path, another is slow path. The comment in kernel
code provides a good explanation of them, I pasted them below::
@@@ -582,7 -612,8 +630,8 @@@ The TCP stack receives an out of order
DSACK to the sender.
* TcpExtTCPDSACKRecv
+
-The TCP stack receives a DSACK, which indicate an acknowledged
+The TCP stack receives a DSACK, which indicates an acknowledged
duplicate packet is received.
* TcpExtTCPDSACKOfoRecv
@@@ -589,59 -621,10 +639,60 @@@
The TCP stack receives a DSACK, which indicate an out of order
duplicate packet is received.
+invalid SACK and DSACK
-
++==
+When a SACK (or DSACK) block is invalid, a corresponding counter would
+be updated. The validation method is base on the start/end sequence
+number of the SACK block. For more details, please refer the comment
+of the function tcp_is_sackblock_valid in the kernel source code. A
+SACK option could have up to 4 blocks, they are checked
+individually. E.g., if 3 blocks of a SACk is invalid, the
+corresponding counter would be updated 3 times. The comment of the
+`Add counters for discarded SACK blocks`_ patch has additional
+explaination:
+
+.. _Add counters for discarded SACK blocks:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f02545a9a16c9a89778b91a162ad16d510bb32
+
+* TcpExtTCPSACKDiscard
+This counter indicates how many SACK blocks are invalid. If the invalid
+SACK block is caused by ACK recording, the TCP stack will only ignore
+it and won't update this counter.
+
+* TcpExtTCPDSACKIgnoredOld and TcpExtTCPDSACKIgnoredNoUndo
+When a DSACK block is invalid, one of these two counters would be
+updated. Which counter will be updated depends on the undo_marker flag
+of the TCP socket. If the undo_marker is not set, the TCP stack isn't
+likely to re-transmit any packets, and we still receive an invalid
+DSACK block, the reason might be that the packet is duplicated in the
+middle of the network. In such scenario, TcpExtTCPDSACKIgnoredNoUndo
+will be updated. If the undo_marker is set, TcpExtTCPDSACKIgnoredOld
+will be updated. As implied in its name, it might be an old packet.
+
+SACK shift
- =
++==
+The linux networking stack stores data in sk_buff struct (skb for
+short). If a SACK block acrosses multiple skb, the TCP stack will try
+to re-arrange data in these skb. E.g. if a SACK block acknowledges seq
+10 to 15, skb1 has seq 10 to 13, skb2 has seq 14 to 20. The seq 14 and
+15 in skb2 would be moved to skb1. This operation is 'shift'. If a
+SACK block acknowledges seq 10 to 20, skb1 has seq 10 to 13, skb2 has
+seq 14 to 20. All data in skb2 will be moved to skb1, and skb2 will be
+discard, this operation is 'merge'.
+
+* TcpExtTCPSackShifted
+A skb is shifted
+
+* TcpExtTCPSackMerged
+A skb is merged
+
+* TcpExtTCPSackShiftFallback
+A skb should be shifted or merged, but the TCP stack doesn't do it for
+some reasons.
+
TCP out of order
- ===
+
* TcpExtTCPOFOQueue
+
The TCP layer receives an out of order packet and has enough memory
to
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!
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/mellanox/mlx5/core/en_rep.c
between commit:
8956f0014ea5 ("net/mlx5e: Fix default amount of channels for VF representors")
from the net tree and commit:
d9ee0491c2ff ("net/mlx5e: Use dedicated uplink vport netdev representor")
from the net-next tree.
I fixed it up (I just used the net-next tree version) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpblQP_5csVJ.pgp
Description: OpenPGP digital signature
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:
tools/testing/selftests/net/Makefile
between commit:
55cbe0794294 ("selftests: net: Add test_vxlan_fdb_changelink.sh")
from the net tree and commit:
e87f53b4fab7 ("selftests: add some benchmark for UDP GRO")
( and following ones) from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/Makefile
index 923570a9708a,9543a4c2f9be..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -4,14 -4,15 +4,16 @@@
CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
CFLAGS += -I../../../../usr/include/
- TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh
rtnetlink.sh
+ TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh \
+ rtnetlink.sh xfrm_policy.sh
TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh ip_defrag.sh
TEST_PROGS += udpgso_bench.sh fib_rule_tests.sh msg_zerocopy.sh psock_snd.sh
+TEST_PROGS += test_vxlan_fdb_changelink.sh
+ TEST_PROGS += udpgro_bench.sh udpgro.sh test_vxlan_under_vrf.sh
reuseport_addr_any.sh
TEST_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket
- TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
- TEST_GEN_FILES += tcp_mmap tcp_inq psock_snd
+ TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
+ TEST_GEN_FILES += tcp_mmap tcp_inq psock_snd txring_overwrite
TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx ip_defrag
TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls
pgp09bPidVq38.pgp
Description: OpenPGP digital signature
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/vxlan.c
between commits:
6db924687139 ("vxlan: Fix error path in __vxlan_dev_create()")
ce5e098f7a10 ("vxlan: changelink: Fix handling of default remotes")
from the net tree and commit:
0e6160f3f5a9 ("vxlan: vxlan_fdb_notify(): Make switchdev notification
configurable")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/vxlan.c
index 0565f8880199,71c3b7b6b1ab..
--- 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(>next, >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 = >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(>remote_ip)) {
- err = vxlan_fdb_create(vxlan, all_zeros_mac,
+ err = vxlan_fdb_update(vxlan, all_zeros_mac,
>remote_ip,
NUD_REACHABLE | NUD_PERMANENT,
+ NLM_F_APPEND | NLM_F_CREATE,
vxlan->cfg.dst_port,
dst->remote_vni,
dst->remote_vni,
pgpMseOFBJXgI.pgp
Description: OpenPGP digital signature
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
pgpYqakizo_6s.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=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!
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:
net/ipv6/ip6_output.c
between commit:
8203e2d844d3 ("net: clear skb->tstamp in forwarding paths")
from the net tree and commit:
f839a6c92504 ("net: Do not route unicast IP packets twice")
from the net-next tree.
I fixed it up (I was not quite sure of the correct ordering - see below)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv6/ip6_output.c
index 4591ca4bdbe8,9d55ee33b7f9..
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@@ -378,7 -378,13 +378,14 @@@ static inline int ip6_forward_finish(st
__IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTFORWDATAGRAMS);
__IP6_ADD_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTOCTETS,
skb->len);
+ #ifdef CONFIG_NET_SWITCHDEV
+ if (skb->offload_l3_fwd_mark) {
+ consume_skb(skb);
+ return 0;
+ }
+ #endif
+
+ skb->tstamp = 0;
return dst_output(net, sk, skb);
}
pgpDuPRud0kEs.pgp
Description: OpenPGP digital signature
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/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");
pgpPLb5QPmc9p.pgp
Description: OpenPGP digital signature
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/crypto/chelsio/chtls/chtls_cm.c
between commit:
0c3a16be700e ("crypto/chelsio/chtls: send/recv window update")
from the net tree and commit:
02d805dc5fe3 ("cxgb4: use new fw interface to get the VIN and smt index")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/crypto/chelsio/chtls/chtls_cm.c
index 931b96c220af,228b91b7d6b5..
--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
@@@ -1079,11 -1074,10 +1079,10 @@@ static struct sock *chtls_recv_sock(str
csk->txq_idx = (rxq_idx < cdev->lldi->ntxq) ? rxq_idx :
port_id * step;
csk->sndbuf = newsk->sk_sndbuf;
- csk->smac_idx = cxgb4_tp_smt_idx(cdev->lldi->adapter_type,
-cxgb4_port_viid(ndev));
+ csk->smac_idx = ((struct port_info *)netdev_priv(ndev))->smt_idx;
- tp->rcv_wnd = select_rcv_wnd(csk);
RCV_WSCALE(tp) = select_rcv_wscale(tcp_full_space(newsk),
- WSCALE_OK(tp),
+ sock_net(newsk)->
+ ipv4.sysctl_tcp_window_scaling,
tp->window_clamp);
neigh_release(n);
inet_inherit_port(_hashinfo, lsk, newsk);
pgpeIvaCKQ0t4.pgp
Description: OpenPGP digital signature
