* Re: [PATCH net-next] can: fix build error without CONFIG_PROC_FS
From: Marc Kleine-Budde @ 2017-04-27 14:29 UTC (permalink / raw)
To: Arnd Bergmann, Oliver Hartkopp, David S. Miller
Cc: Thomas Gleixner, Cong Wang, Mario Kicherer, Eric Dumazet,
linux-can, netdev, linux-kernel
In-Reply-To: <20170427142146.3107957-1-arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 1409 bytes --]
Hello Arnd,
On 04/27/2017 04:21 PM, Arnd Bergmann wrote:
> The procfs dir entry was added inside of an #ifdef, causing a build error
> when we try to access it without CONFIG_PROC_FS set:
>
> net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> net/can/bcm.c: In function 'bcm_connect':
> net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> net/can/bcm.c: In function 'canbcm_pernet_init':
> net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
> net/can/bcm.c: In function 'canbcm_pernet_exit':
> net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
>
> This adds the same #ifdef around all users of the pointer. Alternatively
> we could move the pointer outside of the #ifdef.
>
> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM protocol")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A fix for this problem is part of the pull request I send to David
earlier today:
https://www.mail-archive.com/netdev@vger.kernel.org/msg165764.html
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next] can: fix build error without CONFIG_PROC_FS
From: Arnd Bergmann @ 2017-04-27 14:21 UTC (permalink / raw)
To: Oliver Hartkopp, Marc Kleine-Budde, David S. Miller
Cc: Arnd Bergmann, Thomas Gleixner, Cong Wang, Mario Kicherer,
Eric Dumazet, linux-can, netdev, linux-kernel
The procfs dir entry was added inside of an #ifdef, causing a build error
when we try to access it without CONFIG_PROC_FS set:
net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
net/can/bcm.c: In function 'bcm_connect':
net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
net/can/bcm.c: In function 'canbcm_pernet_init':
net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
net/can/bcm.c: In function 'canbcm_pernet_exit':
net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
This adds the same #ifdef around all users of the pointer. Alternatively
we could move the pointer outside of the #ifdef.
Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM protocol")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/can/bcm.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 0e855917b7e1..e6d9df27400b 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1538,8 +1538,10 @@ static int bcm_release(struct socket *sock)
}
/* remove procfs entry */
+#ifdef CONFIG_PROC_FS
if (net->can.bcmproc_dir && bo->bcm_proc_read)
remove_proc_entry(bo->procname, net->can.bcmproc_dir);
+#endif
/* remove device reference */
if (bo->bound) {
@@ -1597,7 +1599,7 @@ static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
/* no interface reference for ifindex = 0 ('any' CAN device) */
bo->ifindex = 0;
}
-
+#ifdef CONFIG_PROC_FS
if (net->can.bcmproc_dir) {
/* unique socket address as filename */
sprintf(bo->procname, "%lu", sock_i_ino(sk));
@@ -1609,6 +1611,7 @@ static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
goto fail;
}
}
+#endif
bo->bound = 1;
@@ -1691,22 +1694,23 @@ static const struct can_proto bcm_can_proto = {
static int canbcm_pernet_init(struct net *net)
{
+#ifdef CONFIG_PROC_FS
/* create /proc/net/can-bcm directory */
- if (IS_ENABLED(CONFIG_PROC_FS)) {
- net->can.bcmproc_dir =
- proc_net_mkdir(net, "can-bcm", net->proc_net);
- }
+ net->can.bcmproc_dir = proc_net_mkdir(net, "can-bcm", net->proc_net);
+#endif
return 0;
}
static void canbcm_pernet_exit(struct net *net)
{
+#ifdef CONFIG_PROC_FS
/* remove /proc/net/can-bcm directory */
if (IS_ENABLED(CONFIG_PROC_FS)) {
if (net->can.bcmproc_dir)
remove_proc_entry("can-bcm", net->proc_net);
}
+#endif
}
static struct pernet_operations canbcm_pernet_ops __read_mostly = {
--
2.9.0
^ permalink raw reply related
* [PATCH net] net: hns: fix ethtool_get_strings overflow in hns driver
From: Timmy Li @ 2017-04-27 14:18 UTC (permalink / raw)
To: davem, huangdaode, lipeng321, yisen.zhuang, salil.mehta,
yankejian
Cc: mbrugger, netdev, linux-kernel, linuxarm, Timmy Li
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.
When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=ffff801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [<ffff0000084b11b0>](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_fai
Signed-off-by: Timmy Li <lixiaoping3@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 3382441..7faeb5b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -672,7 +672,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)
static int hns_gmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if ((stringset == ETH_SS_STATS) || (stringset == ETH_SS_PRIV_FLAGS))
return ARRAY_SIZE(g_gmac_stats_string);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..e3e8772 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -422,7 +422,7 @@ void hns_ppe_update_stats(struct hns_ppe_cb *ppe_cb)
int hns_ppe_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if ((stringset == ETH_SS_STATS) || (stringset == ETH_SS_PRIV_FLAGS))
return ETH_PPE_STATIC_NUM;
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index f0ed80d6..01a0a03 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -799,7 +799,7 @@ void hns_rcb_get_stats(struct hnae_queue *queue, u64 *data)
*/
int hns_rcb_get_ring_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if ((stringset == ETH_SS_STATS) || (stringset == ETH_SS_PRIV_FLAGS))
return HNS_RING_STATIC_REG_NUM;
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index aae830a..f10b25c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -793,7 +793,7 @@ static void hns_xgmac_get_strings(u32 stringset, u8 *data)
*/
static int hns_xgmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if ((stringset == ETH_SS_STATS) || (stringset == ETH_SS_PRIV_FLAGS))
return ARRAY_SIZE(g_xgmac_stats_string);
return 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] tcp: tcp_rack_reo_timeout() must update tp->tcp_mstamp
From: Neal Cardwell @ 2017-04-27 14:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Soheil Hassas Yeganeh, Yuchung Cheng
In-Reply-To: <1493266255.6453.103.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Apr 27, 2017 at 12:10 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> I wrongly assumed tp->tcp_mstamp was up to date at the time
> tcp_rack_reo_timeout() was called.
>
> It is not true, since we only update tcp->tcp_mstamp when receiving
> a packet (as initially done in commit 69e996c58a35 ("tcp: add
> tp->tcp_mstamp field")
>
> tcp_rack_reo_timeout() being called by a timer and not an incoming
> packet, we need to refresh tp->tcp_mstamp
>
> Fixes: 7c1c7308592f ("tcp: do not pass timestamp to tcp_rack_detect_loss()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks!
neal
^ permalink raw reply
* [PATCH rdma-next] IB/mlx5: Enable IPoIB acceleration
From: Leon Romanovsky @ 2017-04-27 14:01 UTC (permalink / raw)
To: Doug Ledford
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Erez Shitrit, Saeed Mahameed,
Arnd Bergmann, David S . Miller, netdev-u79uwXL29TY76Z2rM5mHXA
From: Erez Shitrit <erezsh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Enable mlx5 IPoIB acceleration by declaring
mlx5_ib_{alloc,free}_rdma_netdev and assigning the mlx5
IPoIB rdma_netdev callbacks.
In addition, this patch brings in sync mlx5's IPoIB parts for net and IB
trees. As a precaution, we disabled IPoIB acceleration by default (in
the mlx5_core Kconfig file).
Signed-off-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Erez Shitrit <erezsh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Hi Doug,
This is connection patch between IPoIB mlx5_core and mlx5_ib parts.
The patch itself is based on merge between your's k.o/for-4.12-rdma-netdevice
commit cc47dd684ee04f9f49f081002a74ef1ba9d14cc8 and David's master
commit b1513c35317c106a1588f3ab32f6888f0e2afd71 , because there was patch
from Stephen exactly in that area:
http://marc.info/?l=linux-netdev&m=149288674816288&w=2
Are you OK with this base?
Or do you prefer patch which will be based on your's branch, which will fail
in merge tests (linux-next) between yours and Dave's tree?
Thanks
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/infiniband/hw/mlx5/main.c | 22 +++++++++++++
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/ipoib.c | 44 +++++++++++++++----------
drivers/net/ethernet/mellanox/mlx5/core/ipoib.h | 2 ++
include/linux/mlx5/driver.h | 19 +++++++++++
5 files changed, 70 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 9f3ba320ce70..d45772da0963 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3530,6 +3530,26 @@ static int mlx5_ib_get_hw_stats(struct ib_device *ibdev,
return num_counters;
}
+static struct net_device*
+mlx5_ib_alloc_rdma_netdev(struct ib_device *hca,
+ u8 port_num,
+ enum rdma_netdev_t type,
+ const char *name,
+ unsigned char name_assign_type,
+ void (*setup)(struct net_device *))
+{
+ if (type != RDMA_NETDEV_IPOIB)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ return mlx5_rdma_netdev_alloc(to_mdev(hca)->mdev, hca,
+ name, setup);
+}
+
+static void mlx5_ib_free_rdma_netdev(struct net_device *netdev)
+{
+ return mlx5_rdma_netdev_free(netdev);
+}
+
static void *mlx5_ib_add(struct mlx5_core_dev *mdev)
{
struct mlx5_ib_dev *dev;
@@ -3660,6 +3680,8 @@ static void *mlx5_ib_add(struct mlx5_core_dev *mdev)
dev->ib_dev.check_mr_status = mlx5_ib_check_mr_status;
dev->ib_dev.get_port_immutable = mlx5_port_immutable;
dev->ib_dev.get_dev_fw_str = get_dev_fw_str;
+ dev->ib_dev.alloc_rdma_netdev = mlx5_ib_alloc_rdma_netdev;
+ dev->ib_dev.free_rdma_netdev = mlx5_ib_free_rdma_netdev;
if (mlx5_core_is_pf(mdev)) {
dev->ib_dev.get_vf_config = mlx5_ib_get_vf_config;
dev->ib_dev.set_vf_link_state = mlx5_ib_set_vf_link_state;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index a84b652f9b54..fc52d742b7f7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -35,6 +35,6 @@ config MLX5_CORE_EN_DCB
config MLX5_CORE_IPOIB
bool "Mellanox Technologies ConnectX-4 IPoIB offloads support"
depends on MLX5_CORE_EN
- default y
+ default n
---help---
MLX5 IPoIB offloads & acceleration support.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/ipoib.c b/drivers/net/ethernet/mellanox/mlx5/core/ipoib.c
index 3c84e36af018..019c230da498 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/ipoib.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/ipoib.c
@@ -30,6 +30,7 @@
* SOFTWARE.
*/
+#include <rdma/ib_verbs.h>
#include <linux/mlx5/fs.h>
#include "en.h"
#include "ipoib.h"
@@ -359,10 +360,10 @@ static int mlx5i_close(struct net_device *netdev)
return 0;
}
-#ifdef notusedyet
/* IPoIB RDMA netdev callbacks */
static int mlx5i_attach_mcast(struct net_device *netdev, struct ib_device *hca,
- union ib_gid *gid, u16 lid, int set_qkey)
+ union ib_gid *gid, u16 lid, int set_qkey,
+ u32 qkey)
{
struct mlx5e_priv *epriv = mlx5i_epriv(netdev);
struct mlx5_core_dev *mdev = epriv->mdev;
@@ -375,6 +376,12 @@ static int mlx5i_attach_mcast(struct net_device *netdev, struct ib_device *hca,
mlx5_core_warn(mdev, "failed attaching QPN 0x%x, MGID %pI6\n",
ipriv->qp.qpn, gid->raw);
+ if (set_qkey) {
+ mlx5_core_dbg(mdev, "%s setting qkey 0x%x\n",
+ netdev->name, qkey);
+ ipriv->qkey = qkey;
+ }
+
return err;
}
@@ -397,15 +404,15 @@ static int mlx5i_detach_mcast(struct net_device *netdev, struct ib_device *hca,
}
static int mlx5i_xmit(struct net_device *dev, struct sk_buff *skb,
- struct ib_ah *address, u32 dqpn, u32 dqkey)
+ struct ib_ah *address, u32 dqpn)
{
struct mlx5e_priv *epriv = mlx5i_epriv(dev);
struct mlx5e_txqsq *sq = epriv->txq2sq[skb_get_queue_mapping(skb)];
struct mlx5_ib_ah *mah = to_mah(address);
+ struct mlx5i_priv *ipriv = epriv->ppriv;
- return mlx5i_sq_xmit(sq, skb, &mah->av, dqpn, dqkey);
+ return mlx5i_sq_xmit(sq, skb, &mah->av, dqpn, ipriv->qkey);
}
-#endif
static int mlx5i_check_required_hca_cap(struct mlx5_core_dev *mdev)
{
@@ -414,22 +421,23 @@ static int mlx5i_check_required_hca_cap(struct mlx5_core_dev *mdev)
if (!MLX5_CAP_GEN(mdev, ipoib_enhanced_offloads)) {
mlx5_core_warn(mdev, "IPoIB enhanced offloads are not supported\n");
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
return 0;
}
-static struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
- struct ib_device *ibdev,
- const char *name,
- void (*setup)(struct net_device *))
+struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
+ struct ib_device *ibdev,
+ const char *name,
+ void (*setup)(struct net_device *))
{
const struct mlx5e_profile *profile = &mlx5i_nic_profile;
int nch = profile->max_nch(mdev);
struct net_device *netdev;
struct mlx5i_priv *ipriv;
struct mlx5e_priv *epriv;
+ struct rdma_netdev *rn;
int err;
if (mlx5i_check_required_hca_cap(mdev)) {
@@ -464,13 +472,13 @@ static struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
mlx5e_attach_netdev(epriv);
netif_carrier_off(netdev);
- /* TODO: set rdma_netdev func pointers
- * rn = &ipriv->rn;
- * rn->hca = ibdev;
- * rn->send = mlx5i_xmit;
- * rn->attach_mcast = mlx5i_attach_mcast;
- * rn->detach_mcast = mlx5i_detach_mcast;
- */
+ /* set rdma_netdev func pointers */
+ rn = &ipriv->rn;
+ rn->hca = ibdev;
+ rn->send = mlx5i_xmit;
+ rn->attach_mcast = mlx5i_attach_mcast;
+ rn->detach_mcast = mlx5i_detach_mcast;
+
return netdev;
err_free_netdev:
@@ -482,7 +490,7 @@ static struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
}
EXPORT_SYMBOL(mlx5_rdma_netdev_alloc);
-static void mlx5_rdma_netdev_free(struct net_device *netdev)
+void mlx5_rdma_netdev_free(struct net_device *netdev)
{
struct mlx5e_priv *priv = mlx5i_epriv(netdev);
const struct mlx5e_profile *profile = priv->profile;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/ipoib.h b/drivers/net/ethernet/mellanox/mlx5/core/ipoib.h
index bae0a5cbc8ad..213191a78464 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/ipoib.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/ipoib.h
@@ -40,7 +40,9 @@
/* ipoib rdma netdev's private data structure */
struct mlx5i_priv {
+ struct rdma_netdev rn; /* keep this first */
struct mlx5_core_qp qp;
+ u32 qkey;
char *mlx5e_priv[0];
};
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index f50864626230..a3bd07608cc6 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1101,6 +1101,25 @@ struct net_device *mlx5_lag_get_roce_netdev(struct mlx5_core_dev *dev);
struct mlx5_uars_page *mlx5_get_uars_page(struct mlx5_core_dev *mdev);
void mlx5_put_uars_page(struct mlx5_core_dev *mdev, struct mlx5_uars_page *up);
+#ifndef CONFIG_MLX5_CORE_IPOIB
+static inline
+struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
+ struct ib_device *ibdev,
+ const char *name,
+ void (*setup)(struct net_device *))
+{
+ return ERR_PTR(-EOPNOTSUPP);
+}
+
+static inline void mlx5_rdma_netdev_free(struct net_device *netdev) {}
+#else
+struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev *mdev,
+ struct ib_device *ibdev,
+ const char *name,
+ void (*setup)(struct net_device *));
+void mlx5_rdma_netdev_free(struct net_device *netdev);
+#endif /* CONFIG_MLX5_CORE_IPOIB */
+
struct mlx5_profile {
u64 mask;
u8 log_max_qp;
--
2.12.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB
From: Nikolay Aleksandrov @ 2017-04-27 13:40 UTC (permalink / raw)
To: Arkadi Sharshevsky, netdev; +Cc: davem, stephen, bridge, Ido Schimmel
In-Reply-To: <1493280485-37845-1-git-send-email-arkadis@mellanox.com>
On 27/04/17 11:08, Arkadi Sharshevsky wrote:
> Commit 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb
> entries") added the ability to "take over an entry which was previously
> learned via HW when it shows up from a SW port".
>
> However, if an entry was learned via HW and then a control packet
> (e.g., ARP request) was trapped to the CPU, the bridge driver will
> update the entry and remove the externally learned flag, although the
> entry is still present in HW. Instead, only clear the externally learned
> flag in case of roaming.
>
> Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb entries")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Arkadi Sharashevsky <arkadis@mellanox.com>
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> net/bridge/br_fdb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index 5a40a87..ab0c7cc 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -589,14 +589,14 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
> if (unlikely(source != fdb->dst)) {
> fdb->dst = source;
> fdb_modified = true;
> + /* Take over HW learned entry */
> + if (unlikely(fdb->added_by_external_learn))
> + fdb->added_by_external_learn = 0;
> }
> if (now != fdb->updated)
> fdb->updated = now;
> if (unlikely(added_by_user))
> fdb->added_by_user = 1;
> - /* Take over HW learned entry */
> - if (unlikely(fdb->added_by_external_learn))
> - fdb->added_by_external_learn = 0;
> if (unlikely(fdb_modified))
> fdb_notify(br, fdb, RTM_NEWNEIGH);
> }
>
Wait, this won't apply to latest net-next due to my patch that added
fdb_modified when changing the ext learned flag. I think you'll have to
respin on top of latest net-next.
^ permalink raw reply
* [PATCH v1 2/3] bnx2x: Reuse bnx2x_null_format_ver()
From: Andy Shevchenko @ 2017-04-27 13:37 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, David S . Miller,
netdev
Cc: Andy Shevchenko
In-Reply-To: <20170427133701.72701-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Reuse bnx2x_null_format_ver() in functions where it's appropriated
instead of open coded variant.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 2acc4f081818..6d11a958200f 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -6161,14 +6161,20 @@ static void bnx2x_link_int_ack(struct link_params *params,
}
}
+static int bnx2x_null_format_ver(u32 spirom_ver, u8 *str, u16 *len)
+{
+ str[0] = '\0';
+ (*len)--;
+ return 0;
+}
+
static int bnx2x_format_ver(u32 num, u8 *str, u16 *len)
{
u16 ret;
if (*len < 10) {
/* Need more than 10chars for this format */
- *str = '\0';
- (*len)--;
+ bnx2x_null_format_ver(num, str, len);
return -EINVAL;
}
@@ -6183,8 +6189,7 @@ static int bnx2x_3_seq_format_ver(u32 num, u8 *str, u16 *len)
if (*len < 10) {
/* Need more than 10chars for this format */
- *str = '\0';
- (*len)--;
+ bnx2x_null_format_ver(num, str, len);
return -EINVAL;
}
@@ -6193,13 +6198,6 @@ static int bnx2x_3_seq_format_ver(u32 num, u8 *str, u16 *len)
return 0;
}
-static int bnx2x_null_format_ver(u32 spirom_ver, u8 *str, u16 *len)
-{
- str[0] = '\0';
- (*len)--;
- return 0;
-}
-
int bnx2x_get_ext_phy_fw_version(struct link_params *params, u8 *version,
u16 len)
{
--
2.11.0
^ permalink raw reply related
* [PATCH v1 3/3] bnx2x: Get rid of useless temporary variable
From: Andy Shevchenko @ 2017-04-27 13:37 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, David S . Miller,
netdev
Cc: Andy Shevchenko
In-Reply-To: <20170427133701.72701-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Replace pattern
int status;
...
status = func(...);
return status;
by
return func(...);
No functional change intented.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 6d11a958200f..7dd83d0ef0a0 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -10618,22 +10618,19 @@ static u8 bnx2x_848xx_read_status(struct bnx2x_phy *phy,
static int bnx2x_8485x_format_ver(u32 raw_ver, u8 *str, u16 *len)
{
- int status = 0;
u32 num;
num = ((raw_ver & 0xF80) >> 7) << 16 | ((raw_ver & 0x7F) << 8) |
((raw_ver & 0xF000) >> 12);
- status = bnx2x_3_seq_format_ver(num, str, len);
- return status;
+ return bnx2x_3_seq_format_ver(num, str, len);
}
static int bnx2x_848xx_format_ver(u32 raw_ver, u8 *str, u16 *len)
{
- int status = 0;
u32 spirom_ver;
+
spirom_ver = ((raw_ver & 0xF80) >> 7) << 16 | (raw_ver & 0x7F);
- status = bnx2x_format_ver(spirom_ver, str, len);
- return status;
+ return bnx2x_format_ver(spirom_ver, str, len);
}
static void bnx2x_8481_hw_reset(struct bnx2x_phy *phy,
@@ -12484,13 +12481,12 @@ static int bnx2x_populate_ext_phy(struct bnx2x *bp,
static int bnx2x_populate_phy(struct bnx2x *bp, u8 phy_index, u32 shmem_base,
u32 shmem2_base, u8 port, struct bnx2x_phy *phy)
{
- int status = 0;
phy->type = PORT_HW_CFG_XGXS_EXT_PHY_TYPE_NOT_CONN;
if (phy_index == INT_PHY)
return bnx2x_populate_int_phy(bp, shmem_base, port, phy);
- status = bnx2x_populate_ext_phy(bp, phy_index, shmem_base, shmem2_base,
+
+ return bnx2x_populate_ext_phy(bp, phy_index, shmem_base, shmem2_base,
port, phy);
- return status;
}
static void bnx2x_phy_def_cfg(struct link_params *params,
--
2.11.0
^ permalink raw reply related
* [PATCH v1 1/3] bnx2x: Replace custom scnprintf()
From: Andy Shevchenko @ 2017-04-27 13:36 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, David S . Miller,
netdev
Cc: Andy Shevchenko
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Use scnprintf() when printing version instead of custom open coded variants.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 79 +++---------------------
1 file changed, 9 insertions(+), 70 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index b209b7f6093e..2acc4f081818 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -6163,94 +6163,33 @@ static void bnx2x_link_int_ack(struct link_params *params,
static int bnx2x_format_ver(u32 num, u8 *str, u16 *len)
{
- u8 *str_ptr = str;
- u32 mask = 0xf0000000;
- u8 shift = 8*4;
- u8 digit;
- u8 remove_leading_zeros = 1;
+ u16 ret;
+
if (*len < 10) {
/* Need more than 10chars for this format */
- *str_ptr = '\0';
+ *str = '\0';
(*len)--;
return -EINVAL;
}
- while (shift > 0) {
- shift -= 4;
- digit = ((num & mask) >> shift);
- if (digit == 0 && remove_leading_zeros) {
- *str_ptr = '0';
- } else {
- if (digit < 0xa)
- *str_ptr = digit + '0';
- else
- *str_ptr = digit - 0xa + 'a';
-
- remove_leading_zeros = 0;
- str_ptr++;
- (*len)--;
- }
- mask = mask >> 4;
- if (shift == 4*4) {
- if (remove_leading_zeros) {
- str_ptr++;
- (*len)--;
- }
- *str_ptr = '.';
- str_ptr++;
- (*len)--;
- remove_leading_zeros = 1;
- }
- }
- if (remove_leading_zeros)
- (*len)--;
+ ret = scnprintf(str, *len, "%hx.%hx", num >> 16, num);
+ *len -= ret;
return 0;
}
static int bnx2x_3_seq_format_ver(u32 num, u8 *str, u16 *len)
{
- u8 *str_ptr = str;
- u32 mask = 0x00f00000;
- u8 shift = 8*3;
- u8 digit;
- u8 remove_leading_zeros = 1;
+ u16 ret;
if (*len < 10) {
/* Need more than 10chars for this format */
- *str_ptr = '\0';
+ *str = '\0';
(*len)--;
return -EINVAL;
}
- while (shift > 0) {
- shift -= 4;
- digit = ((num & mask) >> shift);
- if (digit == 0 && remove_leading_zeros) {
- *str_ptr = '0';
- } else {
- if (digit < 0xa)
- *str_ptr = digit + '0';
- else
- *str_ptr = digit - 0xa + 'a';
-
- remove_leading_zeros = 0;
- str_ptr++;
- (*len)--;
- }
- mask = mask >> 4;
- if ((shift == 4*4) || (shift == 4*2)) {
- if (remove_leading_zeros) {
- str_ptr++;
- (*len)--;
- }
- *str_ptr = '.';
- str_ptr++;
- (*len)--;
- remove_leading_zeros = 1;
- }
- }
- if (remove_leading_zeros)
- (*len)--;
+ ret = scnprintf(str, *len, "%hhx.%hhx.%hhx", num >> 16, num >> 8, num);
+ *len -= ret;
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [RFC net-next 0/2] Introduce bpf_prog ID and iteration
From: Hannes Frederic Sowa @ 2017-04-27 13:36 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, Alexei Starovoitov, kernel-team
In-Reply-To: <20170427062449.80290-1-kafai@fb.com>
On 27.04.2017 08:24, Martin KaFai Lau wrote:
> This patchset introduces the bpf_prog ID and a new bpf cmd to
> iterate all bpf_prog in the system.
>
> It is still incomplete. The idea can be extended to bpf_map.
>
> Martin KaFai Lau (2):
> bpf: Introduce bpf_prog ID
> bpf: Test for bpf_prog ID and BPF_PROG_GET_NEXT_ID
Thanks Martin, I like the approach.
I think the progid is also much more suitable to be used in kallsyms
because it handles collisions correctly and let's correctly walk the
chain (for example imaging loading two identical programs but install
them at different hooks, kallsysms doesn't allow to find out which
program is installed where).
It would help a lot if you could pass the prog_id back during program
creation, otherwise it will be kind of difficult to get a hold on which
program is where. ;)
Thanks,
Hannes
^ permalink raw reply
* Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta
From: Sricharan R @ 2017-04-27 13:35 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: Rafael J. Wysocki, Joerg Roedel, Bjorn Helgaas, linux-acpi,
linux-kernel, linux-pci, Thomas Petazzoni, netdev
In-Reply-To: <20170426181508.687b52af@gmail.com>
Hi,
On 4/26/2017 9:45 PM, Ralph Sennhauser wrote:
> Hi Sricharan R,
>
> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time
> for platform/amba/pci bus devices") causes a kernel panic as in the log
> below on an armada-385. Reverting the commit fixes the issue.
>
> Regards
> Ralph
Somehow not getting a obvious clue on whats going wrong with the logs
below. From the log and looking in to dts, the drivers seems to the one for
"marvell,armada-370-neta". Issue looks the data from the dma has gone bad
and subsequently referring the wrong data has resulted in the crash.
Looks like the dma_masks is the one going wrong.
Can i get some logs from mvneta_probe, about dev->dma_mask,
dev->coherent_dma_mask and dev->dma_ops with and without the patch
to see whats the difference ?
Regards,
Sricharan
>
> ---
>
> [ 18.288244] [c06d8480] *pgd=0061941e(bad)
> [ 18.292271] Internal error: Oops: 80d [#1] SMP ARM
> [ 18.297080] Modules linked in:
> [ 18.471175] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.11.0-rc8-next-20170426 #3
> [ 18.479909] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 18.485850] task: c0a07000 task.stack: c0a00000
> [ 18.490401] PC is at __memzero+0x40/0x80
> [ 18.494336] LR is at 0x0
> [ 18.496878] pc : [<c0317920>] lr : [<00000000>] psr: 00000113
> [ 18.496878] sp : c0a01d0c ip : 00000000 fp : c0a01d34
> [ 18.508402] r10: df43f800 r9 : df43f800 r8 : 00000001
> [ 18.513645] r7 : c06d7e40 r6 : 000007c0 r5 : c06d8480 r4 : de14aa80
> [ 18.520196] r3 : 00000000 r2 : 00000000 r1 : ffffffe4 r0 : c06d8480
> [ 18.526750] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 18.533912] Control: 10c5387d Table: 16f0004a DAC: 00000051
> [ 18.539679] Process swapper/0 (pid: 0, stack limit = 0xc0a00210)
> [ 18.545708] Stack: (0xc0a01d0c to 0xc0a02000)
> [ 18.550082] 1d00: c04caef0 c06d7e40 00000700 0cc04000 00000001
> [ 18.558292] 1d20: df691810 df43f800 c0a01d4c c0a01d38 c04caf20 c04cae7c e1b1d000 df5bd980
> [ 18.566503] 1d40: c0a01dc4 c0a01d50 c043d3d8 c04caf14 df41e494 00000000 1e652500 c0601460
> [ 18.574714] 1d60: dfbd8880 c0a04680 c06d7e40 00000000 dfbd8888 00000000 00000000 00000188
> [ 18.582924] 1d80: 1e652500 dfbd8880 00000040 00000100 df43fc80 00000001 00000000 dfbd8888
> [ 18.591134] 1da0: c043cfd4 00000040 0000012c ffff91f5 c0a02d00 c0a01de8 c0a01e24 c0a01dc8
> [ 18.599345] 1dc0: c04db2d4 c043cfe0 c015d81c c06db4d4 c0a04990 c0a04990 c0a302b2 1f267000
> [ 18.607555] 1de0: c096ab40 dfbd1b40 c0a01de8 c0a01de8 c0a01df0 c0a01df0 c0a01e1c 00000000
> [ 18.615766] 1e00: c0a0208c c0a00000 00000100 00000003 c0a02080 40000003 c0a01e84 c0a01e28
> [ 18.623977] 1e20: c0122e9c c04db0cc c0a01e54 00000101 c0a01e4c 00200102 c0a02d00 ffff91f5
> [ 18.632187] 1e40: 0000000a c06025b4 c0a31740 c09632a8 c0a02080 c0a01e28 c0169788 c0968420
> [ 18.640397] 1e60: 00000000 00000000 00000001 df408000 e0803100 c0a01f58 c0a01e94 c0a01e88
> [ 18.648607] 1e80: c01232d0 c0122d84 c0a01ebc c0a01e98 c015d6e4 c012322c c0a169c0 c0a03fac
> [ 18.656818] 1ea0: e080210c c0a01ee8 e0802100 e0803100 c0a01ee4 c0a01ec0 c01014a4 c015d688
> [ 18.665029] 1ec0: c01085b0 60000013 ffffffff c0a01f1c 00000000 c0a00000 c0a01f44 c0a01ee8
> [ 18.673240] 1ee0: c010c86c c0101460 00000001 00000000 00000000 c0118e40 c0a00000 c0a03cf8
> [ 18.681451] 1f00: c0a03cac c09696f8 00000000 00000000 c0a01f58 c0a01f44 c0a01f48 c0a01f38
> [ 18.689661] 1f20: c01085ac c01085b0 60000013 ffffffff 00000051 00000000 c0a01f54 c0a01f48
> [ 18.697871] 1f40: c05e3634 c010857c c0a01f8c c0a01f58 c0153458 c05e3618 c0a03c80 c0a0f30a
> [ 18.706082] 1f60: c0a30c00 000000bd c0a30c00 c0a03c80 ffffffff c0a30c00 c0833a28 dfffcb40
> [ 18.714292] 1f80: c0a01f9c c0a01f90 c0153718 c01532c0 c0a01fac c0a01fa0 c05dd758 c0153704
> [ 18.722503] 1fa0: c0a01ff4 c0a01fb0 c0800d68 c05dd6e8 ffffffff ffffffff 00000000 c08006f8
> [ 18.730713] 1fc0: 00000000 c0833a28 00000000 c0a30e94 c0a03c9c c0833a24 c0a081e8 0000406a
> [ 18.738923] 1fe0: 414fc091 00000000 00000000 c0a01ff8 0000807c c08009b4 00000000 00000000
> [ 18.747132] Backtrace:
> [ 18.749591] [<c04cae70>] (__build_skb) from [<c04caf20>] (build_skb+0x18/0x6c)
> [ 18.756843] r9:df43f800 r8:df691810 r7:00000001 r6:0cc04000 r5:00000700 r4:c06d7e40
> [ 18.764618] [<c04caf08>] (build_skb) from [<c043d3d8>] (mvneta_poll+0x404/0xc18)
> [ 18.772042] r5:df5bd980 r4:e1b1d000
> [ 18.775632] [<c043cfd4>] (mvneta_poll) from [<c04db2d4>] (net_rx_action+0x214/0x308)
> [ 18.783406] r10:c0a01de8 r9:c0a02d00 r8:ffff91f5 r7:0000012c r6:00000040 r5:c043cfd4
> [ 18.791266] r4:dfbd8888
> [ 18.793810] [<c04db0c0>] (net_rx_action) from [<c0122e9c>] (__do_softirq+0x124/0x248)
> [ 18.801672] r10:40000003 r9:c0a02080 r8:00000003 r7:00000100 r6:c0a00000 r5:c0a0208c
> [ 18.809531] r4:00000000
> [ 18.812074] [<c0122d78>] (__do_softirq) from [<c01232d0>] (irq_exit+0xb0/0xe4)
> [ 18.819325] r10:c0a01f58 r9:e0803100 r8:df408000 r7:00000001 r6:00000000 r5:00000000
> [ 18.827184] r4:c0968420
> [ 18.829729] [<c0123220>] (irq_exit) from [<c015d6e4>] (__handle_domain_irq+0x68/0xbc)
> [ 18.837591] [<c015d67c>] (__handle_domain_irq) from [<c01014a4>] (gic_handle_irq+0x50/0x94)
> [ 18.845976] r9:e0803100 r8:e0802100 r7:c0a01ee8 r6:e080210c r5:c0a03fac r4:c0a169c0
> [ 18.853749] [<c0101454>] (gic_handle_irq) from [<c010c86c>] (__irq_svc+0x6c/0x90)
> [ 18.861261] Exception stack(0xc0a01ee8 to 0xc0a01f30)
> [ 18.866332] 1ee0: 00000001 00000000 00000000 c0118e40 c0a00000 c0a03cf8
> [ 18.874543] 1f00: c0a03cac c09696f8 00000000 00000000 c0a01f58 c0a01f44 c0a01f48 c0a01f38
> [ 18.882753] 1f20: c01085ac c01085b0 60000013 ffffffff
> [ 18.887823] r9:c0a00000 r8:00000000 r7:c0a01f1c r6:ffffffff r5:60000013 r4:c01085b0
> [ 18.895601] [<c0108570>] (arch_cpu_idle) from [<c05e3634>] (default_idle_call+0x28/0x34)
> [ 18.903727] [<c05e360c>] (default_idle_call) from [<c0153458>] (do_idle+0x1a4/0x1d0)
> [ 18.911503] [<c01532b4>] (do_idle) from [<c0153718>] (cpu_startup_entry+0x20/0x24)
> [ 18.919103] r10:dfffcb40 r9:c0833a28 r8:c0a30c00 r7:ffffffff r6:c0a03c80 r5:c0a30c00
> [ 18.926962] r4:000000bd
> [ 18.929508] [<c01536f8>] (cpu_startup_entry) from [<c05dd758>] (rest_init+0x7c/0x80)
> [ 18.937284] [<c05dd6dc>] (rest_init) from [<c0800d68>] (start_kernel+0x3c0/0x3cc)
> [ 18.944796] [<c08009a8>] (start_kernel) from [<0000807c>] (0x807c)
> [ 18.951001] Code: a8a0500c cafffff9 08bd8000 e3110020 (18a0500c)
> [ 18.957119] ---[ end trace 4e5c1e66e49610b0 ]---
> [ 18.961753] Kernel panic - not syncing: Fatal exception in interrupt
> [ 18.968133] CPU1: stopping
> [ 18.970852] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D O 4.11.0-rc8-next-20170426 #3
> [ 18.979585] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 18.985527] Backtrace:
> [ 18.987986] [<c010ba4c>] (dump_backtrace) from [<c010bd20>] (show_stack+0x18/0x1c)
> [ 18.995586] r7:df467f28 r6:60000193 r5:c0a165b0 r4:00000000
> [ 19.001268] [<c010bd08>] (show_stack) from [<c031883c>] (dump_stack+0x94/0xa8)
> [ 19.008520] [<c03187a8>] (dump_stack) from [<c010ecec>] (handle_IPI+0x178/0x198)
> [ 19.015945] r7:df467f28 r6:00000000 r5:00000001 r4:c0a30ef0
> [ 19.021627] [<c010eb74>] (handle_IPI) from [<c01014e4>] (gic_handle_irq+0x90/0x94)
> [ 19.029227] r7:df467f28 r6:e080210c r5:c0a03fac r4:c0a169c0
> [ 19.034908] [<c0101454>] (gic_handle_irq) from [<c010c86c>] (__irq_svc+0x6c/0x90)
> [ 19.042419] Exception stack(0xdf467f28 to 0xdf467f70)
> [ 19.047490] 7f20: 00000001 00000000 00000000 c0118e40 df466000 c0a03cf8
> [ 19.055701] 7f40: c0a03cac c09696f8 00000000 00000000 df467f98 df467f84 df467f88 df467f78
> [ 19.063911] 7f60: c01085ac c01085b0 60000013 ffffffff
> [ 19.068982] r9:df466000 r8:00000000 r7:df467f5c r6:ffffffff r5:60000013 r4:c01085b0
> [ 19.076758] [<c0108570>] (arch_cpu_idle) from [<c05e3634>] (default_idle_call+0x28/0x34)
> [ 19.084882] [<c05e360c>] (default_idle_call) from [<c0153458>] (do_idle+0x1a4/0x1d0)
> [ 19.092657] [<c01532b4>] (do_idle) from [<c0153718>] (cpu_startup_entry+0x20/0x24)
> [ 19.100258] r10:00000000 r9:414fc091 r8:0000406a r7:c0a30f00 r6:10c0387d r5:00000001
> [ 19.108118] r4:00000087
> [ 19.110661] [<c01536f8>] (cpu_startup_entry) from [<c010e918>] (secondary_start_kernel+0x150/0x15c)
> [ 19.119743] [<c010e7c8>] (secondary_start_kernel) from [<0010162c>] (0x10162c)
> [ 19.126993] r5:00000051 r4:1f45c06a
> [ 19.130583] Rebooting in 3 seconds..
>
> ---
>
> git bisect start
> # bad: [e0a8aa40bd2c7d973b6520293f3fd86dcbca847b] Add linux-next specific files for 20170426
> git bisect bad e0a8aa40bd2c7d973b6520293f3fd86dcbca847b
> # good: [c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201] Linux 4.11-rc1
> git bisect good c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
> # good: [221c3c382a529418d3a2acc58f53101103f6ff13] Merge remote-tracking branch 'l2-mtd/master'
> git bisect good 221c3c382a529418d3a2acc58f53101103f6ff13
> # bad: [ffcefbbe2f8c0af5f22af921afd2756baceddd74] Merge remote-tracking branch 'spi/for-next'
> git bisect bad ffcefbbe2f8c0af5f22af921afd2756baceddd74
> # good: [c2e7f82d336a451ebb904b8bf9a5a558cf16c39b] drm: mali-dp: Check the mclk rate and allow up/down scaling
> git bisect good c2e7f82d336a451ebb904b8bf9a5a558cf16c39b
> # good: [03b600f368cfa6f94e9622dda82e60f55b5e6224] Merge remote-tracking branch 'block/for-next'
> git bisect good 03b600f368cfa6f94e9622dda82e60f55b5e6224
> # good: [8b1e05cbcdfc59496eff5870cb6b6ab964ecc733] Merge remote-tracking branch 'battery/for-next'
> git bisect good 8b1e05cbcdfc59496eff5870cb6b6ab964ecc733
> # good: [e765d496d3adb3d69bd8c53df6fd3f3b77e5b1d2] Merge remote-tracking branch 'watchdog/master'
> git bisect good e765d496d3adb3d69bd8c53df6fd3f3b77e5b1d2
> # bad: [858eed97e369df7af0993463f355aa9755227136] Merge remote-tracking branch 'audit/next'
> git bisect bad 858eed97e369df7af0993463f355aa9755227136
> # bad: [efc2195bcc35eebf06805806eb525893f3b9ab5c] Merge branches 'arm/exynos', 'arm/omap', 'arm/rockchip', 'arm/mediatek', 'arm/smmu', 'arm/core', 'x86/vt-d', 'x86/amd' and 'core' into next
> git bisect bad efc2195bcc35eebf06805806eb525893f3b9ab5c
> # bad: [316ca8804ea84a782d5ba2163711ebb22116ff5a] ACPI/IORT: Remove linker section for IORT entries probing
> git bisect bad 316ca8804ea84a782d5ba2163711ebb22116ff5a
> # good: [d7b0558230e444f29488fcee0b0b561015d16f8a] iommu/of: Prepare for deferred IOMMU configuration
> git bisect good d7b0558230e444f29488fcee0b0b561015d16f8a
> # bad: [09515ef5ddad71c7820e5e428da418b709feeb26] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
> git bisect bad 09515ef5ddad71c7820e5e428da418b709feeb26
> # good: [1d9029d440e40b276c0691caed1de10c42d96bef] ACPI/IORT: Add function to check SMMUs drivers presence
> git bisect good 1d9029d440e40b276c0691caed1de10c42d96bef
> # good: [efc8551a276faab19d85079da02c5fb602b0dcbe] of: device: Fix overflow of coherent_dma_mask
> git bisect good efc8551a276faab19d85079da02c5fb602b0dcbe
> # first bad commit: [09515ef5ddad71c7820e5e428da418b709feeb26] of/acpi:
> Configure dma operations at probe time for platform/amba/pci bus devices
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH net-next 6/6] bpf: show bpf programs
From: Hannes Frederic Sowa @ 2017-04-27 13:28 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, ast, daniel, jbenc, aconole, Martin KaFai Lau
In-Reply-To: <20170426212553.fq3uyhktfxvn36rv@ast-mbp>
On 26.04.2017 23:25, Alexei Starovoitov wrote:
> On Wed, Apr 26, 2017 at 08:24:19PM +0200, Hannes Frederic Sowa wrote:
>>
>> +static const char *bpf_type_string(enum bpf_prog_type type)
>> +{
>> + static const char *bpf_type_names[] = {
>> +#define X(type) #type
>> + BPF_PROG_TYPES
>> +#undef X
>> + };
>> +
>> + if (type >= ARRAY_SIZE(bpf_type_names))
>> + return "<unknown>";
>> +
>> + return bpf_type_names[type];
>> +}
>> +
>> static int ebpf_proc_show(struct seq_file *s, void *v)
>> {
>> + struct bpf_prog *prog;
>> + struct bpf_prog_aux *aux;
>> + char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
>> +
>> if (v == SEQ_START_TOKEN) {
>> - seq_printf(s, "# tag\n");
>> + seq_printf(s, "# tag\t\t\ttype\t\t\truntime\tcap\tmemlock\n");
>> return 0;
>> }
>>
>> + aux = v;
>> + prog = aux->prog;
>> +
>> + bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
>> + seq_printf(s, "%s\t%s\t%s\t%s\t%llu\n", prog_tag,
>> + bpf_type_string(prog->type),
>> + prog->jited ? "jit" : "int",
>> + prog->priv_cap_sys_admin ? "priv" : "unpriv",
>> + prog->pages * 1ULL << PAGE_SHIFT);
>
> As I said several times already I'm strongly against procfs
> style of exposing information about the programs.
I would not expand procfs interface to dump ebpf bytecode or jitcode,
albeit I would prefer a file system abstraction for that.
> I don't want this to become debugfs for bpf.
Right now it just prints a list of ebpf programs. You reject of where
things are going or do you already reject this particular patch?
> Maintaining the list of all loaded programs is fine
> and we need a way to iterate through them, but procfs
> is obviously not the interface to do that.
> Programs/maps are binary whereas any fs interface is text.
It should give admins only a high level overview of what is going on in
there system. I don't want o print any kind of opcodes there, just
giving people the possibility to see what is going on.
> It also doesn't scale with large number of programs/maps.
> I prefer Daniel's suggestion on adding 'get_next' like API.
> Also would be good if you can wait for Martin to finish his
> prog->handle/id patches. Then user space will be able
> to iterate through all the progs/maps and fetch all info about
> them through syscall in extensible way.
> And you wouldn't need to abuse kallsyms list for different purpose.
I don't buy the scalability argument:
What is the scalability issue with this O(1) approach on loading and
O(n) (but also without any locks held) on dumping? You can't do any
better. You can even dump several programs with one syscall instead of
slowly iterating over them.
Certainly I can wait with those patches until Martin presented his patches.
And regarding abusing the list, I just renamed it. If you think I abuse
something I can also add another list like bpf_prog_id patches do?
Bye bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 6/6] bpf: show bpf programs
From: Hannes Frederic Sowa @ 2017-04-27 13:22 UTC (permalink / raw)
To: Daniel Borkmann, netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <590112BE.7040902@iogearbox.net>
On 26.04.2017 23:35, Daniel Borkmann wrote:
> On 04/26/2017 08:24 PM, Hannes Frederic Sowa wrote:
>> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> ---
>> include/uapi/linux/bpf.h | 32 +++++++++++++++++++-------------
>> kernel/bpf/core.c | 30 +++++++++++++++++++++++++++++-
>> 2 files changed, 48 insertions(+), 14 deletions(-)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index e553529929f683..d6506e320953d5 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -101,20 +101,26 @@ enum bpf_map_type {
>> BPF_MAP_TYPE_HASH_OF_MAPS,
>> };
>>
>> +#define BPF_PROG_TYPES \
>> + X(BPF_PROG_TYPE_UNSPEC), \
>> + X(BPF_PROG_TYPE_SOCKET_FILTER), \
>> + X(BPF_PROG_TYPE_KPROBE), \
>> + X(BPF_PROG_TYPE_SCHED_CLS), \
>> + X(BPF_PROG_TYPE_SCHED_ACT), \
>> + X(BPF_PROG_TYPE_TRACEPOINT), \
>> + X(BPF_PROG_TYPE_XDP), \
>> + X(BPF_PROG_TYPE_PERF_EVENT), \
>> + X(BPF_PROG_TYPE_CGROUP_SKB), \
>> + X(BPF_PROG_TYPE_CGROUP_SOCK), \
>> + X(BPF_PROG_TYPE_LWT_IN), \
>> + X(BPF_PROG_TYPE_LWT_OUT), \
>> + X(BPF_PROG_TYPE_LWT_XMIT),
>> +
>> +
>> enum bpf_prog_type {
>> - BPF_PROG_TYPE_UNSPEC,
>> - BPF_PROG_TYPE_SOCKET_FILTER,
>> - BPF_PROG_TYPE_KPROBE,
>> - BPF_PROG_TYPE_SCHED_CLS,
>> - BPF_PROG_TYPE_SCHED_ACT,
>> - BPF_PROG_TYPE_TRACEPOINT,
>> - BPF_PROG_TYPE_XDP,
>> - BPF_PROG_TYPE_PERF_EVENT,
>> - BPF_PROG_TYPE_CGROUP_SKB,
>> - BPF_PROG_TYPE_CGROUP_SOCK,
>> - BPF_PROG_TYPE_LWT_IN,
>> - BPF_PROG_TYPE_LWT_OUT,
>> - BPF_PROG_TYPE_LWT_XMIT,
>> +#define X(type) type
>
> Defining X in uapi could clash easily with other headers e.g.
> from application side.
I think that X-macros are so much used that code review should catch
that no X macro is leaked beyond its scope.
I certainly can use some other macro names, maybe something along the
line from bpf_types.h.
>
>> + BPF_PROG_TYPES
>> +#undef X
>> };
>>
>> enum bpf_attach_type {
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 3ba175a24e971a..685c1d0f31e029 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -536,13 +536,41 @@ static void ebpf_proc_stop(struct seq_file *s,
>> void *v)
>> rcu_read_unlock();
>> }
>>
>> +static const char *bpf_type_string(enum bpf_prog_type type)
>> +{
>> + static const char *bpf_type_names[] = {
>> +#define X(type) #type
>> + BPF_PROG_TYPES
>> +#undef X
>> + };
>> +
>> + if (type >= ARRAY_SIZE(bpf_type_names))
>> + return "<unknown>";
>> +
>> + return bpf_type_names[type];
>> +}
>> +
>> static int ebpf_proc_show(struct seq_file *s, void *v)
>> {
>> + struct bpf_prog *prog;
>> + struct bpf_prog_aux *aux;
>> + char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
>> +
>> if (v == SEQ_START_TOKEN) {
>> - seq_printf(s, "# tag\n");
>> + seq_printf(s, "# tag\t\t\ttype\t\t\truntime\tcap\tmemlock\n");
>> return 0;
>> }
>>
>> + aux = v;
>> + prog = aux->prog;
>> +
>> + bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
>> + seq_printf(s, "%s\t%s\t%s\t%s\t%llu\n", prog_tag,
>> + bpf_type_string(prog->type),
>> + prog->jited ? "jit" : "int",
>> + prog->priv_cap_sys_admin ? "priv" : "unpriv",
>> + prog->pages * 1ULL << PAGE_SHIFT);
>
> Yeah, so that would be quite similar to what we dump in
> bpf_prog_show_fdinfo() modulo the priv bit.
And, additionally, that you don't need to have a file descriptor handy
to do so, which is my main point.
> I generally agree that a facility for dumping all progs is needed
> and it was also on the TODO list after the bpf(2) cmd for dumping
> program insns back to user space.
I think this is orthogonal.
> I think the procfs interface has pro and cons: the upside is that
> you can use it with tools like cat to inspect it, but what you still
> cannot do is to say that you want to see the prog insns for, say,
> prog #4 from that list. If we could iterate over that list through fds
> via bpf(2) syscall, you could i) present the same info you have above
> via fdinfo already and ii) also dump the BPF insns from that specific
> program through a BPF_PROG_DUMP bpf(2) command. Once that dump also
> supports maps in progs, you could go further and fetch related map
> fds for inspection, etc.
Sure, that sounds super. But so far Linux and most (maybe I should write
all) subsystems always provided some easy way to get the insights of the
kernel without having to code or rely on special tools so far. And I
very much enjoyed that part on Linux. FreeBSD did very often abstract
some details behind shared libraries and commands that has no easy
pedant to use for with cat and grep.
> Such option of iterating through that would need a new BPF syscall
> cmd aka BPF_PROG_GET_NEXT which returns the first prog from the list
> and you would walk the next one by passing the current fd, which can
> later also be closed as not needed anymore. We could restrict that
> dump to capable(CAP_SYS_ADMIN), and the kernel tree would need to
> ship a tool e.g. under tools/bpf/ that can be used for inspection.
>
Martin already posted his patches which add a bpf_prog_id to ebpf
programs. I will have alook at those and will comment over there.
Thansk for the review,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 4/6] bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
From: Hannes Frederic Sowa @ 2017-04-27 13:17 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, ast, daniel, jbenc, aconole
In-Reply-To: <20170426210826.mlwuuhq7jsu4n7f4@ast-mbp>
Hi,
On 26.04.2017 23:08, Alexei Starovoitov wrote:
> On Wed, Apr 26, 2017 at 08:24:17PM +0200, Hannes Frederic Sowa wrote:
>> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> ---
>> include/linux/filter.h | 6 ++++--
>> kernel/bpf/core.c | 4 +++-
>> kernel/bpf/syscall.c | 7 ++++---
>> kernel/bpf/verifier.c | 4 ++--
>> net/core/filter.c | 6 +++---
>> 5 files changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index 63624c619e371b..635311f57bf24f 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -413,7 +413,8 @@ struct bpf_prog {
>> locked:1, /* Program image locked? */
>> gpl_compatible:1, /* Is filter GPL compatible? */
>> cb_access:1, /* Is control block accessed? */
>> - dst_needed:1; /* Do we need dst entry? */
>> + dst_needed:1, /* Do we need dst entry? */
>> + priv_cap_sys_admin:1; /* Where we loaded as sys_admin? */
>
> This is no go.
> You didn't provide any explanation whatsoever why you want to see this boolean value.
Sorry, should be in the description and will be added if this patch
series is considered to be worthwhile to pursue.
cap_sys_admin influences the verifier a lot in terms which programs are
accepted and which are not. So during investigations it might be even
interesting if the bpf program required those special flags or if the
same program could be loaded just as underprivileged.
I also have to review if we can/should attach cap_sys_admin verified
programs as unprivileged user. It should stop to install a ptr leaking
bpf program as ordinary user, even if one got the file descriptor, no?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] mlx5: work around unused function warning
From: Leon Romanovsky @ 2017-04-27 13:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, David S. Miller, Erez Shitrit,
Dan Carpenter, Stephen Hemminger, Networking,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <CAK8P3a0kX4uNLBvLAHrhtmUc7eBLmD6dXA8=xxY+xJ4OsGFJbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
On Thu, Apr 27, 2017 at 02:04:15PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 27, 2017 at 1:55 PM, Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> > On Thu, Apr 27, 2017 at 01:04:02PM +0200, Arnd Bergmann wrote:
> >> The previous patch addressed a sparse warning but replaced it with a
> >> compiler warning when CONFIG_MODULES is disabled:
> >>
> >> drivers/net/ethernet/mellanox/mlx5/core/ipoib.c:485:13: error: 'mlx5_rdma_netdev_free' defined but not used [-Werror=unused-function]
> >> drivers/net/ethernet/mellanox/mlx5/core/ipoib.c:423:27: error: 'mlx5_rdma_netdev_alloc' defined but not used [-Werror=unused-function]
> >>
> >> We should never export 'static' functions, so this makes them global
> >> again but hides them in another #ifdef like the change before.
> >>
> >> Fixes: a7082ef066f0 ("mlx5: hide unused functions")
> >> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> >
> > Hi Arnd,
> >
> > Thanks for the patch, but Stephen and Saeed already sent patch similar to it.
> > http://marc.info/?l=linux-netdev&m=149288674816288&w=2
>
> That link is for the patch that introduced the warning that I'm fixing here,
> it showed up yesterday in linux-next.
>
> Did you misread my patch, or just give the wrong link?
Sorry, I misread you patch, because I prepared patch which add users for
these functions and didn't notice both "static" and EXPORT_SYMBOLS at the same time.
I will send it in a couple of minutes.
Thanks
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Andrew Lunn @ 2017-04-27 13:04 UTC (permalink / raw)
To: Rafa Corvillo; +Cc: Stephen Hemminger, netdev
In-Reply-To: <5901DE9F.1070005@aoifes.com>
On Thu, Apr 27, 2017 at 02:05:51PM +0200, Rafa Corvillo wrote:
> On 25/04/17 17:27, Stephen Hemminger wrote:
> >On Fri, 21 Apr 2017 14:39:00 +0200
> >Rafa Corvillo <rafael.corvillo@aoifes.com> wrote:
> >
> >>We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build).
> >>It is an imx6 board with 2 ethernet interfaces. One of them is connected to
> >>a Marvell switch.
> >>
> >>The schema of the system is the following:
> >>
Hi Rafa
Your ASCII art got messed up somewhere. Is this the correct
reconstruction?
+-------------------+ eth0
| +--+
| | |
| Embedded system +--+
| |
| ARMv7 |
| | Marvell 88E8057(sky2) +-------------+
| +--+ +--+ +--+ eth1
| | +---------------------+ | | +------+
| +--+ CPU port +--+ mv88e6176 +--+
+------+--+---------+ | |
emulated | | | |
GPIO +--+ +--+ +--+ eth2
MDIO +-----------------------------------+ | | +------+
MDIO +--+ +--+
+-------------+
I assume you are using DSA? Since this is LEDE, it could be swconfig,
but the bridge configuration you mentioned would not make sense for
swconfig.
> >>If I connect the eth1/eth2, the link is up and I can do ping through it.
> >>But, once
> >>I start sending a heavy traffic load the link fails and the kernel sends the
> >>following messages:
> >>
> >>[ 48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 54.877567] net_ratelimit: 6 callbacks suppressed
> >>[ 54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >>[ 61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
> >>length 1518
> >
> >The status error bits are in sky2.h
> >0x5f20010 is
> > 05f2 frame length => 1522
> > 0010 Too long err
> >
> >That means the packet was longer than the configured MTU.
> >You are probably getting packets with VLAN tag but have not configured
> >a VLAN.
Since you are using DSA, you will have DSA tags enabled on frames
to/from the switch. This adds an extra 8 byte header in the frame. My
guess is, it is this header, not the VLAN tag which is causing you MTU
issues.
I think this is the first time i've seen sky2 used in a DSA
setup. mv643xx or mvneta is generally what is used, when using Marvell
chipsets. These drivers are more lenient about MTU, and are happy to
pass frames with additional headers.
> Thanks for the information. I have increased the MTU value to 1550
> (workaround) and it works if sends traffic (with iperf) from my
> computer to the unit. But, if I send traffic outside the unit, I get
> a new error message and link goes down:
Changing the MTU like this is not a good fix. It will allow you to
receive frames which are bigger, but it also means the local network
stack will generate bigger frames to be transmitted. You probably need
to modify the sky2 driver to allow it to receive frames bigger than
the interface MTU, by about 8 bytes.
> [ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
> [ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,
> full duplex, flow control both
Between the sky2 and the switch, do you have two back-to-back PHYs or
are you connecting the RGMII interfaces together?
Andrew
^ permalink raw reply
* Re: [Patch net-next] ipv4: get rid of ip_ra_lock
From: Eric Dumazet @ 2017-04-27 12:46 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <1493240115-779-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, 2017-04-26 at 13:55 -0700, Cong Wang wrote:
> After commit 1215e51edad1 ("ipv4: fix a deadlock in ip_ra_control")
> we always take RTNL lock for ip_ra_control() which is the only place
> we update the list ip_ra_chain, so the ip_ra_lock is no longer needed,
> we just need to disable BH there.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
Looks great, but reading again this code, I believe we do not need to
disable BH at all ?
Thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next v4 0/7] net: improve support for SCTP checksums
From: Marcelo Ricardo Leitner @ 2017-04-27 12:41 UTC (permalink / raw)
To: Davide Caratti
Cc: Tom Herbert, Alexander Duyck, David Laight, David S . Miller,
netdev, linux-sctp
In-Reply-To: <cover.1492692976.git.dcaratti@redhat.com>
On Thu, Apr 20, 2017 at 03:38:06PM +0200, Davide Caratti wrote:
> hello Tom,
>
> On Fri, 2017-04-07 at 11:11 -0700, Tom Herbert wrote:
> > maybe just call it csum_not_ip then. Then just do "if
> > (unlikely(skb->csum_not_ip)) ..."
>
> Ok, done. V4 uses this bit for SCTP only and leaves unmodified behavior
> when offloaded FCoE frames are processed. Further work is still possible
> to extend this fix for FCoE, if needed, either by using additional sk_buff
> bits, or using skb->csum_not_ip and use other data (e.g. skb->csum_offset)
> to distinguish SCTP from FCoE.
>
> > the only case where this new bit is relevant is when
> > CHECKSUM_PARTIAL for a CRC is being done. When it's set for offloading
> > sctp crc it must be set. When CRC is resolved, in the helper for
> > instance, it must be cleared.
>
> in V4 the bit is set when SCTP packets with offloaded checksum are
> generated; the bit is cleared when CRC32c is resolved for such packets
> (i.e. skb->ip_summed transitions from CHECKSUM_PARTIAL to CHECKSUM_NONE).
>
> Any feedbacks are appreciated!
> thank you in advance,
> --
> davide
>
>
> Davide Caratti (7):
> skbuff: add stub to help computing crc32c on SCTP packets
> net: introduce skb_crc32c_csum_help
> sk_buff: remove support for csum_bad in sk_buff
> net: use skb->csum_not_inet to identify packets needing crc32c
> net: more accurate checksumming in validate_xmit_skb()
> openvswitch: more accurate checksumming in queue_userspace_packet()
> sk_buff.h: improve description of CHECKSUM_{COMPLETE,UNNECESSARY}
Other than the comments I did on patch 2, this series LGTM.
>
> Documentation/networking/checksum-offloads.txt | 11 +++--
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 2 +-
> include/linux/netdevice.h | 8 +--
> include/linux/skbuff.h | 58 +++++++++-------------
> net/bridge/netfilter/nft_reject_bridge.c | 5 +-
> net/core/dev.c | 63 +++++++++++++++++++++---
> net/core/skbuff.c | 24 +++++++++
> net/ipv4/netfilter/nf_reject_ipv4.c | 2 +-
> net/ipv6/netfilter/nf_reject_ipv6.c | 3 --
> net/openvswitch/datapath.c | 2 +-
> net/sched/act_csum.c | 1 +
> net/sctp/offload.c | 8 +++
> net/sctp/output.c | 1 +
> 13 files changed, 128 insertions(+), 60 deletions(-)
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB
From: Nikolay Aleksandrov @ 2017-04-27 12:33 UTC (permalink / raw)
To: Arkadi Sharshevsky, netdev; +Cc: Ido Schimmel, bridge, davem
In-Reply-To: <1493280485-37845-1-git-send-email-arkadis@mellanox.com>
On 27/04/17 11:08, Arkadi Sharshevsky wrote:
> Commit 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb
> entries") added the ability to "take over an entry which was previously
> learned via HW when it shows up from a SW port".
>
> However, if an entry was learned via HW and then a control packet
> (e.g., ARP request) was trapped to the CPU, the bridge driver will
> update the entry and remove the externally learned flag, although the
> entry is still present in HW. Instead, only clear the externally learned
> flag in case of roaming.
>
> Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb entries")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Arkadi Sharashevsky <arkadis@mellanox.com>
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> net/bridge/br_fdb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Thanks!
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH RFC net-next v4 2/7] net: introduce skb_crc32c_csum_help
From: Marcelo Ricardo Leitner @ 2017-04-27 12:29 UTC (permalink / raw)
To: Davide Caratti
Cc: Tom Herbert, Alexander Duyck, David Laight, David S . Miller,
netdev, linux-sctp
In-Reply-To: <2d4895be40590b624bed89df38ea64e560aa2f10.1492692976.git.dcaratti@redhat.com>
On Thu, Apr 20, 2017 at 03:38:08PM +0200, Davide Caratti wrote:
> skb_crc32c_csum_help is like skb_checksum_help, but it is designed for
> checksumming SCTP packets using crc32c (see RFC3309), provided that
> libcrc32c.ko has been loaded before. In case libcrc32c is not loaded,
> invoking skb_crc32c_csum_help on a skb results in one the following
> printouts:
>
> warn_crc32c_csum_update: attempt to compute crc32c without libcrc32c.ko
> warn_crc32c_csum_combine: attempt to compute crc32c without libcrc32c.ko
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
> ---
> include/linux/netdevice.h | 1 +
> include/linux/skbuff.h | 3 ++-
> net/core/dev.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index b0aa089..bf84a67 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3898,6 +3898,7 @@ void netdev_rss_key_fill(void *buffer, size_t len);
>
> int dev_get_nest_level(struct net_device *dev);
> int skb_checksum_help(struct sk_buff *skb);
> +int skb_crc32c_csum_help(struct sk_buff *skb);
> struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
> netdev_features_t features, bool tx_path);
> struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index ba3ae21..ec4551b 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -193,7 +193,8 @@
> * accordingly. Note the there is no indication in the skbuff that the
> * CHECKSUM_PARTIAL refers to an SCTP checksum, a driver that supports
> * both IP checksum offload and SCTP CRC offload must verify which offload
> - * is configured for a packet presumably by inspecting packet headers.
> + * is configured for a packet presumably by inspecting packet headers; in
> + * case, skb_crc32c_csum_help is provided to compute CRC on SCTP packets.
> *
> * NETIF_F_FCOE_CRC - This feature indicates that a device is capable of
> * offloading the FCOE CRC in a packet. To perform this offload the stack
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5d33e2b..c7aec95 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -140,6 +140,7 @@
> #include <linux/hrtimer.h>
> #include <linux/netfilter_ingress.h>
> #include <linux/crash_dump.h>
> +#include <linux/sctp.h>
>
> #include "net-sysfs.h"
>
> @@ -2606,6 +2607,45 @@ int skb_checksum_help(struct sk_buff *skb)
> }
> EXPORT_SYMBOL(skb_checksum_help);
>
> +int skb_crc32c_csum_help(struct sk_buff *skb)
> +{
> + __le32 crc32c_csum;
> + int ret = 0, offset;
> +
> + if (skb->ip_summed != CHECKSUM_PARTIAL)
> + goto out;
> +
> + if (unlikely(skb_is_gso(skb)))
> + goto out;
> +
> + /* Before computing a checksum, we should make sure no frag could
> + * be modified by an external entity : checksum could be wrong.
> + */
> + if (unlikely(skb_has_shared_frag(skb))) {
> + ret = __skb_linearize(skb);
> + if (ret)
> + goto out;
> + }
> +
> + offset = skb_checksum_start_offset(skb);
> + crc32c_csum = cpu_to_le32(~__skb_checksum(skb, offset,
> + skb->len - offset, ~(__u32)0,
> + crc32c_csum_stub));
> + offset += offsetof(struct sctphdr, checksum);
> + BUG_ON(offset >= skb_headlen(skb));
I suggest using WARN_ON_ONCE() here and returning an error instead. Will
still allow debugging and won't disrupt the system.
> +
> + if (skb_cloned(skb) &&
> + !skb_clone_writable(skb, offset + sizeof(__le32))) {
> + ret = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
> + if (ret)
> + goto out;
> + }
We could do this check (including the BUG_ON/WARN check above) before
the actual crc32 calc. This can fail, and if it does, we will have
calculated it in vain. Note how offset doesn't really depend on the
checksum result.
I know skb_checksum_help also does it this way, maybe it was because of
some cache optimization on the offset += checksum offset operation?
> + *(__le32 *)(skb->data + offset) = crc32c_csum;
> + skb->ip_summed = CHECKSUM_NONE;
> +out:
> + return ret;
> +}
> +
> __be16 skb_network_protocol(struct sk_buff *skb, int *depth)
> {
> __be16 type = skb->protocol;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_rack_reo_timeout() must update tp->tcp_mstamp
From: Soheil Hassas Yeganeh @ 2017-04-27 12:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Neal Cardwell, Yuchung Cheng
In-Reply-To: <1493266255.6453.103.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Apr 27, 2017 at 12:10 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> I wrongly assumed tp->tcp_mstamp was up to date at the time
> tcp_rack_reo_timeout() was called.
>
> It is not true, since we only update tcp->tcp_mstamp when receiving
> a packet (as initially done in commit 69e996c58a35 ("tcp: add
> tp->tcp_mstamp field")
>
> tcp_rack_reo_timeout() being called by a timer and not an incoming
> packet, we need to refresh tp->tcp_mstamp
>
> Fixes: 7c1c7308592f ("tcp: do not pass timestamp to tcp_rack_detect_loss()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_recovery.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
> index cd72b3d3879e88181c8a4639f0334a24e4cda852..362b8c75bfab44cf87c2a01398a146a271bc1119 100644
> --- a/net/ipv4/tcp_recovery.c
> +++ b/net/ipv4/tcp_recovery.c
> @@ -166,6 +166,7 @@ void tcp_rack_reo_timeout(struct sock *sk)
> u32 timeout, prior_inflight;
>
> prior_inflight = tcp_packets_in_flight(tp);
> + skb_mstamp_get(&tp->tcp_mstamp);
> tcp_rack_detect_loss(sk, &timeout);
> if (prior_inflight != tcp_packets_in_flight(tp)) {
> if (inet_csk(sk)->icsk_ca_state != TCP_CA_Recovery) {
>
>
Thanks for the fix!
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-04-27 12:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170425082741.59428876@xeon-e3>
On 25/04/17 17:27, Stephen Hemminger wrote:
> On Fri, 21 Apr 2017 14:39:00 +0200
> Rafa Corvillo <rafael.corvillo@aoifes.com> wrote:
>
>> We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build).
>> It is an imx6 board with 2 ethernet interfaces. One of them is connected to
>> a Marvell switch.
>>
>> The schema of the system is the following:
>>
>> +-------------------+ eth0
>> | +--+
>> | | |
>> | Embedded system +--+
>> | |
>> | ARMv7 |
>> | | Marvell 88E8057(sky2) +-------------+
>> | +--+ +--+ +--+ eth1
>> | | +---------------------+ | | +------+
>> | +--+ CPU port +--+ mv88e6176 +--+
>> +------+--+---------+ | |
>> emulated| | | |
>> GPIO +--+ +--+ +--+ eth2
>> MDIO +-----------------------------------+ | | +------+
>> MDIO +--+ +--+
>> +-------------+
>>
>> There is a bridge (br-lan) which includes eth0/eth1/eth2
>>
>> If I connect the eth1/eth2, the link is up and I can do ping through it.
>> But, once
>> I start sending a heavy traffic load the link fails and the kernel sends the
>> following messages:
>>
>> [ 48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 54.877567] net_ratelimit: 6 callbacks suppressed
>> [ 54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>> [ 61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
>> length 1518
>
> The status error bits are in sky2.h
> 0x5f20010 is
> 05f2 frame length => 1522
> 0010 Too long err
>
> That means the packet was longer than the configured MTU.
> You are probably getting packets with VLAN tag but have not configured
> a VLAN.
>
>
>
Thanks for the information. I have increased the MTU value to 1550
(workaround) and it works if sends traffic (with iperf) from my computer
to the unit. But, if I send traffic outside the unit, I get a new error
message and link goes down:
[ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
[ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps, full
duplex, flow control both
Rafa
^ permalink raw reply
* Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: Jason A. Donenfeld @ 2017-04-27 12:04 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: Netdev, LKML, David Laight, kernel-hardening, David Miller
In-Reply-To: <20170427113016.GA12448@bistromath.localdomain>
On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> Hmm, I think this can actually happen:
Alright, perhaps better to err on the side of caution, then.
Jason
^ permalink raw reply
* Re: [PATCH net-next] mlx5: work around unused function warning
From: Arnd Bergmann @ 2017-04-27 12:04 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Saeed Mahameed, Matan Barak, David S. Miller, Erez Shitrit,
Dan Carpenter, Stephen Hemminger, Networking, linux-rdma,
Linux Kernel Mailing List
In-Reply-To: <20170427115513.GH14088@mtr-leonro.local>
On Thu, Apr 27, 2017 at 1:55 PM, Leon Romanovsky <leonro@mellanox.com> wrote:
> On Thu, Apr 27, 2017 at 01:04:02PM +0200, Arnd Bergmann wrote:
>> The previous patch addressed a sparse warning but replaced it with a
>> compiler warning when CONFIG_MODULES is disabled:
>>
>> drivers/net/ethernet/mellanox/mlx5/core/ipoib.c:485:13: error: 'mlx5_rdma_netdev_free' defined but not used [-Werror=unused-function]
>> drivers/net/ethernet/mellanox/mlx5/core/ipoib.c:423:27: error: 'mlx5_rdma_netdev_alloc' defined but not used [-Werror=unused-function]
>>
>> We should never export 'static' functions, so this makes them global
>> again but hides them in another #ifdef like the change before.
>>
>> Fixes: a7082ef066f0 ("mlx5: hide unused functions")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hi Arnd,
>
> Thanks for the patch, but Stephen and Saeed already sent patch similar to it.
> http://marc.info/?l=linux-netdev&m=149288674816288&w=2
That link is for the patch that introduced the warning that I'm fixing here,
it showed up yesterday in linux-next.
Did you misread my patch, or just give the wrong link?
Arnd
^ permalink raw reply
* Re: [PATCH net v4 1/3] net: hns: support deferred probe when can not obtain irq
From: Matthias Brugger @ 2017-04-27 11:58 UTC (permalink / raw)
To: Yankejian, davem, salil.mehta, yisen.zhuang, lipeng321, zhouhuiru,
huangdaode
Cc: netdev, linuxarm
In-Reply-To: <1493261053-68197-2-git-send-email-yankejian@huawei.com>
On 27/04/17 04:44, Yankejian wrote:
> From: lipeng <lipeng321@huawei.com>
>
> In the hip06 and hip07 SoCs, the interrupt lines from the
> DSAF controllers are connected to mbigen hw module.
> The mbigen module is probed with module_init, and, as such,
> is not guaranteed to probe before the HNS driver. So we need
> to support deferred probe.
>
> Signed-off-by: lipeng <lipeng321@huawei.com>
> Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> ---
> change log:
> V3 -> V4:
> 1. Delete redundant commit message;
> 2. add Reviewed-by: Matthias Brugger <mbrugger@suse.com>;
>
> V2 -> V3:
> 1. Check return value when platform_get_irq in hns_rcb_get_cfg;
> ---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 +++-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 +++++++-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
> index 6ea8722..a41cf95 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
> @@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
>
> hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
>
> - hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
> + ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
> + if (ret)
> + goto get_rcb_cfg_fail;
a2185587ade7 ("net: hns: Simplify the exception sequence in hns_ppe_init()")
deleted get_rcb_cfg_fail label. This does not compile. Please rebase
against net-next.
Best regards,
Matthias
> }
>
> for (i = 0; i < HNS_PPE_COM_NUM; i++)
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
> index f0ed80d6..673a5d3 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
> @@ -452,7 +452,7 @@ static int hns_rcb_get_base_irq_idx(struct rcb_common_cb *rcb_common)
> *hns_rcb_get_cfg - get rcb config
> *@rcb_common: rcb common device
> */
> -void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
> +int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
> {
> struct ring_pair_cb *ring_pair_cb;
> u32 i;
> @@ -477,10 +477,16 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
> ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
> is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 + 1) :
> platform_get_irq(pdev, base_irq_idx + i * 3);
> + if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] == -EPROBE_DEFER) ||
> + (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] == -EPROBE_DEFER))
> + return -EPROBE_DEFER;
> +
> ring_pair_cb->q.phy_base =
> RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
> hns_rcb_ring_pair_get_cfg(ring_pair_cb);
> }
> +
> + return 0;
> }
>
> /**
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
> index 99b4e1b..3d7b484 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
> @@ -110,7 +110,7 @@ struct rcb_common_cb {
> void hns_rcb_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index);
> int hns_rcb_common_init_hw(struct rcb_common_cb *rcb_common);
> void hns_rcb_start(struct hnae_queue *q, u32 val);
> -void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
> +int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
> void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode,
> u16 *max_vfn, u16 *max_q_per_vf);
>
>
^ 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