* Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2018-04-30
From: David Miller @ 2018-05-01 13:38 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180430170059.13186-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 30 Apr 2018 10:00:50 -0700
> This series contains updates to i40e and i40evf only.
>
> Jia-Ju Bai replaces an instance of GFP_ATOMIC to GFP_KERNEL, since
> i40evf is not in atomic context when i40evf_add_vlan() is called.
>
> Jake cleans up function header comments to ensure that the function
> parameter comments actually match the function parameters. Fixed a
> possible overflow error in the PTP clock code. Fixed warnings regarding
> restricted __be32 type usage.
>
> Mariusz fixes the reading of the LLDP configuration, which moves from
> using relative values to calculating the absolute address.
>
> Jakub adds a check for 10G LR mode for i40e.
>
> Paweł fixes an issue, where changing the MTU would turn on TSO, GSO and
> GRO.
>
> Alex fixes a couple of issues with the UDP tunnel filter configuration.
> First being that the tunnels did not have mutual exclusion in place to
> prevent a race condition between a user request to add/remove a port and
> an update. The second issue was we were deleting filters that were not
> associated with the actual filter we wanted to delete.
>
> Harshitha ensures that the queue map sent by the VF is taken into
> account when enabling/disabling queues in the VF VSI.
>
> The following are changes since commit 76c2a96d42ca3bdac12c463ff27fec3bb2982e3f:
> liquidio: fix spelling mistake: "mac_tx_multi_collison" -> "mac_tx_multi_collision"
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] ipv6: Allow non-gateway ECMP for IPv6
From: Ido Schimmel @ 2018-05-01 13:20 UTC (permalink / raw)
To: David Ahern
Cc: Thomas Winter, netdev, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <89497565-f1e6-a916-70d3-dfc7efa7a7e4@gmail.com>
On Mon, Apr 30, 2018 at 08:59:10PM -0600, David Ahern wrote:
> On 4/30/18 3:15 PM, Thomas Winter wrote:
> > It is valid to have static routes where the nexthop
> > is an interface not an address such as tunnels.
> > For IPv4 it was possible to use ECMP on these routes
> > but not for IPv6.
> >
> > Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
> > Cc: David Ahern <dsahern@gmail.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> > Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> > ---
> > include/net/ip6_route.h | 3 +--
> > net/ipv6/ip6_fib.c | 3 ---
> > 2 files changed, 1 insertion(+), 5 deletions(-)
> >
>
> Interesting. Existing code inserts the dev nexthop as a separate route.
>
> Change looks good to me.
>
> Acked-by: David Ahern <dsahern@gmail.com>
Thanks for the Cc, David. I'll need to adjust mlxsw to support this.
Specifically, mlxsw_sp_fib6_rt_can_mp().
BTW, I hit this bug while looking into this:
https://patchwork.ozlabs.org/patch/907050/
^ permalink raw reply
* Re: [PATCH v2 2/2] net: stmmac: dwmac-meson: extend phy mode setting
From: Martin Blumenstingl @ 2018-05-01 13:20 UTC (permalink / raw)
To: Yixun Lan
Cc: David S. Miller, netdev, Kevin Hilman, Carlo Caione, Rob Herring,
Jerome Brunet, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20180428102111.18384-3-yixun.lan@amlogic.com>
Hello Yixun,
On Sat, Apr 28, 2018 at 12:21 PM, Yixun Lan <yixun.lan@amlogic.com> wrote:
> In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer
> is extended from bit[0] to bit[2:0].
> There is no problem if we configure it to the RGMII 1000M PHY mode,
> since the register setting is coincidentally compatible with previous one,
> but for the RMII 100M PHY mode, the configuration need to be changed to
> value - b100.
> This patch was verified with a RTL8201F 100M ethernet PHY.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> .../ethernet/stmicro/stmmac/dwmac-meson8b.c | 120 +++++++++++++++---
> 1 file changed, 104 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> index 7cb794094a70..4ff231df7322 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> @@ -18,6 +18,7 @@
> #include <linux/io.h>
> #include <linux/ioport.h>
> #include <linux/module.h>
> +#include <linux/of_device.h>
> #include <linux/of_net.h>
> #include <linux/mfd/syscon.h>
> #include <linux/platform_device.h>
> @@ -29,6 +30,10 @@
>
> #define PRG_ETH0_RGMII_MODE BIT(0)
>
> +#define PRG_ETH0_EXT_PHY_MODE_MASK GENMASK(2, 0)
> +#define PRG_ETH0_EXT_RGMII_MODE 1
> +#define PRG_ETH0_EXT_RMII_MODE 4
> +
> /* mux to choose between fclk_div2 (bit unset) and mpll2 (bit set) */
> #define PRG_ETH0_CLK_M250_SEL_SHIFT 4
> #define PRG_ETH0_CLK_M250_SEL_MASK GENMASK(4, 4)
> @@ -47,12 +52,20 @@
>
> #define MUX_CLK_NUM_PARENTS 2
>
> +struct meson8b_dwmac;
> +
> +struct meson8b_dwmac_data {
> + int (*set_phy_mode)(struct meson8b_dwmac *dwmac);
> +};
> +
> struct meson8b_dwmac {
> - struct device *dev;
> - void __iomem *regs;
> - phy_interface_t phy_mode;
> - struct clk *rgmii_tx_clk;
> - u32 tx_delay_ns;
> + struct device *dev;
> + void __iomem *regs;
> +
> + const struct meson8b_dwmac_data *data;
> + phy_interface_t phy_mode;
> + struct clk *rgmii_tx_clk;
> + u32 tx_delay_ns;
> };
>
> struct meson8b_dwmac_clk_configs {
> @@ -171,6 +184,59 @@ static int meson8b_init_rgmii_tx_clk(struct meson8b_dwmac *dwmac)
> return 0;
> }
>
> +static int meson8b_set_phy_mode(struct meson8b_dwmac *dwmac)
> +{
> + switch (dwmac->phy_mode) {
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + /* enable RGMII mode */
> + meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> + PRG_ETH0_RGMII_MODE,
> + PRG_ETH0_RGMII_MODE);
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + /* disable RGMII mode -> enables RMII mode */
> + meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> + PRG_ETH0_RGMII_MODE, 0);
> + break;
> + default:
> + dev_err(dwmac->dev, "fail to set phy-mode %s\n",
> + phy_modes(dwmac->phy_mode));
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int meson_axg_set_phy_mode(struct meson8b_dwmac *dwmac)
> +{
> + switch (dwmac->phy_mode) {
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + /* enable RGMII mode */
> + meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> + PRG_ETH0_EXT_PHY_MODE_MASK,
> + PRG_ETH0_EXT_RGMII_MODE);
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + /* disable RGMII mode -> enables RMII mode */
if you have to re-send it for whatever reason:
maybe you could remove the comments from meson_axg_set_phy_mode. the
"older" register layout requires un-setting RGMII mode to enable RMII
mode. however, for AXG there seem to be two dedicated values (1 and 4)
for each mode
apart from that:
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> + meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> + PRG_ETH0_EXT_PHY_MODE_MASK,
> + PRG_ETH0_EXT_RMII_MODE);
> + break;
> + default:
> + dev_err(dwmac->dev, "fail to set phy-mode %s\n",
> + phy_modes(dwmac->phy_mode));
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
> {
> int ret;
> @@ -188,10 +254,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
>
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> - /* enable RGMII mode */
> - meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_RGMII_MODE,
> - PRG_ETH0_RGMII_MODE);
> -
> /* only relevant for RMII mode -> disable in RGMII mode */
> meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> PRG_ETH0_INVERTED_RMII_CLK, 0);
> @@ -224,10 +286,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
> break;
>
> case PHY_INTERFACE_MODE_RMII:
> - /* disable RGMII mode -> enables RMII mode */
> - meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_RGMII_MODE,
> - 0);
> -
> /* invert internal clk_rmii_i to generate 25/2.5 tx_rx_clk */
> meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
> PRG_ETH0_INVERTED_RMII_CLK,
> @@ -274,6 +332,11 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
> goto err_remove_config_dt;
> }
>
> + dwmac->data = (const struct meson8b_dwmac_data *)
> + of_device_get_match_data(&pdev->dev);
> + if (!dwmac->data)
> + return -EINVAL;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> dwmac->regs = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(dwmac->regs)) {
> @@ -298,6 +361,10 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
> if (ret)
> goto err_remove_config_dt;
>
> + ret = dwmac->data->set_phy_mode(dwmac);
> + if (ret)
> + goto err_remove_config_dt;
> +
> ret = meson8b_init_prg_eth(dwmac);
> if (ret)
> goto err_remove_config_dt;
> @@ -316,10 +383,31 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
> return ret;
> }
>
> +static const struct meson8b_dwmac_data meson8b_dwmac_data = {
> + .set_phy_mode = meson8b_set_phy_mode,
> +};
> +
> +static const struct meson8b_dwmac_data meson_axg_dwmac_data = {
> + .set_phy_mode = meson_axg_set_phy_mode,
> +};
> +
> static const struct of_device_id meson8b_dwmac_match[] = {
> - { .compatible = "amlogic,meson8b-dwmac" },
> - { .compatible = "amlogic,meson8m2-dwmac" },
> - { .compatible = "amlogic,meson-gxbb-dwmac" },
> + {
> + .compatible = "amlogic,meson8b-dwmac",
> + .data = &meson8b_dwmac_data,
> + },
> + {
> + .compatible = "amlogic,meson8m2-dwmac",
> + .data = &meson8b_dwmac_data,
> + },
> + {
> + .compatible = "amlogic,meson-gxbb-dwmac",
> + .data = &meson8b_dwmac_data,
> + },
> + {
> + .compatible = "amlogic,meson-axg-dwmac",
> + .data = &meson_axg_dwmac_data,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(of, meson8b_dwmac_match);
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH iproute2-master] iproute: Parse last nexthop in a multipath route
From: Ido Schimmel @ 2018-05-01 13:16 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern, mlxsw, Ido Schimmel
Continue parsing a multipath payload as long as another nexthop can fit
in the payload.
# ip route add 192.0.2.0/24 nexthop dev dummy0 nexthop dev dummy1
Before:
# ip route show 192.0.2.0/24
192.0.2.0/24
nexthop dev dummy0 weight 1
After:
# ip route show 192.0.2.0/24
192.0.2.0/24
nexthop dev dummy0 weight 1
nexthop dev dummy1 weight 1
Fixes: f48e14880a0e ("iproute: refactor multipath print")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
ip/iproute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index 44351bc51b4b..56dd9f25e38e 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -650,7 +650,7 @@ static void print_rta_multipath(FILE *fp, const struct rtmsg *r,
int len = RTA_PAYLOAD(rta);
int first = 1;
- while (len > sizeof(*nh)) {
+ while (len >= sizeof(*nh)) {
struct rtattr *tb[RTA_MAX + 1];
if (nh->rtnh_len > len)
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: net: meson-dwmac: new compatible name for AXG SoC
From: Rob Herring @ 2018-05-01 12:55 UTC (permalink / raw)
To: Yixun Lan
Cc: David S. Miller, netdev, Kevin Hilman, Carlo Caione,
Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20180428102111.18384-2-yixun.lan@amlogic.com>
On Sat, Apr 28, 2018 at 10:21:10AM +0000, Yixun Lan wrote:
> We need to introduce a new compatible name for the Meson-AXG SoC
> in order to support the RMII 100M ethernet PHY, since the PRG_ETH0
> register of the dwmac glue layer is changed from previous old SoC.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> Documentation/devicetree/bindings/net/meson-dwmac.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH iproute2 1/2] README: update libdb build dependency information
From: Baruch Siach @ 2018-05-01 12:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Baruch Siach
Debian does not distribute libdb4.x-dev for quite some time now. Current
stable carries libdb5.3-dev. Update the wording accordingly.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README b/README
index f66fd5faf4cf..bc82187cf018 100644
--- a/README
+++ b/README
@@ -16,8 +16,8 @@ How to compile this.
--------------------
1. libdbm
-arpd needs to have the db4 development libraries. For Debian
-users this is the package with a name like libdb4.x-dev.
+arpd needs to have the berkeleydb development libraries. For Debian
+users this is the package with a name like libdbX.X-dev.
DBM_INCLUDE points to the directory with db_185.h which
is the include file used by arpd to get to the old format Berkeley
database routines. Often this is in the db-devel package.
--
2.17.0
^ permalink raw reply related
* [PATCH iproute2 2/2] arpd: remove pthread dependency
From: Baruch Siach @ 2018-05-01 12:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Baruch Siach
In-Reply-To: <1918c6139ac3ee9affe8e62817f30b110ab235c7.1525178588.git.baruch@tkos.co.il>
Explicit link with pthread is not needed when linking dynamically. Even
static link with recent libdb does not pull in the code that uses
pthread. Finally, the configure check introduced in commit a25df4887d7
(configure: Check for Berkeley DB for arpd compilation) does not add
-lpthread to its link command.
This change allows arpd build with toolchains that do not provide
threads support.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
misc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/misc/Makefile b/misc/Makefile
index 34ef6b21b4ed..b2dd6b26e2dc 100644
--- a/misc/Makefile
+++ b/misc/Makefile
@@ -25,7 +25,7 @@ rtacct: rtacct.c
$(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o rtacct rtacct.c $(LDLIBS) -lm
arpd: arpd.c
- $(QUIET_CC)$(CC) $(CFLAGS) -I$(DBM_INCLUDE) $(LDFLAGS) -o arpd arpd.c $(LDLIBS) -ldb -lpthread
+ $(QUIET_CC)$(CC) $(CFLAGS) -I$(DBM_INCLUDE) $(LDFLAGS) -o arpd arpd.c $(LDLIBS) -ldb
ssfilter.c: ssfilter.y
$(QUIET_YACC)bison ssfilter.y -o ssfilter.c
--
2.17.0
^ permalink raw reply related
* RE: [PATCH] tipc: fix a potential missing-check bug
From: Jon Maloy @ 2018-05-01 12:01 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Ying Xue, David S. Miller,
open list:TIPC NETWORK LAYER, open list:TIPC NETWORK LAYER,
open list
In-Reply-To: <1525148761-11091-1-git-send-email-wang6495@umn.edu>
> -----Original Message-----
> From: Wenwen Wang [mailto:wang6495@umn.edu]
> Sent: Tuesday, May 01, 2018 00:26
> To: Wenwen Wang <wang6495@umn.edu>
> Cc: Kangjie Lu <kjlu@umn.edu>; Jon Maloy <jon.maloy@ericsson.com>; Ying
> Xue <ying.xue@windriver.com>; David S. Miller <davem@davemloft.net>;
> open list:TIPC NETWORK LAYER <netdev@vger.kernel.org>; open list:TIPC
> NETWORK LAYER <tipc-discussion@lists.sourceforge.net>; open list <linux-
> kernel@vger.kernel.org>
> Subject: [PATCH] tipc: fix a potential missing-check bug
>
> In tipc_link_xmit(), the member field "len" of l->backlog[imp] must be less
> than the member field "limit" of l->backlog[imp] when imp is equal to
> TIPC_SYSTEM_IMPORTANCE. Otherwise, an error code, i.e., -ENOBUFS, is
> returned. This is enforced by the security check. However, at the end of
> tipc_link_xmit(), the length of "list" is added to l->backlog[imp].len without
> any further check. This can potentially cause unexpected values for
> l->backlog[imp].len. If imp is equal to TIPC_SYSTEM_IMPORTANCE and the
> original value of l->backlog[imp].len is less than l->backlog[imp].limit, after
> this addition, l->backlog[imp] could be larger than
> l->backlog[imp].limit.
It can, but only once. That is the intention with allowing oversubscription. This is expected and permitted.
At next sending attempt, if the send queue has not been reduced in the meantime, the link will be reset, as intended.
> That means the security check can potentially be
> bypassed, especially when an adversary can control the length of "list".
The length of 'list' is entirely controlled by TIPC itself, either by the socket layer (where length always is 1 for this type of messages) or
name_dist, In the latter case the length is also 1, except at first link setup, when there guaranteed is no congestion anyway.
I appreciate your interest, but this patch is not needed.
BR
///jon
>
> This patch performs such a check after the modification to
> l->backlog[imp].len (if imp is TIPC_SYSTEM_IMPORTANCE) to avoid such
> security issues. An error code will be returned if an unexpected value of
> l->backlog[imp].len is generated.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> net/tipc/link.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/tipc/link.c b/net/tipc/link.c index 695acb7..62972fa 100644
> --- a/net/tipc/link.c
> +++ b/net/tipc/link.c
> @@ -948,6 +948,11 @@ int tipc_link_xmit(struct tipc_link *l, struct
> sk_buff_head *list,
> continue;
> }
> l->backlog[imp].len += skb_queue_len(list);
> + if (imp == TIPC_SYSTEM_IMPORTANCE &&
> + l->backlog[imp].len >= l->backlog[imp].limit) {
> + pr_warn("%s<%s>, link overflow", link_rst_msg, l-
> >name);
> + return -ENOBUFS;
> + }
> skb_queue_splice_tail_init(list, backlogq);
> }
> l->snd_nxt = seqno;
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-01 11:36 UTC (permalink / raw)
To: Cong Wang, Dave Taht; +Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <CAM_iQpXTYJ7nkFW=H_ZudUksP1UHT=cyLPv6M-XjekfeuzYbXg@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Mon, Apr 30, 2018 at 2:27 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Mon, Apr 30, 2018 at 2:21 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>> sch_cake targets the home router use case and is intended to squeeze the
>>>> most bandwidth and latency out of even the slowest ISP links and routers,
>>>> while presenting an API simple enough that even an ISP can configure it.
>>>>
>>>> Example of use on a cable ISP uplink:
>>>>
>>>> tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter
>>>>
>>>> To shape a cable download link (ifb and tc-mirred setup elided)
>>>>
>>>> tc qdisc add dev ifb0 cake bandwidth 200mbit nat docsis ingress wash
>>>>
>>>> CAKE is filled with:
>>>>
>>>> * A hybrid Codel/Blue AQM algorithm, "Cobalt", tied to an FQ_Codel
>>>> derived Flow Queuing system, which autoconfigures based on the bandwidth.
>>>> * A novel "triple-isolate" mode (the default) which balances per-host
>>>> and per-flow FQ even through NAT.
>>>> * An deficit based shaper, that can also be used in an unlimited mode.
>>>> * 8 way set associative hashing to reduce flow collisions to a minimum.
>>>> * A reasonable interpretation of various diffserv latency/loss tradeoffs.
>>>> * Support for zeroing diffserv markings for entering and exiting traffic.
>>>> * Support for interacting well with Docsis 3.0 shaper framing.
>>>> * Extensive support for DSL framing types.
>>>> * Support for ack filtering.
>>>
>>> Why this TCP ACK filtering has to be built into CAKE qdisc rather than
>>> an independent TC filter? Why other qdisc's can't use it?
>>
>> I actually have a tc - bpf based ack filter, during the development of
>> cake's ack-thinner, that I should submit one of these days. It
>> proved to be of limited use.
>
> Yeah.
>
>>
>> Probably the biggest mistake we made is by calling this cake feature a
>> filter. It isn't.
>
>
> It inspects the payload of each packet and drops packets, therefore it
> is a filter by definition, no matter how you name it.
Well, sure, but the distinguishing feature is that it is a *stateful*
filter, whose reaction depends on the current state of the queue.
>> Maybe we should have called it a "thinner" or something like that? In
>> order to properly "thin" or "reduce" an ack stream
>> you have to have a queue to look at and some related state. TC filters
>> do not operate on queues, qdiscs do. Thus the "ack-filter" here is
>> deeply embedded into cake's flow isolation and queue structures.
>
> TC filters are installed on qdiscs and in the beginning qdiscs were
> queues,for example, pfifo. We already have flow-based filters too
> (cls_flower),so we can make them work together, although probably it
> is not straight forward.
Yeah, but filters don't have any visibility into the queue. You could
conceivably amend the TC filter API to allow this, but it would be quite
intrusive, especially for complicated qdiscs.
I'm not opposed to seeing an API change and generalising the CAKE ACK
filter based on it. But that is certainly out of scope for this
submission...
-Toke
^ permalink raw reply
* Re: [PATCH net-next] udp: Complement partial checksum for GSO packet
From: Willem de Bruijn @ 2018-05-01 10:06 UTC (permalink / raw)
To: Sean Tranchetti
Cc: Willem de Bruijn, David Miller, Network Development,
Subash Abhinov Kasiviswanathan
In-Reply-To: <1525132862-7672-1-git-send-email-stranche@codeaurora.org>
On Tue, May 1, 2018 at 2:01 AM, Sean Tranchetti <stranche@codeaurora.org> wrote:
> Using the udp_v4_check() function to calculate the pseudo header
> for the newly segmented UDP packets results in assigning the complement
> of the value to the UDP header checksum field.
>
> Always undo the complement the partial checksum value in order to
> match the case where GSO is not used on the UDP transmit path.
>
> Fixes: ee80d1ebe5ba ("udp: add udp gso")
> Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> ---
> net/ipv4/udp_offload.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index f78fb36..0062570 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -223,6 +223,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
> csum_replace2(&uh->check, htons(mss),
> htons(seg->len - hdrlen - sizeof(*uh)));
>
> + uh->check = ~uh->check;
> seg->destructor = sock_wfree;
> seg->sk = sk;
> sum_truesize += seg->truesize;
Thanks, this looks plausible. I may have been mistaken by evaluation
showing packets arriving at the peer with the correct checksum before.
On retesting, packets arrive with correct checksum in both cases, and
even when setting purposely bad uh->check values.
Perhaps the two platforms I tested on (bnx2x, mlx4) ignore the pseudo
header and recompute from scratch if CHECKSUM_PARTIAL is set for
udp. Still having a look..
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/6] xen-netfront: add range check for Tx response id
From: Wei Liu @ 2018-05-01 10:05 UTC (permalink / raw)
To: Marek Marczykowski-Górecki
Cc: xen-devel, Juergen Gross, open list:NETWORKING DRIVERS, stable,
open list, Boris Ostrovsky, Wei Liu
In-Reply-To: <960c6d6300fd3450ae9fb1de1c412bef7dbae992.1525122026.git-series.marmarek@invisiblethingslab.com>
On Mon, Apr 30, 2018 at 11:01:48PM +0200, Marek Marczykowski-Górecki wrote:
> Tx response ID is fetched from shared page, so make sure it is sane
> before using it as an array index.
>
> CC: stable@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> ---
> drivers/net/xen-netfront.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 934b8a4..55c9b25 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -394,6 +394,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
> continue;
>
> id = txrsp.id;
> + BUG_ON(id >= NET_TX_RING_SIZE);
It is better to use ARRAY_SIZE here.
Wei.
^ permalink raw reply
* [PATCH] wireless: ipw2200: fix spelling mistake: "functionalitis" -> "functionalities"
From: Colin King @ 2018-05-01 9:36 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in module parameter description text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 87a5e414c2f7..ba3fb1d2ddb4 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -12012,7 +12012,7 @@ MODULE_PARM_DESC(rtap_iface, "create the rtap interface (1 - create, default 0)"
#ifdef CONFIG_IPW2200_QOS
module_param(qos_enable, int, 0444);
-MODULE_PARM_DESC(qos_enable, "enable all QoS functionalitis");
+MODULE_PARM_DESC(qos_enable, "enable all QoS functionalities");
module_param(qos_burst_enable, int, 0444);
MODULE_PARM_DESC(qos_burst_enable, "enable QoS burst mode");
--
2.17.0
^ permalink raw reply related
* Re: KMSAN: uninit-value in _decode_session6
From: syzbot @ 2018-05-01 9:12 UTC (permalink / raw)
To: davem, herbert, kuznet, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs, yoshfuji
In-Reply-To: <000000000000311cdd0569510cc7@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?id=6550343064223744
kernel config:
https://syzkaller.appspot.com/x/.config?id=328654897048964367
dashboard link: https://syzkaller.appspot.com/bug?extid=2974b85346f85b586f4d
compiler: clang version 7.0.0 (trunk 329391)
syzkaller
repro:https://syzkaller.appspot.com/x/repro.syz?id=5023772637659136
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5102535626981376
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2974b85346f85b586f4d@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in _decode_session6+0x6d2/0x16e0
net/ipv6/xfrm6_policy.c:151
CPU: 0 PID: 4529 Comm: syz-executor165 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
_decode_session6+0x6d2/0x16e0 net/ipv6/xfrm6_policy.c:151
__xfrm_decode_session+0x151/0x200 net/xfrm/xfrm_policy.c:2368
xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
icmpv6_route_lookup net/ipv6/icmp.c:372 [inline]
icmp6_send+0x2bf7/0x3730 net/ipv6/icmp.c:551
icmpv6_send+0xe0/0x110 net/ipv6/ip6_icmp.c:43
ip6_link_failure+0x8f/0x580 net/ipv6/route.c:2034
dst_link_failure include/net/dst.h:426 [inline]
ip6_tnl_xmit+0x1423/0x3af0 net/ipv6/ip6_tunnel.c:1215
ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1367 [inline]
ip6_tnl_start_xmit+0x1cc0/0x1ef0 net/ipv6/ip6_tunnel.c:1390
__netdev_start_xmit include/linux/netdevice.h:4066 [inline]
netdev_start_xmit include/linux/netdevice.h:4075 [inline]
xmit_one net/core/dev.c:3026 [inline]
dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042
__dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
neigh_direct_output+0x42/0x50 net/core/neighbour.c:1390
neigh_output include/net/neighbour.h:482 [inline]
ip6_finish_output2+0x1d01/0x2130 net/ipv6/ip6_output.c:120
ip6_finish_output+0xae9/0xba0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip6_output+0x597/0x6c0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:443 [inline]
ip6_local_out+0x15e/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1682 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1702
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x4235/0x4fb0 net/ipv6/raw.c:935
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
sock_write_iter+0x3b9/0x470 net/socket.c:909
call_write_iter include/linux/fs.h:1782 [inline]
new_sync_write fs/read_write.c:469 [inline]
__vfs_write+0x7fb/0x9f0 fs/read_write.c:482
vfs_write+0x463/0x8d0 fs/read_write.c:544
SYSC_write+0x172/0x360 fs/read_write.c:589
SyS_write+0x55/0x80 fs/read_write.c:581
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4418b9
RSP: 002b:00007ffece331e68 EFLAGS: 00000217 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004418b9
RDX: 000000000000036b RSI: 0000000020000240 RDI: 0000000000000004
RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000217 R12: 00000000004025b0
R13: 0000000000402640 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2737 [inline]
__kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
__kmalloc_reserve net/core/skbuff.c:138 [inline]
pskb_expand_head+0x21d/0x1a70 net/core/skbuff.c:1458
__pskb_pull_tail+0x1d7/0x2300 net/core/skbuff.c:1878
pskb_may_pull include/linux/skbuff.h:2112 [inline]
ip6_tnl_parse_tlv_enc_lim+0x7f5/0xa90 net/ipv6/ip6_tunnel.c:411
ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0x911/0x1ef0 net/ipv6/ip6_tunnel.c:1390
__netdev_start_xmit include/linux/netdevice.h:4066 [inline]
netdev_start_xmit include/linux/netdevice.h:4075 [inline]
xmit_one net/core/dev.c:3026 [inline]
dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042
__dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
neigh_direct_output+0x42/0x50 net/core/neighbour.c:1390
neigh_output include/net/neighbour.h:482 [inline]
ip6_finish_output2+0x1d01/0x2130 net/ipv6/ip6_output.c:120
ip6_finish_output+0xae9/0xba0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip6_output+0x597/0x6c0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:443 [inline]
ip6_local_out+0x15e/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1682 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1702
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x4235/0x4fb0 net/ipv6/raw.c:935
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
sock_write_iter+0x3b9/0x470 net/socket.c:909
call_write_iter include/linux/fs.h:1782 [inline]
new_sync_write fs/read_write.c:469 [inline]
__vfs_write+0x7fb/0x9f0 fs/read_write.c:482
vfs_write+0x463/0x8d0 fs/read_write.c:544
SYSC_write+0x172/0x360 fs/read_write.c:589
SyS_write+0x55/0x80 fs/read_write.c:581
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
^ permalink raw reply
* Re: [PATCH RFC 4/9] veth: Use NAPI for XDP
From: Jesper Dangaard Brouer @ 2018-05-01 8:43 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: Toshiaki Makita, netdev, brouer
In-Reply-To: <79ff8b87-2ee2-ce60-36f3-6f3f79cb3272@lab.ntt.co.jp>
On Tue, 1 May 2018 17:02:34 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/05/01 16:50, Jesper Dangaard Brouer wrote:
> > On Tue, 24 Apr 2018 23:39:18 +0900
> > Toshiaki Makita <toshiaki.makita1@gmail.com> wrote:
> >
> >> +static int veth_xdp_enqueue(struct veth_priv *priv, void *ptr)
> >> +{
> >> + if (unlikely(ptr_ring_produce(&priv->xdp_ring, ptr)))
> >> + return -ENOSPC;
> >> +
> >> + return 0;
> >> +}
> >
> > Here we have a lock per (enqueued) packet. I'm working on changing the
> > ndo_xdp_xmit API to allow bulking. And the tun driver have exact same
> > issue/need.
>
> Probably I should have noted in commitlog, but this per-packet lock is
> removed in patch 9.
> I'm curious about if any change is needed by your new API.
Again, I'm just moving this into the generic code, to avoid having to
implement this for every driver.
Plus, with CONFIG_RETPOLINE we have the advantage of only calling
ndo_xdp_xmit once (indirect function pointer call).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net-next 2/2] mlxsw: spectrum_router: Return an error for routes added after abort
From: Ido Schimmel @ 2018-05-01 8:16 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, dsahern, mlxsw, Ido Schimmel
In-Reply-To: <20180501081639.29162-1-idosch@mellanox.com>
We currently do not perform accounting in the driver and thus can't
reject routes before resources are exceeded.
However, in order to make users aware of the fact that routes are no
longer offloaded we can return an error for routes configured after the
abort mechanism was triggered.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index baea97560029..c9fce669cee4 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -5928,6 +5928,13 @@ static int mlxsw_sp_router_fib_event(struct notifier_block *nb,
router->mlxsw_sp);
if (!err || info->extack)
return notifier_from_errno(err);
+ break;
+ case FIB_EVENT_ENTRY_ADD:
+ if (router->aborted) {
+ NL_SET_ERR_MSG_MOD(info->extack, "FIB offload was aborted. Not configuring route");
+ return notifier_from_errno(-EINVAL);
+ }
+ break;
}
fib_work = kzalloc(sizeof(*fib_work), GFP_ATOMIC);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 1/2] mlxsw: spectrum_router: Return an error for non-default FIB rules
From: Ido Schimmel @ 2018-05-01 8:16 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, dsahern, mlxsw, Ido Schimmel
In-Reply-To: <20180501081639.29162-1-idosch@mellanox.com>
Since commit 9776d32537d2 ("net: Move call_fib_rule_notifiers up in
fib_nl_newrule") it is possible to forbid the installation of
unsupported FIB rules.
Have mlxsw return an error for non-default FIB rules in addition to the
existing extack message.
Example:
# ip rule add from 198.51.100.1 table 10
Error: mlxsw_spectrum: FIB rules not supported.
Note that offload is only aborted when non-default FIB rules are already
installed and merely replayed during module initialization.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 8e4edb634b11..baea97560029 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -5899,7 +5899,7 @@ static int mlxsw_sp_router_fib_rule_event(unsigned long event,
}
if (err < 0)
- NL_SET_ERR_MSG_MOD(extack, "FIB rules not supported. Aborting offload");
+ NL_SET_ERR_MSG_MOD(extack, "FIB rules not supported");
return err;
}
@@ -5926,8 +5926,8 @@ static int mlxsw_sp_router_fib_event(struct notifier_block *nb,
case FIB_EVENT_RULE_DEL:
err = mlxsw_sp_router_fib_rule_event(event, info,
router->mlxsw_sp);
- if (!err)
- return NOTIFY_DONE;
+ if (!err || info->extack)
+ return notifier_from_errno(err);
}
fib_work = kzalloc(sizeof(*fib_work), GFP_ATOMIC);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/2] mlxsw: Reject unsupported FIB configurations
From: Ido Schimmel @ 2018-05-01 8:16 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, dsahern, mlxsw, Ido Schimmel
Recently it became possible for listeners of the FIB notification chain
to veto operations such as addition of routes and rules.
Adjust the mlxsw driver to take advantage of it and return an error for
unsupported FIB rules and for routes configured after the abort
mechanism was triggered (due to exceeded resources for example).
Ido Schimmel (2):
mlxsw: spectrum_router: Return an error for non-default FIB rules
mlxsw: spectrum_router: Return an error for routes added after abort
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: [PATCH RFC 6/9] veth: Add ndo_xdp_xmit
From: Jesper Dangaard Brouer @ 2018-05-01 8:14 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, netdev, Tariq Toukan, brouer, Daniel Borkmann,
Alexei Starovoitov, Eran Ben Elisha
In-Reply-To: <6ed7c0c5-d6cb-7870-38da-4bb49707a63c@lab.ntt.co.jp>
On Tue, 1 May 2018 10:02:01 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/05/01 2:27, Jesper Dangaard Brouer wrote:
> > On Thu, 26 Apr 2018 19:52:40 +0900
> > Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >
> >> On 2018/04/26 5:24, Jesper Dangaard Brouer wrote:
> >>> On Tue, 24 Apr 2018 23:39:20 +0900
> >>> Toshiaki Makita <toshiaki.makita1@gmail.com> wrote:
> >>>
> >>>> +static int veth_xdp_xmit(struct net_device *dev, struct xdp_frame *frame)
> >>>> +{
> >>>> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> >>>> + int headroom = frame->data - (void *)frame;
> >>>> + struct net_device *rcv;
> >>>> + int err = 0;
> >>>> +
> >>>> + rcv = rcu_dereference(priv->peer);
> >>>> + if (unlikely(!rcv))
> >>>> + return -ENXIO;
> >>>> +
> >>>> + rcv_priv = netdev_priv(rcv);
> >>>> + /* xdp_ring is initialized on receive side? */
> >>>> + if (rcu_access_pointer(rcv_priv->xdp_prog)) {
> >>>> + err = xdp_ok_fwd_dev(rcv, frame->len);
> >>>> + if (unlikely(err))
> >>>> + return err;
> >>>> +
> >>>> + err = veth_xdp_enqueue(rcv_priv, veth_xdp_to_ptr(frame));
> >>>> + } else {
> >>>> + struct sk_buff *skb;
> >>>> +
> >>>> + skb = veth_build_skb(frame, headroom, frame->len, 0);
> >>>> + if (unlikely(!skb))
> >>>> + return -ENOMEM;
> >>>> +
> >>>> + /* Get page ref in case skb is dropped in netif_rx.
> >>>> + * The caller is responsible for freeing the page on error.
> >>>> + */
> >>>> + get_page(virt_to_page(frame->data));
> >>>
> >>> I'm not sure you can make this assumption, that xdp_frames coming from
> >>> another device driver uses a refcnt based memory model. But maybe I'm
> >>> confused, as this looks like an SKB receive path, but in the
> >>> ndo_xdp_xmit().
> >>
> >> I find this path similar to cpumap, which creates skb from redirected
> >> xdp frame. Once it is converted to skb, skb head is freed by
> >> page_frag_free, so anyway I needed to get the refcount here regardless
> >> of memory model.
> >
> > Yes I know, I wrote cpumap ;-)
> >
> > First of all, I don't want to see such xdp_frame to SKB conversion code
> > in every driver. Because that increase the chances of errors. And
> > when looking at the details, then it seems that you have made the
> > mistake of making it possible to leak xdp_frame info to the SKB (which
> > cpumap takes into account).
>
> Do you mean leaving xdp_frame in skb->head is leaking something? how?
Like commit 97e19cce05e5 ("bpf: reserve xdp_frame size in xdp headroom")
and commit 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data
on page reuse").
But this time, the concern is a bpf_prog attached at TC/bpf_cls level, that can
that can adjust head via bpf_skb_change_head (for XDP it is
bpf_xdp_adjust_head) into the area used by xdp_frame. As described in
https://git.kernel.org/davem/net-next/c/6dfb970d3dbd in is not super
critical at the moment, as this _currently_ runs as CAP_SYS_ADMIN, but
we would like to move towards CAP_NET_ADMIN.
> > Second, I think the refcnt scheme here is wrong. The xdp_frame should
> > be "owned" by XDP and have the proper refcnt to deliver it directly to
> > the network stack.
> >
> > Third, if we choose that we want a fallback, in-case XDP is not enabled
> > on egress dev (but it have an ndo_xdp_xmit), then it should be placed
> > in the generic/core code. E.g. __bpf_tx_xdp_map() could look at the
> > return code from dev->netdev_ops->ndo_xdp() and create an SKB. (Hint,
> > this would make it easy to implement TX bulking towards the dev).
>
> Right, this is a much cleaner way.
>
> Although I feel like we should add this fallback for veth because it
> requires something which is different from other drivers (enabling XDP
> on the peer device of the egress device),
(This is why I Cc'ed Tariq...)
This is actually a general problem with the xdp "xmit" side (and not
specific to veth driver). The problem exists for other drivers as well.
The problem is that a driver can implement ndo_xdp_xmit(), but the
driver might not have allocated the necessary XDP TX-queue resources
yet (or it might not be possible due to system resource limits).
The current "hack" is to load an XDP prog on the egress device, and
then assume that this cause the driver to also allocate the XDP
ndo_xdo_xmit side HW resources. This is IMHO a wrong assumption.
We need a more generic way to test if a net_device is "ready/enabled"
for handling xdp_frames via ndo_xdp_xmit. And Tariq had some ideas on
how to implement this...
My opinion is that it is a waste of (HW/mem) resources to always
allocate resources for ndo_xdp_xmit when loading an XDP program.
Because what if my use-cases are XDP_DROP DDoS filter, or CPUMAP
redirect load-balancer, then I don't want/need ndo_xdp_xmit. E.g.
today using ixgbe on machines with more than 96 CPUs, will fail due to
limited TX queue resources. Thus, blocking the mentioned use-cases.
> I'll drop the part for now. It should not be resolved in the driver
> code.
Thank you.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH RFC 4/9] veth: Use NAPI for XDP
From: Toshiaki Makita @ 2018-05-01 8:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Toshiaki Makita, netdev
In-Reply-To: <20180501095008.207c354f@brouer.com>
On 2018/05/01 16:50, Jesper Dangaard Brouer wrote:
> On Tue, 24 Apr 2018 23:39:18 +0900
> Toshiaki Makita <toshiaki.makita1@gmail.com> wrote:
>
>> +static int veth_xdp_enqueue(struct veth_priv *priv, void *ptr)
>> +{
>> + if (unlikely(ptr_ring_produce(&priv->xdp_ring, ptr)))
>> + return -ENOSPC;
>> +
>> + return 0;
>> +}
>
> Here we have a lock per (enqueued) packet. I'm working on changing the
> ndo_xdp_xmit API to allow bulking. And the tun driver have exact same
> issue/need.
Probably I should have noted in commitlog, but this per-packet lock is
removed in patch 9.
I'm curious about if any change is needed by your new API.
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH] change the comment of vti6_ioctl
From: Steffen Klassert @ 2018-05-01 8:00 UTC (permalink / raw)
To: David Miller; +Cc: sunlw.fnst, netdev, herbert
In-Reply-To: <20180430.115731.1213104451620131850.davem@davemloft.net>
On Mon, Apr 30, 2018 at 11:57:31AM -0400, David Miller wrote:
> From: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
> Date: Sun, 29 Apr 2018 15:05:52 +0800
>
> > The comment of vti6_ioctl() is wrong. which use vti6_tnl_ioctl
> > instead of vti6_ioctl.
> >
> > Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
>
> Please CC: the IPSEC maintainers on future patch submissions to IPSEC
> files, as per the top level MAINTAINERS file.
>
> Steffen, please queue this up, thank you.
Now applied to ipsec-next, thanks everyone!
^ permalink raw reply
* Re: IP_PKTINFO broken by acf568ee859f0 (xfrm: Reinject transport-mode packets through tasklet)
From: Steffen Klassert @ 2018-05-01 7:51 UTC (permalink / raw)
To: Maxime Bizon; +Cc: Herbert Xu, netdev
In-Reply-To: <1524863813.15003.174.camel@sakura.staff.proxad.net>
On Fri, Apr 27, 2018 at 11:16:53PM +0200, Maxime Bizon wrote:
>
> Hello Herbert,
>
> That patch just went into stable 4.14 and is causing a regression on my
> setup.
>
> Basically, IP_PKTINFO does not work anymore on transport-mode packets,
> because skb->cb is now used to store the finish callback.
>
> Was that expected or is it an unforeseen side effect ?
This should be fixed by:
commit 9a3fb9fb84cc ("xfrm: Fix transport mode skb control buffer usage.")
^ permalink raw reply
* Re: [PATCH RFC 4/9] veth: Use NAPI for XDP
From: Jesper Dangaard Brouer @ 2018-05-01 7:50 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: brouer, netdev, Toshiaki Makita
In-Reply-To: <20180424143923.26519-5-toshiaki.makita1@gmail.com>
On Tue, 24 Apr 2018 23:39:18 +0900
Toshiaki Makita <toshiaki.makita1@gmail.com> wrote:
> +static int veth_xdp_enqueue(struct veth_priv *priv, void *ptr)
> +{
> + if (unlikely(ptr_ring_produce(&priv->xdp_ring, ptr)))
> + return -ENOSPC;
> +
> + return 0;
> +}
Here we have a lock per (enqueued) packet. I'm working on changing the
ndo_xdp_xmit API to allow bulking. And the tun driver have exact same
issue/need.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v9 3/4] virtio_net: Extend virtio to use VF datapath when available
From: Jiri Pirko @ 2018-05-01 7:33 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: mst, stephen, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, aaron.f.brown
In-Reply-To: <c965d7f2-9ba6-fc82-ce1c-4d70c3aceb6d@intel.com>
Mon, Apr 30, 2018 at 09:26:34PM CEST, sridhar.samudrala@intel.com wrote:
>On 4/30/2018 12:12 AM, Jiri Pirko wrote:
>> Mon, Apr 30, 2018 at 05:00:33AM CEST, sridhar.samudrala@intel.com wrote:
>> > On 4/28/2018 1:24 AM, Jiri Pirko wrote:
>> > > Fri, Apr 27, 2018 at 07:06:59PM CEST, sridhar.samudrala@intel.com wrote:
>> > > > This patch enables virtio_net to switch over to a VF datapath when a VF
>> > > > netdev is present with the same MAC address. It allows live migration
>> > > > of a VM with a direct attached VF without the need to setup a bond/team
>> > > > between a VF and virtio net device in the guest.
>> > > >
>> > > > The hypervisor needs to enable only one datapath at any time so that
>> > > > packets don't get looped back to the VM over the other datapath. When a VF
>> > > Why? Both datapaths could be enabled at a time. Why the loop on
>> > > hypervisor side would be a problem. This in not an issue for
>> > > bonding/team as well.
>> > Somehow the hypervisor needs to make sure that the broadcasts/multicasts from the VM
>> > sent over the VF datapath don't get looped back to the VM via the virtio-net datapth.
>> Why? Please see below.
>>
>>
>> > This can happen if both datapaths are enabled at the same time.
>> >
>> > I would think this is an issue even with bonding/team as well when virtio-net and
>> > VF are backed by the same PF.
>> >
>> >
>> I believe that the scenario is the same as on an ordinary nic/swich
>> network:
>>
>> ...................
>>
>> host
>> bond0
>> / \
>> eth0 eth1
>> | |
>> ...................
>> | |
>> p1 p2
>>
>> switch
>>
>> ...................
>>
>> It is perfectly valid to p1 and p2 be up and "bridged" together. Bond
>> has to cope with loop-backed frames. "Failover driver" should too,
>> it's the same scenario.
>
>OK. So looks like we should be able to handle this by returning RX_HANDLER_EXACT
>for frames received on standby device when primary is present.
Yep.
^ permalink raw reply
* [PATCH] tipc: fix a potential missing-check bug
From: Wenwen Wang @ 2018-05-01 4:26 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Jon Maloy, Ying Xue, David S. Miller,
open list:TIPC NETWORK LAYER, open list:TIPC NETWORK LAYER,
open list
In tipc_link_xmit(), the member field "len" of l->backlog[imp] must
be less than the member field "limit" of l->backlog[imp] when imp is
equal to TIPC_SYSTEM_IMPORTANCE. Otherwise, an error code, i.e., -ENOBUFS,
is returned. This is enforced by the security check. However, at the end
of tipc_link_xmit(), the length of "list" is added to l->backlog[imp].len
without any further check. This can potentially cause unexpected values for
l->backlog[imp].len. If imp is equal to TIPC_SYSTEM_IMPORTANCE and the
original value of l->backlog[imp].len is less than l->backlog[imp].limit,
after this addition, l->backlog[imp] could be larger than
l->backlog[imp].limit. That means the security check can potentially be
bypassed, especially when an adversary can control the length of "list".
This patch performs such a check after the modification to
l->backlog[imp].len (if imp is TIPC_SYSTEM_IMPORTANCE) to avoid such
security issues. An error code will be returned if an unexpected value of
l->backlog[imp].len is generated.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
net/tipc/link.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 695acb7..62972fa 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -948,6 +948,11 @@ int tipc_link_xmit(struct tipc_link *l, struct sk_buff_head *list,
continue;
}
l->backlog[imp].len += skb_queue_len(list);
+ if (imp == TIPC_SYSTEM_IMPORTANCE &&
+ l->backlog[imp].len >= l->backlog[imp].limit) {
+ pr_warn("%s<%s>, link overflow", link_rst_msg, l->name);
+ return -ENOBUFS;
+ }
skb_queue_splice_tail_init(list, backlogq);
}
l->snd_nxt = seqno;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ipv6: Allow non-gateway ECMP for IPv6
From: David Ahern @ 2018-05-01 2:59 UTC (permalink / raw)
To: Thomas Winter, netdev
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Ido Schimmel
In-Reply-To: <20180430211529.8295-1-Thomas.Winter@alliedtelesis.co.nz>
On 4/30/18 3:15 PM, Thomas Winter wrote:
> It is valid to have static routes where the nexthop
> is an interface not an address such as tunnels.
> For IPv4 it was possible to use ECMP on these routes
> but not for IPv6.
>
> Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> ---
> include/net/ip6_route.h | 3 +--
> net/ipv6/ip6_fib.c | 3 ---
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
Interesting. Existing code inserts the dev nexthop as a separate route.
Change looks good to me.
Acked-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox