* [PATCH net-next 4/7] net: hns3: get vf count by pci_sriov_get_totalvfs
From: Lipeng @ 2017-10-23 11:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1508759467-18397-1-git-send-email-lipeng321@huawei.com>
This patch gets vf count by standard function pci_sriov_get_totalvfs,
instead of info from NIC HW.
Signed-off-by: Lipeng <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 ++-
1 file changed, 2 insertions(+), 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 8508521..4431241 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -837,7 +837,6 @@ static int hclge_parse_func_status(struct hclge_dev *hdev,
else
hdev->flag &= ~HCLGE_FLAG_MAIN;
- hdev->num_req_vfs = status->vf_num / status->pf_num;
return 0;
}
@@ -4361,6 +4360,8 @@ static int hclge_pci_init(struct hclge_dev *hdev)
goto err_clr_master;
}
+ hdev->num_req_vfs = pci_sriov_get_totalvfs(pdev);
+
return 0;
err_clr_master:
pci_clear_master(pdev);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 5/7] net: hns3: fix the TX/RX ring.queue_index in hns3_ring_get_cfg
From: Lipeng @ 2017-10-23 11:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1508759467-18397-1-git-send-email-lipeng321@huawei.com>
The interface hns3_ring_get_cfg only update TX ring queue_index,
but do not update RX ring queue_index. This patch fixes it.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index 58aa2dd..14de0f7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -2506,16 +2506,16 @@ static int hns3_ring_get_cfg(struct hnae3_queue *q, struct hns3_nic_priv *priv,
if (ring_type == HNAE3_RING_TYPE_TX) {
ring_data[q->tqp_index].ring = ring;
+ ring_data[q->tqp_index].queue_index = q->tqp_index;
ring->io_base = (u8 __iomem *)q->io_base + HNS3_TX_REG_OFFSET;
} else {
ring_data[q->tqp_index + queue_num].ring = ring;
+ ring_data[q->tqp_index + queue_num].queue_index = q->tqp_index;
ring->io_base = q->io_base;
}
hnae_set_bit(ring->flag, HNAE3_RING_TYPE_B, ring_type);
- ring_data[q->tqp_index].queue_index = q->tqp_index;
-
ring->tqp = q;
ring->desc = NULL;
ring->desc_cb = NULL;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 6/7] net: hns3: remove redundant memset when alloc buffer
From: Lipeng @ 2017-10-23 11:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1508759467-18397-1-git-send-email-lipeng321@huawei.com>
HW will use packet length to write packets to buffer or read
packets from buffer. There is a redundant memset when alloc buffer,
the memset have no sense and will increase time-consuming.
This patch removes it.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index 14de0f7..06af3c8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1444,8 +1444,6 @@ static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
cb->length = hnae_page_size(ring);
cb->type = DESC_TYPE_PAGE;
- memset(cb->buf, 0, cb->length);
-
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 7/7] net: hns3: fix a bug about hns3_clean_tx_ring
From: Lipeng @ 2017-10-23 11:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1508759467-18397-1-git-send-email-lipeng321@huawei.com>
The return value of hns3_clean_tx_ring means tx ring clean result.
Return true means clean complete and there is no more pakcet need
clean. Retrun false means there is packets need clean and napi need
poll again. The last return of hns3_clean_tx_ring is
"return !!budget" as budget will decrease when clean a buffer.
If there is no valid BD in TX ring, return 0 for hns3_clean_tx_ring
will cause napi poll again and never complete the napi poll. This
patch fixes the bug.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 6 +++---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index 06af3c8..537f6c3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1629,7 +1629,7 @@ static int is_valid_clean_head(struct hns3_enet_ring *ring, int h)
return u > c ? (h > c && h <= u) : (h > c || h <= u);
}
-int hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget)
+bool hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget)
{
struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
struct netdev_queue *dev_queue;
@@ -1640,7 +1640,7 @@ int hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget)
rmb(); /* Make sure head is ready before touch any data */
if (is_ring_empty(ring) || head == ring->next_to_clean)
- return 0; /* no data to poll */
+ return true; /* no data to poll */
if (!is_valid_clean_head(ring, head)) {
netdev_err(netdev, "wrong head (%d, %d-%d)\n", head,
@@ -1649,7 +1649,7 @@ int hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget)
u64_stats_update_begin(&ring->syncp);
ring->stats.io_err_cnt++;
u64_stats_update_end(&ring->syncp);
- return -EIO;
+ return true;
}
bytes = 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
index 6228b26..58dc30b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
@@ -594,7 +594,7 @@ static inline void hns3_write_reg(void __iomem *base, u32 reg, u32 value)
void hns3_ethtool_set_ops(struct net_device *netdev);
-int hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget);
+bool hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget);
int hns3_init_all_ring(struct hns3_nic_priv *priv);
int hns3_uninit_all_ring(struct hns3_nic_priv *priv);
netdev_tx_t hns3_nic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] cxgb4vf: Fix netdev_features flag
From: David Miller @ 2017-10-23 12:13 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun
In-Reply-To: <1508753010-10643-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Mon, 23 Oct 2017 15:33:30 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> GRO is not supported by Chelsio HW when rx_csum is disabled.
> Update the netdev features flag when rx_csum is modified.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
This doesn't even compile:
CC [M] drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:2765:26: error: redefinition of ‘cxgb4vf_fix_features’
static netdev_features_t cxgb4vf_fix_features(struct net_device *dev,
^~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:1114:26: note: previous definition of ‘cxgb4vf_fix_features’ was here
static netdev_features_t cxgb4vf_fix_features(struct net_device *dev,
^~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:1114:26: warning: ‘cxgb4vf_fix_features’ defined but not used [-Wunused-function]
scripts/Makefile.build:313: recipe for target 'drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o' failed
make[1]: *** [drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o] Error 1
Makefile:1653: recipe for target 'drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o' failed
make: *** [drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o] Error 2
^ permalink raw reply
* Re: [iproute PATCH] ss: Distinguish between IPv4 and IPv6 wildcard sockets
From: Stephen Hemminger @ 2017-10-23 12:41 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev, Humberto Alves, Eric Dumazet
In-Reply-To: <20171018175813.5387-1-phil@nwl.cc>
On Wed, 18 Oct 2017 19:58:13 +0200
Phil Sutter <phil@nwl.cc> wrote:
> Commit aba9c23a6e1cb ("ss: enclose IPv6 address in brackets") unified
> display of wildcard sockets in IPv4 and IPv6 to print the unspecified
> address as '*'. Users then complained that they can't distinguish
> between address families anymore, so change this again to what Stephen
> Hemminger suggested:
>
> | *:80 << both IPV6 and IPV4
> | [::]:80 << IPV6_ONLY
> | 0.0.0.0:80 << IPV4_ONLY
>
> Note that on older kernels which don't support INET_DIAG_SKV6ONLY
> attribute, pure IPv6 sockets will still show as '*'.
>
> Cc: Humberto Alves <hjalves@live.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Applied both.
^ permalink raw reply
* Re: [PATCH iproute2] ip maddr: fix filtering by device
From: Stephen Hemminger @ 2017-10-23 12:42 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Petr Vorel, Phil Sutter
In-Reply-To: <20171019082108.40D7AA0EDF@unicorn.suse.cz>
On Thu, 19 Oct 2017 10:21:08 +0200 (CEST)
Michal Kubecek <mkubecek@suse.cz> wrote:
> Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses
> variable len to keep trailing colon from interface name comparison. This
> variable is local to loop body but we set it in one pass and use it in
> following one(s) so that we are actually using (pseudo)random length for
> comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: Avoid
> accessing uninitialized data") always initializes len to zero so that the
> name comparison is always true. As a result, "ip maddr show dev eth0" shows
> IPv4 multicast addresses for all interfaces.
>
> Instead of keeping the length, let's simply replace the trailing colon with
> a null byte. The bonus is that we get correct interface name in ma.name.
>
> Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Applied
^ permalink raw reply
* Re: [PATCH iproute2 1/1] ss: initialize 'fackets' member of tcpstat structure
From: Stephen Hemminger @ 2017-10-23 12:44 UTC (permalink / raw)
To: Roman Mashak; +Cc: jhs, netdev
In-Reply-To: <1508355841-24131-1-git-send-email-mrv@mojatatu.com>
On Wed, 18 Oct 2017 15:44:01 -0400
Roman Mashak <mrv@mojatatu.com> wrote:
> 'fackets' has never been initialized with kernel extracted information, thus
> never really printed.
>
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Applied. Thanks
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ip: bridge_slave: add neigh_suppress to the type help and man pages
From: Stephen Hemminger @ 2017-10-23 12:48 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa
In-Reply-To: <1508245886-24603-1-git-send-email-nikolay@cumulusnetworks.com>
On Tue, 17 Oct 2017 16:11:26 +0300
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> Add neigh_suppress to the type help and document it in ip-link's man page.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, to net-next.
^ permalink raw reply
* Re: [RFC net-next] net: dsa: lan9303 Cpu port and ARL
From: Andrew Lunn @ 2017-10-23 12:58 UTC (permalink / raw)
To: Egil Hjelmeland; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <20171023113506.13600-1-privat@egil-hjelmeland.no>
> However, if some other (virtual) interface is added to the SW bridge, we still
> have the same problem. So I suspect that you want to see something like the
> following:
Yes, it would be good to have dynamic learning of MAC addresses on the
CPU port.
> ---
> net/dsa/tag_lan9303.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/net/dsa/tag_lan9303.c b/net/dsa/tag_lan9303.c
> index 57519597c6fc..1003fd91755c 100644
> --- a/net/dsa/tag_lan9303.c
> +++ b/net/dsa/tag_lan9303.c
> @@ -16,6 +16,7 @@
> #include <linux/slab.h>
>
> #include "dsa_priv.h"
> +#include "../../drivers/net/dsa/lan9303.h"
Don't do that. Export the needed parts in an include file in
include/linux.
Otherwise, i think your approach is O.K.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] cxgb4vf: Fix netdev_features flag
From: kbuild test robot @ 2017-10-23 13:08 UTC (permalink / raw)
To: Ganesh Goudar
Cc: kbuild-all, netdev, davem, nirranjan, indranil, venkatesh,
Arjun Vynipadath, Ganesh Goudar
In-Reply-To: <1508753010-10643-1-git-send-email-ganeshgr@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Hi Arjun,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Ganesh-Goudar/cxgb4vf-Fix-netdev_features-flag/20171023-201033
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:2765:26: error: redefinition of 'cxgb4vf_fix_features'
static netdev_features_t cxgb4vf_fix_features(struct net_device *dev,
^
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:1114:26: note: previous definition of 'cxgb4vf_fix_features' was here
static netdev_features_t cxgb4vf_fix_features(struct net_device *dev,
^
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:1114:26: warning: 'cxgb4vf_fix_features' defined but not used [-Wunused-function]
vim +/cxgb4vf_fix_features +2765 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
2764
> 2765 static netdev_features_t cxgb4vf_fix_features(struct net_device *dev,
2766 netdev_features_t features)
2767 {
2768 /* Disable GRO, if RX_CSUM is disabled */
2769 if (!(features & NETIF_F_RXCSUM))
2770 features &= ~NETIF_F_GRO;
2771
2772 return features;
2773 }
2774
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51684 bytes --]
^ permalink raw reply
* [PATCH net 1/3] net: mvpp2: fix TSO headers allocation and management
From: Antoine Tenart @ 2017-10-23 13:24 UTC (permalink / raw)
To: davem
Cc: Yan Markman, andrew, gregory.clement, thomas.petazzoni,
miquel.raynal, nadavh, linux-kernel, mw, stefanc, netdev,
Antoine Tenart
From: Yan Markman <ymarkman@marvell.com>
TSO headers are managed with txq index and therefore should be aligned
with the txq size, not with the aggregated txq size.
Fixes: 186cd4d4e414 ("net: mvpp2: software tso support")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yan Markman <ymarkman@marvell.com>
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 1a540c88c974..2898ac70b826 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5609,7 +5609,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
txq_pcpu->tso_headers =
dma_alloc_coherent(port->dev->dev.parent,
- MVPP2_AGGR_TXQ_SIZE * TSO_HEADER_SIZE,
+ txq_pcpu->size * TSO_HEADER_SIZE,
&txq_pcpu->tso_headers_dma,
GFP_KERNEL);
if (!txq_pcpu->tso_headers)
@@ -5623,7 +5623,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
kfree(txq_pcpu->buffs);
dma_free_coherent(port->dev->dev.parent,
- MVPP2_AGGR_TXQ_SIZE * MVPP2_DESC_ALIGNED_SIZE,
+ txq_pcpu->size * TSO_HEADER_SIZE,
txq_pcpu->tso_headers,
txq_pcpu->tso_headers_dma);
}
@@ -5647,7 +5647,7 @@ static void mvpp2_txq_deinit(struct mvpp2_port *port,
kfree(txq_pcpu->buffs);
dma_free_coherent(port->dev->dev.parent,
- MVPP2_AGGR_TXQ_SIZE * MVPP2_DESC_ALIGNED_SIZE,
+ txq_pcpu->size * TSO_HEADER_SIZE,
txq_pcpu->tso_headers,
txq_pcpu->tso_headers_dma);
}
--
2.14.2
^ permalink raw reply related
* [PATCH net 2/3] net: mvpp2: do not unmap TSO headers buffers
From: Antoine Tenart @ 2017-10-23 13:24 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, andrew, gregory.clement, thomas.petazzoni,
miquel.raynal, nadavh, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20171023132431.5756-1-antoine.tenart@free-electrons.com>
The TSO header buffers are coming from a per cpu pool and should not
be unmapped as they are reused. The PPv2 driver was unmapping all
descriptors buffers unconditionally. This patch fixes this by checking
the buffers dma addresses before unmapping them, and by not unmapping
those who are located in the TSO header pool.
Fixes: 186cd4d4e414 ("net: mvpp2: software tso support")
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 2898ac70b826..037f26dfe31c 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -1167,6 +1167,11 @@ struct mvpp2_bm_pool {
u32 port_map;
};
+#define IS_TSO_HEADER(txq_pcpu, addr) \
+ ((addr) >= (txq_pcpu)->tso_headers_dma && \
+ (addr) < (txq_pcpu)->tso_headers_dma + \
+ (txq_pcpu)->size * TSO_HEADER_SIZE)
+
/* Queue modes */
#define MVPP2_QDIST_SINGLE_MODE 0
#define MVPP2_QDIST_MULTI_MODE 1
@@ -5321,8 +5326,9 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
struct mvpp2_txq_pcpu_buf *tx_buf =
txq_pcpu->buffs + txq_pcpu->txq_get_index;
- dma_unmap_single(port->dev->dev.parent, tx_buf->dma,
- tx_buf->size, DMA_TO_DEVICE);
+ if (!IS_TSO_HEADER(txq_pcpu, tx_buf->dma))
+ dma_unmap_single(port->dev->dev.parent, tx_buf->dma,
+ tx_buf->size, DMA_TO_DEVICE);
if (tx_buf->skb)
dev_kfree_skb_any(tx_buf->skb);
@@ -6212,12 +6218,15 @@ static inline void
tx_desc_unmap_put(struct mvpp2_port *port, struct mvpp2_tx_queue *txq,
struct mvpp2_tx_desc *desc)
{
+ struct mvpp2_txq_pcpu *txq_pcpu = this_cpu_ptr(txq->pcpu);
+
dma_addr_t buf_dma_addr =
mvpp2_txdesc_dma_addr_get(port, desc);
size_t buf_sz =
mvpp2_txdesc_size_get(port, desc);
- dma_unmap_single(port->dev->dev.parent, buf_dma_addr,
- buf_sz, DMA_TO_DEVICE);
+ if (!IS_TSO_HEADER(txq_pcpu, buf_dma_addr))
+ dma_unmap_single(port->dev->dev.parent, buf_dma_addr,
+ buf_sz, DMA_TO_DEVICE);
mvpp2_txq_desc_put(txq);
}
--
2.14.2
^ permalink raw reply related
* [PATCH net 3/3] net: mvpp2: do not call txq_done from the Tx path when Tx irqs are used
From: Antoine Tenart @ 2017-10-23 13:24 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, andrew, gregory.clement, thomas.petazzoni,
miquel.raynal, nadavh, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20171023132431.5756-1-antoine.tenart@free-electrons.com>
When Tx IRQs are used, txq_bufs_free() can be called from both the Tx
path and from NAPI poll(). This led to CPU stalls as if these two tasks
(Tx and Poll) are scheduled on two CPUs at the same time, DMA unmapping
operations are done on the same txq buffers.
This patch adds a check not to call txq_done() from the Tx path if Tx
interrupts are used as it does not make sense to do so.
Fixes: edc660fa09e2 ("net: mvpp2: replace TX coalescing interrupts with hrtimer")
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 037f26dfe31c..60b4f3d995af 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6499,7 +6499,7 @@ static int mvpp2_tx(struct sk_buff *skb, struct net_device *dev)
}
/* Finalize TX processing */
- if (txq_pcpu->count >= txq->done_pkts_coal)
+ if (!port->has_tx_irqs && txq_pcpu->count >= txq->done_pkts_coal)
mvpp2_txq_done(port, txq, txq_pcpu);
/* Set the timer in case not all frags were processed */
--
2.14.2
^ permalink raw reply related
* Re: Regression in throughput between kvm guests over virtual bridge
From: Wei Xu @ 2017-10-23 13:57 UTC (permalink / raw)
To: Matthew Rosato; +Cc: Jason Wang, netdev, davem, mst
In-Reply-To: <c0b42b27-56f6-c2f9-9476-28d25678808a@linux.vnet.ibm.com>
On Wed, Oct 18, 2017 at 04:17:51PM -0400, Matthew Rosato wrote:
> On 10/12/2017 02:31 PM, Wei Xu wrote:
> > On Thu, Oct 05, 2017 at 04:07:45PM -0400, Matthew Rosato wrote:
> >>
> >> Ping... Jason, any other ideas or suggestions?
> >
> > Hi Matthew,
> > Recently I am doing similar test on x86 for this patch, here are some,
> > differences between our testbeds.
> >
> > 1. It is nice you have got improvement with 50+ instances(or connections here?)
> > which would be quite helpful to address the issue, also you've figured out the
> > cost(wait/wakeup), kindly reminder did you pin uperf client/server along the whole
> > path besides vhost and vcpu threads?
>
> Was not previously doing any pinning whatsoever, just reproducing an
> environment that one of our testers here was running. Reducing guest
> vcpu count from 4->1, still see the regression. Then, pinned each vcpu
> thread and vhost thread to a separate host CPU -- still made no
> difference (regression still present).
>
> >
> > 2. It might be useful to short the traffic path as a reference, What I am running
> > is briefly like:
> > pktgen(host kernel) -> tap(x) -> guest(DPDK testpmd)
> >
> > The bridge driver(br_forward(), etc) might impact performance due to my personal
> > experience, so eventually I settled down with this simplified testbed which fully
> > isolates the traffic from both userspace and host kernel stack(1 and 50 instances,
> > bridge driver, etc), therefore reduces potential interferences.
> >
> > The down side of this is that it needs DPDK support in guest, has this ever be
> > run on s390x guest? An alternative approach is to directly run XDP drop on
> > virtio-net nic in guest, while this requires compiling XDP inside guest which needs
> > a newer distro(Fedora 25+ in my case or Ubuntu 16.10, not sure).
> >
>
> I made an attempt at DPDK, but it has not been run on s390x as far as
> I'm aware and didn't seem trivial to get working.
>
> So instead I took your alternate suggestion & did:
> pktgen(host) -> tap(x) -> guest(xdp_drop)
It is really nice of you for having tried this, I also tried this on x86 with
two ubuntu 16.04 guests, but unfortunately I couldn't reproduce it as well,
but I did get lower throughput with 50 instances than one instance(1-4 vcpus),
is this the same on s390x?
>
> When running this setup, I am not able to reproduce the regression. As
> mentioned previously, I am also unable to reproduce when running one end
> of the uperf connection from the host - I have only ever been able to
> reproduce when both ends of the uperf connection are running within a guest.
Did you see improvement when running uperf from the host if no regression?
It would be pretty nice to run pktgen from the VM as Jason suggested in another
mail(pktgen(vm1) -> tap1 -> bridge -> tap2 -> vm2), this is super close to your
original test case and can help to determine if we can get some clue with tcp or
bridge driver.
Also I am interested in your hardware platform, how many NUMA nodes do you have?
what about your binding(vcpu/vhost/pktgen). For my case, I got a server with 4
NUMA nodes and 12 cpus for each sockets, and I am explicitly launching qemu from
cpu0, then bind vhost(Rx/Tx) to cpu 2&3, and vcpus start from cpu 4(3 vcpus for
each).
>
> > 3. BTW, did you enable hugepage for your guest? It would performance more
> > or less depends on the memory demand when generating traffic, I didn't see
> > similar command lines in yours.
> >
>
> s390x does not currently support passing through hugetlb backing via
> QEMU mem-path.
Okay, thanks for sharing this.
Wei
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] devlink: Add permanent config parameter get/set operations
From: Steve Lin @ 2017-10-23 14:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Netdev List, Jiri Pirko, David S . Miller, Michael Chan,
John Linville, Andy Gospodarek
In-Reply-To: <20171021092421.GB1948@nanopsycho.orion>
On Sat, Oct 21, 2017 at 5:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Oct 20, 2017 at 05:13:39PM CEST, steven.lin1@broadcom.com wrote:
>>On Fri, Oct 20, 2017 at 10:39 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Thu, Oct 19, 2017 at 09:17:05PM CEST, steven.lin1@broadcom.com wrote:
>>>>Add support for permanent config parameter get/set commands. Used
>>>>for parameters held in NVRAM, persistent device configuration.
>>>>
>>>>Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
>>>>Acked-by: Andy Gospodarek <gospo@broadcom.com>
>>>>---
>>>> include/net/devlink.h | 3 +
>>>> include/uapi/linux/devlink.h | 11 ++
>>>> net/core/devlink.c | 234 +++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 248 insertions(+)
>>>>
>>>>diff --git a/include/net/devlink.h b/include/net/devlink.h
>>>>index b9654e1..bd64623 100644
>>>>--- a/include/net/devlink.h
>>>>+++ b/include/net/devlink.h
>>>>@@ -270,6 +270,9 @@ struct devlink_ops {
>>>> int (*eswitch_inline_mode_set)(struct devlink *devlink, u8 inline_mode);
>>>> int (*eswitch_encap_mode_get)(struct devlink *devlink, u8 *p_encap_mode);
>>>> int (*eswitch_encap_mode_set)(struct devlink *devlink, u8 encap_mode);
>>>>+ int (*perm_config_get)(struct devlink *devlink, u32 param, u32 *value);
>>>>+ int (*perm_config_set)(struct devlink *devlink, u32 param, u32 value,
>>>
>>> Please use enum instead of "u32 param". Also, what would happen if the
>>> value is >u32, like string for example? I believe we need to take it into
>>> the consideration for the UAPI sake.
>>>
>>>
>>
>>Using enum instead of u32 param: ok, will do in v3, thanks.
>>
>>Value > u32: In the RFC and v1 versions of the patch, each parameter
>>was its own attribute, so could have its own type (u32, string,
>>whatever). In v2, trying to move to nested parameters w/ parameter
>>being an enum, as requested, it seems to mean that the parameter value
>>now must be defined as a specific type, so I went with u32.
>
> Why? I have to be missing something. In the nest all is same as outside
> of the nest.
>
> Also, please see team_nl_cmd_options_set() where something similar is
> done, for multiple option types.
>
>
Okay, I can implement similar to that driver. In the current
devlink.c/devlink.h, all attributes have specific types, and aren't
dynamic types like the "data" attribute in the team driver, so I had
thought having specific types defined for each attribute was required
in devlink.
^ permalink raw reply
* Re: [PATCH net-next v2 5/6] devlink: Adding num MSI-X vectors per VF NVRAM config param
From: Steve Lin @ 2017-10-23 14:20 UTC (permalink / raw)
To: Yuval Mintz
Cc: Jiri Pirko, netdev@vger.kernel.org, Jiri Pirko,
davem@davemloft.net, michael.chan@broadcom.com,
linville@tuxdriver.com, gospo@broadcom.com
In-Reply-To: <AM0PR0502MB368337378712D3A48EDEF6C8BF400@AM0PR0502MB3683.eurprd05.prod.outlook.com>
On Sat, Oct 21, 2017 at 9:59 AM, Yuval Mintz <yuvalm@mellanox.com> wrote:
>> On Fri, Oct 20, 2017 at 10:10 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> > Fri, Oct 20, 2017 at 04:03:55PM CEST, steven.lin1@broadcom.com wrote:
>> >>On Thu, Oct 19, 2017 at 5:39 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> >>> Thu, Oct 19, 2017 at 10:32:21PM CEST, yuvalm@mellanox.com wrote:
>> >>>>> Adding DEVLINK_PERM_CONFIG_MSIX_VECTORS_PER_VF
>> permanent
>> >>>>> config
>> >>>>> parameter. Defines number of MSI-X vectors allocated per VF.
>> >>>>> Value is permanent (stored in NVRAM), so becomes the new default
>> >>>>> value for this device.
>> >>>>
>> >>>>Sounds like you're having this enforce the same configuration for all
>> child VFs.
>> >>>
>> >>> Yeah, this sounds like per-port config.
>> >>>
>> >>
>> >>Well, it gets a little tricky here. I assume some cards handle this
>> >>per-port. Other cards might handle this per PF, where PF may not
>> >>always correspond 1:1 with a port. And some cards maybe just allow a
>> >>single value for this parameter for the entire card, covering all
>> >>ports/PFs.
>> >>
>> >>To keep things simple and as general as possible, it made sense to set
>> >>all parameters on a per-PCI device level. As I mentioned in my
>> >>cover-letter, the devices most likely to use these proposed commands
>> >>do not have a single "whole asic" PCI b/d/f with internal mechanism
>> >>for accessing ports - most expose each port (and each function on each
>> >>port) as a separate PCI b/d/f, with no separate "whole asic" PCI
>> >>b/d/f. That's how the BCM cards work, and I think that's how the MLNX
>> >>cards work, and others that would be likely to use these cmds.
>> >>
>> >>So, to summarize, you direct the command to the PCI b/d/f you want to
>> >>target. Does this make sense?
>> >
>> > So you plan to have 1 devlink instance for each vf? Not sure that
>> > does sound right to me :/
>> >
>>
>> For the commands proposed in this patchset, AFAIK they all apply on a
>> per-PF or broader, i.e. per-port or whole-card, granularity, since
>> they affect permanent config that applies at boot-up. So, no, the VFs
>> don't really come into play here.
>
> Regardless of whether you're planning on having VFs as devlink instances,
> the actual attribute question remains -
> you're proposing an attribute that forces all VFs to have the same value.
> This probably suits your PCI core limitations but other vendors might have
> a different capability set, and accepting this design limitation now would
> muck all future extension attempts of such attributes.
>
> I think VF configurations should be planned in advance for supporting a
> per-VF Configuration whenever it's possible - even if not required [/possible]
> by the one pushing the new attribute.
>
The commands being added in this patch are for permanent (i.e. NVRAM)
config - essentially setting the new default values for various
features of the device at boot-up. At that initialization time, no
VFs are yet instantiated.
So my perspective was, in general (not just for our specific device /
design), it doesn't seem like permanent config parameters would be set
on individual VFs. That was what my previous comment was trying to
convey.
If that assumption is wrong, though, and there is some device that has
NVRAM config that is set per-VF, I assume the user would instantiate
the VF and then call the devlink API on the pci device corresponding
to the VF they with to affect, and I think the model proposed still
works.
Are you suggesting adding a mechanism to set NVRAM parameters on a
per-VF basis, without instantiating the VF first? I would prefer not
adding such a mechanism unless/until there's a use case for it.
^ permalink raw reply
* problem with rtnetlink 'reference' count
From: Peter Zijlstra @ 2017-10-23 14:25 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev
Hi,
I just ran across commit:
019a316992ee ("rtnetlink: add reference counting to prevent module unload while dump is in progress")
And that commit is _completely_ broken.
1) it not in fact a refcount, so using refcount_t is silly
2) there is a distinct lack of memory barriers, so we can easily
observe the decrement while the msg_handler is still in progress.
3) waiting with a schedule()/yield() loop is complete crap and subject
life-locks, imagine doing that rtnl_unregister_all() from a RT task.
Please fix..
^ permalink raw reply
* Re: [RFC net-next] net: dsa: lan9303 Cpu port and ARL
From: Egil Hjelmeland @ 2017-10-23 14:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <20171023125849.GE6740@lunn.ch>
Thanks for the response, Andrew!
On 23. okt. 2017 14:58, Andrew Lunn wrote:
>> #include "dsa_priv.h"
>> +#include "../../drivers/net/dsa/lan9303.h"
>
> Don't do that. Export the needed parts in an include file in
> include/linux.
>
Do you mean moving struct definitions from drivers/net/dsa/lan9303.h to
a include/linux/lan9303.h? That would be like 80% of
drivers/net/dsa/lan9303.h. I am a bit surprised that is deemed better
than the slightly ugly include.
Or do you have other suggestions?
One possibility could be to have lan9303_tx_use_arl() in
drivers/net/dsa/lan9303-core.c. But it has to be exported, and can
not be inlined.
It is also possible to replace the chip->is_bridged term with:
struct dsa_switch *ds = dp->ds;
if (!dsa_to_port(ds, 1)->bridge_dev)
return false;
if (dsa_to_port(ds, 1)->bridge_dev != dsa_to_port(ds,2)->bridge_dev)
return false;
But it feels silly to duplicate that calculation in the data path.
> Otherwise, i think your approach is O.K.
>
> Andrew
>
Egil
^ permalink raw reply
* RE: [PATCH net-next v2 5/6] devlink: Adding num MSI-X vectors per VF NVRAM config param
From: Yuval Mintz @ 2017-10-23 14:37 UTC (permalink / raw)
To: Steve Lin
Cc: Jiri Pirko, netdev@vger.kernel.org, Jiri Pirko,
davem@davemloft.net, michael.chan@broadcom.com,
linville@tuxdriver.com, gospo@broadcom.com
In-Reply-To: <CA+Jmh7H3QD4W6OrVwny7CXVppGZ4R6GeTh30Sm9sTikk7560dQ@mail.gmail.com>
> >> On Fri, Oct 20, 2017 at 10:10 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >> > Fri, Oct 20, 2017 at 04:03:55PM CEST, steven.lin1@broadcom.com wrote:
> >> >>On Thu, Oct 19, 2017 at 5:39 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> >> >>> Thu, Oct 19, 2017 at 10:32:21PM CEST, yuvalm@mellanox.com wrote:
> >> >>>>> Adding DEVLINK_PERM_CONFIG_MSIX_VECTORS_PER_VF
> >> permanent
> >> >>>>> config
> >> >>>>> parameter. Defines number of MSI-X vectors allocated per VF.
> >> >>>>> Value is permanent (stored in NVRAM), so becomes the new
> default
> >> >>>>> value for this device.
> >> >>>>
> >> >>>>Sounds like you're having this enforce the same configuration for all
> >> child VFs.
> >> >>>
> >> >>> Yeah, this sounds like per-port config.
> >> >>>
> >> >>
> >> >>Well, it gets a little tricky here. I assume some cards handle this
> >> >>per-port. Other cards might handle this per PF, where PF may not
> >> >>always correspond 1:1 with a port. And some cards maybe just allow a
> >> >>single value for this parameter for the entire card, covering all
> >> >>ports/PFs.
> >> >>
> >> >>To keep things simple and as general as possible, it made sense to set
> >> >>all parameters on a per-PCI device level. As I mentioned in my
> >> >>cover-letter, the devices most likely to use these proposed commands
> >> >>do not have a single "whole asic" PCI b/d/f with internal mechanism
> >> >>for accessing ports - most expose each port (and each function on each
> >> >>port) as a separate PCI b/d/f, with no separate "whole asic" PCI
> >> >>b/d/f. That's how the BCM cards work, and I think that's how the
> MLNX
> >> >>cards work, and others that would be likely to use these cmds.
> >> >>
> >> >>So, to summarize, you direct the command to the PCI b/d/f you want
> to
> >> >>target. Does this make sense?
> >> >
> >> > So you plan to have 1 devlink instance for each vf? Not sure that
> >> > does sound right to me :/
> >> >
> >>
> >> For the commands proposed in this patchset, AFAIK they all apply on a
> >> per-PF or broader, i.e. per-port or whole-card, granularity, since
> >> they affect permanent config that applies at boot-up. So, no, the VFs
> >> don't really come into play here.
> >
> > Regardless of whether you're planning on having VFs as devlink instances,
> > the actual attribute question remains -
> > you're proposing an attribute that forces all VFs to have the same value.
> > This probably suits your PCI core limitations but other vendors might have
> > a different capability set, and accepting this design limitation now would
> > muck all future extension attempts of such attributes.
> >
> > I think VF configurations should be planned in advance for supporting a
> > per-VF Configuration whenever it's possible - even if not required
> [/possible]
> > by the one pushing the new attribute.
> >
>
> The commands being added in this patch are for permanent (i.e. NVRAM)
> config - essentially setting the new default values for various
> features of the device at boot-up. At that initialization time, no
> VFs are yet instantiated.
>
> So my perspective was, in general (not just for our specific device /
> design), it doesn't seem like permanent config parameters would be set
> on individual VFs. That was what my previous comment was trying to
> convey.
That's an odd assumption; Why should you assume there's some device
that allows configuring persistent behavior for all VFs but think no other
would set the same on a per-VF basis?
> If that assumption is wrong, though, and there is some device that has
> NVRAM config that is set per-VF, I assume the user would instantiate
> the VF and then call the devlink API on the pci device corresponding
> to the VF they with to affect, and I think the model proposed still
> works.
What would be the purpose of re-configuring a value reflected in the
PCI device for an already instantiated VF?
> Are you suggesting adding a mechanism to set NVRAM parameters on a
> per-VF basis, without instantiating the VF first? I would prefer not
> adding such a mechanism unless/until there's a use case for it.
The thing is that you're suggesting a new UAPI; We don't have the leisure
of pushing a partial implementation and changing it later on.
^ permalink raw reply
* Re: [PATCHv2 net-next 3/3] bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
From: kbuild test robot @ 2017-10-23 14:44 UTC (permalink / raw)
To: Xin Long; +Cc: kbuild-all, network dev, davem, Jiri Pirko
In-Reply-To: <21fdc6d360481b9fffdde8686b9c632b3e207b13.1508755319.git.lucien.xin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
Hi Xin,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Xin-Long/bonding-void-calling-rtmsg_ifinfo-for-netlink-notifications/20171023-203332
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "rtmsg_ifinfo" [net/bridge/bridge.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40202 bytes --]
^ permalink raw reply
* Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: David Howells @ 2017-10-23 14:51 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: dhowells, jlee, linux-kernel, jforbes, Daniel Borkmann,
David S. Miller, netdev, Gary Lin
In-Reply-To: <20171020230040.qlz5rnegldcpzzb7@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> If you want to lock down read access you'd need to disable
> not only bpf, but all of kprobe and likey ftrace, since
> untrusted root can infer kernel data by observing function
> execution even if it cannot load modules and bpf progs.
Okay.
David
^ permalink raw reply
* Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: David Howells @ 2017-10-23 14:53 UTC (permalink / raw)
To: jlee
Cc: dhowells, Alexei Starovoitov, linux-security-module, gnomes,
linux-efi, matthew.garrett, gregkh, linux-kernel, jforbes,
Daniel Borkmann, David S. Miller, netdev, Gary Lin
In-Reply-To: <20171020164343.e5mlq7ukskfjmlpp@linux-rasp2>
jlee@suse.com wrote:
> hm... patch 4 only prevents write_mem() but not read_mem().
> Or I missed anything?
Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem
and /dev/kmem by locking down open of /dev/port. So I've moved this bit to
patch 4, simplified and posted a new variant for patch 4.
David
^ permalink raw reply
* [PATCH net] tcp/dccp: fix again lockdep splat in inet_csk_route_req()
From: Eric Dumazet @ 2017-10-23 15:02 UTC (permalink / raw)
To: kernel test robot; +Cc: David Miller, netdev
In-Reply-To: <20171023095634.lednbqrxtbuooqcx@inn>
From: Eric Dumazet <edumazet@google.com>
In my first attempt to fix the lockdep splat, I forgot we could
enter inet_csk_route_req() with a freshly allocated request socket,
for which refcount has not yet been elevated, due to complex
SLAB_TYPESAFE_BY_RCU rules.
We either are in rcu_read_lock() section _or_ we own a refcount on the
request.
Correct RCU verb to use here is rcu_dereference_check(), although it is
not possible to prove we actually own a reference on a shared
refcount :/
[ 49.844590] lockdep_rcu_suspicious+0xea/0xf3
[ 49.846487] inet_csk_route_req+0x53/0x14d
[ 49.848334] tcp_v4_route_req+0xe/0x10
[ 49.850174] tcp_conn_request+0x31c/0x6a0
[ 49.851992] ? __lock_acquire+0x614/0x822
[ 49.854015] tcp_v4_conn_request+0x5a/0x79
[ 49.855957] ? tcp_v4_conn_request+0x5a/0x79
[ 49.858052] tcp_rcv_state_process+0x98/0xdcc
[ 49.859990] ? sk_filter_trim_cap+0x2f6/0x307
[ 49.862085] tcp_v4_do_rcv+0xfc/0x145
[ 49.864055] ? tcp_v4_do_rcv+0xfc/0x145
[ 49.866173] tcp_v4_rcv+0x5ab/0xaf9
[ 49.868029] ip_local_deliver_finish+0x1af/0x2e7
[ 49.870064] ip_local_deliver+0x1b2/0x1c5
[ 49.871775] ? inet_del_offload+0x45/0x45
[ 49.873916] ip_rcv_finish+0x3f7/0x471
[ 49.875476] ip_rcv+0x3f1/0x42f
[ 49.876991] ? ip_local_deliver_finish+0x2e7/0x2e7
[ 49.878791] __netif_receive_skb_core+0x6d3/0x950
[ 49.880701] ? process_backlog+0x7e/0x216
[ 49.882589] __netif_receive_skb+0x1d/0x5e
[ 49.884122] process_backlog+0x10c/0x216
[ 49.885812] net_rx_action+0x147/0x3df
Fixes: a6ca7abe53633 ("tcp/dccp: fix lockdep splat in inet_csk_route_req()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: kernel test robot <fengguang.wu@intel.com>
Reported-by: Maciej Żenczykowski <maze@google.com>
---
net/ipv4/inet_connection_sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 18cd2eae758ff1a9d8a736e143417c7007b99067..08381782830b50cac621c531a4e7e1cf8dc6577f 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -543,8 +543,8 @@ struct dst_entry *inet_csk_route_req(const struct sock *sk,
struct ip_options_rcu *opt;
struct rtable *rt;
- opt = rcu_dereference_protected(ireq->ireq_opt,
- refcount_read(&req->rsk_refcnt) > 0);
+ opt = rcu_dereference_check(ireq->ireq_opt,
+ refcount_read(&req->rsk_refcnt) > 0);
flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
sk->sk_protocol, inet_sk_flowi_flags(sk),
^ permalink raw reply related
* Re: [PATCHv2 net-next 3/3] bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
From: Xin Long @ 2017-10-23 15:15 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, network dev, davem, Jiri Pirko
In-Reply-To: <201710232254.INLL2XLz%fengguang.wu@intel.com>
On Mon, Oct 23, 2017 at 10:44 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Xin,
>
> [auto build test ERROR on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/Xin-Long/bonding-void-calling-rtmsg_ifinfo-for-netlink-notifications/20171023-203332
> config: x86_64-rhel (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "rtmsg_ifinfo" [net/bridge/bridge.ko] undefined!
sorry, didn't notice bridge is still using rtmsg_ifinfo.
rtmsg_ifinfo actually is no need to be called in br_del_if(),
since patch:
dc709f3 rtnetlink: bring NETDEV_CHANGEUPPER event process back in
rtnetlink_event
I will propose another patch to remove this.
for this bonding one, I will post v3 without removing rtmsg_ifinfo
export first.
^ 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