* [PATCH 1/2] net: dsa: vsc73xx: Use devm_platform_ioremap_resource() in vsc73xx_platform_probe()
From: Markus Elfring @ 2019-09-20 14:28 UTC (permalink / raw)
To: netdev, Andrew Lunn, David S. Miller, Florian Fainelli,
Pawel Dembicki, Vivien Didelot
Cc: LKML, kernel-janitors
In-Reply-To: <98fee5f4-1e45-a0c6-2a38-9201b201c6eb@web.de>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 15:23:39 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/dsa/vitesse-vsc73xx-platform.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/net/dsa/vitesse-vsc73xx-platform.c b/drivers/net/dsa/vitesse-vsc73xx-platform.c
index 0541785f9fee..a3bbf9bd1bf1 100644
--- a/drivers/net/dsa/vitesse-vsc73xx-platform.c
+++ b/drivers/net/dsa/vitesse-vsc73xx-platform.c
@@ -89,7 +89,6 @@ 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);
@@ -101,16 +100,7 @@ static int vsc73xx_platform_probe(struct platform_device *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);
+ vsc_platform->base_addr = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(vsc_platform->base_addr)) {
dev_err(&pdev->dev, "cannot request I/O memory space\n");
ret = -ENXIO;
--
2.23.0
^ permalink raw reply related
* [PATCH 2/2] net: dsa: vsc73xx: Return an error code as a constant in vsc73xx_platform_probe()
From: Markus Elfring @ 2019-09-20 14:30 UTC (permalink / raw)
To: netdev, Andrew Lunn, David S. Miller, Florian Fainelli,
Pawel Dembicki, Vivien Didelot
Cc: LKML, kernel-janitors
In-Reply-To: <98fee5f4-1e45-a0c6-2a38-9201b201c6eb@web.de>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 16:07:07 +0200
* Return an error code without storing it in an intermediate variable.
* Delete the local variable “ret” which became unnecessary
with this refactoring.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/dsa/vitesse-vsc73xx-platform.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/dsa/vitesse-vsc73xx-platform.c b/drivers/net/dsa/vitesse-vsc73xx-platform.c
index a3bbf9bd1bf1..0ae8d904ca85 100644
--- a/drivers/net/dsa/vitesse-vsc73xx-platform.c
+++ b/drivers/net/dsa/vitesse-vsc73xx-platform.c
@@ -89,7 +89,6 @@ static int vsc73xx_platform_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct vsc73xx_platform *vsc_platform;
- int ret;
vsc_platform = devm_kzalloc(dev, sizeof(*vsc_platform), GFP_KERNEL);
if (!vsc_platform)
@@ -103,8 +102,7 @@ static int vsc73xx_platform_probe(struct platform_device *pdev)
vsc_platform->base_addr = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(vsc_platform->base_addr)) {
dev_err(&pdev->dev, "cannot request I/O memory space\n");
- ret = -ENXIO;
- return ret;
+ return -ENXIO;
}
return vsc73xx_probe(&vsc_platform->vsc);
--
2.23.0
^ permalink raw reply related
* [PATCH 3.16 095/132] bonding: fix arp_validate toggling in active-backup mode
From: Ben Hutchings @ 2019-09-20 14:23 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, Denis Kirjanov, netdev, David S. Miller, Veaceslav Falico,
Jarod Wilson, Jay Vosburgh, Andy Gospodarek, Jay Vosburgh
In-Reply-To: <lsq.1568989414.954567518@decadent.org.uk>
3.16.74-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Jarod Wilson <jarod@redhat.com>
commit a9b8a2b39ce65df45687cf9ef648885c2a99fe75 upstream.
There's currently a problem with toggling arp_validate on and off with an
active-backup bond. At the moment, you can start up a bond, like so:
modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1
ip link set bond0 down
echo "ens4f0" > /sys/class/net/bond0/bonding/slaves
echo "ens4f1" > /sys/class/net/bond0/bonding/slaves
ip link set bond0 up
ip addr add 192.168.1.2/24 dev bond0
Pings to 192.168.1.1 work just fine. Now turn on arp_validate:
echo 1 > /sys/class/net/bond0/bonding/arp_validate
Pings to 192.168.1.1 continue to work just fine. Now when you go to turn
arp_validate off again, the link falls flat on it's face:
echo 0 > /sys/class/net/bond0/bonding/arp_validate
dmesg
...
[133191.911987] bond0: Setting arp_validate to none (0)
[133194.257793] bond0: bond_should_notify_peers: slave ens4f0
[133194.258031] bond0: link status definitely down for interface ens4f0, disabling it
[133194.259000] bond0: making interface ens4f1 the new active one
[133197.330130] bond0: link status definitely down for interface ens4f1, disabling it
[133197.331191] bond0: now running without any active interface!
The problem lies in bond_options.c, where passing in arp_validate=0
results in bond->recv_probe getting set to NULL. This flies directly in
the face of commit 3fe68df97c7f, which says we need to set recv_probe =
bond_arp_recv, even if we're not using arp_validate. Said commit fixed
this in bond_option_arp_interval_set, but missed that we can get to that
same state in bond_option_arp_validate_set as well.
One solution would be to universally set recv_probe = bond_arp_recv here
as well, but I don't think bond_option_arp_validate_set has any business
touching recv_probe at all, and that should be left to the arp_interval
code, so we can just make things much tidier here.
Fixes: 3fe68df97c7f ("bonding: always set recv_probe to bond_arp_rcv in arp monitor")
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/bonding/bond_options.c | 7 -------
1 file changed, 7 deletions(-)
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -1068,13 +1068,6 @@ static int bond_option_arp_validate_set(
{
pr_info("%s: Setting arp_validate to %s (%llu)\n",
bond->dev->name, newval->string, newval->value);
-
- if (bond->dev->flags & IFF_UP) {
- if (!newval->value)
- bond->recv_probe = NULL;
- else if (bond->params.arp_interval)
- bond->recv_probe = bond_arp_rcv;
- }
bond->params.arp_validate = newval->value;
return 0;
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: vsc73xx: Use devm_platform_ioremap_resource() in vsc73xx_platform_probe()
From: Andrew Lunn @ 2019-09-20 15:08 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, David S. Miller, Florian Fainelli, Pawel Dembicki,
Vivien Didelot, LKML, kernel-janitors
In-Reply-To: <dbc78014-6ed4-5080-8208-0a5930a3bf6e@web.de>
On Fri, Sep 20, 2019 at 04:28:00PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 15:23:39 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: vsc73xx: Return an error code as a constant in vsc73xx_platform_probe()
From: Andrew Lunn @ 2019-09-20 15:08 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, David S. Miller, Florian Fainelli, Pawel Dembicki,
Vivien Didelot, LKML, kernel-janitors
In-Reply-To: <738c12c8-f51e-d2e5-f31e-7f726cf6325d@web.de>
On Fri, Sep 20, 2019 at 04:30:13PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 16:07:07 +0200
>
> * Return an error code without storing it in an intermediate variable.
>
> * Delete the local variable “ret” which became unnecessary
> with this refactoring.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 0/2] net: dsa: vsc73xx: Adjustments for vsc73xx_platform_probe()
From: Andrew Lunn @ 2019-09-20 15:09 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, David S. Miller, Florian Fainelli, Pawel Dembicki,
Vivien Didelot, LKML, kernel-janitors
In-Reply-To: <98fee5f4-1e45-a0c6-2a38-9201b201c6eb@web.de>
On Fri, Sep 20, 2019 at 04:25:53PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 16:17:18 +0200
>
> Two update suggestions were taken into account
> from static source code analysis.
Hi Markus
netdev is closed at the moment for patch. Please repost once it
reopens, in about 2 weeks time.
Thanks
Andrew
^ permalink raw reply
* Re: [0/2] net: dsa: vsc73xx: Adjustments for vsc73xx_platform_probe()
From: Markus Elfring @ 2019-09-20 15:30 UTC (permalink / raw)
To: Andrew Lunn, netdev
Cc: David S. Miller, Florian Fainelli, Pawel Dembicki, Vivien Didelot,
Linus Walleij, kernel-janitors, LKML
In-Reply-To: <20190920150924.GG3530@lunn.ch>
> netdev is closed at the moment for patch.
I wonder about this information.
> Please repost once it reopens, in about 2 weeks time.
I hope that the presented change possibilities can be integrated
in the near future also without a repetition of this small patch series.
https://lore.kernel.org/patchwork/project/lkml/list/?series=411271
Regards,
Markus
^ permalink raw reply
* [PATCH net v2 0/3] net/smc: move some definitions to UAPI
From: Eugene Syromiatnikov @ 2019-09-20 15:41 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-kernel, Ursula Braun, Karsten Graul
Hello.
As of now, it's a bit difficult to use SMC protocol, as significant part
of definitions related to it are defined in private headers and are not
part of UAPI. The following commits move some definitions to UAPI,
making them readily available to the user space.
Changes since v1[1]:
* Patch "provide fallback diagnostic codes in UAPI" is updated
in accordance with the updated set of diagnostic codes.
[1] https://lkml.org/lkml/2018/10/7/177
Eugene Syromiatnikov (3):
uapi, net/smc: move protocol constant definitions to UAPI
uapi, net/smc: provide fallback diagnostic codes in UAPI
uapi, net/smc: provide socket state constants in UAPI
include/uapi/linux/smc.h | 32 +++++++++++++++++++++++++++++++-
include/uapi/linux/smc_diag.h | 17 +++++++++++++++++
net/smc/smc.h | 22 ++--------------------
net/smc/smc_clc.h | 22 ----------------------
4 files changed, 50 insertions(+), 43 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH net v2 1/3] uapi, net/smc: move protocol constant definitions to UAPI
From: Eugene Syromiatnikov @ 2019-09-20 15:41 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-kernel, Ursula Braun, Karsten Graul
In-Reply-To: <cover.1568993930.git.esyr@redhat.com>
SMCPROTO_* constants are expected to be used by userspace[1],
but they were defined in a private header instead.
[1] http://manpages.ubuntu.com/manpages/cosmic/man7/af_smc.7.html
Fixes: ac7138746e14 ("smc: establish new socket family")
Fixes: aaa4d33f6da1 ("net/smc: enable ipv6 support for smc")
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
include/uapi/linux/smc.h | 7 ++++++-
net/smc/smc.h | 4 +---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/smc.h b/include/uapi/linux/smc.h
index 0e11ca4..10561f8 100644
--- a/include/uapi/linux/smc.h
+++ b/include/uapi/linux/smc.h
@@ -2,7 +2,8 @@
/*
* Shared Memory Communications over RDMA (SMC-R) and RoCE
*
- * Definitions for generic netlink based configuration of an SMC-R PNET table
+ * Definitions for SMC protocol and generic netlink based configuration
+ * of an SMC-R PNET table
*
* Copyright IBM Corp. 2016
*
@@ -12,6 +13,10 @@
#ifndef _UAPI_LINUX_SMC_H_
#define _UAPI_LINUX_SMC_H_
+/* AF_SMC socket protocols */
+#define SMCPROTO_SMC 0 /* SMC protocol, IPv4 */
+#define SMCPROTO_SMC6 1 /* SMC protocol, IPv6 */
+
/* Netlink SMC_PNETID attributes */
enum {
SMC_PNETID_UNSPEC,
diff --git a/net/smc/smc.h b/net/smc/smc.h
index 878313f..e60effc 100644
--- a/net/smc/smc.h
+++ b/net/smc/smc.h
@@ -15,12 +15,10 @@
#include <linux/types.h>
#include <linux/compiler.h> /* __aligned */
#include <net/sock.h>
+#include <linux/smc.h>
#include "smc_ib.h"
-#define SMCPROTO_SMC 0 /* SMC protocol, IPv4 */
-#define SMCPROTO_SMC6 1 /* SMC protocol, IPv6 */
-
extern struct proto smc_proto;
extern struct proto smc_proto6;
--
2.1.4
^ permalink raw reply related
* [PATCH net v2 2/3] uapi, net/smc: provide fallback diagnostic codes in UAPI
From: Eugene Syromiatnikov @ 2019-09-20 15:41 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-kernel, Ursula Braun, Karsten Graul
In-Reply-To: <cover.1568993930.git.esyr@redhat.com>
Since the values to which these codes are corresponding to are already
exposed via sock_diag interface.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
include/uapi/linux/smc.h | 25 +++++++++++++++++++++++++
net/smc/smc_clc.h | 22 ----------------------
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/include/uapi/linux/smc.h b/include/uapi/linux/smc.h
index 10561f8..9fbf365 100644
--- a/include/uapi/linux/smc.h
+++ b/include/uapi/linux/smc.h
@@ -17,6 +17,31 @@
#define SMCPROTO_SMC 0 /* SMC protocol, IPv4 */
#define SMCPROTO_SMC6 1 /* SMC protocol, IPv6 */
+/* Diagnostic codes */
+#define SMC_CLC_DECL_MEM 0x01010000 /* insufficient memory resources */
+#define SMC_CLC_DECL_TIMEOUT_CL 0x02010000 /* timeout w4 QP confirm link */
+#define SMC_CLC_DECL_TIMEOUT_AL 0x02020000 /* timeout w4 QP add link */
+#define SMC_CLC_DECL_CNFERR 0x03000000 /* configuration error */
+#define SMC_CLC_DECL_PEERNOSMC 0x03010000 /* peer did not indicate SMC */
+#define SMC_CLC_DECL_IPSEC 0x03020000 /* IPsec usage */
+#define SMC_CLC_DECL_NOSMCDEV 0x03030000 /* no SMC device found (R or D) */
+#define SMC_CLC_DECL_NOSMCDDEV 0x03030001 /* no SMC-D device found */
+#define SMC_CLC_DECL_NOSMCRDEV 0x03030002 /* no SMC-R device found */
+#define SMC_CLC_DECL_SMCDNOTALK 0x03030003 /* SMC-D dev can't talk to peer */
+#define SMC_CLC_DECL_MODEUNSUPP 0x03040000 /* smc modes do not match (R or D)*/
+#define SMC_CLC_DECL_RMBE_EC 0x03050000 /* peer has eyecatcher in RMBE */
+#define SMC_CLC_DECL_OPTUNSUPP 0x03060000 /* fastopen sockopt not supported */
+#define SMC_CLC_DECL_DIFFPREFIX 0x03070000 /* IP prefix / subnet mismatch */
+#define SMC_CLC_DECL_GETVLANERR 0x03080000 /* err to get vlan id of ip device*/
+#define SMC_CLC_DECL_ISMVLANERR 0x03090000 /* err to reg vlan id on ism dev */
+#define SMC_CLC_DECL_SYNCERR 0x04000000 /* synchronization error */
+#define SMC_CLC_DECL_PEERDECL 0x05000000 /* peer declined during handshake */
+#define SMC_CLC_DECL_INTERR 0x09990000 /* internal error */
+#define SMC_CLC_DECL_ERR_RTOK 0x09990001 /* rtoken handling failed */
+#define SMC_CLC_DECL_ERR_RDYLNK 0x09990002 /* ib ready link failed */
+#define SMC_CLC_DECL_ERR_REGRMB 0x09990003 /* reg rmb failed */
+
+
/* Netlink SMC_PNETID attributes */
enum {
SMC_PNETID_UNSPEC,
diff --git a/net/smc/smc_clc.h b/net/smc/smc_clc.h
index ca20927..db6a78f 100644
--- a/net/smc/smc_clc.h
+++ b/net/smc/smc_clc.h
@@ -28,28 +28,6 @@
#define SMC_TYPE_B 3 /* SMC-R and SMC-D */
#define CLC_WAIT_TIME (6 * HZ) /* max. wait time on clcsock */
#define CLC_WAIT_TIME_SHORT HZ /* short wait time on clcsock */
-#define SMC_CLC_DECL_MEM 0x01010000 /* insufficient memory resources */
-#define SMC_CLC_DECL_TIMEOUT_CL 0x02010000 /* timeout w4 QP confirm link */
-#define SMC_CLC_DECL_TIMEOUT_AL 0x02020000 /* timeout w4 QP add link */
-#define SMC_CLC_DECL_CNFERR 0x03000000 /* configuration error */
-#define SMC_CLC_DECL_PEERNOSMC 0x03010000 /* peer did not indicate SMC */
-#define SMC_CLC_DECL_IPSEC 0x03020000 /* IPsec usage */
-#define SMC_CLC_DECL_NOSMCDEV 0x03030000 /* no SMC device found (R or D) */
-#define SMC_CLC_DECL_NOSMCDDEV 0x03030001 /* no SMC-D device found */
-#define SMC_CLC_DECL_NOSMCRDEV 0x03030002 /* no SMC-R device found */
-#define SMC_CLC_DECL_SMCDNOTALK 0x03030003 /* SMC-D dev can't talk to peer */
-#define SMC_CLC_DECL_MODEUNSUPP 0x03040000 /* smc modes do not match (R or D)*/
-#define SMC_CLC_DECL_RMBE_EC 0x03050000 /* peer has eyecatcher in RMBE */
-#define SMC_CLC_DECL_OPTUNSUPP 0x03060000 /* fastopen sockopt not supported */
-#define SMC_CLC_DECL_DIFFPREFIX 0x03070000 /* IP prefix / subnet mismatch */
-#define SMC_CLC_DECL_GETVLANERR 0x03080000 /* err to get vlan id of ip device*/
-#define SMC_CLC_DECL_ISMVLANERR 0x03090000 /* err to reg vlan id on ism dev */
-#define SMC_CLC_DECL_SYNCERR 0x04000000 /* synchronization error */
-#define SMC_CLC_DECL_PEERDECL 0x05000000 /* peer declined during handshake */
-#define SMC_CLC_DECL_INTERR 0x09990000 /* internal error */
-#define SMC_CLC_DECL_ERR_RTOK 0x09990001 /* rtoken handling failed */
-#define SMC_CLC_DECL_ERR_RDYLNK 0x09990002 /* ib ready link failed */
-#define SMC_CLC_DECL_ERR_REGRMB 0x09990003 /* reg rmb failed */
struct smc_clc_msg_hdr { /* header1 of clc messages */
u8 eyecatcher[4]; /* eye catcher */
--
2.1.4
^ permalink raw reply related
* [PATCH net v2 3/3] uapi, net/smc: provide socket state constants in UAPI
From: Eugene Syromiatnikov @ 2019-09-20 15:42 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-kernel, Ursula Braun, Karsten Graul
In-Reply-To: <cover.1568993930.git.esyr@redhat.com>
As socket state itself is already exposed via sock_diag interface.
Fixes: ac7138746e14 ("smc: establish new socket family")
Fixes: b38d732477e4 ("smc: socket closing and linkgroup cleanup")
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
include/uapi/linux/smc_diag.h | 17 +++++++++++++++++
net/smc/smc.h | 18 +-----------------
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/include/uapi/linux/smc_diag.h b/include/uapi/linux/smc_diag.h
index 8cb3a6f..6798ec0 100644
--- a/include/uapi/linux/smc_diag.h
+++ b/include/uapi/linux/smc_diag.h
@@ -31,6 +31,23 @@ struct smc_diag_msg {
__aligned_u64 diag_inode;
};
+enum smc_state { /* possible states of an SMC socket */
+ SMC_ACTIVE = 1,
+ SMC_INIT = 2,
+ SMC_CLOSED = 7,
+ SMC_LISTEN = 10,
+ /* normal close */
+ SMC_PEERCLOSEWAIT1 = 20,
+ SMC_PEERCLOSEWAIT2 = 21,
+ SMC_APPFINCLOSEWAIT = 24,
+ SMC_APPCLOSEWAIT1 = 22,
+ SMC_APPCLOSEWAIT2 = 23,
+ SMC_PEERFINCLOSEWAIT = 25,
+ /* abnormal close */
+ SMC_PEERABORTWAIT = 26,
+ SMC_PROCESSABORT = 27,
+};
+
/* Mode of a connection */
enum {
SMC_DIAG_MODE_SMCR,
diff --git a/net/smc/smc.h b/net/smc/smc.h
index e60effc..7eaef72 100644
--- a/net/smc/smc.h
+++ b/net/smc/smc.h
@@ -16,6 +16,7 @@
#include <linux/compiler.h> /* __aligned */
#include <net/sock.h>
#include <linux/smc.h>
+#include <linux/smc_diag.h>
#include "smc_ib.h"
@@ -26,23 +27,6 @@ extern struct proto smc_proto6;
#define KERNEL_HAS_ATOMIC64
#endif
-enum smc_state { /* possible states of an SMC socket */
- SMC_ACTIVE = 1,
- SMC_INIT = 2,
- SMC_CLOSED = 7,
- SMC_LISTEN = 10,
- /* normal close */
- SMC_PEERCLOSEWAIT1 = 20,
- SMC_PEERCLOSEWAIT2 = 21,
- SMC_APPFINCLOSEWAIT = 24,
- SMC_APPCLOSEWAIT1 = 22,
- SMC_APPCLOSEWAIT2 = 23,
- SMC_PEERFINCLOSEWAIT = 25,
- /* abnormal close */
- SMC_PEERABORTWAIT = 26,
- SMC_PROCESSABORT = 27,
-};
-
struct smc_link_group;
struct smc_wr_rx_hdr { /* common prefix part of LLC and CDC to demultiplex */
--
2.1.4
^ permalink raw reply related
* Re: Strange routing with VRF and 5.2.7+
From: Ben Greear @ 2019-09-20 15:57 UTC (permalink / raw)
To: netdev
In-Reply-To: <51aae991-a320-43be-bf73-8b8c0ffcba60@candelatech.com>
On 9/10/19 6:08 PM, Ben Greear wrote:
> On 9/10/19 3:17 PM, Ben Greear wrote:
>> Today we were testing creating 200 virtual station vdevs on ath9k, and using
>> VRF for the routing.
>
> Looks like the same issue happens w/out VRF, but there I have oodles of routing
> rules, so it is an area ripe for failure.
>
> Will upgrade to 5.2.14+ and retest, and try 4.20 as well....
Turns out, this was ipsec (strongswan) inserting a rule that pointed to a table
that we then used for a vrf w/out realizing the rule was added.
Stopping strongswan and/or reconfiguring how routing tables are assigned
resolved the issue.
Thanks,
Ben
>
> Thanks,
> Ben
>
>>
>> This really slows down the machine in question.
>>
>> During the minutes that it takes to bring these up and configure them,
>> we loose network connectivity on the management port.
>>
>> If I do 'ip route show', it just shows the default route out of eth0, and
>> the subnet route. But, if I try to ping the gateway, I get an ICMP error
>> coming back from the gateway of one of the virtual stations (which should be
>> safely using VRFs and so not in use when I do a plain 'ping' from the shell).
>>
>> I tried running tshark on eth0 in the background and running ping, and it captures
>> no packets leaving eth0.
>>
>> After some time (and during this time, my various scripts will be (re)configuring
>> vrfs and stations and related vrf routing tables and such,
>> but should *not* be messing with the main routing table, then suddenly
>> things start working again.
>>
>> I am curious if anyone has seen anything similar or has suggestions for more
>> ways to debug this. It seems reproducible, but it is a pain to
>> debug.
>>
>> Thanks,
>> Ben
>>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Fwd: [PATCH] bonding/802.3ad: fix slave initialization states race
From: Алексей Захаров @ 2019-09-20 16:00 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <7154.1568987531@nyx>
>
> Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
> [...]
> > In any event, I think I see what the failure is, I'm working up
> >a patch to test and will post it when I have it ready.
>
> Aleksei,
>
> Would you be able to test the following patch and see if it
> resolves the issue in your testing? This is against current net-next,
> but applies to current net as well. Your kernel appears to be a bit
> older (as the message formats differ), so hopefully it will apply there
> as well. I've tested this a bit (but not the ARP mon portion), and it
> seems to do the right thing, but I can't reproduce the original issue
> locally.
We're testing on ubuntu-bionic 4.15 kernel.
>
> Thanks,
>
> -J
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 931d9d935686..38042399717b 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2086,8 +2086,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> ignore_updelay = !rcu_dereference(bond->curr_active_slave);
>
> bond_for_each_slave_rcu(bond, slave, iter) {
> - slave->new_link = BOND_LINK_NOCHANGE;
> - slave->link_new_state = slave->link;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> link_state = bond_check_dev_link(bond, slave->dev, 0);
>
> @@ -2121,7 +2120,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> }
>
> if (slave->delay <= 0) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> continue;
> }
> @@ -2158,7 +2157,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> slave->delay = 0;
>
> if (slave->delay <= 0) {
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> commit++;
> ignore_updelay = false;
> continue;
> @@ -2196,7 +2195,7 @@ static void bond_miimon_commit(struct bonding *bond)
> struct slave *slave, *primary;
>
> bond_for_each_slave(bond, slave, iter) {
> - switch (slave->new_link) {
> + switch (slave->link_new_state) {
> case BOND_LINK_NOCHANGE:
> /* For 802.3ad mode, check current slave speed and
> * duplex again in case its port was disabled after
> @@ -2268,8 +2267,8 @@ static void bond_miimon_commit(struct bonding *bond)
>
> default:
> slave_err(bond->dev, slave->dev, "invalid new link %d on slave\n",
> - slave->new_link);
> - slave->new_link = BOND_LINK_NOCHANGE;
> + slave->link_new_state);
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> continue;
> }
> @@ -2677,13 +2676,13 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> bond_for_each_slave_rcu(bond, slave, iter) {
> unsigned long trans_start = dev_trans_start(slave->dev);
>
> - slave->new_link = BOND_LINK_NOCHANGE;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> if (slave->link != BOND_LINK_UP) {
> if (bond_time_in_interval(bond, trans_start, 1) &&
> bond_time_in_interval(bond, slave->last_rx, 1)) {
>
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> slave_state_changed = 1;
>
> /* primary_slave has no meaning in round-robin
> @@ -2708,7 +2707,7 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> if (!bond_time_in_interval(bond, trans_start, 2) ||
> !bond_time_in_interval(bond, slave->last_rx, 2)) {
>
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> slave_state_changed = 1;
>
> if (slave->link_failure_count < UINT_MAX)
> @@ -2739,8 +2738,8 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> goto re_arm;
>
> bond_for_each_slave(bond, slave, iter) {
> - if (slave->new_link != BOND_LINK_NOCHANGE)
> - slave->link = slave->new_link;
> + if (slave->link_new_state != BOND_LINK_NOCHANGE)
> + slave->link = slave->link_new_state;
> }
>
> if (slave_state_changed) {
> @@ -2763,9 +2762,9 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> }
>
> /* Called to inspect slaves for active-backup mode ARP monitor link state
> - * changes. Sets new_link in slaves to specify what action should take
> - * place for the slave. Returns 0 if no changes are found, >0 if changes
> - * to link states must be committed.
> + * changes. Sets proposed link state in slaves to specify what action
> + * should take place for the slave. Returns 0 if no changes are found, >0
> + * if changes to link states must be committed.
> *
> * Called with rcu_read_lock held.
> */
> @@ -2777,12 +2776,12 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> int commit = 0;
>
> bond_for_each_slave_rcu(bond, slave, iter) {
> - slave->new_link = BOND_LINK_NOCHANGE;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
> last_rx = slave_last_rx(bond, slave);
>
> if (slave->link != BOND_LINK_UP) {
> if (bond_time_in_interval(bond, last_rx, 1)) {
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> commit++;
> }
> continue;
> @@ -2810,7 +2809,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> if (!bond_is_active_slave(slave) &&
> !rcu_access_pointer(bond->current_arp_slave) &&
> !bond_time_in_interval(bond, last_rx, 3)) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> }
>
> @@ -2823,7 +2822,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> if (bond_is_active_slave(slave) &&
> (!bond_time_in_interval(bond, trans_start, 2) ||
> !bond_time_in_interval(bond, last_rx, 2))) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> }
> }
> @@ -2843,7 +2842,7 @@ static void bond_ab_arp_commit(struct bonding *bond)
> struct slave *slave;
>
> bond_for_each_slave(bond, slave, iter) {
> - switch (slave->new_link) {
> + switch (slave->link_new_state) {
> case BOND_LINK_NOCHANGE:
> continue;
>
> @@ -2893,8 +2892,9 @@ static void bond_ab_arp_commit(struct bonding *bond)
> continue;
>
> default:
> - slave_err(bond->dev, slave->dev, "impossible: new_link %d on slave\n",
> - slave->new_link);
> + slave_err(bond->dev, slave->dev,
> + "impossible: link_new_state %d on slave\n",
> + slave->link_new_state);
> continue;
> }
>
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index f7fe45689142..d416af72404b 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -159,7 +159,6 @@ struct slave {
> unsigned long target_last_arp_rx[BOND_MAX_ARP_TARGETS];
> s8 link; /* one of BOND_LINK_XXXX */
> s8 link_new_state; /* one of BOND_LINK_XXXX */
> - s8 new_link;
> u8 backup:1, /* indicates backup slave. Value corresponds with
> BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
> inactive:1, /* indicates inactive slave */
> @@ -549,7 +548,7 @@ static inline void bond_propose_link_state(struct slave *slave, int state)
>
> static inline void bond_commit_link_state(struct slave *slave, bool notify)
> {
> - if (slave->link == slave->link_new_state)
> + if (slave->link_new_state == BOND_LINK_NOCHANGE)
> return;
>
> slave->link = slave->link_new_state;
>
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
I had to change slave_err to netdev_err, because there's no slave_err
macro in 4.15.
I did some fast testing, things become a bit more weird for me.
Right after reboot one of the slaves hangs with actor port state 71
and partner port state 1.
It doesn't send lacpdu and seems to be broken.
Setting link down and up again fixes slave state.
Dmesg after boot:
[Fri Sep 20 17:56:53 2019] bond-san: Enslaving eth3 as a backup
interface with an up link
[Fri Sep 20 17:56:53 2019] bond-san: Enslaving eth2 as a backup
interface with an up link
[Fri Sep 20 17:56:54 2019] bond-san: Warning: No 802.3ad response from
the link partner for any adapters in the bond
[Fri Sep 20 17:56:54 2019] IPv6: ADDRCONF(NETDEV_UP): bond-san: link
is not ready
[Fri Sep 20 17:56:54 2019] 8021q: adding VLAN 0 to HW filter on device bond-san
[Fri Sep 20 17:56:54 2019] IPv6: ADDRCONF(NETDEV_CHANGE): bond-san:
link becomes ready
[Fri Sep 20 17:56:54 2019] bond-san: link status definitely up for
interface eth3, 10000 Mbps full duplex
[Fri Sep 20 17:56:54 2019] bond-san: first active interface up!
Broken link here is eth2. After set it down and up:
[Fri Sep 20 18:02:04 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:02:04 2019] bond-san: link status up again after -200
ms for interface eth2
[Fri Sep 20 18:02:04 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
If I'm trying to reproduce previous behavior, I get different messages
from time to time:
[Fri Sep 20 18:04:48 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:04:48 2019] bond-san: link status up for interface
eth2, enabling it in 500 ms
[Fri Sep 20 18:04:48 2019] bond-san: invalid new link 3 on slave eth2
[Fri Sep 20 18:04:49 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
or:
[Fri Sep 20 18:05:48 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:05:49 2019] bond-san: link status up again after 0 ms
for interface eth2
[Fri Sep 20 18:05:49 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
In both cases this slave works after up.
--
Best Regards,
Aleksei Zakharov
System administrator
^ permalink raw reply
* Re: CONFIG_NET_TC_SKB_EXT
From: Jakub Kicinski @ 2019-09-20 16:16 UTC (permalink / raw)
To: Vlad Buslov
Cc: David Miller, Paul Blakey, netdev@vger.kernel.org, Jiri Pirko,
Cong Wang, Jamal Hadi Salim, Pravin Shelar, Simon Horman,
Daniel Borkmann, Alexei Starovoitov, Or Gerlitz
In-Reply-To: <vbfk1a41fr1.fsf@mellanox.com>
On Thu, 19 Sep 2019 15:13:55 +0000, Vlad Buslov wrote:
> On Thu 19 Sep 2019 at 14:21, David Miller <davem@davemloft.net> wrote:
> > As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
> > is really not acceptable.
> >
> > It should not be enabled by default at all.
> >
> > Instead the actual users should turn it on or depend upon it, which in
> > this case seems to be OVS.
> >
> > Please fix this, thank you.
>
> Hi David,
>
> We are working on it, but Paul is OoO today. Is it okay if we send the
> fix early next week?
Doesn't really seem like we have too many ways forward here, right?
How about this?
------>8-----------------------------------
net: hide NET_TC_SKB_EXT as a config option
Linus points out the NET_TC_SKB_EXT config option looks suspicious.
Indeed, it should really be selected to ensure correct OvS operation
if TC offload is used. Hopefully those who care about TC-only and
OvS-only performance disable the other one at compilation time.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
net/openvswitch/Kconfig | 1 +
net/sched/Kconfig | 13 +++----------
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
index 22d7d5604b4c..bd407ea7c263 100644
--- a/net/openvswitch/Kconfig
+++ b/net/openvswitch/Kconfig
@@ -15,6 +15,7 @@ config OPENVSWITCH
select NET_MPLS_GSO
select DST_CACHE
select NET_NSH
+ select NET_TC_SKB_EXT if NET_CLS_ACT
---help---
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
environments. In addition to supporting a variety of features
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index b3faafeafab9..f1062ef55098 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -719,6 +719,7 @@ config NET_EMATCH_IPT
config NET_CLS_ACT
bool "Actions"
select NET_CLS
+ select NET_TC_SKB_EXT if OPENVSWITCH
---help---
Say Y here if you want to use traffic control actions. Actions
get attached to classifiers and are invoked after a successful
@@ -964,18 +965,10 @@ config NET_IFE_SKBTCINDEX
depends on NET_ACT_IFE
config NET_TC_SKB_EXT
- bool "TC recirculation support"
- depends on NET_CLS_ACT
- default y if NET_CLS_ACT
+ bool
+ depends on NET_CLS_ACT && OPENVSWITCH
select SKB_EXTENSIONS
- help
- Say Y here to allow tc chain misses to continue in OvS datapath in
- the correct recirc_id, and hardware chain misses to continue in
- the correct chain in tc software datapath.
-
- Say N here if you won't be using tc<->ovs offload or tc chains offload.
-
endif # NET_SCHED
config NET_SCH_FIFO
--
2.21.0
^ permalink raw reply related
* [PATCH net] skge: fix checksum byte order
From: Stephen Hemminger @ 2019-09-20 16:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
From: Stephen Hemminger <stephen@networkplumber.org>
Running old skge driver on PowerPC causes checksum errors
because hardware reported 1's complement checksum is in little-endian
byte order.
Reported-by: Benoit <benoit.sansoni@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/marvell/skge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 0a2ec387a482..095f6c71b4fa 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -3108,7 +3108,7 @@ static struct sk_buff *skge_rx_get(struct net_device *dev,
skb_put(skb, len);
if (dev->features & NETIF_F_RXCSUM) {
- skb->csum = csum;
+ skb->csum = le16_to_cpu(csum);
skb->ip_summed = CHECKSUM_COMPLETE;
}
--
2.17.1
^ permalink raw reply related
* Re: [0/2] net: dsa: vsc73xx: Adjustments for vsc73xx_platform_probe()
From: Florian Fainelli @ 2019-09-20 16:36 UTC (permalink / raw)
To: Markus Elfring, Andrew Lunn, netdev
Cc: David S. Miller, Pawel Dembicki, Vivien Didelot, Linus Walleij,
kernel-janitors, LKML
In-Reply-To: <4a220bc4-0340-d54a-70bd-7bea62257b81@web.de>
On 9/20/19 8:30 AM, Markus Elfring wrote:
>> netdev is closed at the moment for patch.
>
> I wonder about this information.
This is covered here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n40
and you can skip the reading and check this URL:
http://vger.kernel.org/~davem/net-next.html
>
>
>> Please repost once it reopens, in about 2 weeks time.
>
> I hope that the presented change possibilities can be integrated
> in the near future also without a repetition of this small patch series.
> https://lore.kernel.org/patchwork/project/lkml/list/?series=411271
You will have to resend it, and unless a bug fix comes in, which would
be the only reason for your changes not to be "current" anymore, then it
should apply as-is and you should be fine.
--
Florian
^ permalink raw reply
* Re: [PATCH bpf] libbpf: fix version identification on busybox
From: Andrii Nakryiko @ 2019-09-20 16:41 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau, Andrii Nakryiko,
Yonghong Song, Networking, bpf, open list
In-Reply-To: <20190920082204.GC8870@khorivan>
On Fri, Sep 20, 2019 at 1:22 AM Ivan Khoronzhuk
<ivan.khoronzhuk@linaro.org> wrote:
>
> On Thu, Sep 19, 2019 at 01:02:40PM -0700, Andrii Nakryiko wrote:
> >On Thu, Sep 19, 2019 at 11:22 AM Ivan Khoronzhuk
> ><ivan.khoronzhuk@linaro.org> wrote:
> >>
> >> It's very often for embedded to have stripped version of sort in
> >> busybox, when no -V option present. It breaks build natively on target
> >> board causing recursive loop.
> >>
> >> BusyBox v1.24.1 (2019-04-06 04:09:16 UTC) multi-call binary. \
> >> Usage: sort [-nrugMcszbdfimSTokt] [-o FILE] [-k \
> >> start[.offset][opts][,end[.offset][opts]] [-t CHAR] [FILE]...
> >>
> >> Lets modify command a little to avoid -V option.
> >>
> >> Fixes: dadb81d0afe732 ("libbpf: make libbpf.map source of truth for libbpf version")
> >>
> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> >> ---
> >>
> >> Based on bpf/master
> >>
> >> tools/lib/bpf/Makefile | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> >> index c6f94cffe06e..a12490ad6215 100644
> >> --- a/tools/lib/bpf/Makefile
> >> +++ b/tools/lib/bpf/Makefile
> >> @@ -3,7 +3,7 @@
> >>
> >> LIBBPF_VERSION := $(shell \
> >> grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
> >> - sort -rV | head -n1 | cut -d'_' -f2)
> >> + cut -d'_' -f2 | sort -r | head -n1)
> >
> >You can't just sort alphabetically, because:
> >
> >1.2
> >1.11
> >
> >should be in that order. See discussion on mailing thread for original commit.
>
> if X1.X2.X3, where X = {0,1,....99999}
> Then it can be:
>
> -LIBBPF_VERSION := $(shell \
> - grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
> - sort -rV | head -n1 | cut -d'_' -f2)
> +_LBPFLIST := $(patsubst %;,%,$(patsubst LIBBPF_%,%,$(filter LIBBPF_%, \
> + $(shell cat libbpf.map))))
> +_LBPFLIST2 := $(foreach v,$(_LBPFLIST), \
> + $(subst $() $(),,$(foreach n,$(subst .,$() $(),$(v)), \
> + $(shell printf "%05d" $(n)))))
> +_LBPF_VER := $(word $(words $(sort $(_LBPFLIST2))), $(sort $(_LBPFLIST2)))
> +LIBBPF_VERSION := $(patsubst %_$(_LBPF_VER),%,$(filter %_$(_LBPF_VER), \
> + $(join $(addsuffix _, $(_LBPFLIST)),$(_LBPFLIST2))))
>
> It's bigger but avoids invocations of grep/sort/cut/head, only cat/printf
> , thus -V option also.
>
No way, this is way too ugly (and still unreliable, if we ever have
X.Y.Z.W or something). I'd rather go with my original approach of
fetching the last version in libbpf.map file. See
https://www.spinics.net/lists/netdev/msg592703.html.
> >
> >> LIBBPF_MAJOR_VERSION := $(firstword $(subst ., ,$(LIBBPF_VERSION)))
> >>
> >> MAKEFLAGS += --no-print-directory
> >> --
> >> 2.17.1
> >>
>
> --
> Regards,
> Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH 4/4] mt76: mt7615: sync with mt7603 rate control changes
From: Gustavo A. R. Silva @ 2019-09-20 23:44 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless, Lorenzo Bianconi, Roy Luo,
Kalle Valo, David S. Miller, Matthias Brugger, Networking,
linux-arm-kernel, linux-mediatek, Linux Kernel Mailing List,
Ryder Lee
In-Reply-To: <20190704155324.56693-4-nbd@nbd.name>
Hi all,
On 7/4/19 10:53, Felix Fietkau wrote:
[..]
> + for (i = 0, idx = first_idx; count && idx <= last_idx; idx++) {
> + struct ieee80211_tx_rate *cur_rate;
> + int cur_count;
>
> - info->status.rates[i].count = cur_count;
> - final_idx = i;
> + cur_rate = &rs->rates[idx / 2];
> + cur_count = min_t(int, MT7615_RATE_RETRY, count);
> count -= cur_count;
> +
> + if (idx && (cur_rate->idx != info->status.rates[i].idx ||
> + cur_rate->flags != info->status.rates[i].flags)) {
> + i++;
> + if (i == ARRAY_SIZE(info->status.rates))
Is this actually possible ^^^^^^^ ?? in case it is, see my comments below...
> + break;
> +
> + info->status.rates[i] = *cur_rate;
> + info->status.rates[i].count = 0;
> + }
> +
> + info->status.rates[i].count += cur_count;
> }
>
> out:
> - final_rate_flags = info->status.rates[final_idx].flags;
> + final_rate_flags = info->status.rates[i].flags;
There is an out-of-bounds access here........^^^ and see below...
>
> switch (FIELD_GET(MT_TX_RATE_MODE, final_rate)) {
> case MT_PHY_TYPE_CCK:
> @@ -713,8 +778,8 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
> return false;
> }
>
> - info->status.rates[final_idx].idx = final_rate;
> - info->status.rates[final_idx].flags = final_rate_flags;
> + info->status.rates[i].idx = final_rate;
> + info->status.rates[i].flags = final_rate_flags;
here too ............... ^^^^
>
> return true;
> }
--
Gustavo
^ permalink raw reply
* Re: [PATCH net v2 1/3] net: sched: sch_htb: don't call qdisc_put() while holding tree lock
From: Cong Wang @ 2019-09-20 16:53 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <vbfv9tnzdnb.fsf@mellanox.com>
On Thu, Sep 19, 2019 at 11:27 PM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 20 Sep 2019 at 04:05, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Thu, Sep 19, 2019 at 1:14 PM Vlad Buslov <vladbu@mellanox.com> wrote:
> >> Notes:
> >> Changes V1 -> V2:
> >>
> >> - Extend sch API with new qdisc_put_empty() function that has same
> >> implementation as regular qdisc_put() but skips parts that reset qdisc
> >> and free all packet buffers from gso_skb and skb_bad_txq queues.
> >
> > I don't understand why you need a new API here, as long as qdisc_reset()
> > gets called before releasing sch tree lock, the ->reset() inside qdisc_put(),
> > after releasing sch tree lock, should be a nop, right?
>
> Yes, but I wanted to make it explicit, so anyone else looking at the
> code of those Qdiscs would know that manual reset with appropriate
> locking is required. And it didn't require much new code because
> qdisc_put() and qidsc_put_empty() just reuse same __qdisc_put(). I'll
> revert it back, if you suggest that original approach is better.
It is unnecessary for -net/-stable. And you can always add a comment
to explain this if it is not clear.
Thanks.
^ permalink raw reply
* [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The DWMAC 4.10 supports the same enhanced addressing mode as later
generations. Parse this capability from the hardware feature registers
and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
Thierry
Thierry Reding (2):
net: stmmac: Only enable enhanced addressing mode when needed
net: stmmac: Support enhanced addressing mode for DWMAC 4.10
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
.../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
.../ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++
include/linux/stmmac.h | 1 +
7 files changed, 39 insertions(+), 3 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH v3 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
Enhanced addressing mode is only required when more than 32 bits need to
be addressed. Add a DMA configuration parameter to enable this mode only
when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++
include/linux/stmmac.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 64956465c030..3e00fd8befcf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -27,7 +27,10 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= XGMAC_AAL;
- writel(value | XGMAC_EAME, ioaddr + XGMAC_DMA_SYSBUS_MODE);
+ if (dma_cfg->eame)
+ value |= XGMAC_EAME;
+
+ writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
}
static void dwxgmac2_dma_init_chan(void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06ccd216ae90..ecd461207dbc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4497,6 +4497,12 @@ int stmmac_dvr_probe(struct device *device,
if (!ret) {
dev_info(priv->device, "Using %d bits DMA width\n",
priv->dma_cap.addr64);
+
+ /*
+ * If more than 32 bits can be addressed, make sure to
+ * enable enhanced addressing mode.
+ */
+ priv->plat->dma_cfg->eame = true;
} else {
ret = dma_set_mask_and_coherent(device, DMA_BIT_MASK(32));
if (ret) {
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 7ad7ae35cf88..d300ac907c76 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
int fixed_burst;
int mixed_burst;
bool aal;
+ bool eame;
};
#define AXI_BLEN 7
--
2.23.0
^ permalink raw reply related
* [PATCH v3 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
The address width of the controller can be read from hardware feature
registers much like on XGMAC. Add support for parsing the ADDR64 field
so that the DMA mask can be set accordingly.
This avoids getting swiotlb involved for DMA on Tegra186 and later.
Also make sure that the upper 32 bits of the DMA address are written to
the DMA descriptors when enhanced addressing mode is used. Similarily,
for each channel, the upper 32 bits of the DMA descriptor ring's base
address also need to be programmed to make sure the correct memory can
be fetched when the DMA descriptor ring is located beyond the 32-bit
boundary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v3:
- unconditionally write upper 32 bits
Changes in v2:
- also program the upper 32 bits of the DMA descriptor base address for
each channel
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
.../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 2ed11a581d80..f634fa09dffc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -183,6 +183,7 @@ enum power_event {
#define GMAC_HW_HASH_TB_SZ GENMASK(25, 24)
#define GMAC_HW_FEAT_AVSEL BIT(20)
#define GMAC_HW_TSOEN BIT(18)
+#define GMAC_HW_ADDR64 GENMASK(15, 14)
#define GMAC_HW_TXFIFOSIZE GENMASK(10, 6)
#define GMAC_HW_RXFIFOSIZE GENMASK(4, 0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index dbde23e7e169..d546041d2fcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -431,8 +431,8 @@ static void dwmac4_get_addr(struct dma_desc *p, unsigned int *addr)
static void dwmac4_set_addr(struct dma_desc *p, dma_addr_t addr)
{
- p->des0 = cpu_to_le32(addr);
- p->des1 = 0;
+ p->des0 = cpu_to_le32(lower_32_bits(addr));
+ p->des1 = cpu_to_le32(upper_32_bits(addr));
}
static void dwmac4_clear(struct dma_desc *p)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 3ed5508586ef..8439dd84f786 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -79,6 +79,7 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
+ writel(upper_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR_HI(chan));
writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR(chan));
}
@@ -97,6 +98,7 @@ static void dwmac4_dma_init_tx_chan(void __iomem *ioaddr,
writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
+ writel(upper_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR_HI(chan));
writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
}
@@ -132,6 +134,9 @@ static void dwmac4_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= DMA_SYS_BUS_AAL;
+ if (dma_cfg->eame)
+ value |= DMA_SYS_BUS_EAME;
+
writel(value, ioaddr + DMA_SYS_BUS_MODE);
}
@@ -354,6 +359,23 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->hash_tb_sz = (hw_cap & GMAC_HW_HASH_TB_SZ) >> 24;
dma_cap->av = (hw_cap & GMAC_HW_FEAT_AVSEL) >> 20;
dma_cap->tsoen = (hw_cap & GMAC_HW_TSOEN) >> 18;
+
+ dma_cap->addr64 = (hw_cap & GMAC_HW_ADDR64) >> 14;
+ switch (dma_cap->addr64) {
+ case 0:
+ dma_cap->addr64 = 32;
+ break;
+ case 1:
+ dma_cap->addr64 = 40;
+ break;
+ case 2:
+ dma_cap->addr64 = 48;
+ break;
+ default:
+ dma_cap->addr64 = 32;
+ break;
+ }
+
/* RX and TX FIFO sizes are encoded as log2(n / 128). Undo that by
* shifting and store the sizes in bytes.
*/
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index b66da0237d2a..5299fa1001a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -65,6 +65,7 @@
#define DMA_SYS_BUS_MB BIT(14)
#define DMA_AXI_1KBBE BIT(13)
#define DMA_SYS_BUS_AAL BIT(12)
+#define DMA_SYS_BUS_EAME BIT(11)
#define DMA_AXI_BLEN256 BIT(7)
#define DMA_AXI_BLEN128 BIT(6)
#define DMA_AXI_BLEN64 BIT(5)
@@ -91,7 +92,9 @@
#define DMA_CHAN_CONTROL(x) DMA_CHANX_BASE_ADDR(x)
#define DMA_CHAN_TX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x4)
#define DMA_CHAN_RX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x8)
+#define DMA_CHAN_TX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x10)
#define DMA_CHAN_TX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x14)
+#define DMA_CHAN_RX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x18)
#define DMA_CHAN_RX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x1c)
#define DMA_CHAN_TX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x20)
#define DMA_CHAN_RX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x28)
--
2.23.0
^ permalink raw reply related
* [PATCH] net: stmmac: Fix page pool size
From: Thierry Reding @ 2019-09-20 17:01 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The size of individual pages in the page pool in given by an order. The
order is the binary logarithm of the number of pages that make up one of
the pages in the pool. However, the driver currently passes the number
of pages rather than the order, so it ends up wasting quite a bit of
memory.
Fix this by taking the binary logarithm and passing that in the order
field.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ecd461207dbc..f8c90dba6db8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1550,13 +1550,15 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
for (queue = 0; queue < rx_count; queue++) {
struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
struct page_pool_params pp_params = { 0 };
+ unsigned int num_pages;
rx_q->queue_index = queue;
rx_q->priv_data = priv;
pp_params.flags = PP_FLAG_DMA_MAP;
pp_params.pool_size = DMA_RX_SIZE;
- pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+ num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+ pp_params.order = ilog2(num_pages);
pp_params.nid = dev_to_node(priv->device);
pp_params.dev = priv->device;
pp_params.dma_dir = DMA_FROM_DEVICE;
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] dimlib: make DIMLIB a hidden symbol
From: Tal Gilboa @ 2019-09-20 17:02 UTC (permalink / raw)
To: Uwe Kleine-König, Saeed Mahameed, Arthur Kiyanovski
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190920133115.12802-1-uwe@kleine-koenig.org>
On 9/20/2019 4:31 PM, Uwe Kleine-König wrote:
> According to Tal Gilboa the only benefit from DIM comes from a driver
> that uses it. So it doesn't make sense to make this symbol user visible,
> instead all drivers that use it should select it (as is already the case
> AFAICT).
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> lib/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index cc04124ed8f7..9fe8a21fd183 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -555,8 +555,7 @@ config SIGNATURE
> Implementation is done using GnuPG MPI library
>
> config DIMLIB
> - bool "DIM library"
> - default y
> + bool
> help
> Dynamic Interrupt Moderation library.
> Implements an algorithm for dynamically change CQ moderation values
>
There's a pending series using DIM which didn't add the select clause
[1]. Arthur, FYI. Other than that LGTM.
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg314304.html
^ permalink raw reply
* Re: [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC 4.10
From: Florian Fainelli @ 2019-09-20 17:02 UTC (permalink / raw)
To: Thierry Reding, David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, Jon Hunter,
Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
On 9/20/19 10:00 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The DWMAC 4.10 supports the same enhanced addressing mode as later
> generations. Parse this capability from the hardware feature registers
> and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
Do you think these two patches should have companion Fixes: tag? They
are definitively bug fixes, but maybe you would also want those to be
back ported to -stable trees?
>
> Thierry
>
> Thierry Reding (2):
> net: stmmac: Only enable enhanced addressing mode when needed
> net: stmmac: Support enhanced addressing mode for DWMAC 4.10
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
> .../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
> .../ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++
> include/linux/stmmac.h | 1 +
> 7 files changed, 39 insertions(+), 3 deletions(-)
>
--
Florian
^ 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