* Re: [PATCH V2 net-next 0/8] Misc bug fixes & small enhancements for HNS3 Driver
From: David Miller @ 2018-08-14 16:58 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil.lnk, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Tue, 14 Aug 2018 17:13:11 +0100
> This patch-set presents some bug fixes and minor enhancements to
> HNS3 Ethernet driver.
>
> Rework Summary:
> (*) Patch V1->V2
> 1. Fixed David S Miller's comments
> 2. Dropped patch 0005 "net: hns3: Fix for vf vlan delete failed problem" for now.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan @ 2018-08-14 16:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: security, Kevin Deus, Samuel Ortiz, David S. Miller, Allen Pais,
Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180814095413.vbjkcjkmytkffyaz@mwanda>
On Tue, Aug 14, 2018 at 2:54 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Thanks. This is great. I'm so glad these are finally getting fixed.
>
> Do we need to fix nfc_hci_msg_rx_work() and nfc_hci_recv_from_llc() as
> well? In nfc_hci_recv_from_llc() we allow pipe to be NFC_HCI_FRAGMENT
> (0x7f) so that's one element beyond the end of the array and the
> NFC_HCI_HCP_RESPONSE isn't checked.
>
> Also nci_hci_msg_rx_work() and nci_hci_data_received_cb() use
> NCI_HCP_MSG_GET_PIPE() so those could be off by one.
Good point. From hci.h:
/*
* According to specification 102 622 chapter 4.4 Pipes,
* the pipe identifier is 7 bits long.
*/
#define NFC_HCI_MAX_PIPES 127
And then:
struct nfc_hci_dev {
...
struct nfc_hci_pipe pipes[NFC_HCI_MAX_PIPES];
...
}
I think the correct fix would be to change it to:
struct nfc_hci_pipe pipes[NFC_HCI_MAX_PIPES + 1];
What do you think?
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH v2 iproute2-next] Add SKB Priority qdisc support in tc(8)
From: David Ahern @ 2018-08-14 14:08 UTC (permalink / raw)
To: Nishanth Devarajan; +Cc: netdev, doucette, michel
In-Reply-To: <20180814025719.GA8435@gmail.com>
On 8/13/18 8:57 PM, Nishanth Devarajan wrote:
> sch_skbprio is a qdisc that prioritizes packets according to their skb->priority
> field. Under congestion, it drops already-enqueued lower priority packets to
> make space available for higher priority packets. Skbprio was conceived as a
> solution for denial-of-service defenses that need to route packets with
> different priorities as a means to overcome DoS attacks.
>
> Signed-off-by: Nishanth Devarajan <ndev2021@gmail.com>
> Reviewed-by: Michel Machado <michel@digirati.com.br>
> ---
> v2
> *Patch applies cleanly, fixes for proper code indentation.
> ---
> man/man8/tc-skbprio.8 | 70 ++++++++++++++++++++++++++++++++++++++++++
> tc/Makefile | 1 +
> tc/q_skbprio.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 155 insertions(+)
> create mode 100644 man/man8/tc-skbprio.8
> create mode 100644 tc/q_skbprio.c
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH] rds: fix building with IPV6=m
From: Santosh Shilimkar @ 2018-08-14 16:53 UTC (permalink / raw)
To: Arnd Bergmann, David S. Miller
Cc: Anders Roxell, Greg Thelen, Ka-Cheong Poon, Stephen Hemminger,
netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <20180814090752.1681486-1-arnd@arndb.de>
On 8/14/2018 2:07 AM, Arnd Bergmann wrote:
> When CONFIG_RDS_TCP is built-in and CONFIG_IPV6 is a loadable
> module, we get a link error agains the modular ipv6_chk_addr()
> function:
>
> net/rds/tcp.o: In function `rds_tcp_laddr_check':
> tcp.c:(.text+0x3b2): undefined reference to `ipv6_chk_addr'
>
> This adds back a dependency that forces RDS_TCP to also be
> a loadable module when IPV6 is one.
>
> Fixes: e65d4d96334e ("rds: Remove IPv6 dependency")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> net/rds/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/rds/Kconfig b/net/rds/Kconfig
> index 41f75563b54b..01b3bd6a3708 100644
> --- a/net/rds/Kconfig
> +++ b/net/rds/Kconfig
> @@ -16,6 +16,7 @@ config RDS_RDMA
> config RDS_TCP
> tristate "RDS over TCP"
> depends on RDS
> + depends on IPV6 || !IPV6
> ---help---
> Allow RDS to use TCP as a transport.
> This transport does not support RDMA operations.
>
Its weird depends on but probably ok since we get to module
to be enabled with or without IPV6.
Thanks for the patch Arnd !!
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* RE: [PATCH net-next 5/9] net: hns3: Fix for vf vlan delete failed problem
From: Salil Mehta @ 2018-08-14 16:35 UTC (permalink / raw)
To: David Miller
Cc: Zhuangyuzeng (Yisen), lipeng (Y), mehta.salil.lnk@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Linuxarm,
linyunsheng
In-Reply-To: <20180813.085637.2236041056676583980.davem@davemloft.net>
Hi Dave,
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, August 13, 2018 4:57 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil.lnk@gmail.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; linyunsheng <linyunsheng@huawei.com>
> Subject: Re: [PATCH net-next 5/9] net: hns3: Fix for vf vlan delete
> failed problem
>
> From: Salil Mehta <salil.mehta@huawei.com>
> Date: Sun, 12 Aug 2018 10:47:34 +0100
>
> > Fixes: 9dba194574e3 ("{topost} net: hns3: fix for vlan table
> problem")
>
> This commit ID doesn't exist.
Thanks for catching this. This commit ID was from our internal branch
and ideally should have been from net-next - I should have caught this
earlier, sorry for this!
I have for now dropped this patch from the series as there is another
related patch(being referred in the Fixes string) that would need to
be merged with this patch before sending to net-next. Therefore, will
refloat this patch along with other related patch later in next cycle.
>
> Also, I really don't think the string "{topost}" would be in the commit
> header line.
Yes, this is stray and will be removed when this patch is sent next.
Thank you
Salil
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: missing unlock on error path
From: Andrew Lunn @ 2018-08-14 13:42 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Vivien Didelot, Florian Fainelli, netdev, kernel-janitors
In-Reply-To: <20180814090905.rm6i665c5utl7d32@kili.mountain>
On Tue, Aug 14, 2018 at 12:09:05PM +0300, Dan Carpenter wrote:
> We added a new error path, but we need to drop the lock before we return.
>
> Fixes: 2d2e1dd29962 ("net: dsa: mv88e6xxx: Cache the port cmode")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: bitwise vs logical bug
From: Andrew Lunn @ 2018-08-14 13:41 UTC (permalink / raw)
To: Dan Carpenter
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
kernel-janitors
In-Reply-To: <20180814090643.ilis47jhsaa2sbhi@kili.mountain>
On Tue, Aug 14, 2018 at 12:06:43PM +0300, Dan Carpenter wrote:
> We are trying to test if these flags are set but there are some && vs &
> typos.
>
> Fixes: efd1ba6af93f ("net: dsa: mv88e6xxx: Add SERDES phydev_mac_change up for 6390")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next] net: filter: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2018-08-14 16:20 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1472592 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/core/filter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 15b9d2d..fd423ce 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7235,6 +7235,7 @@ sk_reuseport_is_valid_access(int off, int size,
case offsetof(struct sk_reuseport_md, eth_protocol):
if (size < FIELD_SIZEOF(struct sk_buff, protocol))
return false;
+ /* fall through */
case offsetof(struct sk_reuseport_md, ip_protocol):
case offsetof(struct sk_reuseport_md, bind_inany):
case offsetof(struct sk_reuseport_md, len):
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 1/9] net: hns3: Add support for serdes loopback selftest
From: Salil Mehta @ 2018-08-14 16:17 UTC (permalink / raw)
To: David Miller
Cc: Zhuangyuzeng (Yisen), lipeng (Y), mehta.salil.lnk@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Linuxarm,
linyunsheng
In-Reply-To: <20180813.085456.1905254242911513146.davem@davemloft.net>
Hi Dave,
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, August 13, 2018 4:55 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil.lnk@gmail.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; linyunsheng <linyunsheng@huawei.com>
> Subject: Re: [PATCH net-next 1/9] net: hns3: Add support for serdes
> loopback selftest
>
> From: Salil Mehta <salil.mehta@huawei.com>
> Date: Sun, 12 Aug 2018 10:47:30 +0100
>
> > -#define HNS3_SELF_TEST_TPYE_NUM 1
> > +#define HNS3_SELF_TEST_TPYE_NUM 2
Sure, fixed in V2. Thanks.
>
> Is this supposed to be the number of self test "types"? If so, this
> CPP
> macro should be named "HNS3_SELF_TEST_TYPE_NUM".
>
> > +
> > + count ++;
> ^
>
> Please remove that unnecessary space
Sure, fixed in V2 version, thanks.
>
> > + } while (++i < HCLGE_SERDES_RETRY_NUM &&
> ^^
>
> Only need one space there, not two.
Thank you. Fixed in V2.
Best regards
Salil
^ permalink raw reply
* [PATCH V2 net-next 8/8] net: hns3: Add vlan filter setting by ethtool command -K
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
Revision(0x20) HW does not support enabling or disabling individual
netdev's HW_VLAN_CTAG_FILTER feature, and Revision(0x21) supports
enabling or disabling individual netdev's HW_VLAN_CTAG_FILTER
feature.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b28c7e1..3554dca 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1673,6 +1673,9 @@ static struct pci_driver hns3_driver = {
/* set default feature to hns3 */
static void hns3_set_default_feature(struct net_device *netdev)
{
+ struct hnae3_handle *h = hns3_get_handle(netdev);
+ struct pci_dev *pdev = h->pdev;
+
netdev->priv_flags |= IFF_UNICAST_FLT;
netdev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
@@ -1706,6 +1709,9 @@ static void hns3_set_default_feature(struct net_device *netdev)
NETIF_F_GRO | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM | NETIF_F_GSO_UDP_TUNNEL |
NETIF_F_GSO_UDP_TUNNEL_CSUM;
+
+ if (pdev->revision != 0x20)
+ netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER;
}
static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 7/8] net: hns3: Set tx ring' tc info when netdev is up
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
The HNS3_RING_TX_RING_TC_REG register is used to map tx ring to
specific tc, the tx queue to tc mapping is needed by the hardware
to do the correct tx schedule.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 24 ++++++++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b7b9ee3..b28c7e1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2974,6 +2974,28 @@ static void hns3_init_ring_hw(struct hns3_enet_ring *ring)
}
}
+static void hns3_init_tx_ring_tc(struct hns3_nic_priv *priv)
+{
+ struct hnae3_knic_private_info *kinfo = &priv->ae_handle->kinfo;
+ int i;
+
+ for (i = 0; i < HNAE3_MAX_TC; i++) {
+ struct hnae3_tc_info *tc_info = &kinfo->tc_info[i];
+ int j;
+
+ if (!tc_info->enable)
+ continue;
+
+ for (j = 0; j < tc_info->tqp_count; j++) {
+ struct hnae3_queue *q;
+
+ q = priv->ring_data[tc_info->tqp_offset + j].ring->tqp;
+ hns3_write_dev(q, HNS3_RING_TX_RING_TC_REG,
+ tc_info->tc);
+ }
+ }
+}
+
int hns3_init_all_ring(struct hns3_nic_priv *priv)
{
struct hnae3_handle *h = priv->ae_handle;
@@ -3385,6 +3407,8 @@ int hns3_nic_reset_all_ring(struct hnae3_handle *h)
rx_ring->next_to_use = 0;
}
+ hns3_init_tx_ring_tc(priv);
+
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 0f071a0..a02a96a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -37,6 +37,7 @@ enum hns3_nic_state {
#define HNS3_RING_TX_RING_BASEADDR_L_REG 0x00040
#define HNS3_RING_TX_RING_BASEADDR_H_REG 0x00044
#define HNS3_RING_TX_RING_BD_NUM_REG 0x00048
+#define HNS3_RING_TX_RING_TC_REG 0x00050
#define HNS3_RING_TX_RING_TAIL_REG 0x00058
#define HNS3_RING_TX_RING_HEAD_REG 0x0005C
#define HNS3_RING_TX_RING_FBDNUM_REG 0x00060
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 6/8] net: hns3: Remove tx ring BD len register in hns3_enet
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
There is no HNS3_RING_TX_RING_BD_LEN_REG register according
to UM, so this patch removes it.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 --
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index a64d69c..b7b9ee3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2969,8 +2969,6 @@ static void hns3_init_ring_hw(struct hns3_enet_ring *ring)
hns3_write_dev(q, HNS3_RING_TX_RING_BASEADDR_H_REG,
(u32)((dma >> 31) >> 1));
- hns3_write_dev(q, HNS3_RING_TX_RING_BD_LEN_REG,
- hns3_buf_size2type(ring->buf_size));
hns3_write_dev(q, HNS3_RING_TX_RING_BD_NUM_REG,
ring->desc_num / 8 - 1);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index e4b4a8f..0f071a0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -37,7 +37,6 @@ enum hns3_nic_state {
#define HNS3_RING_TX_RING_BASEADDR_L_REG 0x00040
#define HNS3_RING_TX_RING_BASEADDR_H_REG 0x00044
#define HNS3_RING_TX_RING_BD_NUM_REG 0x00048
-#define HNS3_RING_TX_RING_BD_LEN_REG 0x0004C
#define HNS3_RING_TX_RING_TAIL_REG 0x00058
#define HNS3_RING_TX_RING_HEAD_REG 0x0005C
#define HNS3_RING_TX_RING_FBDNUM_REG 0x00060
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 4/8] net: hns3: Fix for phy link issue when using marvell phy driver
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
For marvell phy m88e1510, bit SUPPORTED_FIBRE of phydev->supported
is default on. Both phy_resume() and phy_suspend() will check the
SUPPORTED_FIBRE bit and write register of fibre page.
Currently in hns3 driver, the SUPPORTED_FIBRE bit will be cleared
after phy_connect_direct() finished. Because phy_resume() is called
in phy_connect_direct(), and phy_suspend() is called when disconnect
phy device, so the operation for fibre page register is not symmetrical.
It will cause phy link issue when reload hns3 driver.
This patch fixes it by disable the SUPPORTED_FIBRE before connecting
phy.
Fixes: 256727da7395 ("net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
index 85a123d..398971a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -202,6 +202,8 @@ int hclge_mac_connect_phy(struct hclge_dev *hdev)
if (!phydev)
return 0;
+ phydev->supported &= ~SUPPORTED_FIBRE;
+
ret = phy_connect_direct(netdev, phydev,
hclge_mac_adjust_link,
PHY_INTERFACE_MODE_SGMII);
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 3/8] net: hns3: Fix for information of phydev lost problem when down/up
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
Function call of phy_connect_direct will reinitialize phydev. Some
information like advertising will be lost. Phy_connect_direct only
needs to be called once. And driver can run well. This patch adds
some functions to ensure that phy_connect_direct is called only once
to solve the information of phydev lost problem occurring when we stop
the net and open it again.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 24 +++++++++++++++++----
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 25 ++++++++++++++++++----
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h | 4 +++-
3 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 5f30ea4..2e9c8b9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3782,7 +3782,7 @@ static int hclge_ae_start(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_dev *hdev = vport->back;
- int i, ret;
+ int i;
for (i = 0; i < vport->alloc_tqps; i++)
hclge_tqp_enable(hdev, i, 0, true);
@@ -3796,9 +3796,7 @@ static int hclge_ae_start(struct hnae3_handle *handle)
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
- ret = hclge_mac_start_phy(hdev);
- if (ret)
- return ret;
+ hclge_mac_start_phy(hdev);
return 0;
}
@@ -5417,6 +5415,16 @@ static void hclge_get_mdix_mode(struct hnae3_handle *handle,
*tp_mdix = ETH_TP_MDI;
}
+static int hclge_init_instance_hw(struct hclge_dev *hdev)
+{
+ return hclge_mac_connect_phy(hdev);
+}
+
+static void hclge_uninit_instance_hw(struct hclge_dev *hdev)
+{
+ hclge_mac_disconnect_phy(hdev);
+}
+
static int hclge_init_client_instance(struct hnae3_client *client,
struct hnae3_ae_dev *ae_dev)
{
@@ -5436,6 +5444,13 @@ static int hclge_init_client_instance(struct hnae3_client *client,
if (ret)
return ret;
+ ret = hclge_init_instance_hw(hdev);
+ if (ret) {
+ client->ops->uninit_instance(&vport->nic,
+ 0);
+ return ret;
+ }
+
if (hdev->roce_client &&
hnae3_dev_roce_supported(hdev)) {
struct hnae3_client *rc = hdev->roce_client;
@@ -5498,6 +5513,7 @@ static void hclge_uninit_client_instance(struct hnae3_client *client,
if (client->type == HNAE3_CLIENT_ROCE)
return;
if (client->ops->uninit_instance) {
+ hclge_uninit_instance_hw(hdev);
client->ops->uninit_instance(&vport->nic, 0);
hdev->nic_client = NULL;
vport->nic.client = NULL;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
index 2065ee2f..85a123d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -193,7 +193,7 @@ static void hclge_mac_adjust_link(struct net_device *netdev)
netdev_err(netdev, "failed to configure flow control.\n");
}
-int hclge_mac_start_phy(struct hclge_dev *hdev)
+int hclge_mac_connect_phy(struct hclge_dev *hdev)
{
struct net_device *netdev = hdev->vport[0].nic.netdev;
struct phy_device *phydev = hdev->hw.mac.phydev;
@@ -213,11 +213,29 @@ int hclge_mac_start_phy(struct hclge_dev *hdev)
phydev->supported &= HCLGE_PHY_SUPPORTED_FEATURES;
phydev->advertising = phydev->supported;
- phy_start(phydev);
-
return 0;
}
+void hclge_mac_disconnect_phy(struct hclge_dev *hdev)
+{
+ struct phy_device *phydev = hdev->hw.mac.phydev;
+
+ if (!phydev)
+ return;
+
+ phy_disconnect(phydev);
+}
+
+void hclge_mac_start_phy(struct hclge_dev *hdev)
+{
+ struct phy_device *phydev = hdev->hw.mac.phydev;
+
+ if (!phydev)
+ return;
+
+ phy_start(phydev);
+}
+
void hclge_mac_stop_phy(struct hclge_dev *hdev)
{
struct net_device *netdev = hdev->vport[0].nic.netdev;
@@ -227,5 +245,4 @@ void hclge_mac_stop_phy(struct hclge_dev *hdev)
return;
phy_stop(phydev);
- phy_disconnect(phydev);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h
index bb3ce35..5fbf7dd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h
@@ -5,7 +5,9 @@
#define __HCLGE_MDIO_H
int hclge_mac_mdio_config(struct hclge_dev *hdev);
-int hclge_mac_start_phy(struct hclge_dev *hdev);
+int hclge_mac_connect_phy(struct hclge_dev *hdev);
+void hclge_mac_disconnect_phy(struct hclge_dev *hdev);
+void hclge_mac_start_phy(struct hclge_dev *hdev);
void hclge_mac_stop_phy(struct hclge_dev *hdev);
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 2/8] net: hns3: Fix for command format parsing error in hclge_is_all_function_id_zero
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Xi Wang
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Xi Wang <wangxi11@huawei.com>
According to the functional specification of hardware, the first
descriptor of response from command 'lookup vlan talbe' is not valid.
Currently, the first descriptor is parsed as normal value, which will
cause an expected error.
This patch fixes this problem by skipping the first descriptor.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 9209122..5f30ea4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3930,7 +3930,7 @@ static bool hclge_is_all_function_id_zero(struct hclge_desc *desc)
#define HCLGE_FUNC_NUMBER_PER_DESC 6
int i, j;
- for (i = 0; i < HCLGE_DESC_NUMBER; i++)
+ for (i = 1; i < HCLGE_DESC_NUMBER; i++)
for (j = 0; j < HCLGE_FUNC_NUMBER_PER_DESC; j++)
if (desc[i].data[j])
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 1/8] net: hns3: Add support for serdes loopback selftest
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
This patch adds support for serdes loopback selftest in hns3
driver.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
Patch V2: Fixed comments from Davis S Miller
@Link, https://lkml.org/lkml/2018/8/13/385
Patch V1: Initial Submit
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 11 +++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 12 +++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 57 +++++++++++++++++++++-
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 80ba95d..f70ee69 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -53,7 +53,7 @@ static const struct hns3_stats hns3_rxq_stats[] = {
#define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
-#define HNS3_SELF_TEST_TPYE_NUM 1
+#define HNS3_SELF_TEST_TYPE_NUM 2
#define HNS3_NIC_LB_TEST_PKT_NUM 1
#define HNS3_NIC_LB_TEST_RING_ID 0
#define HNS3_NIC_LB_TEST_PACKET_SIZE 128
@@ -78,6 +78,7 @@ static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop, bool en)
return -EOPNOTSUPP;
switch (loop) {
+ case HNAE3_MAC_INTER_LOOP_SERDES:
case HNAE3_MAC_INTER_LOOP_MAC:
ret = h->ae_algo->ops->set_loopback(h, loop, en);
break;
@@ -287,7 +288,7 @@ static void hns3_self_test(struct net_device *ndev,
{
struct hns3_nic_priv *priv = netdev_priv(ndev);
struct hnae3_handle *h = priv->ae_handle;
- int st_param[HNS3_SELF_TEST_TPYE_NUM][2];
+ int st_param[HNS3_SELF_TEST_TYPE_NUM][2];
bool if_running = netif_running(ndev);
#if IS_ENABLED(CONFIG_VLAN_8021Q)
bool dis_vlan_filter;
@@ -303,6 +304,10 @@ static void hns3_self_test(struct net_device *ndev,
st_param[HNAE3_MAC_INTER_LOOP_MAC][1] =
h->flags & HNAE3_SUPPORT_MAC_LOOPBACK;
+ st_param[HNAE3_MAC_INTER_LOOP_SERDES][0] = HNAE3_MAC_INTER_LOOP_SERDES;
+ st_param[HNAE3_MAC_INTER_LOOP_SERDES][1] =
+ h->flags & HNAE3_SUPPORT_SERDES_LOOPBACK;
+
if (if_running)
dev_close(ndev);
@@ -316,7 +321,7 @@ static void hns3_self_test(struct net_device *ndev,
set_bit(HNS3_NIC_STATE_TESTING, &priv->state);
- for (i = 0; i < HNS3_SELF_TEST_TPYE_NUM; i++) {
+ for (i = 0; i < HNS3_SELF_TEST_TYPE_NUM; i++) {
enum hnae3_loop loop_type = (enum hnae3_loop)st_param[i][0];
if (!st_param[i][1])
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index cd0a4f2..821d4c2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -94,6 +94,7 @@ enum hclge_opcode_type {
HCLGE_OPC_QUERY_LINK_STATUS = 0x0307,
HCLGE_OPC_CONFIG_MAX_FRM_SIZE = 0x0308,
HCLGE_OPC_CONFIG_SPEED_DUP = 0x0309,
+ HCLGE_OPC_SERDES_LOOPBACK = 0x0315,
/* PFC/Pause commands */
HCLGE_OPC_CFG_MAC_PAUSE_EN = 0x0701,
@@ -775,6 +776,17 @@ struct hclge_reset_cmd {
u8 fun_reset_vfid;
u8 rsv[22];
};
+
+#define HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B BIT(0)
+#define HCLGE_CMD_SERDES_DONE_B BIT(0)
+#define HCLGE_CMD_SERDES_SUCCESS_B BIT(1)
+struct hclge_serdes_lb_cmd {
+ u8 mask;
+ u8 enable;
+ u8 result;
+ u8 rsv[21];
+};
+
#define HCLGE_DEFAULT_TX_BUF 0x4000 /* 16k bytes */
#define HCLGE_TOTAL_PKT_BUF 0x108000 /* 1.03125M bytes */
#define HCLGE_DEFAULT_DV 0xA000 /* 40k byte */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fc813b7..9209122 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -787,9 +787,10 @@ static int hclge_get_sset_count(struct hnae3_handle *handle, int stringset)
hdev->hw.mac.speed == HCLGE_MAC_SPEED_1G) {
count += 1;
handle->flags |= HNAE3_SUPPORT_MAC_LOOPBACK;
- } else {
- count = -EOPNOTSUPP;
}
+
+ count++;
+ handle->flags |= HNAE3_SUPPORT_SERDES_LOOPBACK;
} else if (stringset == ETH_SS_STATS) {
count = ARRAY_SIZE(g_mac_stats_string) +
ARRAY_SIZE(g_all_32bit_stats_string) +
@@ -3670,6 +3671,55 @@ static int hclge_set_mac_loopback(struct hclge_dev *hdev, bool en)
return ret;
}
+static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en)
+{
+#define HCLGE_SERDES_RETRY_MS 10
+#define HCLGE_SERDES_RETRY_NUM 100
+ struct hclge_serdes_lb_cmd *req;
+ struct hclge_desc desc;
+ int ret, i = 0;
+
+ req = (struct hclge_serdes_lb_cmd *)&desc.data[0];
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_SERDES_LOOPBACK, false);
+
+ if (en) {
+ req->enable = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ req->mask = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ } else {
+ req->mask = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ }
+
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "serdes loopback set fail, ret = %d\n", ret);
+ return ret;
+ }
+
+ do {
+ msleep(HCLGE_SERDES_RETRY_MS);
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_SERDES_LOOPBACK,
+ true);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "serdes loopback get, ret = %d\n", ret);
+ return ret;
+ }
+ } while (++i < HCLGE_SERDES_RETRY_NUM &&
+ !(req->result & HCLGE_CMD_SERDES_DONE_B));
+
+ if (!(req->result & HCLGE_CMD_SERDES_DONE_B)) {
+ dev_err(&hdev->pdev->dev, "serdes loopback set timeout\n");
+ return -EBUSY;
+ } else if (!(req->result & HCLGE_CMD_SERDES_SUCCESS_B)) {
+ dev_err(&hdev->pdev->dev, "serdes loopback set failed in fw\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int hclge_set_loopback(struct hnae3_handle *handle,
enum hnae3_loop loop_mode, bool en)
{
@@ -3681,6 +3731,9 @@ static int hclge_set_loopback(struct hnae3_handle *handle,
case HNAE3_MAC_INTER_LOOP_MAC:
ret = hclge_set_mac_loopback(hdev, en);
break;
+ case HNAE3_MAC_INTER_LOOP_SERDES:
+ ret = hclge_set_serdes_loopback(hdev, en);
+ break;
default:
ret = -ENOTSUPP;
dev_err(&hdev->pdev->dev,
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 0/8] Misc bug fixes & small enhancements for HNS3 Driver
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm
This patch-set presents some bug fixes and minor enhancements to
HNS3 Ethernet driver.
Rework Summary:
(*) Patch V1->V2
1. Fixed David S Miller's comments
2. Dropped patch 0005 "net: hns3: Fix for vf vlan delete failed problem" for now.
Fuyun Liang (1):
net: hns3: Fix for information of phydev lost problem when down/up
Jian Shen (1):
net: hns3: Fix for phy link issue when using marvell phy driver
Peng Li (2):
net: hns3: Add support for serdes loopback selftest
net: hns3: Add vlan filter setting by ethtool command -K
Xi Wang (1):
net: hns3: Fix for command format parsing error in
hclge_is_all_function_id_zero
Yunsheng Lin (3):
net: hns3: Fix desc num set to default when setting channel
net: hns3: Remove tx ring BD len register in hns3_enet
net: hns3: Set tx ring' tc info when netdev is up
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 32 ++++++-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 11 ++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 12 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 105 +++++++++++++++++----
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 27 +++++-
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h | 4 +-
7 files changed, 165 insertions(+), 28 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-14 13:20 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <20180814121734.105769fa@redhat.com>
On 2018年08月14日 18:17, Jesper Dangaard Brouer wrote:
> On Tue, 14 Aug 2018 15:59:01 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
>>> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>>>> Hi:
>>>>
>>>> This series tries to implement XDP support for rx hanlder. This would
>>>> be useful for doing native XDP on stacked device like macvlan, bridge
>>>> or even bond.
>>>>
>>>> The idea is simple, let stacked device register a XDP rx handler. And
>>>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>>>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>>>> handler may then decide how to proceed, it could consume the buff, ask
>>>> driver to drop the packet or ask the driver to fallback to normal skb
>>>> path.
>>>>
>>>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>>>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>>>> example. For ease comparision, generic XDP support for rx handler was
>>>> also implemented.
>>>>
>>>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>>>> shows about 83% improvement.
>>> I'm missing the motiviation for this.
>>> It seems performance of such solution is ~1M packet per second.
>> Notice it was measured by virtio-net which is kind of slow.
>>
>>> What would be a real life use case for such feature ?
>> I had another run on top of 10G mlx4 and macvlan:
>>
>> XDP_DROP on mlx4: 14.0Mpps
>> XDP_DROP on macvlan: 10.05Mpps
>>
>> Perf shows macvlan_hash_lookup() and indirect call to
>> macvlan_handle_xdp() are the reasons for the number drop. I think the
>> numbers are acceptable. And we could try more optimizations on top.
>>
>> So here's real life use case is trying to have an fast XDP path for rx
>> handler based device:
>>
>> - For containers, we can run XDP for macvlan (~70% of wire speed). This
>> allows a container specific policy.
>> - For VM, we can implement macvtap XDP rx handler on top. This allow us
>> to forward packet to VM without building skb in the setup of macvtap.
>> - The idea could be used by other rx handler based device like bridge,
>> we may have a XDP fast forwarding path for bridge.
>>
>>> Another concern is that XDP users expect to get line rate performance
>>> and native XDP delivers it. 'generic XDP' is a fallback only
>>> mechanism to operate on NICs that don't have native XDP yet.
>> So I can replace generic XDP TX routine with a native one for macvlan.
> If you simply implement ndo_xdp_xmit() for macvlan, and instead use
> XDP_REDIRECT, then we are basically done.
As I replied in another thread this probably not true. Its
ndo_xdp_xmit() just need to call under layer device's ndo_xdp_xmit()
except for the case of bridge mode.
>
>
>>> Toshiaki's veth XDP work fits XDP philosophy and allows
>>> high speed networking to be done inside containers after veth.
>>> It's trying to get to line rate inside container.
>> This is one of the goal of this series as well. I agree veth XDP work
>> looks pretty fine, but it only work for a specific setup I believe since
>> it depends on XDP_REDIRECT which is supported by few drivers (and
>> there's no VF driver support).
> The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
> argument that only a few drivers implement this. Especially since all
> drivers also need to be extended with your proposed xdp_do_pass() call.
>
> (rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
> that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
> have to allocate HW TX-queue resources. If we disconnect RX and TX
> side of redirect, then we can implement RX-side in an afternoon.
That's exactly the point, ndo_xdp_xmit() may requires per CPU TX queues
which breaks assumptions of some drivers. And since we don't disconnect
RX and TX, it looks to me the partial implementation is even worse?
Consider a user can redirect from mlx4 to ixgbe but not ixgbe to mlx4.
>
>
>> And in order to make it work for a end
>> user, the XDP program still need logic like hash(map) lookup to
>> determine the destination veth.
> That _is_ the general idea behind XDP and eBPF, that we need to add logic
> that determine the destination. The kernel provides the basic
> mechanisms for moving/redirecting packets fast, and someone else
> builds an orchestration tool like Cilium, that adds the needed logic.
Yes, so my reply is for the concern about performance. I meant anyway
the hash lookup will make it not hit the wire speed.
>
> Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
> accessible from XDP.
Yes.
>
> For macvlan, I imagine that we could add a BPF helper that allows you
> to lookup/call macvlan_hash_lookup().
That's true but we still need a method to feed macvlan with XDP buff.
I'm not sure if this could be treated as another kind of redirection,
but ndo_xdp_xmit() could not be used for this case for sure. Compared to
redirection, XDP rx handler has its own advantages:
1) Use the exist API and userspace to setup the network topology instead
of inventing new tools and its own specific API. This means user can
just setup macvlan (macvtap, bridge or other) as usual and simply attach
XDP programs to both macvlan and its under layer device.
2) Ease the processing of complex logic, XDP can not do cloning or
reference counting. We can differ those cases and let normal networking
stack to deal with such packets seamlessly. I believe this is one of the
advantage of XDP. This makes us to focus on the fast path and greatly
simplify the codes.
Like ndo_xdp_xmit(), XDP rx handler is used to feed RX handler with XDP
buff. It's just another basic mechanism. Policy is still done by XDP
program itself.
Thanks
>
>
>>> This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
>>> and the users will get confused with forever slow modes of XDP.
>>>
>>> Please explain the problem you're trying to solve.
>>> "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
>>>
>
^ permalink raw reply
* Re: WARNING: suspicious RCU usage in bpf_prog_array_copy_core
From: Y Song @ 2018-08-14 15:59 UTC (permalink / raw)
To: syzbot; +Cc: Alexei Starovoitov, Daniel Borkmann, LKML, netdev, syzkaller-bugs
In-Reply-To: <000000000000863a6e057361feb4@google.com>
On Tue, Aug 14, 2018 at 2:40 AM, syzbot
<syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 4110b42356f3 Add linux-next specific files for 20180810
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=109bac02400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> dashboard link: https://syzkaller.appspot.com/bug?extid=6e72317008eef84a216b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=157ef48a400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e16cf8400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
>
> =============================
> WARNING: suspicious RCU usage
> 4.18.0-rc8-next-20180810+ #36 Not tainted
> -----------------------------
> kernel/bpf/core.c:1582 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by syz-executor287/4449:
> #0: 00000000d8131c0c (&ctx->mutex){+.+.}, at:
> perf_event_ctx_lock_nested+0x375/0x600 kernel/events/core.c:1276
> #1: 000000006c916250 (bpf_event_mutex){+.+.}, at:
> perf_event_query_prog_array+0x1c6/0x380 kernel/trace/bpf_trace.c:1062
>
> stack backtrace:
> CPU: 1 PID: 4449 Comm: syz-executor287 Not tainted 4.18.0-rc8-next-20180810+
> #36
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4562
> bpf_prog_array_copy_core+0x2d9/0x360 kernel/bpf/core.c:1582
> bpf_prog_array_copy_info+0x9a/0x110 kernel/bpf/core.c:1720
> perf_event_query_prog_array+0x22e/0x380 kernel/trace/bpf_trace.c:1063
> _perf_ioctl+0x986/0x1600 kernel/events/core.c:5079
> perf_ioctl+0x59/0x80 kernel/events/core.c:5110
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:501 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> __do_sys_ioctl fs/ioctl.c:709 [inline]
> __se_sys_ioctl fs/ioctl.c:707 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440409
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fffc5fc1488 EFLAGS: 00000217 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
> RDX: 0000000020000180 RSI: 00000000c008240a RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 0000000000401c90
> R13: 0000000000401d20 R14: 0000000000000000
>
I will take a look at this one.
We have a mutex lock at kernel/trace/bpf_trace.c,
1062 mutex_lock(&bpf_event_mutex);
1063 ret = bpf_prog_array_copy_info(event->tp_event->prog_array,
1064 ids,
1065 ids_len,
1066 &prog_cnt);
1067 mutex_unlock(&bpf_event_mutex);
We may need a variant of rcu_dereference, e.g., rcu_dereference_protected.
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Uwe Kleine-König @ 2018-08-14 15:58 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, netdev, mdf, stable, kernel,
Brad Mouring, Andrew Lunn, Florian Fainelli
In-Reply-To: <20180814141240.9085-1-a.fatoum@pengutronix.de>
Hello Ahmad,
On Tue, Aug 14, 2018 at 04:12:40PM +0200, Ahmad Fatoum wrote:
> The referenced commit broke initializing macb on the EVB-KSZ9477 eval board.
> There, of_mdiobus_register was called even for the fixed-link representing
> the SPI-connected switch PHY, with the result that the driver attempts to
> enumerate PHYs on a non-existent MDIO bus:
>
> libphy: MACB_mii_bus: probed
> mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
> [snip]
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
> macb f0028000.ethernet: broken fixed-link specification
>
> Cc: <stable@vger.kernel.org>
> Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup")
I added the people involved in 739de9a1563a to Cc. Maybe they want to
comment. So not stripping the remaining part of the original mail.
Best regards
Uwe
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 26 +++++++++++++++---------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index a6c911bb5ce2..d202a03c42ed 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -481,11 +481,6 @@ static int macb_mii_probe(struct net_device *dev)
>
> if (np) {
> if (of_phy_is_fixed_link(np)) {
> - if (of_phy_register_fixed_link(np) < 0) {
> - dev_err(&bp->pdev->dev,
> - "broken fixed-link specification\n");
> - return -ENODEV;
> - }
> bp->phy_node = of_node_get(np);
> } else {
> bp->phy_node = of_parse_phandle(np, "phy-handle", 0);
> @@ -568,7 +563,7 @@ static int macb_mii_init(struct macb *bp)
> {
> struct macb_platform_data *pdata;
> struct device_node *np;
> - int err;
> + int err = -ENXIO;
>
> /* Enable management port */
> macb_writel(bp, NCR, MACB_BIT(MPE));
> @@ -591,10 +586,21 @@ static int macb_mii_init(struct macb *bp)
> dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
>
> np = bp->pdev->dev.of_node;
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> + if (np && of_phy_is_fixed_link(np)) {
> + if (of_phy_register_fixed_link(np) < 0) {
> + dev_err(&bp->pdev->dev,
> + "broken fixed-link specification\n");
> + goto err_out_free_mdiobus;
> + }
> +
> + err = mdiobus_register(bp->mii_bus);
> + } else {
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> +
> + err = of_mdiobus_register(bp->mii_bus, np);
> + }
>
> - err = of_mdiobus_register(bp->mii_bus, np);
> if (err)
> goto err_out_free_mdiobus;
>
> @@ -606,9 +612,9 @@ static int macb_mii_init(struct macb *bp)
>
> err_out_unregister_bus:
> mdiobus_unregister(bp->mii_bus);
> +err_out_free_mdiobus:
> if (np && of_phy_is_fixed_link(np))
> of_phy_deregister_fixed_link(np);
> -err_out_free_mdiobus:
> of_node_put(bp->phy_node);
> mdiobus_free(bp->mii_bus);
> err_out:
> --
> 2.18.0
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH net-next v3] xen-netfront: fix warn message as irq device name has '/'
From: Xiao Liang @ 2018-08-14 15:21 UTC (permalink / raw)
To: netdev, xen-devel, davem, jgross, boris.ostrovsky
Cc: linux-kernel, Xiao Liang
There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9(
xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found
under /proc/irq/xx/.
This patch only picks up device type and id as its name.
With the patch, now /proc/interrupts looks like below and the warning message gone:
70: 21 0 0 0 xen-dyn -event vif0-q0-tx
71: 15 0 0 0 xen-dyn -event vif0-q0-rx
72: 14 0 0 0 xen-dyn -event vif0-q1-tx
73: 33 0 0 0 xen-dyn -event vif0-q1-rx
74: 12 0 0 0 xen-dyn -event vif0-q2-tx
75: 24 0 0 0 xen-dyn -event vif0-q2-rx
76: 19 0 0 0 xen-dyn -event vif0-q3-tx
77: 21 0 0 0 xen-dyn -event vif0-q3-rx
Below is call trace information without this patch:
name 'device/vif/0-q0-tx'
WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
RIP: 0010:__xlate_proc_name+0x85/0xa0
RSP: 0018:ffffb85c40473c18 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006
RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff984c7f516930
RBP: ffffb85c40473cb8 R08: 000000000000002c R09: 0000000000000229
R10: 0000000000000000 R11: 0000000000000001 R12: ffffb85c40473c98
R13: ffffb85c40473cb8 R14: ffffb85c40473c50 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff984c7f500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f69b6899038 CR3: 000000001c20a006 CR4: 00000000001606e0
Call Trace:
__proc_create+0x45/0x230
? snprintf+0x49/0x60
proc_mkdir_data+0x35/0x90
register_handler_proc+0xef/0x110
? proc_register+0xfc/0x110
? proc_create_data+0x70/0xb0
__setup_irq+0x39b/0x660
? request_threaded_irq+0xad/0x160
request_threaded_irq+0xf5/0x160
? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
bind_evtchn_to_irqhandler+0x3d/0x70
? xenbus_alloc_evtchn+0x41/0xa0
netback_changed+0xa46/0xcda [xen_netfront]
? find_watch+0x40/0x40
xenwatch_thread+0xc5/0x160
? finish_wait+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
---[ end trace 650e5561b0caab3a ]---
Signed-off-by: Xiao Liang <xiliang@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
drivers/net/xen-netfront.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 799cba4624a5..c4955bd303bb 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1604,14 +1604,16 @@ static int xennet_init_queue(struct netfront_queue *queue)
{
unsigned short i;
int err = 0;
+ char *devid;
spin_lock_init(&queue->tx_lock);
spin_lock_init(&queue->rx_lock);
timer_setup(&queue->rx_refill_timer, rx_refill_timeout, 0);
- snprintf(queue->name, sizeof(queue->name), "%s-q%u",
- queue->info->xbdev->nodename, queue->id);
+ devid = strrchr(queue->info->xbdev->nodename, '/') + 1;
+ snprintf(queue->name, sizeof(queue->name), "vif%s-q%u",
+ devid, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
--
2.17.1
^ permalink raw reply related
* [iproute PATCH 3/3] testsuite: Add a first ss test validating ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
This tests a few ssfilter expressions by selecting sockets from a TCP
dump file. The dump was created using the following command:
| ss -ntaD testsuite/tests/ss/ss1.dump
It is fed into ss via TCPDIAG_FILE environment variable.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/tests/ss/ss1.dump | Bin 0 -> 720 bytes
testsuite/tests/ss/ssfilter.t | 48 ++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
create mode 100644 testsuite/tests/ss/ss1.dump
create mode 100755 testsuite/tests/ss/ssfilter.t
diff --git a/testsuite/tests/ss/ss1.dump b/testsuite/tests/ss/ss1.dump
new file mode 100644
index 0000000000000000000000000000000000000000..9c273231c78418593cabda324ca20d5a6d41e1aa
GIT binary patch
literal 720
zcmYdbU|<koU}A81#K^!c$-uzG1r!hiVj=)DnwkbEe>Nin11kdun3n(~QOsv#0-E2u
z3TO>b6#}61K{9Mm>1mU45ek8<2e$al?_I?phHf4@A7mgq)YMKS^Irfxb<qmH`3z!5
zI?&An@_`;h1*}l+IW<)G-$HV~2v7|(Quu?kWB@U8m~jCOCpJ!4Kn5Uz1}J+jQk<|d
zaDxLs0Vs!J4=`@#c`%6mJHX%s)dr$e(D>kZgGJtnxD>cjP}t=IBMn#FbAjW2%?&j3
Wu$m7G%#dh=`5=oj%@O8f3p)VpCN7Tv
literal 0
HcmV?d00001
diff --git a/testsuite/tests/ss/ssfilter.t b/testsuite/tests/ss/ssfilter.t
new file mode 100755
index 0000000000000..e74f1765cb723
--- /dev/null
+++ b/testsuite/tests/ss/ssfilter.t
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+. lib/generic.sh
+
+# % ./misc/ss -Htna
+# LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
+# ESTAB 0 0 10.0.0.1:22 10.0.0.1:36266
+# ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22
+# ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312
+export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
+
+ts_log "[Testing ssfilter]"
+
+ts_ss "$0" "Match dport = 22" -Htna dport = 22
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match dport 22" -Htna dport 22
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match (dport)" -Htna '( dport = 22 )'
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match src = 0.0.0.0" -Htna src = 0.0.0.0
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src 0.0.0.0" -Htna src 0.0.0.0
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src sport" -Htna src 0.0.0.0 sport = 22
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src and sport" -Htna src 0.0.0.0 and sport = 22
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src and sport and dport" -Htna src 10.0.0.1 and sport = 22 and dport = 50312
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match src and sport and (dport)" -Htna 'src 10.0.0.1 and sport = 22 and ( dport = 50312 )'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match src and (sport and dport)" -Htna 'src 10.0.0.1 and ( sport = 22 and dport = 50312 )'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match (src and sport) and dport" -Htna '( src 10.0.0.1 and sport = 22 ) and dport = 50312'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match (src or src) and dst" -Htna '( src 0.0.0.0 or src 10.0.0.1 ) and dst 10.0.0.2'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 0/3] Fix and test ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
This series contains a fix for ssfilter and introduces a testscript to
verify correct functionality.
Phil Sutter (3):
ss: Review ssfilter
testsuite: Prepare for ss tests
testsuite: Add a first ss test validating ssfilter
misc/ssfilter.y | 36 ++++++++++++++-----------
testsuite/Makefile | 2 +-
testsuite/lib/generic.sh | 37 ++++++++++----------------
testsuite/tests/ss/ss1.dump | Bin 0 -> 720 bytes
testsuite/tests/ss/ssfilter.t | 48 ++++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 39 deletions(-)
create mode 100644 testsuite/tests/ss/ss1.dump
create mode 100755 testsuite/tests/ss/ssfilter.t
--
2.18.0
^ permalink raw reply
* [iproute PATCH 1/3] ss: Review ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
The original problem was ssfilter rejecting single expressions if
enclosed in braces, such as:
| sport = 22 or ( dport = 22 )
This is fixed by allowing 'expr' to be an 'exprlist' enclosed in braces.
The no longer required recursion in 'exprlist' being an 'exprlist'
enclosed in braces is dropped.
In addition to that, a few other things are changed:
* Remove pointless 'null' prefix in 'appled' before 'exprlist'.
* For simple equals matches, '=' operator was required for ports but not
allowed for hosts. Make this consistent by making '=' operator
optional in both cases.
Reported-by: Samuel Mannehed <samuel@cendio.se>
Fixes: b2038cc0b2403 ("ssfilter: Eliminate shift/reduce conflicts")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ssfilter.y | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/misc/ssfilter.y b/misc/ssfilter.y
index 88d4229a9b241..0413dddaa7584 100644
--- a/misc/ssfilter.y
+++ b/misc/ssfilter.y
@@ -42,24 +42,22 @@ static void yyerror(char *s)
%nonassoc '!'
%%
-applet: null exprlist
+applet: exprlist
{
- *yy_ret = $2;
- $$ = $2;
+ *yy_ret = $1;
+ $$ = $1;
}
| null
;
+
null: /* NOTHING */ { $$ = NULL; }
;
+
exprlist: expr
| '!' expr
{
$$ = alloc_node(SSF_NOT, $2);
}
- | '(' exprlist ')'
- {
- $$ = $2;
- }
| exprlist '|' expr
{
$$ = alloc_node(SSF_OR, $1);
@@ -77,13 +75,21 @@ exprlist: expr
}
;
-expr: DCOND HOSTCOND
+eq: '='
+ | /* nothing */
+ ;
+
+expr: '(' exprlist ')'
+ {
+ $$ = $2;
+ }
+ | DCOND eq HOSTCOND
{
- $$ = alloc_node(SSF_DCOND, $2);
+ $$ = alloc_node(SSF_DCOND, $3);
}
- | SCOND HOSTCOND
+ | SCOND eq HOSTCOND
{
- $$ = alloc_node(SSF_SCOND, $2);
+ $$ = alloc_node(SSF_SCOND, $3);
}
| DPORT GEQ HOSTCOND
{
@@ -101,7 +107,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_D_GE, $3));
}
- | DPORT '=' HOSTCOND
+ | DPORT eq HOSTCOND
{
$$ = alloc_node(SSF_DCOND, $3);
}
@@ -126,7 +132,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_S_GE, $3));
}
- | SPORT '=' HOSTCOND
+ | SPORT eq HOSTCOND
{
$$ = alloc_node(SSF_SCOND, $3);
}
@@ -134,7 +140,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_SCOND, $3));
}
- | DEVNAME '=' DEVCOND
+ | DEVNAME eq DEVCOND
{
$$ = alloc_node(SSF_DEVCOND, $3);
}
@@ -142,7 +148,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_DEVCOND, $3));
}
- | FWMARK '=' MARKMASK
+ | FWMARK eq MARKMASK
{
$$ = alloc_node(SSF_MARKMASK, $3);
}
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 2/3] testsuite: Prepare for ss tests
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
This merges the shared bits from ts_tc() and ts_ip() into a common
function for being wrapped by the first ones and adds a third ts_ss()
for testing ss commands.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/Makefile | 2 +-
testsuite/lib/generic.sh | 37 ++++++++++++++-----------------------
2 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 2a54e5c845e65..8fcbc557ff9a7 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -65,7 +65,7 @@ endif
TMP_ERR=`mktemp /tmp/tc_testsuite.XXXXXX`; \
TMP_OUT=`mktemp /tmp/tc_testsuite.XXXXXX`; \
STD_ERR="$$TMP_ERR" STD_OUT="$$TMP_OUT" \
- TC="$$i/tc/tc" IP="$$i/ip/ip" DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
+ TC="$$i/tc/tc" IP="$$i/ip/ip" SS=$$i/misc/ss DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
ERRF="$(RESULTS_DIR)/$@.$$o.err" $(KENV) $(PREFIX) tests/$@ > $(RESULTS_DIR)/$@.$$o.out; \
if [ "$$?" = "127" ]; then \
echo "SKIPPED"; \
diff --git a/testsuite/lib/generic.sh b/testsuite/lib/generic.sh
index 8cef20fa1b280..f92260fc40cf3 100644
--- a/testsuite/lib/generic.sh
+++ b/testsuite/lib/generic.sh
@@ -26,16 +26,17 @@ ts_skip()
exit 127
}
-ts_tc()
+__ts_cmd()
{
+ CMD=$1; shift
SCRIPT=$1; shift
DESC=$1; shift
- $TC $@ 2> $STD_ERR > $STD_OUT
+ $CMD $@ 2> $STD_ERR > $STD_OUT
if [ -s $STD_ERR ]; then
ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $TC $@"
+ ts_err "command: $CMD $@"
ts_err "stderr output:"
ts_err_cat $STD_ERR
if [ -s $STD_OUT ]; then
@@ -50,29 +51,19 @@ ts_tc()
fi
}
-ts_ip()
+ts_tc()
{
- SCRIPT=$1; shift
- DESC=$1; shift
+ __ts_cmd "$TC" "$@"
+}
- $IP $@ 2> $STD_ERR > $STD_OUT
- RET=$?
+ts_ip()
+{
+ __ts_cmd "$IP" "$@"
+}
- if [ -s $STD_ERR ] || [ "$RET" != "0" ]; then
- ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $IP $@"
- ts_err "stderr output:"
- ts_err_cat $STD_ERR
- if [ -s $STD_OUT ]; then
- ts_err "stdout output:"
- ts_err_cat $STD_OUT
- fi
- elif [ -s $STD_OUT ]; then
- echo "${SCRIPT}: ${DESC} succeeded with output:"
- cat $STD_OUT
- else
- echo "${SCRIPT}: ${DESC} succeeded"
- fi
+ts_ss()
+{
+ __ts_cmd "$SS" "$@"
}
ts_qdisc_available()
--
2.18.0
^ permalink raw reply related
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