* [PATCH 3/4] net: dsa: vsc73xx: add support for parallel mode
From: Pawel Dembicki @ 2019-07-01 15:27 UTC (permalink / raw)
Cc: linus.walleij, paweldembicki, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, Rob Herring, Mark Rutland,
netdev, devicetree, linux-kernel
In-Reply-To: <20190701152723.624-1-paweldembicki@gmail.com>
This patch add platform part of vsc73xx driver.
It allows to use chip connected by PI interface.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
---
drivers/net/dsa/Kconfig | 8 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/vitesse-vsc73xx-platform.c | 166 +++++++++++++++++++++
3 files changed, 175 insertions(+)
create mode 100644 drivers/net/dsa/vitesse-vsc73xx-platform.c
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 4ab2aa09e2e4..80965808949d 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -116,4 +116,12 @@ config NET_DSA_VITESSE_VSC73XX_SPI
---help---
This enables support for the Vitesse VSC7385, VSC7388, VSC7395
and VSC7398 SparX integrated ethernet switches in SPI managed mode.
+
+config NET_DSA_VITESSE_VSC73XX_PLATFORM
+ tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
+ depends on HAS_IOMEM
+ select NET_DSA_VITESSE_VSC73XX
+ ---help---
+ This enables support for the Vitesse VSC7385, VSC7388, VSC7395
+ and VSC7398 SparX integrated ethernet switches in Platform managed mode.
endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 117bf78be211..d5e4c668ac03 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX) += vitesse-vsc73xx-core.o
+obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_PLATFORM) += vitesse-vsc73xx-platform.o
obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_SPI) += vitesse-vsc73xx-spi.o
obj-y += b53/
obj-y += microchip/
diff --git a/drivers/net/dsa/vitesse-vsc73xx-platform.c b/drivers/net/dsa/vitesse-vsc73xx-platform.c
new file mode 100644
index 000000000000..b2e5da0ffde3
--- /dev/null
+++ b/drivers/net/dsa/vitesse-vsc73xx-platform.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/* DSA driver for:
+ * Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
+ *
+ * This driver takes control of the switch chip over Platform and
+ * configures it to route packages around when connected to a CPU port.
+ *
+ * Copyright (C) 2019 pawel Dembicki <paweldembicki@gmail.com>
+ * Based on vitesse-vsc-spi.c by:
+ * Copyright (C) 2018 Linus Wallej <linus.walleij@linaro.org>
+ * Includes portions of code from the firmware uploader by:
+ * Copyright (C) 2009 Gabor Juhos <juhosg@openwrt.org>
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "vitesse-vsc73xx.h"
+
+#define VSC73XX_CMD_PLATFORM_BLOCK_SHIFT 14
+#define VSC73XX_CMD_PLATFORM_BLOCK_MASK 0x7
+#define VSC73XX_CMD_PLATFORM_SUBBLOCK_SHIFT 10
+#define VSC73XX_CMD_PLATFORM_SUBBLOCK_MASK 0xf
+#define VSC73XX_CMD_PLATFORM_REGISTER_SHIFT 2
+
+/**
+ * struct vsc73xx_platform - VSC73xx Platform state container
+ */
+struct vsc73xx_platform {
+ struct platform_device *pdev;
+ void __iomem *base_addr;
+ struct vsc73xx vsc;
+};
+
+static const struct vsc73xx_ops vsc73xx_platform_ops;
+
+static u32 vsc73xx_make_addr(u8 block, u8 subblock, u8 reg)
+{
+ u32 ret;
+
+ ret = (block & VSC73XX_CMD_PLATFORM_BLOCK_MASK)
+ << VSC73XX_CMD_PLATFORM_BLOCK_SHIFT;
+ ret |= (subblock & VSC73XX_CMD_PLATFORM_SUBBLOCK_MASK)
+ << VSC73XX_CMD_PLATFORM_SUBBLOCK_SHIFT;
+ ret |= reg << VSC73XX_CMD_PLATFORM_REGISTER_SHIFT;
+
+ return ret;
+}
+
+static int vsc73xx_platform_read(struct vsc73xx *vsc, u8 block, u8 subblock,
+ u8 reg, u32 *val)
+{
+ struct vsc73xx_platform *vsc_platform = vsc->priv;
+ u32 offset;
+
+ if (!vsc73xx_is_addr_valid(block, subblock))
+ return -EINVAL;
+
+ offset = vsc73xx_make_addr(block, subblock, reg);
+
+ mutex_lock(&vsc->lock);
+ *val = ioread32be(vsc_platform->base_addr + offset);
+ mutex_unlock(&vsc->lock);
+
+ return 0;
+}
+
+static int vsc73xx_platform_write(struct vsc73xx *vsc, u8 block, u8 subblock,
+ u8 reg, u32 val)
+{
+ struct vsc73xx_platform *vsc_platform = vsc->priv;
+ u32 offset;
+
+ if (!vsc73xx_is_addr_valid(block, subblock))
+ return -EINVAL;
+
+ offset = vsc73xx_make_addr(block, subblock, reg);
+
+ mutex_lock(&vsc->lock);
+ iowrite32be(val, vsc_platform->base_addr + offset);
+ mutex_unlock(&vsc->lock);
+
+ return 0;
+}
+
+static int vsc73xx_platform_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct vsc73xx_platform *vsc_platform;
+ struct resource *res = NULL;
+ int ret;
+
+ vsc_platform = devm_kzalloc(dev, sizeof(*vsc_platform), GFP_KERNEL);
+ if (!vsc_platform)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, vsc_platform);
+ vsc_platform->pdev = pdev;
+ vsc_platform->vsc.dev = dev;
+ vsc_platform->vsc.priv = vsc_platform;
+ vsc_platform->vsc.ops = &vsc73xx_platform_ops;
+
+ /* obtain I/O memory space */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "cannot obtain I/O memory space\n");
+ ret = -ENXIO;
+ return ret;
+ }
+
+ vsc_platform->base_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (!vsc_platform->base_addr) {
+ dev_err(&pdev->dev, "cannot request I/O memory space\n");
+ ret = -ENXIO;
+ return ret;
+ }
+
+ return vsc73xx_probe(&vsc_platform->vsc);
+}
+
+static int vsc73xx_platform_remove(struct platform_device *pdev)
+{
+ struct vsc73xx_platform *vsc_platform = platform_get_drvdata(pdev);
+
+ return vsc73xx_remove(&vsc_platform->vsc);
+}
+
+static const struct vsc73xx_ops vsc73xx_platform_ops = {
+ .read = vsc73xx_platform_read,
+ .write = vsc73xx_platform_write,
+};
+
+static const struct of_device_id vsc73xx_platform_of_match[] = {
+ {
+ .compatible = "vitesse,vsc7385-platform",
+ },
+ {
+ .compatible = "vitesse,vsc7388-platform",
+ },
+ {
+ .compatible = "vitesse,vsc7395-platform",
+ },
+ {
+ .compatible = "vitesse,vsc7398-platform",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, vsc73xx_platform_of_match);
+
+static struct platform_driver vsc73xx_platform_driver = {
+ .probe = vsc73xx_platform_probe,
+ .remove = vsc73xx_platform_remove,
+ .driver = {
+ .name = "vsc73xx-platform",
+ .of_match_table = vsc73xx_platform_of_match,
+ },
+};
+module_platform_driver(vsc73xx_platform_driver);
+
+MODULE_AUTHOR("Pawel Dembicki <paweldembicki@gmail.com>");
+MODULE_DESCRIPTION("Vitesse VSC7385/7388/7395/7398 Platform driver");
+MODULE_LICENSE("GPL v2");
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] net: dsa: Change DT bindings for Vitesse VSC73xx switches
From: Pawel Dembicki @ 2019-07-01 15:27 UTC (permalink / raw)
Cc: linus.walleij, paweldembicki, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, Rob Herring, Mark Rutland,
netdev, devicetree, linux-kernel
This commit document changes after split vsc73xx driver into core and
spi part. The change of DT bindings is required for support the same
vsc73xx chip, which need PI bus to communicate with CPU. It also
introduce how to use vsc73xx platform driver.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
---
.../bindings/net/dsa/vitesse,vsc73xx.txt | 74 ++++++++++++++++---
1 file changed, 64 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
index ed4710c40641..c6a4cd85891c 100644
--- a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
+++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
@@ -2,8 +2,8 @@ Vitesse VSC73xx Switches
========================
This defines device tree bindings for the Vitesse VSC73xx switch chips.
-The Vitesse company has been acquired by Microsemi and Microsemi in turn
-acquired by Microchip but retains this vendor branding.
+The Vitesse company has been acquired by Microsemi and Microsemi has
+been acquired Microchip but retains this vendor branding.
The currently supported switch chips are:
Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
@@ -11,16 +11,26 @@ Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
-The device tree node is an SPI device so it must reside inside a SPI bus
-device tree node, see spi/spi-bus.txt
+This switch could have two different management interface.
+
+If SPI interface is used, the device tree node is an SPI device so it must
+reside inside a SPI bus device tree node, see spi/spi-bus.txt
+
+If Platform driver is used, the device tree node is an platform device so it
+must reside inside a platform bus device tree node.
Required properties:
-- compatible: must be exactly one of:
- "vitesse,vsc7385"
- "vitesse,vsc7388"
- "vitesse,vsc7395"
- "vitesse,vsc7398"
+- compatible (SPI): must be exactly one of:
+ "vitesse,vsc7385-spi"
+ "vitesse,vsc7388-spi"
+ "vitesse,vsc7395-spi"
+ "vitesse,vsc7398-spi"
+- compatible (Platform): must be exactly one of:
+ "vitesse,vsc7385-platform"
+ "vitesse,vsc7388-platform"
+ "vitesse,vsc7395-platform"
+ "vitesse,vsc7398-platform"
- gpio-controller: indicates that this switch is also a GPIO controller,
see gpio/gpio.txt
- #gpio-cells: this must be set to <2> and indicates that we are a twocell
@@ -38,8 +48,9 @@ and subnodes of DSA switches.
Examples:
+SPI:
switch@0 {
- compatible = "vitesse,vsc7395";
+ compatible = "vitesse,vsc7395-spi";
reg = <0>;
/* Specified for 2.5 MHz or below */
spi-max-frequency = <2500000>;
@@ -79,3 +90,46 @@ switch@0 {
};
};
};
+
+Platform:
+switch@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "vitesse,vsc7385-platform";
+ reg = <0x2 0x0 0x20000>;
+ reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ vsc: port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&enet0>;
+ phy-mode = "rgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+
+};
--
2.20.1
^ permalink raw reply related
* [PATCH net] net: don't warn in inet diag when IPV6 is disabled
From: Stephen Hemminger @ 2019-07-01 15:23 UTC (permalink / raw)
To: davem, kuznet, yoshfuji; +Cc: netdev, Stephen Hemminger
If IPV6 was disabled, then ss command would cause a kernel warning
because the command was attempting to dump IPV6 socke information.
This should not be a warning, instead just return a normal error
code.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202249
Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
net/ipv4/raw_diag.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/raw_diag.c b/net/ipv4/raw_diag.c
index 899e34ceb560..045485d39f23 100644
--- a/net/ipv4/raw_diag.c
+++ b/net/ipv4/raw_diag.c
@@ -19,9 +19,11 @@ raw_get_hashinfo(const struct inet_diag_req_v2 *r)
{
if (r->sdiag_family == AF_INET) {
return &raw_v4_hashinfo;
-#if IS_ENABLED(CONFIG_IPV6)
} else if (r->sdiag_family == AF_INET6) {
+#if IS_ENABLED(CONFIG_IPV6)
return &raw_v6_hashinfo;
+#else
+ return ERR_PTR(-EOPNOTSUPP);
#endif
} else {
pr_warn_once("Unexpected inet family %d\n",
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Willem de Bruijn @ 2019-07-01 15:12 UTC (permalink / raw)
To: Antoine Tenart
Cc: David Miller, Richard Cochran, alexandre.belloni, UNGLinuxDriver,
ralf, paul.burton, jhogan, Network Development, linux-mips,
thomas.petazzoni, allan.nielsen
In-Reply-To: <20190701100327.6425-9-antoine.tenart@bootlin.com>
On Mon, Jul 1, 2019 at 6:05 AM Antoine Tenart
<antoine.tenart@bootlin.com> wrote:
>
> This patch adds support for PTP Hardware Clock (PHC) to the Ocelot
> switch for both PTP 1-step and 2-step modes.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> void ocelot_deinit(struct ocelot *ocelot)
> {
> + struct ocelot_port *port;
> + struct ocelot_skb *entry;
> + struct list_head *pos;
> + int i;
> +
> destroy_workqueue(ocelot->stats_queue);
> mutex_destroy(&ocelot->stats_lock);
> ocelot_ace_deinit();
> +
> + for (i = 0; i < ocelot->num_phys_ports; i++) {
> + port = ocelot->ports[i];
> +
> + list_for_each(pos, &port->skbs) {
> + entry = list_entry(pos, struct ocelot_skb, head);
> +
> + list_del(pos);
list_for_each_safe
> + kfree(entry);
> + }
> + }
> }
> EXPORT_SYMBOL(ocelot_deinit);
^ permalink raw reply
* Re: [PATCH v2 0/3] vsock/virtio: several fixes in the .probe() and .remove()
From: Stefan Hajnoczi @ 2019-07-01 15:11 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Stefan Hajnoczi, David S. Miller
In-Reply-To: <20190628123659.139576-1-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
On Fri, Jun 28, 2019 at 02:36:56PM +0200, Stefano Garzarella wrote:
> During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock
> before registering the driver", Stefan pointed out some possible issues
> in the .probe() and .remove() callbacks of the virtio-vsock driver.
>
> This series tries to solve these issues:
> - Patch 1 adds RCU critical sections to avoid use-after-free of
> 'the_virtio_vsock' pointer.
> - Patch 2 stops workers before to call vdev->config->reset(vdev) to
> be sure that no one is accessing the device.
> - Patch 3 moves the works flush at the end of the .remove() to avoid
> use-after-free of 'vsock' object.
>
> v2:
> - Patch 1: use RCU to protect 'the_virtio_vsock' pointer
> - Patch 2: no changes
> - Patch 3: flush works only at the end of .remove()
> - Removed patch 4 because virtqueue_detach_unused_buf() returns all the buffers
> allocated.
>
> v1: https://patchwork.kernel.org/cover/10964733/
This looks good to me.
Did you run any stress tests? For example an SMP guest constantly
connecting and sending packets together with a script that
hotplug/unplugs vhost-vsock-pci from the host side.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
From: Stefan Hajnoczi @ 2019-07-01 15:10 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Stefan Hajnoczi, David S. Miller
In-Reply-To: <20190628123659.139576-2-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
On Fri, Jun 28, 2019 at 02:36:57PM +0200, Stefano Garzarella wrote:
> Some callbacks used by the upper layers can run while we are in the
> .remove(). A potential use-after-free can happen, because we free
> the_virtio_vsock without knowing if the callbacks are over or not.
>
> To solve this issue we move the assignment of the_virtio_vsock at the
> end of .probe(), when we finished all the initialization, and at the
> beginning of .remove(), before to release resources.
> For the same reason, we do the same also for the vdev->priv.
>
> We use RCU to be sure that all callbacks that use the_virtio_vsock
> ended before freeing it. This is not required for callbacks that
> use vdev->priv, because after the vdev->config->del_vqs() we are sure
> that they are ended and will no longer be invoked.
My question is answered in Patch 3.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] vsock/virtio: fix flush of works during the .remove()
From: Stefan Hajnoczi @ 2019-07-01 15:09 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Stefan Hajnoczi, David S. Miller
In-Reply-To: <20190628123659.139576-4-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On Fri, Jun 28, 2019 at 02:36:59PM +0200, Stefano Garzarella wrote:
> This patch moves the flush of works after vdev->config->del_vqs(vdev),
> because we need to be sure that no workers run before to free the
> 'vsock' object.
>
> Since we stopped the workers using the [tx|rx|event]_run flags,
> we are sure no one is accessing the device while we are calling
> vdev->config->reset(vdev), so we can safely move the workers' flush.
>
> Before the vdev->config->del_vqs(vdev), workers can be scheduled
> by VQ callbacks, so we must flush them after del_vqs(), to avoid
> use-after-free of 'vsock' object.
Nevermind, I looked back at Patch 2 and saw the send_pkt and loopback
work functions were also updated. Thanks!
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] vsock/virtio: fix flush of works during the .remove()
From: Stefan Hajnoczi @ 2019-07-01 15:08 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Stefan Hajnoczi, David S. Miller
In-Reply-To: <20190628123659.139576-4-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On Fri, Jun 28, 2019 at 02:36:59PM +0200, Stefano Garzarella wrote:
> This patch moves the flush of works after vdev->config->del_vqs(vdev),
> because we need to be sure that no workers run before to free the
> 'vsock' object.
>
> Since we stopped the workers using the [tx|rx|event]_run flags,
> we are sure no one is accessing the device while we are calling
> vdev->config->reset(vdev), so we can safely move the workers' flush.
What about send_pkt and loopback work? How were they stopped safely?
For example, if send_pkt work executes then we're in trouble since it
accesses the tx virtqueue which is deleted by ->del_vqs().
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] samples: pktgen: allow to specify destination port
From: Jesper Dangaard Brouer @ 2019-07-01 15:08 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: David S . Miller, netdev, brouer, Robert Olsson, Jean Hsiao
In-Reply-To: <20190629133358.8251-2-danieltimlee@gmail.com>
On Sat, 29 Jun 2019 22:33:58 +0900
"Daniel T. Lee" <danieltimlee@gmail.com> wrote:
> Currently, kernel pktgen has the feature to specify udp destination port
> for sending packet. (e.g. pgset "udp_dst_min 9")
>
> But on samples, each of the scripts doesn't have any option to achieve this.
>
> This commit adds the DST_PORT option to specify the target port(s) in the script.
>
> -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
Nice feature, this look very usable for testing. I think my QA asked
me for something similar.
One nitpick is that script named pktgen_sample03_burst_single_flow.sh
implies this is a single flow, but by specifying a port-range this will
be more flows. I'm okay with adding this, as the end-user specifying a
port-range should realize this. Thus, you get my ACK.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Another thing you should realize (but you/we cannot do anything about)
is that when the scripts use burst or clone, then the port (UDPDST_RND)
will be the same for all packets in the same burst. I don't know if it
matters for your use-case.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] hinic: reduce rss_init stack usage
From: Arnd Bergmann @ 2019-07-01 15:03 UTC (permalink / raw)
To: David Miller
Cc: Aviad Krawczyk, xuechaojing, Jesse Brandeburg, zhaochen6,
Eric Dumazet, Dann Frazier, Networking, Linux Kernel Mailing List
In-Reply-To: <20190628.093215.173840298920978641.davem@davemloft.net>
On Fri, Jun 28, 2019 at 6:32 PM David Miller <davem@davemloft.net> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Fri, 28 Jun 2019 12:31:44 +0200
>
> > On 32-bit architectures, putting an array of 256 u32 values on the
> > stack uses more space than the warning limit:
> >
> > drivers/net/ethernet/huawei/hinic/hinic_main.c: In function 'hinic_rss_init':
> > drivers/net/ethernet/huawei/hinic/hinic_main.c:286:1: error: the frame size of 1068 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> >
> > I considered changing the code to use u8 values here, since that's
> > all the hardware supports, but dynamically allocating the array is
> > a more isolated fix here.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Applied to net-next.
Thanks
> Arnd, please make it clear what tree you are targetting in the
> future.
Sorry about missing this again. I usually remember but sometimes
one slips through when I send a lot of patches for different subsystems
at once.
Arnd
^ permalink raw reply
* Re: [PATCH 00/11] XDP unaligned chunk placement support
From: Laatz, Kevin @ 2019-07-01 14:58 UTC (permalink / raw)
To: Jonathan Lemon
Cc: Jakub Kicinski, netdev, ast, daniel, bjorn.topel, magnus.karlsson,
bpf, intel-wired-lan, bruce.richardson, ciara.loftus
In-Reply-To: <BAE24CBF-416D-4665-B2C9-CE1F5EAE28FF@gmail.com>
On 28/06/2019 21:29, Jonathan Lemon wrote:
> On 28 Jun 2019, at 9:19, Laatz, Kevin wrote:
>> On 27/06/2019 22:25, Jakub Kicinski wrote:
>>> I think that's very limiting. What is the challenge in providing
>>> aligned addresses, exactly?
>> The challenges are two-fold:
>> 1) it prevents using arbitrary buffer sizes, which will be an issue
>> supporting e.g. jumbo frames in future.
>> 2) higher level user-space frameworks which may want to use AF_XDP,
>> such as DPDK, do not currently support having buffers with 'fixed'
>> alignment.
>> The reason that DPDK uses arbitrary placement is that:
>> - it would stop things working on certain NICs which need the
>> actual writable space specified in units of 1k - therefore we need 2k
>> + metadata space.
>> - we place padding between buffers to avoid constantly
>> hitting the same memory channels when accessing memory.
>> - it allows the application to choose the actual buffer size
>> it wants to use.
>> We make use of the above to allow us to speed up processing
>> significantly and also reduce the packet buffer memory size.
>>
>> Not having arbitrary buffer alignment also means an AF_XDP driver
>> for DPDK cannot be a drop-in replacement for existing drivers in
>> those frameworks. Even with a new capability to allow an arbitrary
>> buffer alignment, existing apps will need to be modified to use that
>> new capability.
>
> Since all buffers in the umem are the same chunk size, the original
> buffer
> address can be recalculated with some multiply/shift math. However,
> this is
> more expensive than just a mask operation.
Yes, we can do this.
Another option we have is to add a socket option for querying the
metadata length from the driver (assuming it doesn't vary per packet).
We can use that information to get back the original address using
subtraction.
Alternatively, we can change the Rx descriptor format to include the
metadata length. We could do this in a couple of ways, for example,
rather than returning the address at the start of the packet, instead
return the buffer address that was passed in, and adding another 16-bit
field to specify the start of the packet offset with that buffer. Id
using 16-bits of descriptor space is not desirable, an alternative could
be to limit umem sizes to e.g. 2^48 bits (256 terabytes should be
enough, right :-) ) and use the remaining 16 bits of the address as a
packet offset. Other variations on these approaches are obviously
possible too.
^ permalink raw reply
* Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
From: Stefan Hajnoczi @ 2019-07-01 14:54 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Stefan Hajnoczi, David S. Miller
In-Reply-To: <20190628123659.139576-2-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Fri, Jun 28, 2019 at 02:36:57PM +0200, Stefano Garzarella wrote:
> Some callbacks used by the upper layers can run while we are in the
> .remove(). A potential use-after-free can happen, because we free
> the_virtio_vsock without knowing if the callbacks are over or not.
>
> To solve this issue we move the assignment of the_virtio_vsock at the
> end of .probe(), when we finished all the initialization, and at the
> beginning of .remove(), before to release resources.
> For the same reason, we do the same also for the vdev->priv.
>
> We use RCU to be sure that all callbacks that use the_virtio_vsock
> ended before freeing it. This is not required for callbacks that
> use vdev->priv, because after the vdev->config->del_vqs() we are sure
> that they are ended and will no longer be invoked.
->del_vqs() is only called at the very end, did you forget to move it
earlier?
In particular, the virtqueue handler callbacks schedule a workqueue.
The work functions use container_of() to get vsock. We need to be sure
that the work item isn't freed along with vsock while the work item is
still pending.
How do we know that the virtqueue handler is never called in such a way
that it sees vsock != NULL (there is no explicit memory barrier on the
read side) and then schedules a work item after flush_work() has run?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] samples: pktgen: add some helper functions for port parsing
From: Jesper Dangaard Brouer @ 2019-07-01 14:51 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: David S . Miller, netdev, brouer, Robert Olsson
In-Reply-To: <20190629133358.8251-1-danieltimlee@gmail.com>
On Sat, 29 Jun 2019 22:33:57 +0900
"Daniel T. Lee" <danieltimlee@gmail.com> wrote:
> This commit adds port parsing and port validate helper function to parse
> single or range of port(s) from a given string. (e.g. 1234, 443-444)
>
> Helpers will be used in prior to set target port(s) in samples/pktgen.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> samples/pktgen/functions.sh | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
Nice bash shellcode with use of array variables.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> diff --git a/samples/pktgen/functions.sh b/samples/pktgen/functions.sh
> index f8bb3cd0f4ce..4af4046d71be 100644
> --- a/samples/pktgen/functions.sh
> +++ b/samples/pktgen/functions.sh
> @@ -162,3 +162,37 @@ function get_node_cpus()
>
> echo $node_cpu_list
> }
> +
> +# Given a single or range of port(s), return minimum and maximum port number.
> +function parse_ports()
> +{
> + local port_str=$1
> + local port_list
> + local min_port
> + local max_port
> +
> + IFS="-" read -ra port_list <<< $port_str
> +
> + min_port=${port_list[0]}
> + max_port=${port_list[1]:-$min_port}
> +
> + echo $min_port $max_port
> +}
> +
> +# Given a minimum and maximum port, verify port number.
> +function validate_ports()
> +{
> + local min_port=$1
> + local max_port=$2
> +
> + # 0 < port < 65536
> + if [[ $min_port -gt 0 && $min_port -lt 65536 ]]; then
> + if [[ $max_port -gt 0 && $max_port -lt 65536 ]]; then
> + if [[ $min_port -le $max_port ]]; then
> + return 0
> + fi
> + fi
> + fi
> +
> + err 5 "Invalid port(s): $min_port-$max_port"
> +}
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v3] ss: introduce switch to print exact value of data rates
From: David Ahern @ 2019-07-01 14:51 UTC (permalink / raw)
To: Tomasz Torcz; +Cc: netdev
In-Reply-To: <20190701115242.25960-1-tomasz.torcz@nordea.com>
On 7/1/19 5:52 AM, Tomasz Torcz wrote:
> Introduce -X/--exact switch to disable human-friendly printing
> of data rates. Without the switch (default), data is presented as MBps/Kbps.
>
> Signed-off-by: Tomasz Torcz <tomasz.torcz@nordea.com>
> ---
> man/man8/ss.8 | 3 +++
> misc/ss.c | 12 ++++++++++--
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> Changes in v3:
> - updated ss man page with new option
>
ss now has Numeric option which can be used for this as well if we
broaden the meaning to be 'raw numbers over human readable'.
^ permalink raw reply
* Re: iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Skyler Hawthorne @ 2019-07-01 14:34 UTC (permalink / raw)
To: Marc Haber, linux-kernel, linux-wireless, netdev
In-Reply-To: <20190625130317.GB31363@torres.zugschlus.de>
Hello, I'm also still experiencing this issue on 5.1.15. It's making it
very difficult to use my work laptop in my office, since it has many
access points and frequently has to reauthenticate. I hit this bug 1-3
times per day, and the only way to fix it is a hard shutdown. Has there
been any effort to identify and/or fix the cause?
--
Skyler
On Tue, 2019-06-25 at 15:03 +0200, Marc Haber wrote:
> On Sun, Jun 02, 2019 at 03:48:42PM +0200, Marc Haber wrote:
> > On Thu, May 30, 2019 at 10:12:57AM +0200, Marc Haber wrote:
> > > on my primary notebook, a Lenovo X260, with an Intel Wireless
> > > 8260
> > > (8086:24f3), running Debian unstable, I have started to see
> > > network
> > > hangs since upgrading to kernel 5.1. In this situation, I cannot
> > > restart Network-Manager (the call just hangs), I can log out of
> > > X, but
> > > the system does not cleanly shut down and I need to Magic SysRq
> > > myself
> > > out of the running system. This happens about once every two
> > > days.
> >
> > The issue is also present in 5.1.5 and 5.1.6.
>
> Almost a month later, 5.1.15 still crashes about twice a day on my
> Notebook. The error message seems pretty clear to me, how can I go on
> from there and may be identify a line number outside of a library?
>
> Greetings
> Marc
>
>
^ permalink raw reply
* Re: [RFC iproute2] netns: add mounting state file for each netns
From: Nicolas Dichtel @ 2019-07-01 14:17 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev, Alexander Aring
In-Reply-To: <CAGnkfhz92SA7_kbARMzTqj3sTE3pgE=FEOXzFQxX6m=cemJUkg@mail.gmail.com>
Le 01/07/2019 à 15:50, Matteo Croce a écrit :
> On Mon, Jul 1, 2019 at 2:38 PM Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
>>
>> Le 30/06/2019 à 21:29, Matteo Croce a écrit :
>>> When ip creates a netns, there is a small time interval between the
>>> placeholder file creation in NETNS_RUN_DIR and the bind mount from /proc.
>>>
>>> Add a temporary file named .mounting-$netns which gets deleted after the
>>> bind mount, so watching for delete event matching the .mounting-* name
>>> will notify watchers only after the bind mount has been done.
>> Probably a naive question, but why creating those '.mounting-$netns' files in
>> the directory where netns are stored? Why not another directory, something like
>> /var/run/netns-monitor/?
>>
>>
>> Regards,
>> Nicolas
>
> Yes, would work too. But ideally I'd wait for the mount inotify notifications.
>
Yes, I agree.
^ permalink raw reply
* [PATCH] net:gue.h:Fix shifting signed 32-bit value by 31 bits problem
From: Vandana BN @ 2019-07-01 14:16 UTC (permalink / raw)
To: David S . Miller , netdev, linux-kernel
Cc: skhan, gregkh, linux-kernel-mentees, Vandana BN
Fix GUE_PFLAG_REMCSUM to use "U" cast to avoid shifting signed
32-bit value by 31 bits problem.
Signed-off-by: Vandana BN <bnvandana@gmail.com>
---
include/net/gue.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/gue.h b/include/net/gue.h
index fdad41469b65..3a6595bfa641 100644
--- a/include/net/gue.h
+++ b/include/net/gue.h
@@ -60,7 +60,7 @@ struct guehdr {
/* Private flags in the private option extension */
-#define GUE_PFLAG_REMCSUM htonl(1 << 31)
+#define GUE_PFLAG_REMCSUM htonl(1U << 31)
#define GUE_PLEN_REMCSUM 4
#define GUE_PFLAGS_ALL (GUE_PFLAG_REMCSUM)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH iproute2] man: tc-netem.8: fix URL for netem page
From: Andrea Claudi @ 2019-07-01 14:10 UTC (permalink / raw)
To: netdev, Stephen Hemminger; +Cc: David Ahern
In-Reply-To: <39256a189709ec195fd97da736ee5b003a49f298.1561989640.git.aclaudi@redhat.com>
On Mon, Jul 1, 2019 at 4:05 PM Andrea Claudi <aclaudi@redhat.com> wrote:
>
> URL for netem page on sources section points to a no more existent
> resource. Fix this using the correct URL.
>
> Fixes: cd72dcf13c8a4 ("netem: add man-page")
> Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
> ---
> man/man8/tc-netem.8 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/man/man8/tc-netem.8 b/man/man8/tc-netem.8
> index 111109cf042f0..5a08a406a4a7b 100644
> --- a/man/man8/tc-netem.8
> +++ b/man/man8/tc-netem.8
> @@ -219,7 +219,7 @@ April 2005
> (http://devresources.linux-foundation.org/shemminger/netem/LCA2005_paper.pdf)
>
> .IP " 2. " 4
> -Netem page from Linux foundation, (http://www.linuxfoundation.org/en/Net:Netem)
> +Netem page from Linux foundation, (https://wiki.linuxfoundation.org/networking/netem)
>
> .IP " 3. " 4
> Salsano S., Ludovici F., Ordine A., "Definition of a general and intuitive loss
> --
> 2.20.1
>
Hi Stephen,
I noticed that the link to your LCA 2005 paper is wrong, too (it
actually redirects to the home page of the Linux Foundation Wiki). If
you provide me the correct URL, I will happily send a v2 of this patch
fixing that, too.
Regards,
Andrea
^ permalink raw reply
* [PATCH iproute2] man: tc-netem.8: fix URL for netem page
From: Andrea Claudi @ 2019-07-01 14:04 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern
URL for netem page on sources section points to a no more existent
resource. Fix this using the correct URL.
Fixes: cd72dcf13c8a4 ("netem: add man-page")
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
---
man/man8/tc-netem.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/tc-netem.8 b/man/man8/tc-netem.8
index 111109cf042f0..5a08a406a4a7b 100644
--- a/man/man8/tc-netem.8
+++ b/man/man8/tc-netem.8
@@ -219,7 +219,7 @@ April 2005
(http://devresources.linux-foundation.org/shemminger/netem/LCA2005_paper.pdf)
.IP " 2. " 4
-Netem page from Linux foundation, (http://www.linuxfoundation.org/en/Net:Netem)
+Netem page from Linux foundation, (https://wiki.linuxfoundation.org/networking/netem)
.IP " 3. " 4
Salsano S., Ludovici F., Ordine A., "Definition of a general and intuitive loss
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 3/8] Documentation/bindings: net: ocelot: document the PTP ready IRQ
From: Andrew Lunn @ 2019-07-01 13:54 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190701100327.6425-4-antoine.tenart@bootlin.com>
On Mon, Jul 01, 2019 at 12:03:22PM +0200, Antoine Tenart wrote:
> One additional interrupt needs to be described within the Ocelot device
> tree node: the PTP ready one. This patch documents the binding needed to
> do so.
Hi Antoine
Same questions/points as for the register bank :-)
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/8] Documentation/bindings: net: ocelot: document the PTP bank
From: Andrew Lunn @ 2019-07-01 13:52 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190701100327.6425-2-antoine.tenart@bootlin.com>
On Mon, Jul 01, 2019 at 12:03:20PM +0200, Antoine Tenart wrote:
> One additional register range needs to be described within the Ocelot
> device tree node: the PTP. This patch documents the binding needed to do
> so.
Hi Antoine
Are there any more register banks? Maybe just add them all?
Also, you should probably add a comment that despite it being in the
Required part of the binding, it is actually optional.
Andrew
^ permalink raw reply
* Re: [RFC iproute2] netns: add mounting state file for each netns
From: Matteo Croce @ 2019-07-01 13:50 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, Alexander Aring
In-Reply-To: <e2173091-1c7a-fd74-95ea-41eedbab92d3@6wind.com>
On Mon, Jul 1, 2019 at 2:38 PM Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
>
> Le 30/06/2019 à 21:29, Matteo Croce a écrit :
> > When ip creates a netns, there is a small time interval between the
> > placeholder file creation in NETNS_RUN_DIR and the bind mount from /proc.
> >
> > Add a temporary file named .mounting-$netns which gets deleted after the
> > bind mount, so watching for delete event matching the .mounting-* name
> > will notify watchers only after the bind mount has been done.
> Probably a naive question, but why creating those '.mounting-$netns' files in
> the directory where netns are stored? Why not another directory, something like
> /var/run/netns-monitor/?
>
>
> Regards,
> Nicolas
Yes, would work too. But ideally I'd wait for the mount inotify notifications.
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [PATCH] sis900: add ethtool tests (link, eeprom)
From: Andrew Lunn @ 2019-07-01 13:46 UTC (permalink / raw)
To: Sergej Benilov; +Cc: venza, netdev
In-Reply-To: <20190701090333.25277-1-sergej.benilov@googlemail.com>
On Mon, Jul 01, 2019 at 11:03:33AM +0200, Sergej Benilov wrote:
> Add tests for ethtool: link test, EEPROM read test.
> Correct a few typos, too.
Hi Sergej
Please split this up into two patches. The first one should fixing the
typos.
Rather than implementing a test for the EEPROM, add support for
ethtool --eeprom-dump. That is much more useful.
The link test does not show you anything which you cannot get via ip
link show. If there is no carrier, the link is down. So drop that.
The patch also has white space issues. Spaces where there should be
tabs. Please run ./scripts/checkpatch.pl.
Andrew
^ permalink raw reply
* [PATCH net-next] ipv6: icmp: allow flowlabel reflection in echo replies
From: Eric Dumazet @ 2019-07-01 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
Extend flowlabel_reflect bitmask to allow conditional
reflection of incoming flowlabels in echo replies.
Note this has precedence against auto flowlabels.
Add flowlabel_reflect enum to replace hard coded
values.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Documentation/networking/ip-sysctl.txt | 4 +++-
include/net/ipv6.h | 7 +++++++
net/ipv6/af_inet6.c | 2 +-
net/ipv6/icmp.c | 3 +++
net/ipv6/sysctl_net_ipv6.c | 4 ++--
net/ipv6/tcp_ipv6.c | 2 +-
6 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index e0d8a96e2c671e3d09d234c8ed49799b08240259..f0e6d1f53485d6cbfcd73c9cd079b970d976b6d9 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1452,7 +1452,7 @@ flowlabel_reflect - INTEGER
environments. See RFC 7690 and:
https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01
- This is a mask of two bits.
+ This is a bitmask.
1: enabled for established flows
Note that this prevents automatic flowlabel changes, as done
@@ -1463,6 +1463,8 @@ flowlabel_reflect - INTEGER
If set, a RST packet sent in response to a SYN packet on a closed
port will reflect the incoming flow label.
+ 4: enabled for ICMPv6 echo reply messages.
+
Default: 0
fib_multipath_hash_policy - INTEGER
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index b41f6a0fa903e9916e293f86f8bfb0f264161e80..8eca5fb30376f3a0a40ff0dc438cbad9ff56142a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -301,6 +301,13 @@ struct ipv6_txoptions {
/* Option buffer, as read by IPV6_PKTOPTIONS, starts here. */
};
+/* flowlabel_reflect sysctl values */
+enum flowlabel_reflect {
+ FLOWLABEL_REFLECT_ESTABLISHED = 1,
+ FLOWLABEL_REFLECT_TCP_RESET = 2,
+ FLOWLABEL_REFLECT_ICMPV6_ECHO_REPLIES = 4,
+};
+
struct ip6_flowlabel {
struct ip6_flowlabel __rcu *next;
__be32 label;
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 7382a927d1eb74a6bbf4d5f83de336ccab5a2ae2..8369af32cef619b5d8fd2fcfaeb12924941d4ae8 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -208,7 +208,7 @@ static int inet6_create(struct net *net, struct socket *sock, int protocol,
np->mc_loop = 1;
np->mc_all = 1;
np->pmtudisc = IPV6_PMTUDISC_WANT;
- np->repflow = net->ipv6.sysctl.flowlabel_reflect & 1;
+ np->repflow = net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_ESTABLISHED;
sk->sk_ipv6only = net->ipv6.sysctl.bindv6only;
/* Init the ipv4 part of the socket since we can have sockets
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 12906301ec7baedcccfba224b93d30cb6060c3b9..62c997201970a664cbcfd526d426af07ae019b0e 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -703,6 +703,9 @@ static void icmpv6_echo_reply(struct sk_buff *skb)
tmp_hdr.icmp6_type = ICMPV6_ECHO_REPLY;
memset(&fl6, 0, sizeof(fl6));
+ if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_ICMPV6_ECHO_REPLIES)
+ fl6.flowlabel = ip6_flowlabel(ipv6_hdr(skb));
+
fl6.flowi6_proto = IPPROTO_ICMPV6;
fl6.daddr = ipv6_hdr(skb)->saddr;
if (saddr)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 6d86fac472e7298cbd8df7aa0b190cf0087675e2..8b3fe81783ed945e2f9172fd9008f48fed474475 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -23,7 +23,7 @@
static int zero;
static int one = 1;
-static int three = 3;
+static int flowlabel_reflect_max = 0x7;
static int auto_flowlabels_min;
static int auto_flowlabels_max = IP6_AUTO_FLOW_LABEL_MAX;
@@ -116,7 +116,7 @@ static struct ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
.extra1 = &zero,
- .extra2 = &three,
+ .extra2 = &flowlabel_reflect_max,
},
{
.procname = "max_dst_opts_number",
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 408d9ec2697154e840a26675765e8a9c1636ada4..4f3f99b3982099b3c64669f0445bc68d27390c89 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -989,7 +989,7 @@ static void tcp_v6_send_reset(const struct sock *sk, struct sk_buff *skb)
if (sk->sk_state == TCP_TIME_WAIT)
label = cpu_to_be32(inet_twsk(sk)->tw_flowlabel);
} else {
- if (net->ipv6.sysctl.flowlabel_reflect & 2)
+ if (net->ipv6.sysctl.flowlabel_reflect & FLOWLABEL_REFLECT_TCP_RESET)
label = ip6_flowlabel(ipv6h);
}
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: r8169 not working on 5.2.0rc6 with GPD MicroPC
From: Andrew Lunn @ 2019-07-01 13:35 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Karsten Wiborg, nic_swsd, romieu, netdev
In-Reply-To: <94b0f05e-2521-7251-ab92-b099a3cf99c9@gmail.com>
> When the vendor driver assigns a random MAC address, it writes it to the
> chip. The related registers may be persistent (can't say exactly due to
> missing documentation).
If the device supports WOL, it could be it is powered using the
standby supply, not the main supply. Try pulling the plug from the
wall to really remove all power.
Andrew
^ 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