* Re: [PATCH net 6/7] net: ip6_gre: Split up ip6gre_changelink()
From: William Tu @ 2018-05-17 19:48 UTC (permalink / raw)
To: Petr Machata
Cc: Linux Kernel Network Developers, David Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Dmitry Kozlov
In-Reply-To: <8cc069a772b633ee9c2ba4f7cb8564ac2e097dac.1526567568.git.petrm@mellanox.com>
On Thu, May 17, 2018 at 7:36 AM, Petr Machata <petrm@mellanox.com> wrote:
> Extract from ip6gre_changelink() a reusable function
> ip6gre_changelink_common(). This will allow introduction of
> ERSPAN-specific _changelink() function with not a lot of code
> duplication.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
LGTM.
Acked-by: William Tu <u9012063@gmail.com>
> net/ipv6/ip6_gre.c | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 4dfa21d..c17e38b 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -1921,37 +1921,52 @@ static int ip6gre_newlink(struct net *src_net, struct net_device *dev,
> return err;
> }
>
> -static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[],
> - struct nlattr *data[],
> - struct netlink_ext_ack *extack)
> +static struct ip6_tnl *
> +ip6gre_changelink_common(struct net_device *dev, struct nlattr *tb[],
> + struct nlattr *data[], struct __ip6_tnl_parm *p_p,
> + struct netlink_ext_ack *extack)
> {
> struct ip6_tnl *t, *nt = netdev_priv(dev);
> struct net *net = nt->net;
> struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
> - struct __ip6_tnl_parm p;
> struct ip_tunnel_encap ipencap;
>
> if (dev == ign->fb_tunnel_dev)
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
>
> if (ip6gre_netlink_encap_parms(data, &ipencap)) {
> int err = ip6_tnl_encap_setup(nt, &ipencap);
>
> if (err < 0)
> - return err;
> + return ERR_PTR(err);
> }
>
> - ip6gre_netlink_parms(data, &p);
> + ip6gre_netlink_parms(data, p_p);
>
> - t = ip6gre_tunnel_locate(net, &p, 0);
> + t = ip6gre_tunnel_locate(net, p_p, 0);
>
> if (t) {
> if (t->dev != dev)
> - return -EEXIST;
> + return ERR_PTR(-EEXIST);
> } else {
> t = nt;
> }
>
> + return t;
> +}
> +
> +static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[],
> + struct nlattr *data[],
> + struct netlink_ext_ack *extack)
> +{
> + struct ip6gre_net *ign = net_generic(dev_net(dev), ip6gre_net_id);
> + struct __ip6_tnl_parm p;
> + struct ip6_tnl *t;
> +
> + t = ip6gre_changelink_common(dev, tb, data, &p, extack);
> + if (IS_ERR(t))
> + return PTR_ERR(t);
> +
> ip6gre_tunnel_unlink(ign, t);
> ip6gre_tnl_change(t, &p, !tb[IFLA_MTU]);
> ip6gre_tunnel_link(ign, t);
> --
> 2.4.11
>
^ permalink raw reply
* Re: [PATCH] bonding: introduce link change helper
From: David Miller @ 2018-05-17 19:51 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: netdev
In-Reply-To: <1526522963-4317-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date: Wed, 16 May 2018 19:09:23 -0700
> Introduce an new common helper to avoid redundancy.
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net 7/7] net: ip6_gre: Fix ip6erspan hlen calculation
From: William Tu @ 2018-05-17 19:52 UTC (permalink / raw)
To: Petr Machata
Cc: Linux Kernel Network Developers, David Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Dmitry Kozlov
In-Reply-To: <c010e9a0dd4fdf31ea8c9308be04e6e93bd30c5c.1526567568.git.petrm@mellanox.com>
On Thu, May 17, 2018 at 7:36 AM, Petr Machata <petrm@mellanox.com> wrote:
> Even though ip6erspan_tap_init() sets up hlen and tun_hlen according to
> what ERSPAN needs, it goes ahead to call ip6gre_tnl_link_config() which
> overwrites these settings with GRE-specific ones.
>
> Similarly for changelink callbacks, which are handled by
> ip6gre_changelink() calls ip6gre_tnl_change() calls
> ip6gre_tnl_link_config() as well.
>
> The difference ends up being 12 vs. 20 bytes, and this is generally not
> a problem, because a 12-byte request likely ends up allocating more and
> the extra 8 bytes are thus available. However correct it is not.
>
> So replace the newlink and changelink callbacks with an ERSPAN-specific
> ones, reusing the newly-introduced _common() functions.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
Acked-by: William Tu <u9012063@gmail.com>
Thanks, using ERSPAN-specific newlink and changelink is also on
my todo list. I'm hitting another issue related to the shared collect_md_tun
between erspan and gre, I will make my patch based on this series.
> net/ipv6/ip6_gre.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 65 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index c17e38b..36b1669 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -81,6 +81,7 @@ static int ip6gre_tunnel_init(struct net_device *dev);
> static void ip6gre_tunnel_setup(struct net_device *dev);
> static void ip6gre_tunnel_link(struct ip6gre_net *ign, struct ip6_tnl *t);
> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu);
> +static void ip6erspan_tnl_link_config(struct ip6_tnl *t, int set_mtu);
>
> /* Tunnel hash table */
>
> @@ -1751,6 +1752,19 @@ static const struct net_device_ops ip6gre_tap_netdev_ops = {
> .ndo_get_iflink = ip6_tnl_get_iflink,
> };
>
> +static int ip6erspan_calc_hlen(struct ip6_tnl *tunnel)
> +{
> + int t_hlen;
> +
> + tunnel->tun_hlen = 8;
> + tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen +
> + erspan_hdr_len(tunnel->parms.erspan_ver);
> +
> + t_hlen = tunnel->hlen + sizeof(struct ipv6hdr);
> + tunnel->dev->hard_header_len = LL_MAX_HEADER + t_hlen;
> + return t_hlen;
> +}
> +
> static int ip6erspan_tap_init(struct net_device *dev)
> {
> struct ip6_tnl *tunnel;
> @@ -1774,12 +1788,7 @@ static int ip6erspan_tap_init(struct net_device *dev)
> return ret;
> }
>
> - tunnel->tun_hlen = 8;
> - tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen +
> - erspan_hdr_len(tunnel->parms.erspan_ver);
> - t_hlen = tunnel->hlen + sizeof(struct ipv6hdr);
> -
> - dev->hard_header_len = LL_MAX_HEADER + t_hlen;
> + t_hlen = ip6erspan_calc_hlen(tunnel);
> dev->mtu = ETH_DATA_LEN - t_hlen;
> if (dev->type == ARPHRD_ETHER)
> dev->mtu -= ETH_HLEN;
> @@ -1787,7 +1796,7 @@ static int ip6erspan_tap_init(struct net_device *dev)
> dev->mtu -= 8;
>
> dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> - ip6gre_tnl_link_config(tunnel, 1);
> + ip6erspan_tnl_link_config(tunnel, 1);
>
> return 0;
> }
> @@ -2118,6 +2127,53 @@ static void ip6erspan_tap_setup(struct net_device *dev)
> netif_keep_dst(dev);
> }
>
> +static int ip6erspan_newlink(struct net *src_net, struct net_device *dev,
> + struct nlattr *tb[], struct nlattr *data[],
> + struct netlink_ext_ack *extack)
> +{
> + int err = ip6gre_newlink_common(src_net, dev, tb, data, extack);
> + struct ip6_tnl *nt = netdev_priv(dev);
> + struct net *net = dev_net(dev);
> +
> + if (!err) {
> + ip6erspan_tnl_link_config(nt, !tb[IFLA_MTU]);
> + ip6gre_tunnel_link(net_generic(net, ip6gre_net_id), nt);
> + }
> + return err;
> +}
> +
> +static void ip6erspan_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> +{
> + ip6gre_tnl_link_config_common(t);
> + ip6gre_tnl_link_config_route(t, set_mtu, ip6erspan_calc_hlen(t));
> +}
> +
> +static int ip6erspan_tnl_change(struct ip6_tnl *t,
> + const struct __ip6_tnl_parm *p, int set_mtu)
> +{
> + ip6gre_tnl_copy_tnl_parm(t, p);
> + ip6erspan_tnl_link_config(t, set_mtu);
> + return 0;
> +}
> +
> +static int ip6erspan_changelink(struct net_device *dev, struct nlattr *tb[],
> + struct nlattr *data[],
> + struct netlink_ext_ack *extack)
> +{
> + struct ip6gre_net *ign = net_generic(dev_net(dev), ip6gre_net_id);
> + struct __ip6_tnl_parm p;
> + struct ip6_tnl *t;
> +
> + t = ip6gre_changelink_common(dev, tb, data, &p, extack);
> + if (IS_ERR(t))
> + return PTR_ERR(t);
> +
> + ip6gre_tunnel_unlink(ign, t);
> + ip6erspan_tnl_change(t, &p, !tb[IFLA_MTU]);
> + ip6gre_tunnel_link(ign, t);
> + return 0;
> +}
> +
> static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
> .kind = "ip6gre",
> .maxtype = IFLA_GRE_MAX,
> @@ -2154,8 +2210,8 @@ static struct rtnl_link_ops ip6erspan_tap_ops __read_mostly = {
> .priv_size = sizeof(struct ip6_tnl),
> .setup = ip6erspan_tap_setup,
> .validate = ip6erspan_tap_validate,
> - .newlink = ip6gre_newlink,
> - .changelink = ip6gre_changelink,
> + .newlink = ip6erspan_newlink,
> + .changelink = ip6erspan_changelink,
> .get_size = ip6gre_get_size,
> .fill_info = ip6gre_fill_info,
> .get_link_net = ip6_tnl_get_link_net,
> --
> 2.4.11
>
^ permalink raw reply
* Re: [PATCH net-next] vmxnet3: Replace msleep(1) with usleep_range()
From: David Miller @ 2018-05-17 19:56 UTC (permalink / raw)
To: yuehaibing; +Cc: doshir, pv-drivers, netdev, linux-kernel
In-Reply-To: <20180517034641.30004-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 17 May 2018 11:46:41 +0800
> As documented in Documentation/timers/timers-howto.txt,
> replace msleep(1) with usleep_range().
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Allocate buffers from local node
From: David Miller @ 2018-05-17 19:57 UTC (permalink / raw)
To: hpuranik; +Cc: netdev, linux-kernel, timur
In-Reply-To: <1526545680-21650-1-git-send-email-hpuranik@codeaurora.org>
From: Hemanth Puranik <hpuranik@codeaurora.org>
Date: Thu, 17 May 2018 13:58:00 +0530
> Currently we use non-NUMA aware allocation for TPD and RRD buffers,
> this patch modifies to use NUMA friendly allocation.
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
> ---
> drivers/net/ethernet/qualcomm/emac/emac-mac.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
> index 092718a..c3df86a 100644
> --- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
> +++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
> @@ -684,9 +684,10 @@ static int emac_tx_q_desc_alloc(struct emac_adapter *adpt,
> {
> struct emac_ring_header *ring_header = &adpt->ring_header;
> size_t size;
> + int node = dev_to_node(adpt->netdev->dev.parent);
Please order local variable declarations from longest to shortest line
(ie. reverse christmas tree layout).
> @@ -725,9 +726,10 @@ static int emac_rx_descs_alloc(struct emac_adapter *adpt)
> struct emac_ring_header *ring_header = &adpt->ring_header;
> struct emac_rx_queue *rx_q = &adpt->rx_q;
> size_t size;
> + int node = dev_to_node(adpt->netdev->dev.parent);
Likewise.
^ permalink raw reply
* [PATCH net-next v3 0/3] net: Allow more drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-17 20:07 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
Hi David,
This patch series includes more drivers to be build tested with COMPILE_TEST
enabled. This helps cover some of the issues I just ran into with missing
a driver *sigh*.
Chanves in v3:
- drop the TI Keystone NETCP driver from the COMPILE_TEST additions
Changes in v2:
- allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
registers, this is not meant to run, so this is not a real issue if we
are not matching the correct register layout
Florian Fainelli (3):
net: ethernet: ti: Allow most drivers with COMPILE_TEST
net: ethernet: freescale: Allow FEC with COMPILE_TEST
net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST
drivers/net/ethernet/freescale/Kconfig | 2 +-
drivers/net/ethernet/freescale/fec.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +-
drivers/net/ethernet/ti/Kconfig | 12 ++++++------
drivers/net/phy/Kconfig | 4 ++--
5 files changed, 11 insertions(+), 11 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH net-next v3 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-17 20:07 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
In-Reply-To: <20180517200745.19142-1-f.fainelli@gmail.com>
Most of the TI drivers build just fine with COMPILE_TEST, cpmac (AR7) is
the exception because it uses a header file from
arch/mips/include/asm/mach-ar7/ar7.h and keystone netcp which requires
help from drivers/soc/ti/ for queue management helpers.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 48a541eb0af2..9263d638bd6d 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_TI
config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
- depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+ depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 ) || COMPILE_TEST
select TI_DAVINCI_MDIO
select TI_DAVINCI_CPDMA
select PHYLIB
@@ -30,7 +30,7 @@ config TI_DAVINCI_EMAC
config TI_DAVINCI_MDIO
tristate "TI DaVinci MDIO Support"
- depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
+ depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
select PHYLIB
---help---
This driver supports TI's DaVinci MDIO module.
@@ -40,7 +40,7 @@ config TI_DAVINCI_MDIO
config TI_DAVINCI_CPDMA
tristate "TI DaVinci CPDMA Support"
- depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+ depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
---help---
This driver supports TI's DaVinci CPDMA dma engine.
@@ -60,7 +60,7 @@ config TI_CPSW_ALE
config TI_CPSW
tristate "TI CPSW Switch Support"
- depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+ depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
select TI_CPSW_PHY_SEL
@@ -75,7 +75,7 @@ config TI_CPSW
config TI_CPTS
bool "TI Common Platform Time Sync (CPTS) Support"
- depends on TI_CPSW || TI_KEYSTONE_NETCP
+ depends on TI_CPSW || TI_KEYSTONE_NETCP || COMPILE_TEST
depends on POSIX_TIMERS
---help---
This driver supports the Common Platform Time Sync unit of
--
2.14.1
^ permalink raw reply related
* [PATCH net-next v3 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST
From: Florian Fainelli @ 2018-05-17 20:07 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
In-Reply-To: <20180517200745.19142-1-f.fainelli@gmail.com>
The Freescale FEC driver builds fine with COMPILE_TEST, so make that
possible.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/freescale/Kconfig | 2 +-
drivers/net/ethernet/freescale/fec.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 6e490fd2345d..a580a3dcbe59 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_FREESCALE
config FEC
tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- ARCH_MXC || SOC_IMX28)
+ ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index e7381f8ef89d..4778b663653e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -21,7 +21,7 @@
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
- defined(CONFIG_ARM64)
+ defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
/*
* Just figures, Motorola would have to change the offsets for
* registers in the same peripheral device on different models
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index f3e43db0d6cb..4358f586e28f 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2107,7 +2107,7 @@ static int fec_enet_get_regs_len(struct net_device *ndev)
/* List of registers that can be safety be read to dump them with ethtool */
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
- defined(CONFIG_ARM64)
+ defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
static u32 fec_enet_register_offset[] = {
FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT, FEC_R_CNTRL,
--
2.14.1
^ permalink raw reply related
* [PATCH net-next v3 3/3] net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST
From: Florian Fainelli @ 2018-05-17 20:07 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
In-Reply-To: <20180517200745.19142-1-f.fainelli@gmail.com>
Those drivers build just fine with COMPILE_TEST, so make that possible.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0e2305ccc91f..343989f9f9d9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -118,7 +118,7 @@ config MDIO_I2C
config MDIO_MOXART
tristate "MOXA ART MDIO interface support"
- depends on ARCH_MOXART
+ depends on ARCH_MOXART || COMPILE_TEST
help
This driver supports the MDIO interface found in the network
interface units of the MOXA ART SoC
@@ -142,7 +142,7 @@ config MDIO_OCTEON
config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
- depends on ARCH_SUNXI
+ depends on ARCH_SUNXI || COMPILE_TEST
help
This driver supports the MDIO interface found in the network
interface units of the Allwinner SoC that have an EMAC (A10,
--
2.14.1
^ permalink raw reply related
* Re: pull-request: wireless-drivers-next 2018-05-17
From: David Miller @ 2018-05-17 20:10 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87k1s2k6x9.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 17 May 2018 11:44:34 +0300
> here's a pull request to net-next for 4.18. I forgot to mention in the
> signed tag was that one id is added to include/linux/mmc/sdio_ids.h but
> that was acked by Ulf.
>
> I suspect hat because of my merge of wireless-drivers into
> wireless-drivers-next the diffstat from request-pull was wrong again. I
> manually replaced that with the diffstat from my test pull to net-next.
>
> Please let me know if you have any problems.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion
From: David Miller @ 2018-05-17 20:12 UTC (permalink / raw)
To: antoine.tenart
Cc: kishon, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180517082939.14598-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Thu, 17 May 2018 10:29:29 +0200
> @Dave: patches 7 to 10 should go through the mvebu tree (Gregory in
> Cc.) to avoid any conflict with the other mvebu dt patches taken during
> this cycle.
>
> The series is based on today's net-next.
Ok, patches 1-6 applied to net-next, thank you.
^ permalink raw reply
* Re: [bpf-next PATCH 2/2] bpf: add sk_msg prog sk access tests to test_verifier
From: John Fastabend @ 2018-05-17 20:12 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: ast, daniel, netdev
In-Reply-To: <20180517185703.4zdqjyynrc5gkt5q@kafai-mbp.dhcp.thefacebook.com>
On 05/17/2018 11:57 AM, Martin KaFai Lau wrote:
> On Thu, May 17, 2018 at 08:54:10AM -0700, John Fastabend wrote:
>> Add tests for BPF_PROG_TYPE_SK_MSG to test_verifier for read access
>> to new sk fields.
>>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> ---
[...]
>> + {
>> + "invalid read past end of SK_MSG",
>> + .insns = {
>> + BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
>> + offsetof(struct sk_msg_md, local_port) + 4),
>> + BPF_EXIT_INSN(),
>> + },
>> + .errstr = "",
> no errstr in this case?
>
>> + .result = REJECT,
>> + .prog_type = BPF_PROG_TYPE_SK_MSG,
>> + },
>> + {
>> + "invalid read offset in SK_MSG",
>> + .insns = {
>> + BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
>> + offsetof(struct sk_msg_md, family) + 1),
>> + BPF_EXIT_INSN(),
>> + },
>> + .errstr = "",
> same here.
>
>> + .result = REJECT,
>> + .prog_type = BPF_PROG_TYPE_SK_MSG,
>> + },
>> + {
>> "direct packet read for SK_MSG",
>> .insns = {
>> BPF_LDX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1,
>>
> Other than the above,
>
For completeness I guess we should have the err string
included. I'll send a v2 and push ACKs forward.
> Acked-by: Martin KaFai Lau <kafai@fb.com>
>
^ permalink raw reply
* Re: [bpf-next PATCH 1/2] bpf: allow sk_msg programs to read sock fields
From: John Fastabend @ 2018-05-17 20:16 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: ast, daniel, netdev
In-Reply-To: <20180517181736.e6l5lw4ek6w44ede@kafai-mbp.dhcp.thefacebook.com>
On 05/17/2018 11:17 AM, Martin KaFai Lau wrote:
> On Thu, May 17, 2018 at 08:54:04AM -0700, John Fastabend wrote:
>> Currently sk_msg programs only have access to the raw data. However,
>> it is often useful when building policies to have the policies specific
>> to the socket endpoint. This allows using the socket tuple as input
>> into filters, etc.
>>
>> This patch adds ctx access to the sock fields.
>>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> ---
>> include/linux/filter.h | 1
>> include/uapi/linux/bpf.h | 8 +++
>> kernel/bpf/sockmap.c | 1
>> net/core/filter.c | 114 +++++++++++++++++++++++++++++++++++++++++++++-
> It is indeed a lot of dup lines with sock_ops_convert_ctx_access()
> as you mentioned in the cover.
>
> Other than that, LGTM.
>
> Acked-by: Martin KaFai Lau <kafafi@fb.com>
>
>> 4 files changed, 121 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index 9dbcb9d..d358d18 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -517,6 +517,7 @@ struct sk_msg_buff {
>> bool sg_copy[MAX_SKB_FRAGS];
>> __u32 flags;
>> struct sock *sk_redir;
>> + struct sock *sk;
>> struct sk_buff *skb;
>> struct list_head list;
>> };
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index d94d333..97446bb 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -2176,6 +2176,14 @@ enum sk_action {
>> struct sk_msg_md {
>> void *data;
>> void *data_end;
>> +
>> + __u32 family;
>> + __u32 remote_ip4; /* Stored in network byte order */
>> + __u32 local_ip4; /* Stored in network byte order */
>> + __u32 remote_ip6[4]; /* Stored in network byte order */
>> + __u32 local_ip6[4]; /* Stored in network byte order */
>> + __u32 remote_port; /* Stored in network byte order */
>> + __u32 local_port; /* stored in host byte order */
> This ordering inconsistency could be a trap to write bpf_prog
> but I guess it is too late to change now considering
> bpf_sock_ops is also using this convention.
>
Yep, when writing both bpf_sock_ops programs and sk_msg based
programs its nice to have them both use the same semantics. The
two programs, at least in my experience, are used together
typically sharing maps and heavily dependent on one another.
> Just curious, we cannot always assume inet_sk and then uses
> its inet_sport?
>
For now we only support SOCK_STREAM so I guess we could also
use inet_sport but then it wouldn't align with bpf_sock_ops.
If we want to add it later we can put another field in there
to use it "__u32 source_port". For now though I prefer to keep
the bpf_sock_ops and sk_msg_md sock field access aligned.
.John
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: mvpp2: avoid checking for free aggregated descriptors twice
From: David Miller @ 2018-05-17 20:19 UTC (permalink / raw)
To: antoine.tenart
Cc: ymarkman, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, mw
In-Reply-To: <20180517083427.15793-2-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Thu, 17 May 2018 10:34:25 +0200
> From: Yan Markman <ymarkman@marvell.com>
>
> Avoid repeating the check for free aggregated descriptors when it
> already failed at the beginning of the function.
>
> Signed-off-by: Yan Markman <ymarkman@marvell.com>
> [Antoine: commit message]
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: mvpp2: set mac address does not require the stop/start sequence
From: David Miller @ 2018-05-17 20:19 UTC (permalink / raw)
To: antoine.tenart
Cc: ymarkman, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, mw
In-Reply-To: <20180517083427.15793-3-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Thu, 17 May 2018 10:34:26 +0200
> From: Yan Markman <ymarkman@marvell.com>
>
> Remove special stop/start handling from the set_mac_address callback.
> All this special care is not needed, and can be removed. It also
> simplifies the up/down status in the driver and helps avoiding possible
> link status mismatch issues.
>
> Signed-off-by: Yan Markman <ymarkman@marvell.com>
> [Antoine: commit message]
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: mvpp2: print rx error with rate-limit
From: David Miller @ 2018-05-17 20:19 UTC (permalink / raw)
To: antoine.tenart
Cc: ymarkman, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, mw
In-Reply-To: <20180517083427.15793-4-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Thu, 17 May 2018 10:34:27 +0200
> From: Yan Markman <ymarkman@marvell.com>
>
> Prevent flood of RX error prints during heavy traffic with weak signal
> in link by checking net_ratelimit() before using netdev_err().
>
> Signed-off-by: Yan Markman <ymarkman@marvell.com>
> [Antoine: small rework, commit message]
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [patch net-next] nfp: flower: fix error path during representor creation
From: David Miller @ 2018-05-17 20:23 UTC (permalink / raw)
To: jiri
Cc: netdev, jakub.kicinski, simon.horman, dirk.vandermerwe,
john.hurley, pieter.jansenvanvuuren, oss-drivers
In-Reply-To: <20180517100643.24044-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 17 May 2018 12:06:43 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Don't store repr pointer to reprs array until the representor is
> successfully created. This avoids message about "representor
> destruction" even when it was never created. Also it cleans-up the flow.
> Also, check return value after port alloc.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net-next] net/smc: init conn.tx_work & conn.send_lock sooner
From: David Miller @ 2018-05-17 20:25 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ubraun, linux-s390
In-Reply-To: <20180517105421.182397-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 17 May 2018 03:54:21 -0700
> syzkaller found that following program crashes the host :
>
> {
> int fd = socket(AF_SMC, SOCK_STREAM, 0);
> int val = 1;
>
> listen(fd, 0);
> shutdown(fd, SHUT_RDWR);
> setsockopt(fd, 6, TCP_NODELAY, &val, 4);
> }
>
> Simply initialize conn.tx_work & conn.send_lock at socket creation,
> rather than deeper in the stack.
...
> Fixes: 01d2f7e2cdd3 ("net/smc: sockopts TCP_NODELAY and TCP_CORK")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Ursula Braun <ubraun@linux.ibm.com>
> Cc: linux-s390@vger.kernel.org
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net/ncsi: prevent a couple array underflows
From: David Miller @ 2018-05-17 20:28 UTC (permalink / raw)
To: dan.carpenter; +Cc: sam, netdev, gwshan, kernel-janitors
In-Reply-To: <20180517123336.GB7655@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 17 May 2018 15:33:36 +0300
> We recently refactored this code and introduced a static checker
> warning. Smatch complains that if cmd->index is zero then we would
> underflow the arrays. That's obviously true.
>
> The question is whether we prevent cmd->index from being zero at a
> different level. I've looked at the code and I don't immediately see
> a check for that.
>
> Fixes: 062b3e1b6d4f ("net/ncsi: Refactor MAC, VLAN filters")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied to net-next, thanks Dan.
^ permalink raw reply
* Re: [PATCH net] tls: don't use stack memory in a scatterlist
From: Matt Mullins @ 2018-05-17 20:28 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, Dave Watson, linux-kernel@vger.kernel.org,
aviadye@mellanox.com, Doron Roberts-Kedes
In-Reply-To: <20180517.145056.1635507477734784563.davem@davemloft.net>
On Thu, 2018-05-17 at 14:50 -0400, David Miller wrote:
> I'm surprised this problem wasn't discovered sooner. How exactly did you
> discover it? Did you actually see it trigger or is this purely from code
> inspection?
Honestly, I'm not sure how it got uncovered, but it was observed at
runtime. Doron Roberts-Kedes hit a null pointer dereference so we
turned on CONFIG_DEBUG_SG -- then it became a proper
BUG_ON(!virt_addr_valid(buf)); in sg_set_buf.
^ permalink raw reply
* Re: [patch net-next RFC 04/12] dsa: set devlink port attrs for dsa ports
From: Andrew Lunn @ 2018-05-17 20:28 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jiri Pirko, netdev, davem, idosch, jakub.kicinski, mlxsw,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <408e70ee-d3b4-8431-5ca7-6defa17b7088@gmail.com>
> The platform data assumes there is a network device named "eth0" as the
> parent device, yes I know this is terrible, but unfortunately we don't
> have anything better at this point
That is something we need to solve. With DT, it is easy, we have a
phandle to a device, and the name does not matter. systemd can rename
eth0 to enp0s25 and we will still find it, because we don't look for
the name, we look for the OF node associated to the device.
For platform data driven devices, we don't have this luxury. I have an
intel board with a Marvell switch. I have Debian running on it, so
systemd renames the interface. Builtin vs modules then becomes an
issue. Does the switch driver probe before or after systemd renames
the interface?
For embedded systems like this, we probably need a way to find an
interface based on its bus location, not its name. Not as good, but
maybe sufficient, a function which gives us the first physical
interface the machine has.
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version
From: David Miller @ 2018-05-17 20:31 UTC (permalink / raw)
To: andrea.greco.gapmilano; +Cc: tobin, a.greco, m.grzeschik, linux-kernel, netdev
In-Reply-To: <20180517130529.2684-1-andrea.greco.gapmilano@gmail.com>
From: Andrea Greco <andrea.greco.gapmilano@gmail.com>
Date: Thu, 17 May 2018 15:05:29 +0200
> + /* Will be set by userspace during if setup */
> + dev->dev_addr[0] = 0;
Hmmm... really?
Also, every error path from this point forward will leak 'dev'.
^ permalink raw reply
* Re: [bpf PATCH 2/2] bpf: parse and verdict prog attach may race with bpf map update
From: Daniel Borkmann @ 2018-05-17 20:31 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev
In-Reply-To: <20180516214656.6664.34077.stgit@john-Precision-Tower-5810>
On 05/16/2018 11:46 PM, John Fastabend wrote:
> In the sockmap design BPF programs (SK_SKB_STREAM_PARSER and
> SK_SKB_STREAM_VERDICT) are attached to the sockmap map type and when
> a sock is added to the map the programs are used by the socket.
> However, sockmap updates from both userspace and BPF programs can
> happen concurrently with the attach and detach of these programs.
>
> To resolve this we use the bpf_prog_inc_not_zero and a READ_ONCE()
> primitive to ensure the program pointer is not refeched and
> possibly NULL'd before the refcnt increment. This happens inside
> a RCU critical section so although the pointer reference in the map
> object may be NULL (by a concurrent detach operation) the reference
> from READ_ONCE will not be free'd until after grace period. This
> ensures the object returned by READ_ONCE() is valid through the
> RCU criticl section and safe to use as long as we "know" it may
> be free'd shortly.
>
> Daniel spotted a case in the sock update API where instead of using
> the READ_ONCE() program reference we used the pointer from the
> original map, stab->bpf_{verdict|parse}. The problem with this is
> the logic checks the object returned from the READ_ONCE() is not
> NULL and then tries to reference the object again but using the
> above map pointer, which may have already been NULL'd by a parallel
> detach operation. If this happened bpf_porg_inc_not_zero could
> dereference a NULL pointer.
>
> Fix this by using variable returned by READ_ONCE() that is checked
> for NULL.
>
> Fixes: 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support")
> Reported-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> kernel/bpf/sockmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index f03aaa8..583c1eb 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -1703,11 +1703,11 @@ static int sock_map_ctx_update_elem(struct bpf_sock_ops_kern *skops,
> * we increment the refcnt. If this is the case abort with an
> * error.
> */
> - verdict = bpf_prog_inc_not_zero(stab->bpf_verdict);
> + verdict = bpf_prog_inc_not_zero(verdict);
> if (IS_ERR(verdict))
> return PTR_ERR(verdict);
>
> - parse = bpf_prog_inc_not_zero(stab->bpf_parse);
> + parse = bpf_prog_inc_not_zero(parse);
> if (IS_ERR(parse)) {
> bpf_prog_put(verdict);
> return PTR_ERR(parse);
Isn't the same sort of behavior also possible with the bpf_prog_inc_not_zero(stab->bpf_tx_msg)?
Meaning, we now have verdict and parse covered with the patch, but the original tx_msg we
fetched earlier via READ_ONCE() where same would apply not (yet)?
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: fixed copy-pasting error in ife tests
From: David Miller @ 2018-05-17 20:31 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1526562769-20708-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Thu, 17 May 2018 09:12:49 -0400
> Reported-by: Vlad Buslov <vladbu@mellanox.com>
> Reported-by: Davide Caratti <dcaratti@redhat.com>
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH] selftests/bpf: check return value of fopen in test_verifier.c
From: Daniel Borkmann @ 2018-05-17 20:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: joe, Alexei Starovoitov
In-Reply-To: <152657877097.9825.6742536221308880897.stgit@firesoul>
On 05/17/2018 07:39 PM, Jesper Dangaard Brouer wrote:
> Commit 0a6748740368 ("selftests/bpf: Only run tests if !bpf_disabled")
> forgot to check return value of fopen.
>
> This caused some confusion, when running test_verifier (from
> tools/testing/selftests/bpf/) on an older kernel (< v4.4) as it will
> simply seqfault.
>
> This fix avoids the segfault and prints an error, but allow program to
> continue. Given the sysctl was introduced in 1be7f75d1668 ("bpf:
> enable non-root eBPF programs"), we know that the running kernel
> cannot support unpriv, thus continue with unpriv_disabled = true.
>
> Fixes: 0a6748740368 ("selftests/bpf: Only run tests if !bpf_disabled")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied to bpf, thanks Jesper!
^ 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