* [PATCH net-next v3 3/4] enetc: Add ENETC PF level external MDIO support
From: Claudiu Manoil @ 2019-02-22 15:04 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550847859-17346-1-git-send-email-claudiu.manoil@nxp.com>
Each ENETC PF has its own MDIO interface, the corresponding
MDIO registers are mapped in the ENETC's Port register block.
The current patch adds a driver for these PF level MDIO buses,
so that each PF can manage directly its own external link.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - used readx_poll_timeout()
- added mdio node child to the port node
- added code comments, removed redundant err messages,
minor code cleanup
v3 - replaced dev_err w/ dev_dbg for read() issues
drivers/net/ethernet/freescale/enetc/Makefile | 3 +-
drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 199 ++++++++++++++++++++++
drivers/net/ethernet/freescale/enetc/enetc_pf.c | 12 ++
drivers/net/ethernet/freescale/enetc/enetc_pf.h | 6 +
4 files changed, 219 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c
diff --git a/drivers/net/ethernet/freescale/enetc/Makefile b/drivers/net/ethernet/freescale/enetc/Makefile
index 6976602..7139e41 100644
--- a/drivers/net/ethernet/freescale/enetc/Makefile
+++ b/drivers/net/ethernet/freescale/enetc/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_FSL_ENETC) += fsl-enetc.o
-fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o
+fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o \
+ enetc_mdio.o
fsl-enetc-$(CONFIG_PCI_IOV) += enetc_msg.o
fsl-enetc-objs := enetc_pf.o $(fsl-enetc-y)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
new file mode 100644
index 0000000..77b9cd1
--- /dev/null
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/* Copyright 2019 NXP */
+
+#include <linux/mdio.h>
+#include <linux/of_mdio.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+
+#include "enetc_pf.h"
+
+struct enetc_mdio_regs {
+ u32 mdio_cfg; /* MDIO configuration and status */
+ u32 mdio_ctl; /* MDIO control */
+ u32 mdio_data; /* MDIO data */
+ u32 mdio_addr; /* MDIO address */
+};
+
+#define bus_to_enetc_regs(bus) (struct enetc_mdio_regs __iomem *)((bus)->priv)
+
+#define ENETC_MDIO_REG_OFFSET 0x1c00
+#define ENETC_MDC_DIV 258
+
+#define MDIO_CFG_CLKDIV(x) ((((x) >> 1) & 0xff) << 8)
+#define MDIO_CFG_BSY BIT(0)
+#define MDIO_CFG_RD_ER BIT(1)
+#define MDIO_CFG_ENC45 BIT(6)
+ /* external MDIO only - driven on neg MDC edge */
+#define MDIO_CFG_NEG BIT(23)
+
+#define MDIO_CTL_DEV_ADDR(x) ((x) & 0x1f)
+#define MDIO_CTL_PORT_ADDR(x) (((x) & 0x1f) << 5)
+#define MDIO_CTL_READ BIT(15)
+#define MDIO_DATA(x) ((x) & 0xffff)
+
+#define TIMEOUT 1000
+static int enetc_mdio_wait_complete(struct enetc_mdio_regs __iomem *regs)
+{
+ u32 val;
+
+ return readx_poll_timeout(enetc_rd_reg, ®s->mdio_cfg, val,
+ !(val & MDIO_CFG_BSY), 10, 10 * TIMEOUT);
+}
+
+static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
+ u16 value)
+{
+ struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ u32 mdio_ctl, mdio_cfg;
+ u16 dev_addr;
+ int ret;
+
+ mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+ if (regnum & MII_ADDR_C45) {
+ dev_addr = (regnum >> 16) & 0x1f;
+ mdio_cfg |= MDIO_CFG_ENC45;
+ } else {
+ /* clause 22 (ie 1G) */
+ dev_addr = regnum & 0x1f;
+ mdio_cfg &= ~MDIO_CFG_ENC45;
+ }
+
+ enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* set port and dev addr */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+
+ /* set the register address */
+ if (regnum & MII_ADDR_C45) {
+ enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+ }
+
+ /* write the value */
+ enetc_wr_reg(®s->mdio_data, MDIO_DATA(value));
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ u32 mdio_ctl, mdio_cfg;
+ u16 dev_addr, value;
+ int ret;
+
+ mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+ if (regnum & MII_ADDR_C45) {
+ dev_addr = (regnum >> 16) & 0x1f;
+ mdio_cfg |= MDIO_CFG_ENC45;
+ } else {
+ dev_addr = regnum & 0x1f;
+ mdio_cfg &= ~MDIO_CFG_ENC45;
+ }
+
+ enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* set port and device addr */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+
+ /* set the register address */
+ if (regnum & MII_ADDR_C45) {
+ enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+ }
+
+ /* initiate the read */
+ enetc_wr_reg(®s->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+
+ ret = enetc_mdio_wait_complete(regs);
+ if (ret)
+ return ret;
+
+ /* return all Fs if nothing was there */
+ if (enetc_rd_reg(®s->mdio_cfg) & MDIO_CFG_RD_ER) {
+ dev_dbg(&bus->dev,
+ "Error while reading PHY%d reg at %d.%hhu\n",
+ phy_id, dev_addr, regnum);
+ return 0xffff;
+ }
+
+ value = enetc_rd_reg(®s->mdio_data) & 0xffff;
+
+ return value;
+}
+
+int enetc_mdio_probe(struct enetc_pf *pf)
+{
+ struct device *dev = &pf->si->pdev->dev;
+ struct enetc_mdio_regs __iomem *regs;
+ struct device_node *np;
+ struct mii_bus *bus;
+ int ret;
+
+ bus = mdiobus_alloc_size(sizeof(regs));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "Freescale ENETC MDIO Bus";
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+ /* store the enetc mdio base address for this bus */
+ regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
+ bus->priv = regs;
+
+ np = of_get_child_by_name(dev->of_node, "mdio");
+ if (!np) {
+ dev_err(dev, "MDIO node missing\n");
+ ret = -EINVAL;
+ goto err_registration;
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret) {
+ of_node_put(np);
+ dev_err(dev, "cannot register MDIO bus\n");
+ goto err_registration;
+ }
+
+ of_node_put(np);
+ pf->mdio = bus;
+
+ return 0;
+
+err_registration:
+ mdiobus_free(bus);
+
+ return ret;
+}
+
+void enetc_mdio_remove(struct enetc_pf *pf)
+{
+ if (pf->mdio) {
+ mdiobus_unregister(pf->mdio);
+ mdiobus_free(pf->mdio);
+ }
+}
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 7d28f5e..15876a6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -746,6 +746,7 @@ static void enetc_pf_netdev_setup(struct enetc_si *si, struct net_device *ndev,
static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
{
+ struct enetc_pf *pf = enetc_si_priv(priv->si);
struct device_node *np = priv->dev->of_node;
int err;
@@ -770,12 +771,22 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
priv->phy_node = of_node_get(np);
}
+ if (!of_phy_is_fixed_link(np)) {
+ err = enetc_mdio_probe(pf);
+ if (err) {
+ of_node_put(priv->phy_node);
+ return err;
+ }
+ }
+
priv->if_mode = of_get_phy_mode(np);
if (priv->if_mode < 0) {
dev_err(priv->dev, "missing phy type\n");
of_node_put(priv->phy_node);
if (of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
+ else
+ enetc_mdio_remove(pf);
return -EINVAL;
}
@@ -898,6 +909,7 @@ static void enetc_pf_remove(struct pci_dev *pdev)
unregister_netdev(si->ndev);
+ enetc_mdio_remove(pf);
enetc_of_put_phy(priv);
enetc_free_msix(priv);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 2061ae5..10dd1b5 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -42,8 +42,14 @@ struct enetc_pf {
char vlan_promisc_simap; /* bitmap of SIs in VLAN promisc mode */
DECLARE_BITMAP(vlan_ht_filter, ENETC_VLAN_HT_SIZE);
DECLARE_BITMAP(active_vlans, VLAN_N_VID);
+
+ struct mii_bus *mdio; /* saved for cleanup */
};
int enetc_msg_psi_init(struct enetc_pf *pf);
void enetc_msg_psi_free(struct enetc_pf *pf);
void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int mbox_id, u16 *status);
+
+/* MDIO */
+int enetc_mdio_probe(struct enetc_pf *pf);
+void enetc_mdio_remove(struct enetc_pf *pf);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v3 1/4] arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints
From: Claudiu Manoil @ 2019-02-22 15:04 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550847859-17346-1-git-send-email-claudiu.manoil@nxp.com>
The LS1028A SoC features a PCI Integrated Endpoint Root Complex
(IERC) defining several integrated PCI devices, including the ENETC
ethernet controller integrated endpoints (IEPs). The IERC implements
ECAM (Enhanced Configuration Access Mechanism) to provide access
to the PCIe config space of the IEPs. This means the the IEPs
(including ENETC) do not support the standard PCIe BARs, instead
the Enhanced Allocation (EA) capability structures in the ECAM space
are used to fix the base addresses in the system, and the PCI
subsystem uses these structures for device enumeration and discovery.
The "ranges" entries contain basic information from these EA capabily
structures required by the kernel for device enumeration.
The current patch also enables the first 2 ENETC PFs (Physiscal
Functions) and the associated VFs (Virtual Functions), 2 VFs for
each PF. Each of these ENETC PFs has an external ethernet port
on the LS1028A SoC.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - none
v3 - none
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 33 ++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index a8cf92a..7f5a8e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -335,5 +335,38 @@
<GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ pcie@1f0000000 { /* Integrated Endpoint Root Complex */
+ compatible = "pci-host-ecam-generic";
+ reg = <0x01 0xf0000000 0x0 0x100000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ msi-parent = <&its>;
+ device_type = "pci";
+ bus-range = <0x0 0x0>;
+ dma-coherent;
+ msi-map = <0 &its 0x17 0xe>;
+ iommu-map = <0 &smmu 0x17 0xe>;
+ /* PF0-6 BAR0 - non-prefetchable memory */
+ ranges = <0x82000000 0x0 0x00000000 0x1 0xf8000000 0x0 0x160000
+ /* PF0-6 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf8160000 0x0 0x070000
+ /* PF0: VF0-1 BAR0 - non-prefetchable memory */
+ 0x82000000 0x0 0x00000000 0x1 0xf81d0000 0x0 0x020000
+ /* PF0: VF0-1 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf81f0000 0x0 0x020000
+ /* PF1: VF0-1 BAR0 - non-prefetchable memory */
+ 0x82000000 0x0 0x00000000 0x1 0xf8210000 0x0 0x020000
+ /* PF1: VF0-1 BAR2 - prefetchable memory */
+ 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000>;
+
+ enetc_port0: pci@0,0 {
+ reg = <0x000000 0 0 0 0>;
+ };
+ enetc_port1: pci@0,1 {
+ reg = <0x000100 0 0 0 0>;
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v3 2/4] arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the LS1028A RDB board
From: Claudiu Manoil @ 2019-02-22 15:04 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
In-Reply-To: <1550847859-17346-1-git-send-email-claudiu.manoil@nxp.com>
The LS1028A RDB board features an Atheros PHY connected over
SGMII to the ENETC PF0 (or Port0). ENETC Port1 (PF1) has no
external connection on this board, so it can be disabled for now.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - added a mdio node as parent for the phy node
v3 - none
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..f86b054 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -71,3 +71,20 @@
&duart1 {
status = "okay";
};
+
+&enetc_port0 {
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+};
+
+&enetc_port1 {
+ status = "disabled";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v3 0/4] enetc: Add mdio support and device tree nodes
From: Claudiu Manoil @ 2019-02-22 15:04 UTC (permalink / raw)
To: Shawn Guo, Li Yang, David S . Miller
Cc: alexandru.marginean, linux-arm-kernel, devicetree, netdev,
linux-kernel
This is the missing part to enable PCI probing of the ENETC ethernet
ports on the LS1028A SoC and external traffic on the LS1028A RDB board.
It's one of the first items on the TODO list for the recently merged
ENETC ethernet driver.
v3: Add DT bindings doc for ENETC connections
Claudiu Manoil (4):
arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints
arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the
LS1028A RDB board
enetc: Add ENETC PF level external MDIO support
dt-bindings: net: freescale: enetc: Add connection bindings for ENETC
ethernet nodes
.../devicetree/bindings/net/fsl-enetc.txt | 109 +++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 17 ++
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 33 ++++
drivers/net/ethernet/freescale/enetc/Makefile | 3 +-
drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 199 +++++++++++++++++++++
drivers/net/ethernet/freescale/enetc/enetc_pf.c | 12 ++
drivers/net/ethernet/freescale/enetc/enetc_pf.h | 6 +
7 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/fsl-enetc.txt
create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c
--
2.7.4
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: Michael S. Tsirkin @ 2019-02-22 15:14 UTC (permalink / raw)
To: si-wei liu
Cc: Samudrala, Sridhar, Siwei Liu, Jiri Pirko, Stephen Hemminger,
David Miller, Netdev, virtualization, virtio-dev,
Brandeburg, Jesse, Alexander Duyck, Jakub Kicinski, Jason Wang,
liran.alon
In-Reply-To: <d9ef40a2-237b-0cce-4401-ecaeac4c602a@oracle.com>
On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei liu wrote:
>
>
> On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote:
> >
> >
> > On 2/21/2019 7:33 PM, si-wei liu wrote:
> > >
> > >
> > > On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
> > > > On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
> > > > > Sorry for replying to this ancient thread. There was some remaining
> > > > > issue that I don't think the initial net_failover patch got addressed
> > > > > cleanly, see:
> > > > >
> > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
> > > > >
> > > > > The renaming of 'eth0' to 'ens4' fails because the udev userspace was
> > > > > not specifically writtten for such kernel automatic enslavement.
> > > > > Specifically, if it is a bond or team, the slave would typically get
> > > > > renamed *before* virtual device gets created, that's what udev can
> > > > > control (without getting netdev opened early by the other part of
> > > > > kernel) and other userspace components for e.g. initramfs,
> > > > > init-scripts can coordinate well in between. The in-kernel
> > > > > auto-enslavement of net_failover breaks this userspace convention,
> > > > > which don't provides a solution if user care about consistent naming
> > > > > on the slave netdevs specifically.
> > > > >
> > > > > Previously this issue had been specifically called out when IFF_HIDDEN
> > > > > and the 1-netdev was proposed, but no one gives out a solution to this
> > > > > problem ever since. Please share your mind how to proceed and solve
> > > > > this userspace issue if netdev does not welcome a 1-netdev model.
> > > > Above says:
> > > >
> > > > there's no motivation in the systemd/udevd community at
> > > > this point to refactor the rename logic and make it work well with
> > > > 3-netdev.
> > > >
> > > > What would the fix be? Skip slave devices?
> > > >
> > > There's nothing user can get if just skipping slave devices - the
> > > name is still unchanged and unpredictable e.g. eth0, or eth1 the
> > > next reboot, while the rest may conform to the naming scheme (ens3
> > > and such). There's no way one can fix this in userspace alone - when
> > > the failover is created the enslaved netdev was opened by the kernel
> > > earlier than the userspace is made aware of, and there's no
> > > negotiation protocol for kernel to know when userspace has done
> > > initial renaming of the interface. I would expect netdev list should
> > > at least provide the direction in general for how this can be
> > > solved...
I was just wondering what did you mean when you said
"refactor the rename logic and make it work well with 3-netdev" -
was there a proposal udev rejected?
Anyway, can we write a time diagram for what happens in which order that
leads to failure? That would help look for triggers that we can tie
into, or add new ones.
> > >
> > Is there an issue if slave device names are not predictable? The user/admin scripts are expected
> > to only work with the master failover device.
> Where does this expectation come from?
>
> Admin users may have ethtool or tc configurations that need to deal with
> predictable interface name. Third-party app which was built upon specifying
> certain interface name can't be modified to chase dynamic names.
>
> Specifically, we have pre-canned image that uses ethtool to fine tune VF
> offload settings post boot for specific workload. Those images won't work
> well if the name is constantly changing just after couple rounds of live
> migration.
It should be possible to specify the ethtool configuration on the
master and have it automatically propagated to the slave.
BTW this is something we should look at IMHO.
> > Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
> > about moving them to a hidden network namespace so that they are not visible from the default namespace.
> > I looked into this sometime back, but did not find the right kernel api to create a network namespace within
> > kernel. If so, we could use this mechanism to simulate a 1-netdev model.
> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
> model as much transparent to a real NIC as possible, while a hidden netns is
> just the vehicle). However, I recall there was resistance around this
> discussion that even the concept of hiding itself is a taboo for Linux
> netdev. I would like to summon potential alternatives before concluding
> 1-netdev is the only solution too soon.
>
> Thanks,
> -Siwei
Your scripts would not work at all then, right?
> >
> > > -Siwei
> > >
> > >
^ permalink raw reply
* Re: [PATCH net-next v2] ip_tunnel: Add dst_cache management lwtunnel_state of ip tunnel
From: wenxu @ 2019-02-22 15:21 UTC (permalink / raw)
To: David Ahern, davem, netdev
In-Reply-To: <9277b934-63f6-2f16-bd46-948bc64cc46e@gmail.com>
On 2019/2/22 下午11:03, David Ahern wrote:
> On 2/21/19 11:14 PM, wenxu wrote:
>> build_state in the rcu_read_lock and disable the preempt
>>
>> rcu_read_lock();
>> ops = rcu_dereference(lwtun_encaps[encap_type]);
>> if (likely(ops && ops->build_state && try_module_get(ops->owner))) {
>> found = true;
>> ret = ops->build_state(encap, family, cfg, lws, extack);
>> if (ret)
>> module_put(ops->owner);
>> }
>> rcu_read_unlock();
>>
> Missed that.
>
> Once a reference is taken the rcu_read_lock can be dropped before
> calling build_state allowing the allocations to be GFP_KERNEL.
>
I don't think the rcu_read_lock can be dropped. The whole operation of the reference should be protect
in the rcu_read_lock that ensure the ops will not be destroy (if it will be)
^ permalink raw reply
* Re: [PATCH bpf v2] bpf, lpm: fix lookup bug in map_delete_elem
From: Daniel Borkmann @ 2019-02-22 15:22 UTC (permalink / raw)
To: Alban Crequy, ast; +Cc: kafai, netdev, linux-kernel, alban, iago
In-Reply-To: <20190222131908.6207-1-alban@kinvolk.io>
On 02/22/2019 02:19 PM, Alban Crequy wrote:
> From: Alban Crequy <alban@kinvolk.io>
>
> trie_delete_elem() was deleting an entry even though it was not matching
> if the prefixlen was correct. This patch adds a check on matchlen.
>
> Reproducer:
>
> $ sudo bpftool map create /sys/fs/bpf/mylpm type lpm_trie key 8 value 1 entries 128 name mylpm flags 1
> $ sudo bpftool map update pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 aa bb cc dd value hex 01
> $ sudo bpftool map dump pinned /sys/fs/bpf/mylpm
> key: 10 00 00 00 aa bb cc dd value: 01
> Found 1 element
> $ sudo bpftool map delete pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 ff ff ff ff
> $ echo $?
> 0
> $ sudo bpftool map dump pinned /sys/fs/bpf/mylpm
> Found 0 elements
>
> A similar reproducer is added in the selftests.
>
> Without the patch:
>
> $ sudo ./tools/testing/selftests/bpf/test_lpm_map
> test_lpm_map: test_lpm_map.c:485: test_lpm_delete: Assertion `bpf_map_delete_elem(map_fd, key) == -1 && errno == ENOENT' failed.
> Aborted
>
> With the patch: test_lpm_map runs without errors.
>
> Fixes: e454cf595853 ("bpf: Implement map_delete_elem for BPF_MAP_TYPE_LPM_TRIE")
> Cc: Craig Gallek <kraig@google.com>
> Signed-off-by: Alban Crequy <alban@kinvolk.io>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] samples/bpf: Fix dummy program unloading for xdp_redirect samples
From: Daniel Borkmann @ 2019-02-22 15:23 UTC (permalink / raw)
To: Martin Lau, Maciej Fijalkowski
Cc: Toke Høiland-Jørgensen, netdev@vger.kernel.org
In-Reply-To: <20190221224735.wf4364mmyajw7ly7@kafai-mbp.dhcp.thefacebook.com>
On 02/21/2019 11:47 PM, Martin Lau wrote:
> On Thu, Feb 21, 2019 at 05:30:54PM +0100, Maciej Fijalkowski wrote:
>> On Thu, 21 Feb 2019 17:05:39 +0100
>> Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>>> The xdp_redirect and xdp_redirect_map sample programs both load a dummy
>>> program onto the egress interfaces. However, the unload code checks these
>>> programs against the wrong fd number, and thus refuses to unload them. Fix
> s/fd/id/
Applied and fixed above typo, thanks!
>>> the comparison to avoid this.
> The change LGTM.
>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
>
^ permalink raw reply
* [PATCH] batman-adv: fix warning in function batadv_v_elp_get_throughput
From: Anders Roxell @ 2019-02-22 15:25 UTC (permalink / raw)
To: mareklindner, sw, a, davem
Cc: b.a.t.m.a.n, netdev, linux-kernel, Anders Roxell
When CONFIG_CFG80211 isn't enabled the compiler correcly warns about
'sinfo.pertid' may be unused. It can also happen for other error
conditions that it not warn about.
net/batman-adv/bat_v_elp.c: In function ‘batadv_v_elp_get_throughput.isra.0’:
include/net/cfg80211.h:6370:13: warning: ‘sinfo.pertid’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
kfree(sinfo->pertid);
~~~~~^~~~~~~~
Rework so that we only release '&sinfo' if cfg80211_get_station returns
zero.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
net/batman-adv/bat_v_elp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c
index a9b7919c9de5..d5df0114f08a 100644
--- a/net/batman-adv/bat_v_elp.c
+++ b/net/batman-adv/bat_v_elp.c
@@ -104,8 +104,10 @@ static u32 batadv_v_elp_get_throughput(struct batadv_hardif_neigh_node *neigh)
ret = cfg80211_get_station(real_netdev, neigh->addr, &sinfo);
- /* free the TID stats immediately */
- cfg80211_sinfo_release_content(&sinfo);
+ if (!ret) {
+ /* free the TID stats immediately */
+ cfg80211_sinfo_release_content(&sinfo);
+ }
dev_put(real_netdev);
if (ret == -ENOENT) {
--
2.19.2
^ permalink raw reply related
* Re: [PATCH] net: dsa: read mac address from DT for slave device
From: Florian Fainelli @ 2019-02-22 15:43 UTC (permalink / raw)
To: Vinod Koul, David S. Miller
Cc: linux-arm-msm, Bjorn Andersson, Xiaofei Shen, Andrew Lunn,
Vivien Didelot, Niklas Cassel, netdev
In-Reply-To: <20190222125815.12866-1-vkoul@kernel.org>
On 2/22/19 4:58 AM, Vinod Koul wrote:
> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>
> Before creating a slave netdevice, get the mac address from DTS and
> apply in case it is valid.
Can you explain your use case in details?
Assigning a MAC address to a network device that represents a switch
port does not quite make sense in general. The switch port is really
representing one end of a pipe, so one side you have stations and on the
other side, you have the CPU/management Ethernet MAC controller's MAC
address which constitutes a station as well. The DSA slave network
devices are just software constructs meant to steer traffic towards
specific ports of the switch, but they are all from the perpsective of
traffic reaching the CPU Port in the first place, therefore traffic that
is generally a known unicast Ethernet frame with the CPU's MAC address
as MAC DA (and of course all types of unknown MC, management traffic etc.)
By default, DSA switch need to come up in a configuration where all
ports (except CPU/management) must be strictly separate from every other
port such that we can achieve what a standalone Ethernet NIC would do.
This works because all ports are isolated from one another, so there is
no cross talk and so having the same MAC address (the one from the CPU)
on the DSA slave network devices just works, each port is a separate
broadcast domain.
Once you start bridging one or ore ports, the bridge root port will have
a MAC address, most likely the one the CPU/management Ethernet MAC, but
similarly, this is not an issue and that's exactly how a software bridge
would work as well.
>
> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> include/net/dsa.h | 1 +
> net/dsa/dsa2.c | 1 +
> net/dsa/slave.c | 5 ++++-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index b3eefe8e18fd..aa24ce756679 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -198,6 +198,7 @@ struct dsa_port {
> unsigned int index;
> const char *name;
> const struct dsa_port *cpu_dp;
> + const char *mac;
> struct device_node *dn;
> unsigned int ageing_time;
> u8 stp_state;
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index a1917025e155..afb7d9fa42f6 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -261,6 +261,7 @@ static int dsa_port_setup(struct dsa_port *dp)
> int err = 0;
>
> memset(&dp->devlink_port, 0, sizeof(dp->devlink_port));
> + dp->mac = of_get_mac_address(dp->dn);
>
> if (dp->type != DSA_PORT_TYPE_UNUSED)
> err = devlink_port_register(ds->devlink, &dp->devlink_port,
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index a3fcc1d01615..8e64c4e947c6 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1308,7 +1308,10 @@ int dsa_slave_create(struct dsa_port *port)
> slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
> slave_dev->hw_features |= NETIF_F_HW_TC;
> slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
> - eth_hw_addr_inherit(slave_dev, master);
> + if (port->mac && is_valid_ether_addr(port->mac))
> + ether_addr_copy(slave_dev->dev_addr, port->mac);
> + else
> + eth_hw_addr_inherit(slave_dev, master);
> slave_dev->priv_flags |= IFF_NO_QUEUE;
> slave_dev->netdev_ops = &dsa_slave_netdev_ops;
> slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
>
--
Florian
^ permalink raw reply
* [stable 3.18 backport v2] netlink: Trim skb to alloc size to avoid MSG_TRUNC
From: Mark Salyzyn @ 2019-02-22 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: Arad, Ronen, David S . Miller, Mark Salyzyn, Greg Kroah-Hartman,
Dmitry Safonov, David Ahern, Kirill Tkhai, Andrei Vagin,
Li RongQing, YU Bo, Denys Vlasenko, netdev, stable, Eric Dumazet,
Alexander Potapenko
From: "Arad, Ronen" <ronen.arad@intel.com>
Direct this upstream db65a3aaf29ecce2e34271d52e8d2336b97bd9fe sha to
stable 3.18. This patch addresses a race condition where a call to
nlk->max_recvmsg_len = max(nlk->max_recvmsg_len, len);
nlk->max_recvmsg_len = min_t(size_t, nlk->max_recvmsg_len,
one thread in-between another thread:
skb = netlink_alloc_skb(sk,
and
skb_reserve(skb, skb_tailroom(skb) -
nlk->max_recvmsg_len);
in netlink_dump. The result can be a negative value and will cause
a kernel panic ad BUG at net/core/skbuff.c because the negative value
turns into an extremely large positive value.
Original commit:
netlink_dump() allocates skb based on the calculated min_dump_alloc or
a per socket max_recvmsg_len.
min_alloc_size is maximum space required for any single netdev
attributes as calculated by rtnl_calcit().
max_recvmsg_len tracks the user provided buffer to netlink_recvmsg.
It is capped at 16KiB.
The intention is to avoid small allocations and to minimize the number
of calls required to obtain dump information for all net devices.
netlink_dump packs as many small messages as could fit within an skb
that was sized for the largest single netdev information. The actual
space available within an skb is larger than what is requested. It could
be much larger and up to near 2x with align to next power of 2 approach.
Allowing netlink_dump to use all the space available within the
allocated skb increases the buffer size a user has to provide to avoid
truncaion (i.e. MSG_TRUNG flag set).
It was observed that with many VLANs configured on at least one netdev,
a larger buffer of near 64KiB was necessary to avoid "Message truncated"
error in "ip link" or "bridge [-c[ompressvlans]] vlan show" when
min_alloc_size was only little over 32KiB.
This patch trims skb to allocated size in order to allow the user to
avoid truncation with more reasonable buffer size.
Signed-off-by: Ronen Arad <ronen.arad@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry pick commit db65a3aaf29ecce2e34271d52e8d2336b97bd9fe)
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ronen Arad <ronen.arad@intel.com>
Cc: "David S . Miller" <davem@davemloft.net>
Cc: Dmitry Safonov <dima@arista.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Andrei Vagin <avagin@virtuozzo.com>
Cc: Li RongQing <lirongqing@baidu.com>
Cc: YU Bo <tsu.yubo@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 3.18
---
net/netlink/af_netlink.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 50096e0edd8e..14295cef6b76 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1977,6 +1977,7 @@ static int netlink_dump(struct sock *sk)
struct nlmsghdr *nlh;
struct module *module;
int err = -ENOBUFS;
+ int alloc_min_size;
int alloc_size;
mutex_lock(nlk->cb_mutex);
@@ -1985,9 +1986,6 @@ static int netlink_dump(struct sock *sk)
goto errout_skb;
}
- cb = &nlk->cb;
- alloc_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
-
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
goto errout_skb;
@@ -1996,22 +1994,34 @@ static int netlink_dump(struct sock *sk)
* to reduce number of system calls on dump operations, if user
* ever provided a big enough buffer.
*/
- if (alloc_size < nlk->max_recvmsg_len) {
- skb = netlink_alloc_skb(sk,
- nlk->max_recvmsg_len,
- nlk->portid,
+ cb = &nlk->cb;
+ alloc_min_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
+
+ if (alloc_min_size < nlk->max_recvmsg_len) {
+ alloc_size = nlk->max_recvmsg_len;
+ skb = netlink_alloc_skb(sk, alloc_size, nlk->portid,
(GFP_KERNEL & ~__GFP_WAIT) |
__GFP_NOWARN | __GFP_NORETRY);
- /* available room should be exact amount to avoid MSG_TRUNC */
- if (skb)
- skb_reserve(skb, skb_tailroom(skb) -
- nlk->max_recvmsg_len);
}
- if (!skb)
+ if (!skb) {
+ alloc_size = alloc_min_size;
skb = netlink_alloc_skb(sk, alloc_size, nlk->portid,
(GFP_KERNEL & ~__GFP_WAIT));
+ }
if (!skb)
goto errout_skb;
+
+ /* Trim skb to allocated size. User is expected to provide buffer as
+ * large as max(min_dump_alloc, 16KiB (mac_recvmsg_len capped at
+ * netlink_recvmsg())). dump will pack as many smaller messages as
+ * could fit within the allocated skb. skb is typically allocated
+ * with larger space than required (could be as much as near 2x the
+ * requested size with align to next power of 2 approach). Allowing
+ * dump to use the excess space makes it difficult for a user to have a
+ * reasonable static buffer based on the expected largest dump of a
+ * single netdev. The outcome is MSG_TRUNC error.
+ */
+ skb_reserve(skb, skb_tailroom(skb) - alloc_size);
netlink_skb_set_owner_r(skb, sk);
if (nlk->dump_done_errno > 0)
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* [PATCH net 0/2] selftests: pmtu: fix and increase coverage
From: Paolo Abeni @ 2019-02-22 16:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
This series includes a fixup for the pmtu test script, related to ipv6
address management, and adds coverage for the recently reported and fixed
pmtu exception issue
Paolo Abeni (2):
selftests: pmtu: disable dad in all namespaces
selftests: pmtu: add explicit tests for pmtu exceptions cleanup
tools/testing/selftests/net/pmtu.sh | 80 +++++++++++++++++++++++------
1 file changed, 64 insertions(+), 16 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net 1/2] selftests: pmtu: disable dad in all namespaces
From: Paolo Abeni @ 2019-02-22 16:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
In-Reply-To: <cover.1550851038.git.pabeni@redhat.com>
Otherwise, the configured IPv6 address could be still "tentative"
at test time, possibly causing tests failures.
We can also drop some sleep along the code and decrease the
timeout for most commands so that the test runtime decreases.
Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
tools/testing/selftests/net/pmtu.sh | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index e2c94e47707c..634e91e8fe25 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -263,8 +263,6 @@ setup_fou_or_gue() {
${ns_a} ip link set ${encap}_a up
${ns_b} ip link set ${encap}_b up
-
- sleep 1
}
setup_fou44() {
@@ -302,6 +300,10 @@ setup_gue66() {
setup_namespaces() {
for n in ${NS_A} ${NS_B} ${NS_R1} ${NS_R2}; do
ip netns add ${n} || return 1
+
+ # disable dad, so that we don't have to wait to use the
+ # configured IPv6 addresses
+ ip netns exec ${n} sysctl -q net/ipv6/conf/default/accept_dad=0
done
}
@@ -337,8 +339,6 @@ setup_vti() {
${ns_a} ip link set vti${proto}_a up
${ns_b} ip link set vti${proto}_b up
-
- sleep 1
}
setup_vti4() {
@@ -375,8 +375,6 @@ setup_vxlan_or_geneve() {
${ns_a} ip link set ${type}_a up
${ns_b} ip link set ${type}_b up
-
- sleep 1
}
setup_geneve4() {
@@ -588,8 +586,8 @@ test_pmtu_ipvX() {
mtu "${ns_b}" veth_B-R2 1500
# Create route exceptions
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1800 ${dst1} > /dev/null
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1800 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst1} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst2} > /dev/null
# Check that exceptions have been created with the correct PMTU
pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst1})"
@@ -621,7 +619,7 @@ test_pmtu_ipvX() {
# Decrease remote MTU on path via R2, get new exception
mtu "${ns_r2}" veth_R2-B 400
mtu "${ns_b}" veth_B-R2 400
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1400 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1400 ${dst2} > /dev/null
pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst2})"
check_pmtu_value "lock 552" "${pmtu_2}" "exceeding MTU, with MTU < min_pmtu" || return 1
@@ -638,7 +636,7 @@ test_pmtu_ipvX() {
check_pmtu_value "1500" "${pmtu_2}" "increasing local MTU" || return 1
# Get new exception
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1400 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1400 ${dst2} > /dev/null
pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst2})"
check_pmtu_value "lock 552" "${pmtu_2}" "exceeding MTU, with MTU < min_pmtu" || return 1
}
@@ -687,7 +685,7 @@ test_pmtu_ipvX_over_vxlanY_or_geneveY_exception() {
mtu "${ns_a}" ${type}_a $((${ll_mtu} + 1000))
mtu "${ns_b}" ${type}_b $((${ll_mtu} + 1000))
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst})"
@@ -767,7 +765,7 @@ test_pmtu_ipvX_over_fouY_or_gueY() {
mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst})"
@@ -825,13 +823,13 @@ test_pmtu_vti4_exception() {
# Send DF packet without exceeding link layer MTU, check that no
# exception is created
- ${ns_a} ping -q -M want -i 0.1 -w 2 -s ${ping_payload} ${tunnel4_b_addr} > /dev/null
+ ${ns_a} ping -q -M want -i 0.1 -w 1 -s ${ping_payload} ${tunnel4_b_addr} > /dev/null
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel4_b_addr})"
check_pmtu_value "" "${pmtu}" "sending packet smaller than PMTU (IP payload length ${esp_payload_rfc4106})" || return 1
# Now exceed link layer MTU by one byte, check that exception is created
# with the right PMTU value
- ${ns_a} ping -q -M want -i 0.1 -w 2 -s $((ping_payload + 1)) ${tunnel4_b_addr} > /dev/null
+ ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((ping_payload + 1)) ${tunnel4_b_addr} > /dev/null
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel4_b_addr})"
check_pmtu_value "${esp_payload_rfc4106}" "${pmtu}" "exceeding PMTU (IP payload length $((esp_payload_rfc4106 + 1)))"
}
@@ -847,7 +845,7 @@ test_pmtu_vti6_exception() {
mtu "${ns_b}" veth_b 4000
mtu "${ns_a}" vti6_a 5000
mtu "${ns_b}" vti6_b 5000
- ${ns_a} ${ping6} -q -i 0.1 -w 2 -s 60000 ${tunnel6_b_addr} > /dev/null
+ ${ns_a} ${ping6} -q -i 0.1 -w 1 -s 60000 ${tunnel6_b_addr} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel6_b_addr})"
--
2.20.1
^ permalink raw reply related
* [PATCH net 2/2] selftests: pmtu: add explicit tests for pmtu exceptions cleanup
From: Paolo Abeni @ 2019-02-22 16:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
In-Reply-To: <cover.1550851038.git.pabeni@redhat.com>
Add a couple of new tests, explicitly checking that the kernel
timely releases pmtu exceptions on related device removal.
This is mostly a regression test vs the issue fixed by:
https://patchwork.ozlabs.org/patch/1045488/
Only 2 new test cases have been added, instead of extending all
the existing ones, because the reproducer requires executing
several commands and would slow down too much the tests otherwise.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
tools/testing/selftests/net/pmtu.sh | 52 ++++++++++++++++++++++++++++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index 634e91e8fe25..4bc72bc26899 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -135,7 +135,9 @@ tests="
pmtu_vti6_default_mtu vti6: default MTU assignment
pmtu_vti4_link_add_mtu vti4: MTU setting on link creation
pmtu_vti6_link_add_mtu vti6: MTU setting on link creation
- pmtu_vti6_link_change_mtu vti6: MTU changes on link changes"
+ pmtu_vti6_link_change_mtu vti6: MTU changes on link changes
+ pmtu_ipv4_exception_cleanup ipv4: cleanup of cached exceptions
+ pmtu_ipv6_exception_cleanup ipv6: cleanup of cached exceptions"
NS_A="ns-$(mktemp -u XXXXXX)"
NS_B="ns-$(mktemp -u XXXXXX)"
@@ -1006,6 +1008,54 @@ test_pmtu_vti6_link_change_mtu() {
return ${fail}
}
+test_cleanup_vxlanY_or_geneveY_exception() {
+ outer="${1}"
+ encap="${2}"
+ ll_mtu=4000
+
+ which taskset 2>/dev/null | return 2
+ which timeout 2>/dev/null | return 2
+ cpu_list=`grep processor /proc/cpuinfo | cut -d ' ' -f 2`
+
+ setup namespaces routing ${encap}${outer} || return 2
+ trace "${ns_a}" ${encap}_a "${ns_b}" ${encap}_b \
+ "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \
+ "${ns_b}" veth_B-R1 "${ns_r1}" veth_R1-B
+
+ # Create route exception by exceeding link layer MTU
+ mtu "${ns_a}" veth_A-R1 $((${ll_mtu} + 1000))
+ mtu "${ns_r1}" veth_R1-A $((${ll_mtu} + 1000))
+ mtu "${ns_b}" veth_B-R1 ${ll_mtu}
+ mtu "${ns_r1}" veth_R1-B ${ll_mtu}
+
+ mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
+ mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
+
+ # fill exception cache for multiple cpus [2]
+ # we can always use inner ipv4 for that
+ ncpus=0
+ for cpu in $cpu_list; do
+ taskset --cpu-list ${cpu} ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${tunnel4_b_addr} > /dev/null
+ ncpus=$((ncpus + 1))
+ [ ${ncpus} -gt 1 ] && break
+ done
+
+ fail=0
+ if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
+ err " can't delete veth device in a timely manner, pmtu dst likely leaked"
+ fail=1
+ fi
+ return ${fail}
+}
+
+test_pmtu_ipv6_exception_cleanup() {
+ test_cleanup_vxlanY_or_geneveY_exception 6 vxlan
+}
+
+test_pmtu_ipv4_exception_cleanup() {
+ test_cleanup_vxlanY_or_geneveY_exception 4 vxlan
+}
+
usage() {
echo
echo "$0 [OPTIONS] [TEST]..."
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v2] route: Add a new fib_multipath_hash_policy base on cpu id for tunnel packet
From: Nikolay Aleksandrov @ 2019-02-22 16:08 UTC (permalink / raw)
To: wenxu, davem; +Cc: netdev
In-Reply-To: <f4edcd7e-339c-4a55-ed85-ca16f4720f13@ucloud.cn>
On 22/02/2019 14:50, wenxu wrote:
> On 2019/2/22 下午6:26, Nikolay Aleksandrov wrote:
>> On 22/02/2019 11:20, wenxu@ucloud.cn wrote:
>>> From: wenxu <wenxu@ucloud.cn>
>>>
>>> Current fib_multipath_hash_policy can make hash based on the L3 or
>>> L4. But it only work on the outer IP. So a specific tunnel always
>>> has the same hash value. But a specific tunnel may contain so many
>>> inner connections. However there is no good way for tunnel packet.
>>> A specific tunnel route based on the percpu dst_cache. It will not
>>> lookup route table for each packet.
>>>
>>> This patch provide a based cpu id hash policy. The different
>>> connection run on different cpu and there will be different hash
>>> value for percpu dst_cache.
>>>
>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>> ---
>>> net/ipv4/route.c | 6 ++++++
>>> net/ipv4/sysctl_net_ipv4.c | 2 +-
>>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>>
>> Hi,
>> When we had the same issue in the bonding, we added a new mode which used
>> the flow dissector to get the inner headers and hash on them.
>> I believe that is even easier nowadays, but I think people wanted to
>> use different hash algorithms as well and last we discussed this we
>> were talking about yet another bpf use to generate the hash.
>> Now we got bpf_set_hash() which can be used to achieve this from various
>> places, if you use that with hash_policy=1 (L4) then skb->hash will
>> be used and you can achieve any hashing that you desire.
>>
>> Cheers,
>> Nik
>>
>>
> Yes, we can set the skb->hash. But ip tunnel lookup the route table without skb.
>
> The most important for performance issue most tunnel send work with dst_cache.
>
> The dst_cache is percpu cache. So the number of dst_entry of a specific tunnel is the cpu cores .
>
> So It's more better hash based on outer and cpu id.
>
>
I was just hoping for a more generic solution, anyway if this would go forward
please add documentation for the new option in Documentation/networking/ip-sysctl.txt
there's a description of fib_multipath_hash_policy. Also how is this supposed to work
if skb is present & skb->hash is set ? I believe it will be ignored, so it really only
works for lookups without an skb (or without a generated hash).
A thought (unchecked/untested, may not make much sense, feel free to ignore):
Why don't you make it mix flowi4_mark in with the hash and add some tunnel option
which mixes the CPU in that field ?
That is the new '2' mode will mix flowi4_mark with the hash and if some specific
tunnel option is set, the tunnel code will mix smp_current_id() with fl4's mark
before calling ip_route_output(), this sounds more useful to me as users will be
able to affect the hash calculation via the mark from other places in different
ways.
Cheers,
Nik
^ permalink raw reply
* Re: [PATCH net] Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
From: Nikolay Aleksandrov @ 2019-02-22 16:20 UTC (permalink / raw)
To: Hangbin Liu, netdev
Cc: roopa, bridge, davem, yinxu, Greg Kroah-Hartman, stable,
Sebastian Gottschall, Linus Lüssing
In-Reply-To: <20190222132232.24123-1-liuhangbin@gmail.com>
On 22/02/2019 15:22, Hangbin Liu wrote:
> This reverts commit 5a2de63fd1a5 ("bridge: do not add port to router list
> when receives query with source 0.0.0.0") and commit 0fe5119e267f ("net:
> bridge: remove ipv6 zero address check in mcast queries")
>
> The reason is RFC 4541 is not a standard but suggestive. Currently we
> will elect 0.0.0.0 as Querier if there is no ip address configured on
> bridge. If we do not add the port which recives query with source
> 0.0.0.0 to router list, the IGMP reports will not be about to forward
> to Querier, IGMP data will also not be able to forward to dest.
>
> As Nikolay suggested, revert this change first and add a boolopt api
> to disable none-zero election in future if needed.
>
> Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
> Reported-by: Sebastian Gottschall <s.gottschall@newmedia-net.de>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Fixes: 0fe5119e267f ("net: bridge: remove ipv6 zero address check in mcast queries")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> net/bridge/br_multicast.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
Thank you. Unfortunately we made a mistake and have to fix compatibility with
the current bridges. As noted in the commit message if this is needed it can
be added as optional behaviour with default off so we don't break any setups.
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH] NETWORKING: avoid use IPCB in cipso_v4_error
From: Nazarov Sergey @ 2019-02-22 16:35 UTC (permalink / raw)
To: David Miller
Cc: paul@paul-moore.com, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org
In-Reply-To: <20190218.172544.1436352995315454863.davem@davemloft.net>
I tried to analyze the cases of using icmp_send in kernel. It indirectly used by many protocols:
ARP, IP, UDP, Netfilter, IPVS, IPIP, GRE over IP, CLIP, XFRM, CIPSOv4.
Different IP tunnels and XFRM operating directly over IP layer and if using own skb->cb data,
having IP header data in front of it. CLIP uses icmp_send for packets from arp queue only.
So, If I right, only TCP layer moves IP header data and only CIPSOv4 operates on both IP and
TCP layers now.
19.02.2019, 04:25, "David Miller" <davem@davemloft.net>:
> From: Nazarov Sergey <s-nazarov@yandex.ru>
> Date: Mon, 18 Feb 2019 16:39:11 +0300
>
>> I think, it would not be a good solution, if I will analyze all
>> subsystems using icmp_send, because I do not have enough knowledge
>> for this. I propose to add a new function, for example,
>> ismp_send_safe, something like that:
>
> Please don't do this.
>
> Solve the problem properly by auditing each case, there aren't a lot and
> it is not too difficult to see the upcall sites.
^ permalink raw reply
* Re: [PATCH] tcp: detect use sendpage for slab-based objects
From: Eric Dumazet @ 2019-02-22 16:39 UTC (permalink / raw)
To: Vasily Averin; +Cc: netdev
In-Reply-To: <80f35733-e3cf-c7da-1822-87054903dc67@virtuozzo.com>
On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>
> On 2/21/19 7:00 PM, Eric Dumazet wrote:
> > On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin <vvs@virtuozzo.com> wrote:
> >> index 2079145a3b7c..cf9572f4fc0f 100644
> >> --- a/net/ipv4/tcp.c
> >> +++ b/net/ipv4/tcp.c
> >> @@ -996,6 +996,7 @@ ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
> >> goto wait_for_memory;
> >>
> >> if (can_coalesce) {
> >> + WARN_ON_ONCE(PageSlab(page));
> >
> > Please use VM_WARN_ON_ONCE() to make this a nop for CONFIG_VM_DEBUG=n
> >
> > Also the whole tcp_sendpage() should be protected, not only the coalescing part.
> >
> > (The get_page() done few lines later should not be attempted either)
> >
> >> skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy);
> >> } else {
> >> get_page(page);
> >> --
> >
> > It seems the bug has nothing to do with TCP, and belongs to the caller.
> >
> > Otherwise you need to add the check to all existing .sendpage() /
> > .sendpage_locked() handler out there.
>
> Eric, could you please elaborate once again why tcp_sendpage() should not handle slab objects?
Simply because SLAB has its own way to manage objects from a page, and
does not care
about the underlying page having its refcount elevated.
ptr = kmalloc(xx)
... < here you can attempt cheating and add one to the underlying page>
kfree(ptr); // SLAB does not care of page count, it will effectively
put ptr in the free list.
ptr2 = kmalloc(xx); //
ptr2 can be the same than ptr (object was kfreed() earlier)
This means that some other stuff will happily reuse the piece of
memory that you wanted to use for zero-copy.
This is a serious bug IMO, since this would allow for data corruption.
>
> There is known restriction: sendpage should not be called for pages with counter=0,
> because internal put_page() releases the page. All sendpage callers I know have such check.
>
> However why they should add one check for PageSlab?
>
> Let me explain the problem once again:
> I do not see any bugs neither in tcp nor in any sendpage callers,
> there is false alert on receiving side that crashes correctly worked host.
This is not a false alert, but a very fundamental issue.
We can not mix kmalloc() and page fragments, this simply is buggy.
>
> There is network block device with XFS,
> XFS submit IO request with slab objects,
> block device driver checks that page count is positive and decides to use sendpage.
> sendpage calls tcp_sendpage() that can merge 2 neighbour slab objects into one tcp fragment.
>
> If data is transferred outside -- nothing bad happen, network device successfully send data outside.
> However if data is received locally tcp_recvmsg detects strange vector with "merged" slab objects.
> It is not real problem, data can be accessed correctly, however this check calls BUG_ON and crashes the host.
>
> By this way recently added hardening check forces all .sendpage callers modify code that worked correctly for ages.
>
> It looks abnormal to me, but I do not understand how to fix this problem correctly.
>
> I do not like an idea to keep current state -- it can trigger crash of correctly worked hosts in some rare corner cases.
> I do not like an idea to fix all callers -- why they need modify correctly worked code to protect from false positive?
> I do not like an idea to modify tcp -- to block merge of fragments with slab objects like I proposed earlier.
> We can trigger warning in tcp code -- to inform .sendpage callers that they are under fire,
> however I agree with yours "bug has nothing to do with TCP" and do not understand why we need to modify tcp_sendpage().
>
> May be it's better to replace BUG_ON to WARN_ON in hardening check?
> Could you probably advise some other solution?
>
> Thank you,
> Vasily Averin
^ permalink raw reply
* Re: [PATCH net-next] net: phy: let genphy_c45_read_abilities also check aneg capability
From: Maxime Chevallier @ 2019-02-22 16:51 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
netdev@vger.kernel.org
In-Reply-To: <a798f789-94a9-f1ac-1cba-276a2c517089@gmail.com>
Hello Heiner,
On Fri, 22 Feb 2019 08:23:04 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
>When using genphy_c45_read_abilities() as get_features callback we
>also have to set the autoneg capability in phydev->supported.
>@@ -336,6 +336,17 @@ int genphy_c45_pma_read_abilities(struct phy_device *phydev)
This makes the helper not reading PMA-only registers, so the naming
isn't really relevant anymore, but that's a small detail.
Other than that,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 3/5] devlink: create a special NDO for getting the devlink instance
From: Jakub Kicinski @ 2019-02-22 16:56 UTC (permalink / raw)
To: Michal Kubecek; +Cc: davem, jiri, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190222095131.GQ23151@unicorn.suse.cz>
On Fri, 22 Feb 2019 10:51:31 +0100, Michal Kubecek wrote:
> On Thu, Feb 21, 2019 at 09:46:18AM -0800, Jakub Kicinski wrote:
> > Instead of iterating over all devlink ports add a NDO which
> > will return the devlink instance from the driver.
> >
> > Suggested-by: Jiri Pirko <jiri@resnulli.us>
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> > include/linux/netdevice.h | 6 ++++
> > net/core/devlink.c | 62 +++++++++++++--------------------------
> > 2 files changed, 26 insertions(+), 42 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index aab4d9f6613d..eebcef6b8191 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -940,6 +940,8 @@ struct dev_ifalias {
> > char ifalias[];
> > };
> >
> > +struct devlink;
> > +
> > /*
> > * This structure defines the management hooks for network devices.
> > * The following hooks can be defined; unless noted otherwise, they are
> > @@ -1248,6 +1250,9 @@ struct dev_ifalias {
> > * that got dropped are freed/returned via xdp_return_frame().
> > * Returns negative number, means general error invoking ndo, meaning
> > * no frames were xmit'ed and core-caller will free all frames.
> > + * struct devlink *(*ndo_get_devlink)(struct net_device *dev);
> > + * Get devlink instance associated with a given netdev.
> > + * Called with a reference on the device only, rtnl_lock is not held.
>
> The formulation is a bit ambiguous. Do I understand correctly that what
> it says is that device reference is sufficient and rtnl_lock is not
> necessary (but there is no harm if caller holds rtnl_lock)?
Yes, only reference is held, the expectation is that drivers free
netdevs before they unregister devlink. The devlink vs rtnl ordering
gets a bit tricky, drivers should definitely not expect rtnl to be held
in this NDO. If the caller comes from rtnl path (like ethtool) it will
likely have to release rtnl before taking devlink->lock.
^ permalink raw reply
* INFO: task hung in rtnetlink_rcv_msg
From: syzbot @ 2019-02-22 17:00 UTC (permalink / raw)
To: ast, christian, daniel, davem, dsahern, hawk, idosch,
jakub.kicinski, john.fastabend, kafai, ktkhai, linux-kernel,
netdev, petrm, roopa, songliubraving, syzkaller-bugs, xdp-newbies,
yhs
Hello,
syzbot found the following crash on:
HEAD commit: 64c0133eb88a Merge tag 'armsoc-fixes' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14976800c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=8218a8a0ff60c19b8eae
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c8a14cc00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1189db74c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8218a8a0ff60c19b8eae@syzkaller.appspotmail.com
INFO: task syz-executor725:8005 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #75
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor725 D27984 8005 7591 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x40a/0xb00 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 <7a> fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac037 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
INFO: task syz-executor725:8008 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #75
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor725 D27552 8008 7590 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x40a/0xb00 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 <7a> fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac03d R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
INFO: task syz-executor725:8009 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #75
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor725 D28008 8009 7595 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x40a/0xb00 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 <7a> fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac03d R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
INFO: task syz-executor725:8010 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #75
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor725 D28000 8010 7596 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x40a/0xb00 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 <7a> fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac03e R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
INFO: task syz-executor725:8011 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #75
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor725 D28008 8011 7594 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x40a/0xb00 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 <7a> fd ff 11 7a
fd ff 11 7a fd ff 11 7a fd ff 11 7a fd ff 11 7a fd
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac03b R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
Showing all locks held in the system:
3 locks held by kworker/1:1/22:
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:220 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:59 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 000000009b0b09b4 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0x87e/0x1790 kernel/workqueue.c:2144
#1: 00000000e8391065 ((addr_chk_work).work){+.+.}, at:
process_one_work+0x8b4/0x1790 kernel/workqueue.c:2148
#2: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:77
1 lock held by khungtaskd/1040:
#0: 00000000083344d4 (rcu_read_lock){....}, at:
debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:4389
1 lock held by rsyslogd/7472:
#0: 000000007562dcc1 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110
fs/file.c:795
2 locks held by getty/7562:
#0: 000000000837ceb2 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000d91e6e17 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7563:
#0: 00000000243db696 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000000002034d (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7564:
#0: 00000000a59e483b (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000004032d53a (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7565:
#0: 0000000025343c97 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000727bf19a (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7566:
#0: 000000003dac20af (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000fef38c44 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7567:
#0: 00000000da1bfc9c (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000f82cf636 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/7568:
#0: 00000000a5d9fcdf (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000005ae165cb (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
1 lock held by syz-executor725/8002:
1 lock held by syz-executor725/8005:
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock
net/core/rtnetlink.c:77 [inline]
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x40a/0xb00
net/core/rtnetlink.c:5127
1 lock held by syz-executor725/8008:
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock
net/core/rtnetlink.c:77 [inline]
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x40a/0xb00
net/core/rtnetlink.c:5127
1 lock held by syz-executor725/8009:
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock
net/core/rtnetlink.c:77 [inline]
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x40a/0xb00
net/core/rtnetlink.c:5127
1 lock held by syz-executor725/8010:
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock
net/core/rtnetlink.c:77 [inline]
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x40a/0xb00
net/core/rtnetlink.c:5127
1 lock held by syz-executor725/8011:
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnl_lock
net/core/rtnetlink.c:77 [inline]
#0: 00000000da1e0257 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x40a/0xb00
net/core/rtnetlink.c:5127
=============================================
NMI backtrace for cpu 0
CPU: 0 PID: 1040 Comm: khungtaskd Not tainted 5.0.0-rc6+ #75
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:203 [inline]
watchdog+0x9df/0xee0 kernel/hung_task.c:287
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 0 to CPUs 1:
INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.415
msecs
NMI backtrace for cpu 1
CPU: 1 PID: 8002 Comm: syz-executor725 Not tainted 5.0.0-rc6+ #75
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:unwind_next_frame.part.0+0x1a8/0x9a0
arch/x86/kernel/unwind_frame.c:329
Code: 8b 6d 20 4c 89 ee 48 89 df 4c 89 95 60 ff ff ff 4c 89 9d 68 ff ff ff
4c 89 8d 70 ff ff ff e8 6f f7 ff ff 4c 8b 8d 70 ff ff ff <41> 89 c0 4c 8b
9d 68 ff ff ff b8 01 00 00 00 45 84 c0 4c 8b 95 60
RSP: 0018:ffff888096136e28 EFLAGS: 00000286
RAX: 0000000000000001 RBX: ffff888096136f00 RCX: 1ffff11012c26de8
RDX: dffffc0000000000 RSI: 1ffff11012c26d00 RDI: ffff888096136f48
RBP: ffff888096136ed8 R08: 0000000000000001 R09: ffff888096136f50
R10: ffff888096136f28 R11: ffff888096136f38 R12: 1ffff11012c26dca
R13: ffff888096137b70 R14: ffff888096137b40 R15: ffff888096137f58
FS: 00000000024b2880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 000000009810b000 CR4: 00000000001406e0
Call Trace:
unwind_next_frame+0x3b/0x50 arch/x86/kernel/unwind_frame.c:287
__save_stack_trace+0x7a/0xf0 arch/x86/kernel/stacktrace.c:44
save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
__do_kmalloc_node mm/slab.c:3673 [inline]
__kmalloc_node_track_caller+0x4e/0x70 mm/slab.c:3687
__kmalloc_reserve.isra.0+0x40/0xf0 net/core/skbuff.c:140
pskb_expand_head+0x14e/0xdd0 net/core/skbuff.c:1465
netlink_trim+0x215/0x270 net/netlink/af_netlink.c:1292
netlink_unicast+0xbf/0x720 net/netlink/af_netlink.c:1326
rtnetlink_send+0xf0/0x110 net/core/rtnetlink.c:721
tcf_add_notify net/sched/act_api.c:1325 [inline]
tcf_action_add+0x243/0x370 net/sched/act_api.c:1344
tc_ctl_action+0x3b6/0x4bd net/sched/act_api.c:1392
rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5130
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4459f9
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 0b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdc979ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004459f9
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00000000000ac031 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000200015a6 R11: 0000000000000246 R12: 0000000000406890
R13: 0000000000406920 R14: 0000000000000000 R15: 0000000000000000
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next 4/5] nfp: add .ndo_get_devlink
From: Jakub Kicinski @ 2019-02-22 17:02 UTC (permalink / raw)
To: Michal Kubecek; +Cc: davem, jiri, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190222100450.GR23151@unicorn.suse.cz>
On Fri, 22 Feb 2019 11:04:50 +0100, Michal Kubecek wrote:
> On Thu, Feb 21, 2019 at 09:46:19AM -0800, Jakub Kicinski wrote:
> > Support getting devlink instance from a new NDO.
> >
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> > drivers/net/ethernet/netronome/nfp/nfp_app.h | 2 ++
> > drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 11 +++++++++++
> > drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 1 +
> > drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 1 +
> > 4 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.h b/drivers/net/ethernet/netronome/nfp/nfp_app.h
> > index d578d856a009..f8d422713705 100644
> > --- a/drivers/net/ethernet/netronome/nfp/nfp_app.h
> > +++ b/drivers/net/ethernet/netronome/nfp/nfp_app.h
> > @@ -433,4 +433,6 @@ int nfp_app_nic_vnic_alloc(struct nfp_app *app, struct nfp_net *nn,
> > int nfp_app_nic_vnic_init_phy_port(struct nfp_pf *pf, struct nfp_app *app,
> > struct nfp_net *nn, unsigned int id);
> >
> > +struct devlink *nfp_devlink_get_devlink(struct net_device *netdev);
> > +
> > #endif
> > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > index db2da99f6aa7..e9eca99cf493 100644
> > --- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > +++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > @@ -376,3 +376,14 @@ void nfp_devlink_port_unregister(struct nfp_port *port)
> > {
> > devlink_port_unregister(&port->dl_port);
> > }
> > +
> > +struct devlink *nfp_devlink_get_devlink(struct net_device *netdev)
> > +{
> > + struct nfp_app *app;
> > +
> > + app = nfp_app_from_netdev(netdev);
> > + if (!app)
> > + return NULL;
> > +
> > + return priv_to_devlink(app->pf);
> > +}
>
> AFAICS this would return a pointer to zero initialized struct devlink
> when built with CONFIG_DEVLINK=n. Then devlink_compat_running_version()
> would execute
>
> if (!dev->netdev_ops->ndo_get_devlink)
> return;
>
> devlink = dev->netdev_ops->ndo_get_devlink(dev);
> if (!devlink || !devlink->ops->info_get)
> return;
>
> with non-null devlink but null devlink->ops so that it dereferences null
> pointer (and so does devlink_compat_flash_update()).
devlink_compat_flash_update() is this if CONFIG_DEVLINK=n:
static inline int
devlink_compat_flash_update(struct net_device *dev, const char *file_name)
{
return -EOPNOTSUPP;
}
No?
> Maybe it would be safer not to call ndo_get_devlink directly and have
> an inline wrapper like
>
> #if IS_ENABLED(CONFIG_NET_DEVLINK)
> static inline struct devlink *dev_get_devlink(struct net_device *dev)
> {
> if (dev->netdev_ops->ndo_get_devlink)
> return dev->netdev_ops->ndo_get_devlink();
> else
> retrurn NULL;
> }
> #else
> static inline struct devlink *dev_get_devlink(struct net_device *dev)
> {
> return NULL;
> }
> #endif
>
> so that one can simply call the wrapper and check return value for NULL.
Only devlink code can call this ndo, and it doesn't exist with
DEVLINK=n. I don't dislike wrappers for NDOs, but I'll defer to Jiri
to decide if we want a wrapper here (without the #if/#else, just the
first part for code clarity) :)
^ permalink raw reply
* Re: [PATCH v5 0/5] M_CAN Framework re-write
From: Dan Murphy @ 2019-02-22 17:05 UTC (permalink / raw)
To: Wolfgang Grandegger, mkl, davem; +Cc: linux-can, netdev, linux-kernel
In-Reply-To: <b60b8781-d979-24e7-805a-95f9237c816e@ti.com>
Wolfgang
On 2/22/19 6:50 AM, Dan Murphy wrote:
> Wolfgang
>
> On 2/22/19 3:38 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> what kernel version is that patch series for. I have problems to apply it!
>>
>
> It is based off of Master
>
> commit 2137397c92aec3713fa10be3c9b830f9a1674e60 (linux_master/master)
>
> And I successfully rebased on top of
>
> commit 8a61716ff2ab23eddd1f7a05a075a374e4d0c3d4 (linux_master/master)
> Merge tag 'ceph-for-5.0-rc8' of git://github.com/ceph/ceph-client
>
I just pulled these patches and they applied fine to the top commit of linux master
Do I need to rebase on top of a for-next branch for you?
Dan
> Dan
>
>> Wolfgang.
>>
>> Am 21.02.19 um 17:41 schrieb Wolfgang Grandegger:
>>> Hello Dan,
>>>
>>> I will have a closer look end of this week!
>>>
>>> Wolfgang.
>>>
>>> Am 21.02.19 um 17:24 schrieb Dan Murphy:
>>>> Bump
>>>>
>>>> On 2/14/19 12:27 PM, Dan Murphy wrote:
>>>>> Hello
>>>>>
>>>>> OK I did not give up on this patch series just got a little preoccupied with
>>>>> some other kernel work. But here is the update per the comments.
>>>>>
>>>>> It should be understood I broke these out for reviewability.
>>>>> For instance the first patch does not compile on its own as including this
>>>>> patch should not change the current functionality and it pulls all the io-mapped
>>>>> code from the m_can base file to a platfrom file.
>>>>>
>>>>> The next patch "Migrate the m_can code to use the framework"
>>>>> is the change to the kernel for the io-mapped conversion from a flat file to use
>>>>> the framework. Finally the rename patch just renames the m_can_priv to
>>>>> m_can_classdev. I broke this change out specifically for readability of the
>>>>> migration patch per comments on the code.
>>>>>
>>>>> AFAIC the first 3 patches can all be squashed into a single patch. Or the
>>>>> first 2 patches in the series can be re-arranged but then m_can functionality is
>>>>> affected in the migration patch.
>>>>>
>>>>> Again the first 3 patches here are all just for readability and review purposes.
>>>>>
>>>>> Dan
>>>>>
>>>>> Dan Murphy (5):
>>>>> can: m_can: Create a m_can platform framework
>>>>> can: m_can: Migrate the m_can code to use the framework
>>>>> can: m_can: Rename m_can_priv to m_can_classdev
>>>>> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
>>>>> can: tcan4x5x: Add tcan4x5x driver to the kernel
>>>>>
>>>>> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
>>>>> drivers/net/can/m_can/Kconfig | 14 +-
>>>>> drivers/net/can/m_can/Makefile | 2 +
>>>>> drivers/net/can/m_can/m_can.c | 788 +++++++++---------
>>>>> drivers/net/can/m_can/m_can.h | 159 ++++
>>>>> drivers/net/can/m_can/m_can_platform.c | 198 +++++
>>>>> drivers/net/can/m_can/tcan4x5x.c | 531 ++++++++++++
>>>>> 7 files changed, 1320 insertions(+), 409 deletions(-)
>>>>> create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>>>> create mode 100644 drivers/net/can/m_can/m_can.h
>>>>> create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>>>> create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>>>>
>>>>
>>>>
>
>
--
------------------
Dan Murphy
^ permalink raw reply
* WARNING in xt_compat_add_offset
From: syzbot @ 2019-02-22 17:10 UTC (permalink / raw)
To: coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 8a61716ff2ab Merge tag 'ceph-for-5.0-rc8' of git://github...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1456fa6cc00000
kernel config: https://syzkaller.appspot.com/x/.config?x=7132344728e7ec3f
dashboard link: https://syzkaller.appspot.com/bug?extid=276ddebab3382bbf72db
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=140c0914c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready
8021q: adding VLAN 0 to HW filter on device batadv0
cannot load conntrack support for proto=7
WARNING: CPU: 1 PID: 7458 at net/netfilter/x_tables.c:654
xt_compat_add_offset+0x22a/0x290 net/netfilter/x_tables.c:654
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 7458 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:571
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:xt_compat_add_offset+0x22a/0x290 net/netfilter/x_tables.c:654
Code: 00 01 e8 59 67 bb fb 44 89 e0 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f
5d c3 e8 42 67 bb fb 0f 0b e9 56 fe ff ff e8 36 67 bb fb <0f> 0b 41 bc f4
ff ff ff eb ce 4c 89 f7 e8 14 6a f2 fb e9 75 ff ff
RSP: 0018:ffff8880a8197808 EFLAGS: 00010293
RAX: ffff88809055e040 RBX: ffff8882166548d0 RCX: ffffffff85b47892
RDX: 0000000000000000 RSI: ffffffff85b47a4a RDI: ffff8882166549f0
RBP: ffff8880a8197838 R08: ffff88809055e040 R09: ffffed1042cca92f
R10: ffffed1042cca92e R11: ffff888216654977 R12: 0000000000000018
R13: 0000000000000030 R14: ffff88809055e040 R15: 0000000000000000
size_entry_mwt net/bridge/netfilter/ebtables.c:2183 [inline]
compat_copy_entries+0x51b/0x1360 net/bridge/netfilter/ebtables.c:2208
compat_do_replace+0x3b3/0x680 net/bridge/netfilter/ebtables.c:2302
compat_do_ebt_set_ctl+0x229/0x278 net/bridge/netfilter/ebtables.c:2384
compat_nf_sockopt net/netfilter/nf_sockopt.c:144 [inline]
compat_nf_setsockopt+0x9b/0x140 net/netfilter/nf_sockopt.c:156
compat_ip_setsockopt net/ipv4/ip_sockglue.c:1284 [inline]
compat_ip_setsockopt+0x106/0x140 net/ipv4/ip_sockglue.c:1265
compat_udp_setsockopt+0x68/0xb0 net/ipv4/udp.c:2629
compat_ipv6_setsockopt+0xca/0x210 net/ipv6/ipv6_sockglue.c:959
inet_csk_compat_setsockopt+0x99/0x120 net/ipv4/inet_connection_sock.c:1054
compat_tcp_setsockopt+0x4d/0x80 net/ipv4/tcp.c:3079
compat_sock_common_setsockopt+0xb4/0x150 net/core/sock.c:3002
__compat_sys_setsockopt+0x176/0x610 net/compat.c:404
__do_compat_sys_setsockopt net/compat.c:417 [inline]
__se_compat_sys_setsockopt net/compat.c:414 [inline]
__ia32_compat_sys_setsockopt+0xbd/0x150 net/compat.c:414
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x281/0xc98 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fd3869
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f7fcf0cc EFLAGS: 00000296 ORIG_RAX: 000000000000016e
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000000000
RDX: 0000000000000080 RSI: 00000000200000c0 RDI: 0000000000000270
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 1/3] ipv4: icmp: use icmp_sk_exit()
From: Eric Dumazet @ 2019-02-22 17:11 UTC (permalink / raw)
To: Kefeng Wang, davem, netdev
In-Reply-To: <20190222015800.192135-1-wangkefeng.wang@huawei.com>
On 02/21/2019 05:57 PM, Kefeng Wang wrote:
> Simply use icmp_sk_exit() when inet_ctl_sock_create() fail in icmp_sk_init().
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> net/ipv4/icmp.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 065997f414e6..364cfe5e414b 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -1245,9 +1245,7 @@ static int __net_init icmp_sk_init(struct net *net)
> return 0;
>
> fail:
> - for_each_possible_cpu(i)
> - inet_ctl_sock_destroy(*per_cpu_ptr(net->ipv4.icmp_sk, i));
> - free_percpu(net->ipv4.icmp_sk);
> + icmp_sk_exit(net);
> return err;
> }
>
>
I do not like this. Future changes in icmp_sk_exit() might trigger a bug in this seldom tested path.
^ 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