* [PATCH RFC/RFT net-next 05/17] net/ipv6: wrappers for neighbor table references
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
In-Reply-To: <20180717120651.15748-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Create a helper, ipv6_neigh_table, for retrieving a reference to the ipv6
neighbor table. Add additional wrappers for commonly used neigh_* functions
to avoid propagating the ipv6_neigh_table lookup all over the code.
For ipv6, the neighbor table may not exist (e.g., IPv6 not enabled at
build time or the module is not loaded) so NULL checks are needed before
use.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/net/ndisc.h | 69 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 65 insertions(+), 4 deletions(-)
diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index ddfbb591e2c5..078951ac54fd 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -374,17 +374,70 @@ static inline u32 ndisc_hashfn(const void *pkey, const struct net_device *dev, _
(p32[3] * hash_rnd[3]));
}
-static inline struct neighbour *__ipv6_neigh_lookup_noref(struct net_device *dev, const void *pkey)
+static inline struct neigh_table *ipv6_neigh_table(struct net *net)
{
- return ___neigh_lookup_noref(&nd_tbl, neigh_key_eq128, ndisc_hashfn, pkey, dev);
+ return neigh_find_table(net, AF_INET6);
}
-static inline struct neighbour *__ipv6_neigh_lookup(struct net_device *dev, const void *pkey)
+static inline struct neighbour *ipv6_neigh_create(struct net_device *dev,
+ const void *pkey,
+ bool want_ref)
+{
+ struct neigh_table *tbl = ipv6_neigh_table(dev_net(dev));
+ struct neighbour *n = NULL;
+
+ if (tbl)
+ n = __neigh_create(tbl, pkey, dev, want_ref);
+
+ return n;
+}
+
+static inline struct neighbour *ipv6_neigh_lookup(struct net_device *dev,
+ const void *pkey)
+{
+ struct neigh_table *tbl = ipv6_neigh_table(dev_net(dev));
+ struct neighbour *n = NULL;
+
+ if (tbl)
+ n = neigh_lookup(tbl, pkey, dev);
+
+ return n;
+}
+
+static inline struct neighbour *__ipv6_neigh_lookup(struct net_device *dev,
+ const void *pkey, int creat)
+{
+ struct neigh_table *tbl = ipv6_neigh_table(dev_net(dev));
+ struct neighbour *n = NULL;
+
+ if (tbl)
+ n = __neigh_lookup(tbl, pkey, dev, creat);
+
+ return n;
+}
+
+static inline
+struct neighbour *___ipv6_neigh_lookup_noref(struct net_device *dev,
+ const void *pkey)
+{
+ struct neigh_table *tbl = ipv6_neigh_table(dev_net(dev));
+ struct neighbour *n = NULL;
+
+ if (tbl)
+ n = ___neigh_lookup_noref(tbl, neigh_key_eq128, ndisc_hashfn,
+ pkey, dev);
+
+ return n;
+}
+
+static inline
+struct neighbour *__ipv6_neigh_lookup_noref(struct net_device *dev,
+ const void *pkey)
{
struct neighbour *n;
rcu_read_lock_bh();
- n = __ipv6_neigh_lookup_noref(dev, pkey);
+ n = ___ipv6_neigh_lookup_noref(dev, pkey);
if (n && !refcount_inc_not_zero(&n->refcnt))
n = NULL;
rcu_read_unlock_bh();
@@ -409,6 +462,14 @@ static inline void __ipv6_confirm_neigh(struct net_device *dev,
rcu_read_unlock_bh();
}
+static inline struct pneigh_entry *ipv6_pneigh_lookup(struct net *net,
+ const void *key,
+ struct net_device *dev,
+ int creat)
+{
+ return pneigh_lookup(ipv6_neigh_table(net), net, key, dev, creat);
+}
+
int ndisc_init(void);
int ndisc_late_init(void);
--
2.11.0
^ permalink raw reply related
* [PATCH RFC/RFT net-next 04/17] net/ipv4: Remove open coded use of arp table
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
In-Reply-To: <20180717120651.15748-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Convert existing uses for arp_tbl to the helpers introduced in the previous
patch.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/bridge/br_arp_nd_proxy.c | 2 +-
net/ipv4/arp.c | 36 ++++++++++++++++++++----------------
net/ipv4/devinet.c | 8 ++++----
net/ipv4/fib_semantics.c | 2 +-
net/ipv4/ip_output.c | 2 +-
net/ipv4/route.c | 4 ++--
6 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
index 2cf7716254be..29a1e25fc169 100644
--- a/net/bridge/br_arp_nd_proxy.c
+++ b/net/bridge/br_arp_nd_proxy.c
@@ -183,7 +183,7 @@ void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
return;
}
- n = neigh_lookup(&arp_tbl, &tip, vlandev);
+ n = ipv4_neigh_lookup(vlandev, &tip);
if (n) {
struct net_bridge_fdb_entry *f;
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index e90c89ef8c08..fd4a380da9bb 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -678,6 +678,7 @@ static bool arp_is_garp(struct net *net, struct net_device *dev,
static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
{
+ struct neigh_table *tbl = ipv4_neigh_table(net);
struct net_device *dev = skb->dev;
struct in_device *in_dev = __in_dev_get_rcu(dev);
struct arphdr *arp;
@@ -827,7 +828,7 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
if (!dont_send && IN_DEV_ARPFILTER(in_dev))
dont_send = arp_filter(sip, tip, dev);
if (!dont_send) {
- n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+ n = neigh_event_ns(tbl, sha, &sip, dev);
if (n) {
arp_send_dst(ARPOP_REPLY, ETH_P_ARP,
sip, dev, tip, sha,
@@ -842,8 +843,8 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
(arp_fwd_proxy(in_dev, dev, rt) ||
arp_fwd_pvlan(in_dev, dev, rt, sip, tip) ||
(rt->dst.dev != dev &&
- pneigh_lookup(&arp_tbl, net, &tip, dev, 0)))) {
- n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+ pneigh_lookup(tbl, net, &tip, dev, 0)))) {
+ n = neigh_event_ns(tbl, sha, &sip, dev);
if (n)
neigh_release(n);
@@ -855,7 +856,7 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
dev->dev_addr, sha,
reply_dst);
} else {
- pneigh_enqueue(&arp_tbl,
+ pneigh_enqueue(tbl,
in_dev->arp_parms, skb);
goto out_free_dst;
}
@@ -866,7 +867,7 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
/* Update our ARP tables */
- n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
+ n = __neigh_lookup(tbl, &sip, dev, 0);
addr_type = -1;
if (n || IN_DEV_ARP_ACCEPT(in_dev)) {
@@ -887,7 +888,7 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
/* postpone calculation to as late as possible */
inet_addr_type_dev_table(net, dev, sip) ==
RTN_UNICAST)))))
- n = __neigh_lookup(&arp_tbl, &sip, dev, 1);
+ n = __neigh_lookup(tbl, &sip, dev, 1);
}
if (n) {
@@ -1011,7 +1012,7 @@ static int arp_req_set_public(struct net *net, struct arpreq *r,
return -ENODEV;
}
if (mask) {
- if (!pneigh_lookup(&arp_tbl, net, &ip, dev, 1))
+ if (!pneigh_lookup(ipv4_neigh_table(net), net, &ip, dev, 1))
return -ENOBUFS;
return 0;
}
@@ -1063,7 +1064,7 @@ static int arp_req_set(struct net *net, struct arpreq *r,
break;
}
- neigh = __neigh_lookup_errno(&arp_tbl, &ip, dev);
+ neigh = __neigh_lookup_errno(ipv4_neigh_table(net), &ip, dev);
err = PTR_ERR(neigh);
if (!IS_ERR(neigh)) {
unsigned int state = NUD_STALE;
@@ -1098,7 +1099,7 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev)
struct neighbour *neigh;
int err = -ENXIO;
- neigh = neigh_lookup(&arp_tbl, &ip, dev);
+ neigh = ipv4_neigh_lookup(dev, &ip);
if (neigh) {
if (!(neigh->nud_state & NUD_NOARP)) {
read_lock_bh(&neigh->lock);
@@ -1116,9 +1117,9 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev)
static int arp_invalidate(struct net_device *dev, __be32 ip)
{
- struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev);
+ struct neigh_table *tbl = ipv4_neigh_table(dev_net(dev));
+ struct neighbour *neigh = neigh_lookup(tbl, &ip, dev);
int err = -ENXIO;
- struct neigh_table *tbl = &arp_tbl;
if (neigh) {
if (neigh->nud_state & ~NUD_NOARP)
@@ -1141,7 +1142,7 @@ static int arp_req_delete_public(struct net *net, struct arpreq *r,
__be32 mask = ((struct sockaddr_in *)&r->arp_netmask)->sin_addr.s_addr;
if (mask == htonl(0xFFFFFFFF))
- return pneigh_delete(&arp_tbl, net, &ip, dev);
+ return pneigh_delete(ipv4_neigh_table(net), net, &ip, dev);
if (mask)
return -EINVAL;
@@ -1248,13 +1249,13 @@ static int arp_netdev_event(struct notifier_block *this, unsigned long event,
switch (event) {
case NETDEV_CHANGEADDR:
- neigh_changeaddr(&arp_tbl, dev);
+ neigh_changeaddr(ipv4_neigh_table(dev_net(dev)), dev);
rt_cache_flush(dev_net(dev));
break;
case NETDEV_CHANGE:
change_info = ptr;
if (change_info->flags_changed & IFF_NOARP)
- neigh_changeaddr(&arp_tbl, dev);
+ neigh_changeaddr(ipv4_neigh_table(dev_net(dev)), dev);
break;
default:
break;
@@ -1273,7 +1274,7 @@ static struct notifier_block arp_netdev_notifier = {
*/
void arp_ifdown(struct net_device *dev)
{
- neigh_ifdown(&arp_tbl, dev);
+ neigh_ifdown(ipv4_neigh_table(dev_net(dev)), dev);
}
@@ -1403,10 +1404,13 @@ static int arp_seq_show(struct seq_file *seq, void *v)
static void *arp_seq_start(struct seq_file *seq, loff_t *pos)
{
+ struct net *net = seq_file_net(seq);
+
/* Don't want to confuse "arp -a" w/ magic entries,
* so we tell the generic iterator to skip NUD_NOARP.
*/
- return neigh_seq_start(seq, pos, &arp_tbl, NEIGH_SEQ_SKIP_NOARP);
+ return neigh_seq_start(seq, pos, ipv4_neigh_table(net),
+ NEIGH_SEQ_SKIP_NOARP);
}
/* ------------------------------------------------------------------------ */
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index d7585ab1a77a..07a57fd1a343 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -239,6 +239,7 @@ EXPORT_SYMBOL(in_dev_finish_destroy);
static struct in_device *inetdev_init(struct net_device *dev)
{
+ struct net *net = dev_net(dev);
struct in_device *in_dev;
int err = -ENOMEM;
@@ -247,11 +248,10 @@ static struct in_device *inetdev_init(struct net_device *dev)
in_dev = kzalloc(sizeof(*in_dev), GFP_KERNEL);
if (!in_dev)
goto out;
- memcpy(&in_dev->cnf, dev_net(dev)->ipv4.devconf_dflt,
- sizeof(in_dev->cnf));
+ memcpy(&in_dev->cnf, net->ipv4.devconf_dflt, sizeof(in_dev->cnf));
in_dev->cnf.sysctl = NULL;
in_dev->dev = dev;
- in_dev->arp_parms = neigh_parms_alloc(dev, &arp_tbl);
+ in_dev->arp_parms = neigh_parms_alloc(dev, ipv4_neigh_table(net));
if (!in_dev->arp_parms)
goto out_kfree;
if (IPV4_DEVCONF(in_dev->cnf, FORWARDING))
@@ -309,7 +309,7 @@ static void inetdev_destroy(struct in_device *in_dev)
RCU_INIT_POINTER(dev->ip_ptr, NULL);
devinet_sysctl_unregister(in_dev);
- neigh_parms_release(&arp_tbl, in_dev->arp_parms);
+ neigh_parms_release(ipv4_neigh_table(dev_net(dev)), in_dev->arp_parms);
arp_ifdown(dev);
call_rcu(&in_dev->rcu_head, in_dev_rcu_put);
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index f3c89ccf14c5..d91cf61e044e 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -440,7 +440,7 @@ static int fib_detect_death(struct fib_info *fi, int order,
struct neighbour *n;
int state = NUD_NONE;
- n = neigh_lookup(&arp_tbl, &fi->fib_nh[0].nh_gw, fi->fib_dev);
+ n = ipv4_neigh_lookup(fi->fib_dev, &fi->fib_nh[0].nh_gw);
if (n) {
state = n->nud_state;
neigh_release(n);
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e2b6bd478afb..0e880d4b859e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -221,7 +221,7 @@ static int ip_finish_output2(struct net *net, struct sock *sk, struct sk_buff *s
nexthop = (__force u32) rt_nexthop(rt, ip_hdr(skb)->daddr);
neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
if (unlikely(!neigh))
- neigh = __neigh_create(&arp_tbl, &nexthop, dev, false);
+ neigh = ipv4_neigh_create_noref(dev, &nexthop);
if (!IS_ERR(neigh)) {
int res;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 74e1df60ab7f..56dfa77c19ab 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -448,7 +448,7 @@ static struct neighbour *ipv4_dst_neigh_lookup(const struct dst_entry *dst,
n = __ipv4_neigh_lookup(dev, *(__force u32 *)pkey);
if (n)
return n;
- return neigh_create(&arp_tbl, pkey, dev);
+ return ipv4_neigh_create(dev, pkey);
}
static void ipv4_confirm_neigh(const struct dst_entry *dst, const void *daddr)
@@ -770,7 +770,7 @@ static void __ip_do_redirect(struct rtable *rt, struct sk_buff *skb, struct flow
n = __ipv4_neigh_lookup(rt->dst.dev, new_gw);
if (!n)
- n = neigh_create(&arp_tbl, &new_gw, rt->dst.dev);
+ n = ipv4_neigh_create(rt->dst.dev, &new_gw);
if (!IS_ERR(n)) {
if (!(n->nud_state & NUD_VALID)) {
neigh_event_send(n, NULL);
--
2.11.0
^ permalink raw reply related
* [PATCH RFC/RFT net-next 03/17] net/ipv4: wrappers for arp table references
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
In-Reply-To: <20180717120651.15748-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Create a helper, ipv4_neigh_table, for retrieving a reference to the arp
table. Add additional wrappers for commonly used neigh_* functions to
avoid propagating the ipv4_neigh_table lookup all over the code.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/net/arp.h | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/net/arp.h b/include/net/arp.h
index 977aabfcdc03..7b503bedd9fb 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -10,6 +10,29 @@
extern struct neigh_table arp_tbl;
+static inline struct neigh_table *ipv4_neigh_table(struct net *net)
+{
+ return neigh_find_table(net, AF_INET);
+}
+
+static inline struct neighbour *ipv4_neigh_create(struct net_device *dev,
+ const void *pkey)
+{
+ return neigh_create(ipv4_neigh_table(dev_net(dev)), pkey, dev);
+}
+
+static inline struct neighbour *ipv4_neigh_create_noref(struct net_device *dev,
+ const void *pkey)
+{
+ return __neigh_create(ipv4_neigh_table(dev_net(dev)), pkey, dev, false);
+}
+
+static inline struct neighbour *ipv4_neigh_lookup(struct net_device *dev,
+ void *key)
+{
+ return neigh_lookup(ipv4_neigh_table(dev_net(dev)), key, dev);
+}
+
static inline u32 arp_hashfn(const void *pkey, const struct net_device *dev, u32 *hash_rnd)
{
u32 key = *(const u32 *)pkey;
@@ -23,7 +46,8 @@ static inline struct neighbour *__ipv4_neigh_lookup_noref(struct net_device *dev
if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
key = INADDR_ANY;
- return ___neigh_lookup_noref(&arp_tbl, neigh_key_eq32, arp_hashfn, &key, dev);
+ return ___neigh_lookup_noref(ipv4_neigh_table(dev_net(dev)),
+ neigh_key_eq32, arp_hashfn, &key, dev);
}
static inline struct neighbour *__ipv4_neigh_lookup(struct net_device *dev, u32 key)
--
2.11.0
^ permalink raw reply related
* [PATCH RFC/RFT net-next 02/17] net/neigh: export neigh_find_table
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
In-Reply-To: <20180717120651.15748-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
neighbor code already has an API for access to neighbor caches by
address family. Export it for use by networking code. Add the
namespace as an input arg and make family a u8 versus an int (all
existing callers pass ndm_family which is a u8).
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/net/neighbour.h | 2 ++
net/core/neighbour.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 6c1eecd56a4d..5bc4d79b4b3a 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -229,6 +229,8 @@ enum {
NEIGH_LINK_TABLE = NEIGH_NR_TABLES /* Pseudo table for neigh_xmit */
};
+struct neigh_table *neigh_find_table(struct net *net, u8 family);
+
static inline int neigh_parms_family(struct neigh_parms *p)
{
return p->tbl->family;
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index cbe85d8d4cc2..e8630f9de24a 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1625,7 +1625,7 @@ int neigh_table_clear(int index, struct neigh_table *tbl)
}
EXPORT_SYMBOL(neigh_table_clear);
-static struct neigh_table *neigh_find_table(int family)
+struct neigh_table *neigh_find_table(struct net *net, u8 family)
{
struct neigh_table *tbl = NULL;
@@ -1643,6 +1643,7 @@ static struct neigh_table *neigh_find_table(int family)
return tbl;
}
+EXPORT_SYMBOL(neigh_find_table);
static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh,
struct netlink_ext_ack *extack)
@@ -1672,7 +1673,7 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh,
}
}
- tbl = neigh_find_table(ndm->ndm_family);
+ tbl = neigh_find_table(net, ndm->ndm_family);
if (tbl == NULL)
return -EAFNOSUPPORT;
@@ -1740,7 +1741,7 @@ static int neigh_add(struct sk_buff *skb, struct nlmsghdr *nlh,
goto out;
}
- tbl = neigh_find_table(ndm->ndm_family);
+ tbl = neigh_find_table(net, ndm->ndm_family);
if (tbl == NULL)
return -EAFNOSUPPORT;
--
2.11.0
^ permalink raw reply related
* [PATCH RFC/RFT net-next 01/17] net/ipv4: rename ipv4_neigh_lookup to ipv4_dst_neigh_lookup
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
In-Reply-To: <20180717120651.15748-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Consistency with ipv6 name for similar function and allows
ipv4_neigh_lookup to be reused for the wrapper to the arp table.
---
net/ipv4/route.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1df6e97106d7..74e1df60ab7f 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -153,7 +153,7 @@ static u32 *ipv4_cow_metrics(struct dst_entry *dst, unsigned long old)
return NULL;
}
-static struct neighbour *ipv4_neigh_lookup(const struct dst_entry *dst,
+static struct neighbour *ipv4_dst_neigh_lookup(const struct dst_entry *dst,
struct sk_buff *skb,
const void *daddr);
static void ipv4_confirm_neigh(const struct dst_entry *dst, const void *daddr);
@@ -170,7 +170,7 @@ static struct dst_ops ipv4_dst_ops = {
.update_pmtu = ip_rt_update_pmtu,
.redirect = ip_do_redirect,
.local_out = __ip_local_out,
- .neigh_lookup = ipv4_neigh_lookup,
+ .neigh_lookup = ipv4_dst_neigh_lookup,
.confirm_neigh = ipv4_confirm_neigh,
};
@@ -430,7 +430,7 @@ void rt_cache_flush(struct net *net)
rt_genid_bump_ipv4(net);
}
-static struct neighbour *ipv4_neigh_lookup(const struct dst_entry *dst,
+static struct neighbour *ipv4_dst_neigh_lookup(const struct dst_entry *dst,
struct sk_buff *skb,
const void *daddr)
{
@@ -2537,7 +2537,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
.update_pmtu = ipv4_rt_blackhole_update_pmtu,
.redirect = ipv4_rt_blackhole_redirect,
.cow_metrics = ipv4_rt_blackhole_cow_metrics,
- .neigh_lookup = ipv4_neigh_lookup,
+ .neigh_lookup = ipv4_dst_neigh_lookup,
};
struct dst_entry *ipv4_blackhole_route(struct net *net, struct dst_entry *dst_orig)
--
2.11.0
^ permalink raw reply related
* [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace
From: dsahern @ 2018-07-17 12:06 UTC (permalink / raw)
To: netdev
Cc: nikita.leshchenko, roopa, stephen, idosch, jiri, saeedm,
alex.aring, linux-wpan, netfilter-devel, linux-kernel,
David Ahern
From: David Ahern <dsahern@gmail.com>
Nikita Leshenko reported that neighbor entries in one namespace can
evict neighbor entries in another. The problem is that the neighbor
tables have entries across all namespaces without separate accounting
and with global limits on when to scan for entries to evict.
Resolve by making the neighbor tables for ipv4, ipv6 and decnet per
namespace and making the accounting and threshold limits per namespace.
David Ahern (17):
net/ipv4: rename ipv4_neigh_lookup to ipv4_dst_neigh_lookup
net/neigh: export neigh_find_table
net/ipv4: wrappers for arp table references
net/ipv4: Remove open coded use of arp table
net/ipv6: wrappers for neighbor table references
net/ipv6: Remove open coded use of neighbor table
drivers/net: remove open coding of neighbor tables
net: Remove nd_tbl from ipv6 stub
net: Remove arp_tbl and nd_tbl from headers
net: Add key_len to neighbor constructor
net: Change neigh_table_init and neigh_table_clear signature
net/neigh: Change neigh_xmit to take an address family
net/neighbor: Convert internal functions away from neigh_tables
net/ipv4: Convert arp table to per namespace
net/ipv6: Convert neighbor table to per-namespace
net/decnet: Move neighbor table to per-namespace
net/neighbor: Remove neigh_tables and NEIGH enum
drivers/infiniband/ulp/ipoib/ipoib_main.c | 14 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 35 ++---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 11 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 27 ++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 8 +-
.../ethernet/netronome/nfp/flower/tunnel_conf.c | 2 +-
drivers/net/ethernet/rocker/rocker_main.c | 4 +-
drivers/net/ethernet/rocker/rocker_ofdpa.c | 2 +-
drivers/net/vrf.c | 4 +-
drivers/net/vxlan.c | 10 +-
include/net/addrconf.h | 1 -
include/net/arp.h | 25 +++-
include/net/ndisc.h | 75 +++++++++-
include/net/neighbour.h | 17 +--
include/net/net_namespace.h | 3 +
include/net/netns/ipv4.h | 1 +
include/net/netns/ipv6.h | 1 +
net/atm/clip.c | 14 +-
net/bridge/br_arp_nd_proxy.c | 4 +-
net/core/filter.c | 3 +-
net/core/neighbour.c | 115 +++++++++-----
net/decnet/dn_neigh.c | 8 +-
net/ieee802154/6lowpan/tx.c | 2 +-
net/ipv4/arp.c | 130 +++++++++-------
net/ipv4/devinet.c | 8 +-
net/ipv4/fib_semantics.c | 2 +-
net/ipv4/ip_output.c | 2 +-
net/ipv4/route.c | 12 +-
net/ipv6/addrconf.c | 16 +-
net/ipv6/af_inet6.c | 1 -
net/ipv6/ip6_output.c | 4 +-
net/ipv6/ndisc.c | 165 +++++++++++----------
net/ipv6/route.c | 12 +-
net/mpls/af_mpls.c | 33 ++---
net/mpls/mpls_iptunnel.c | 6 +-
net/netfilter/nf_flow_table_ip.c | 4 +-
net/netfilter/nft_fwd_netdev.c | 6 +-
37 files changed, 467 insertions(+), 320 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] rds: IPv6 support
From: Sowmini Varadhan @ 2018-07-17 11:27 UTC (permalink / raw)
To: Ka-Cheong Poon; +Cc: netdev, santosh.shilimkar, davem, rds-devel
In-Reply-To: <954b0239-5d03-997c-d242-cbbd8c0dc8e4@oracle.com>
On (07/17/18 13:32), Ka-Cheong Poon wrote:
>
> The app can use either structures to make the call. When the
> app fills in the structure, it knows what it is filling in,
> either sockaddr_in or sockaddr_in6. So it knows the right size
> to use. The app can also use IPv4 mapped address in a sockaddr_in6
> without a problem.
tupical applications that I have seen in routing applicaitons
will use a union like
union {
struct sockaddr_in sin;
struct sockaddr_in sin5;
}
Or they will use sockadd_storage. Passing down the sizeoof that structure
will do the worng thing thing in the existing code for ipv4 (even
though it will not generate EFAOIT)..
> Could you please explain the inconsistency? An app can use IPv4
> mapped address in a sockaddr_in6 to operate on an IPv4 connection,
> in case you are thinking of this new addition in v3 of the patch.
bind() and connect() are using the sa_family/ss_family to have
the application signal to the kernel about whether ipv4 or ipv6 is
desired. (and bind and connect are doing the right thing for
v4mapped, so that doesnt seem to be a problem there)
In this case you want the application to signal that info via
the optlen. (And the reason for this inconsistency is that you dont
want to deal with the user->kernel copy in the same way?)
--Sowmini
^ permalink raw reply
* Re: [libvirt] opening tap devices that are created in a container
From: Roman Mohr @ 2018-07-17 11:58 UTC (permalink / raw)
To: Martin Kletzander
Cc: fabiand, libvir-list, netdev, jbaron, ebiederm, davem, laine
In-Reply-To: <20180711101005.GA13392@wheatley>
[-- Attachment #1.1: Type: text/plain, Size: 5460 bytes --]
On Wed, Jul 11, 2018 at 12:10 PM <nert@wheatley> wrote:
> On Mon, Jul 09, 2018 at 05:00:49PM -0400, Jason Baron wrote:
> >
> >
> >On 07/08/2018 02:01 AM, Martin Kletzander wrote:
> >> On Thu, Jul 05, 2018 at 06:24:20PM +0200, Roman Mohr wrote:
> >>> On Thu, Jul 5, 2018 at 4:20 PM Jason Baron <jbaron@akamai.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Opening tap devices, such as macvtap, that are created in containers
> is
> >>>> problematic because the interface for opening tap devices is via
> >>>> /dev/tapNN and devtmpfs is not typically mounted inside a container as
> >>>> its not namespace aware. It is possible to do a mknod() in the
> >>>> container, once the tap devices are created, however, since the tap
> >>>> devices are created dynamically its not possible to apriori allow
> access
> >>>> to certain major/minor numbers, since we don't know what these are
> going
> >>>> to be. In addition, its desirable to not allow the mknod capability in
> >>>> containers. This behavior, I think is somewhat inconsistent with the
> >>>> tuntap driver where one can create tuntap devices inside a container
> by
> >>>> first opening /dev/net/tun and then using them by supplying the tuntap
> >>>> device name via the ioctl(TUNSETIFF). And since TUNSETIFF validates
> the
> >>>> network namespace, one is limited to opening network devices that
> belong
> >>>> to your current network namespace.
> >>>>
> >>>> Here are some options to this issue, that I wanted to get feedback
> >>>> about, and just wondering if anybody else has run into this.
> >>>>
> >>>> 1)
> >>>>
> >>>> Don't create the tap device, such as macvtap in the container.
> Instead,
> >>>> create the tap device outside of the container and then move it into
> the
> >>>> desired container network namespace. In addition, do a mknod() for the
> >>>> corresponding /dev/tapNN device from outside the container before
> doing
> >>>> chroot().
> >>>>
> >>>> This solution still doesn't allow tap devices to be created inside the
> >>>> container. Thus, in the case of kubevirt, which runs libvirtd inside
> of
> >>>> a container, it would mean changing libvirtd to open existing tap
> >>>> devices (as opposed to the current behavior of creating new ones).
> This
> >>>> would not require any kernel changes, but as mentioned seems
> >>>> inconsistent with the tuntap interface.
> >>>>
> >>>
> >>> For KubeVirt, apart from how exactly the device ends up in the
> >>> container, I
> >>> would want to pursue a way where all network preparations which require
> >>> privileges happens from a privileged process *outside* of the
> container.
> >>> Like CNI solutions do it. They run outside, have privileges and then
> >>> create
> >>> devices in the right network/mount namespace or move them there. The
> >>> final
> >>> goal for KubeVirt is that our pod with the qemu process is completely
> >>> unprivileged and privileged setup happens from outside.
> >>>
> >>> As a consequence, and depending on which route Dan pursues with the
> >>> restructured libvirt, I would assume that either a privileged
> >>> libvirtd-part
> >>> outside of containers creates the devices by entering the right
> >>> namespaces,
> >>> or that libvirt in the container can consume pre-created tun/tap
> devices,
> >>> like qemu.
> >>>
> >>
> >> That would be nice, but as far as I understand there will always be a
> >> need for
> >> some privileges if you want to use a tap device. It's nice that CNI
> >> does that
> >> and all the containers can run unprivileged, but that's because they do
> >> not open
> >> the tap device and they do not do any privileged operations on it. But
> >> QEMU
> >> needs to. So the only way would be passing an opened fd to the
> >> container or
> >> opening the tap device there and making the fd usable for one process in
> >> the
> >> container. Is this already supported for some type of containers in
> >> some way?
> >>
> >> Martin
> >
> >Hi,
> >
> >So another option here call it #3 is to pass open fds via unix sockets.
> >If there are privileged operations that QEMU is trying to do with the fd
> >though, how will opening it first and then passing it to an unprivileged
> >QEMU address that? Is the opener doing those operations first?
> >
>
> Sorry for the confusion, but QEMU is not doing any privileged operations.
> I got
> confused by the fact that anyone can open and do a R/W on a tap device.
> But it
> looks like that's on purpose. No capabilities are needed for opening
> /dev/net/tun and calling ioctl(TUNSETIFF) with existing name and then
> doing R/W
> operations on it. It just works.
>
> Correct me if I'm wrong, but to sum it all up, the only things that we
> need to
> figure out (which might possibly be solved by ideas in the other thread)
> are:
>
> tap:
> - Existence of /dev/net/tun
> - Having permissions to open it (0666 by default, shouldn't be a nig deal)
> - Knowing the device name
>
> macvtap:
> - Existence of /dev/tapXX
> - Having permissions to open /dev/tapXX
> - One of the following:
> - Knowing the device name (and being able to translate it using a
> netlink socket)
> - Knowing the the device index
>
> The rest should be an implementation detail.
>
> Am I right? Did I miss anything?
At least from the KubeVirt use-case that sounds to be the things which we
would need to solve the networking setup in a similar way like the
Container Network Interface implementations solve the setup in k8s.
Best Regards,
Roman
[-- Attachment #1.2: Type: text/html, Size: 6899 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Hanna Hawa @ 2018-07-17 11:54 UTC (permalink / raw)
To: torvalds
Cc: corbet, davem, edumazet, gregkh, griebichler.josef, hannes,
jbrouer, linux-kernel, linux-media, linux-usb, mchehab, mingo,
netdev, pabeni, peterz, riel, stern, dmaengine, vkoul,
dan.j.williams, nadavh, thomas.petazzoni, Omri Itach
In-Reply-To: <CA+55aFwuAojr7vAfiRO-2je-wDs7pu+avQZNhX_k9NN=D7_zVQ@mail.gmail.com>
Hi,
I'm a software developer working in Marvell SoC team.
I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040 SoC
with 4 ARMv8 cores of CA72)
Raid 5 built with Marvell DMA engine and async_tx mechanism
(ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2) uses a tasklet to clean
the done descriptors from the queue.
The panic (see below) occurs while building the RAID-5 (mdadm) or while
writing/reading to the raid partition.
After some debug/bisect/diff, found that patch "softirq: Let ksoftirqd
do its job" is problematic patch.
- Using v4.14.0 and problematic patch reverted - no timout issue.
- Using v4.14.0 (including softirq patch) and the additional fix
proposed by Linus - no timeout issue.
As others have reported in this thread, the softirq change is causing
some regression.
Would it be possible to either revert the patch or apply a fix such as
the one proposed by Linus ?
Below panic message:
[ 25.371495] mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
[ 25.377101] Kernel panic - not syncing: async_tx_quiesce: DMA error
waiting for transaction
[ 25.377101]
[ 25.386973] CPU: 0 PID: 1417 Comm: md0_raid5 Not tainted 4.14.0 #16
[ 25.393264] Hardware name: Marvell Armada 8040 DB board (DT)
[ 25.398946] Call trace:
[ 25.401410] [<ffff000008089310>] dump_backtrace+0x0/0x380
[ 25.406831] [<ffff0000080896a4>] show_stack+0x14/0x20
[ 25.411904] [<ffff00000890fa78>] dump_stack+0x98/0xb8
[ 25.416976] [<ffff0000080c8ef0>] panic+0x118/0x280
[ 25.421788] [<ffff000008386a44>] async_tx_quiesce+0x74/0x78
[ 25.427382] [<ffff000008386ca4>] async_memcpy+0x1a4/0x2a0
[ 25.432806] [<ffff000008747f9c>] async_copy_data.isra.16+0x1b4/0x280
[ 25.439186] [<ffff00000874b6fc>] raid_run_ops+0x514/0x1320
[ 25.444694] [<ffff000008751550>] handle_stripe+0x1040/0x2848
[ 25.450377] [<ffff000008752f98>]
handle_active_stripes.isra.28+0x240/0x460
[ 25.457279] [<ffff000008753468>] raid5d+0x2b0/0x450
[ 25.462177] [<ffff00000875ead4>] md_thread+0x104/0x160
[ 25.467338] [<ffff0000080e638c>] kthread+0xfc/0x128
[ 25.472234] [<ffff000008085354>] ret_from_fork+0x10/0x1c
[ 25.477571] Kernel Offset: disabled
[ 25.481073] CPU features: 0x002000
[ 25.484487] Memory Limit: none
[ 25.487556] ---[ end Kernel panic - not syncing: async_tx_quiesce:
DMA error waiting for transaction
[ 25.487556]
Thanks,
Hanna
^ permalink raw reply
* Re: [PATCH net-next 1/3] docs: networking: Fix indices heading indentation
From: Markus Heiser @ 2018-07-17 11:45 UTC (permalink / raw)
To: Tobin C. Harding, David S. Miller; +Cc: linux-doc, netdev, linux-kernel
In-Reply-To: <1d7a309eb7561b9bb4c31f5deb9a0b63b6263232.camel@darmarit.de>
Am Dienstag, den 17.07.2018, 10:28 +0200 schrieb Markus Heiser:
> Am Dienstag, den 17.07.2018, 14:29 +1000 schrieb Tobin C. Harding:
> > Currently the 'Indices' heading is not aligned with column 0, it should
> > be.
>
> Hi Tobin, thats not correct. The 'Indices' heading is a part of the 'only'
> block:
>
> http://www.sphinx-doc.org/en/stable/markup/misc.html#including-content-based-on-tags
>
> -- Markus --
I realized that we have not well documented SPHINXDIRS, to be more elaborate ..
The tag 'subproject' will be set from the networking/conf.py if you run:
make -k SPHINXDIRS="networking" htmldocs
to just build only the networking folder (aka subproject). For more info,
please run 'make help' and take a look at the 'Documentation targets' section.
In short: a subfolder of Documentation/ with a conf.py file in, is a subproject
and can be build separate.
-- Markus --
>
> >
> > Fix 'Indices' heading indentation.
> >
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> > ---
> > Documentation/networking/index.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
> > index 6123a7e9e1da..a4bbde70bcb9 100644
> > --- a/Documentation/networking/index.rst
> > +++ b/Documentation/networking/index.rst
> > @@ -20,7 +20,7 @@ Contents:
> >
> > .. only:: subproject
> >
> > - Indices
> > - =======
> > +Indices
> > +=======
> >
> > * :ref:`genindex`
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" 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
* [PATCH] Bluetooth: Use lock_sock_nested in bt_accept_enqueue
From: Philipp Puschmann @ 2018-07-17 11:41 UTC (permalink / raw)
To: marcel
Cc: johan.hedberg, davem, linux-bluetooth, netdev, linux-kernel,
Philipp Puschmann
Fixes this warning that was provoked by a pairing:
[60258.016221] WARNING: possible recursive locking detected
[60258.021558] 4.15.0-RD1812-BSP #1 Tainted: G O
[60258.027146] --------------------------------------------
[60258.032464] kworker/u5:0/70 is trying to acquire lock:
[60258.037609] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<87759073>] bt_accept_enqueue+0x3c/0x74
[60258.046863]
[60258.046863] but task is already holding lock:
[60258.052704] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.062905]
[60258.062905] other info that might help us debug this:
[60258.069441] Possible unsafe locking scenario:
[60258.069441]
[60258.075368] CPU0
[60258.077821] ----
[60258.080272] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.085510] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.090748]
[60258.090748] *** DEADLOCK ***
[60258.090748]
[60258.096676] May be due to missing lock nesting notation
[60258.096676]
[60258.103472] 5 locks held by kworker/u5:0/70:
[60258.107747] #0: ((wq_completion)%shdev->name#2){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
[60258.117263] #1: ((work_completion)(&hdev->rx_work)){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
[60258.126942] #2: (&conn->chan_lock){+.+.}, at: [<7877c8c3>] l2cap_connect+0x80/0x4f8
[60258.134806] #3: (&chan->lock/2){+.+.}, at: [<2e16c724>] l2cap_connect+0x8c/0x4f8
[60258.142410] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.153043]
[60258.153043] stack backtrace:
[60258.157413] CPU: 1 PID: 70 Comm: kworker/u5:0 Tainted: G O 4.15.0-RD1812-BSP #1
[60258.165945] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[60258.172485] Workqueue: hci0 hci_rx_work
[60258.176331] Backtrace:
[60258.178797] [<8010c9fc>] (dump_backtrace) from [<8010ccbc>] (show_stack+0x18/0x1c)
[60258.186379] r7:80e55fe4 r6:80e55fe4 r5:20050093 r4:00000000
[60258.192058] [<8010cca4>] (show_stack) from [<809864e8>] (dump_stack+0xb0/0xdc)
[60258.199301] [<80986438>] (dump_stack) from [<8016ecc8>] (__lock_acquire+0xffc/0x11d4)
[60258.207144] r9:5e2bb019 r8:630f974c r7:ba8a5940 r6:ba8a5ed8 r5:815b5220 r4:80fa081c
[60258.214901] [<8016dccc>] (__lock_acquire) from [<8016f620>] (lock_acquire+0x78/0x98)
[60258.222655] r10:00000040 r9:00000040 r8:808729f0 r7:00000001 r6:00000000 r5:60050013
[60258.230491] r4:00000000
[60258.233045] [<8016f5a8>] (lock_acquire) from [<806ee974>] (lock_sock_nested+0x64/0x88)
[60258.240970] r7:00000000 r6:b796e870 r5:00000001 r4:b796e800
[60258.246643] [<806ee910>] (lock_sock_nested) from [<808729f0>] (bt_accept_enqueue+0x3c/0x74)
[60258.255004] r8:00000001 r7:ba7d3c00 r6:ba7d3ea4 r5:ba7d2000 r4:b796e800
[60258.261717] [<808729b4>] (bt_accept_enqueue) from [<808aa39c>] (l2cap_sock_new_connection_cb+0x68/0x88)
[60258.271117] r5:b796e800 r4:ba7d2000
[60258.274708] [<808aa334>] (l2cap_sock_new_connection_cb) from [<808a294c>] (l2cap_connect+0x190/0x4f8)
[60258.283933] r5:00000001 r4:ba6dce00
[60258.287524] [<808a27bc>] (l2cap_connect) from [<808a4a14>] (l2cap_recv_frame+0x744/0x2cf8)
[60258.295800] r10:ba6dcf24 r9:00000004 r8:b78d8014 r7:00000004 r6:bb05d000 r5:00000004
[60258.303635] r4:bb05d008
[60258.306183] [<808a42d0>] (l2cap_recv_frame) from [<808a7808>] (l2cap_recv_acldata+0x210/0x214)
[60258.314805] r10:b78e7800 r9:bb05d960 r8:00000001 r7:bb05d000 r6:0000000c r5:b7957a80
[60258.322641] r4:ba6dce00
[60258.325188] [<808a75f8>] (l2cap_recv_acldata) from [<8087630c>] (hci_rx_work+0x35c/0x4e8)
[60258.333374] r6:80e5743c r5:bb05d7c8 r4:b7957a80
[60258.338004] [<80875fb0>] (hci_rx_work) from [<8013dc7c>] (process_one_work+0x1a4/0x4fc)
[60258.346018] r10:00000001 r9:00000000 r8:baabfef8 r7:ba997500 r6:baaba800 r5:baaa5d00
[60258.353853] r4:bb05d7c8
[60258.356401] [<8013dad8>] (process_one_work) from [<8013e028>] (worker_thread+0x54/0x5cc)
[60258.364503] r10:baabe038 r9:baaba834 r8:80e05900 r7:00000088 r6:baaa5d18 r5:baaba800
[60258.372338] r4:baaa5d00
[60258.374888] [<8013dfd4>] (worker_thread) from [<801448f8>] (kthread+0x134/0x160)
[60258.382295] r10:ba8310b8 r9:bb07dbfc r8:8013dfd4 r7:baaa5d00 r6:00000000 r5:baaa8ac0
[60258.390130] r4:ba831080
[60258.392682] [<801447c4>] (kthread) from [<801080b4>] (ret_from_fork+0x14/0x20)
[60258.399915] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801447c4
[60258.407751] r4:baaa8ac0 r3:baabe000
Signed-off-by: Philipp Puschmann <pp@emlix.com>
---
net/bluetooth/af_bluetooth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 3264e1873219..deacc52d7ff1 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -159,7 +159,7 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk)
BT_DBG("parent %p, sk %p", parent, sk);
sock_hold(sk);
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
bt_sk(sk)->parent = parent;
release_sock(sk);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-17 10:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Steve Wise, Sagi Grimberg, Doug Ledford, Jason Gunthorpe,
RDMA mailing list, Saeed Mahameed, linux-netdev
In-Reply-To: <20180717085831.GB3152@mtr-leonro.mtl.com>
On 7/17/2018 11:58 AM, Leon Romanovsky wrote:
> On Tue, Jul 17, 2018 at 11:46:40AM +0300, Max Gurtovoy wrote:
>>
>>
>> On 7/16/2018 8:08 PM, Steve Wise wrote:
>>> Hey Max:
>>>
>>>
>>
>> Hey,
>>
>>> On 7/16/2018 11:46 AM, Max Gurtovoy wrote:
>>>>
>>>>
>>>> On 7/16/2018 5:59 PM, Sagi Grimberg wrote:
>>>>>
>>>>>> Hi,
>>>>>> I've tested this patch and seems problematic at this moment.
>>>>>
>>>>> Problematic how? what are you seeing?
>>>>
>>>> Connection failures and same error Steve saw:
>>>>
>>>> [Mon Jul 16 16:19:11 2018] nvme nvme0: Connect command failed, error
>>>> wo/DNR bit: -16402
>>>> [Mon Jul 16 16:19:11 2018] nvme nvme0: failed to connect queue: 2 ret=-18
>>>>
>>>>
>>>>>
>>>>>> maybe this is because of the bug that Steve mentioned in the NVMe
>>>>>> mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
>>>>>> initiator and I'll run his suggestion as well.
>>>>>
>>>>> Is your device irq affinity linear?
>>>>
>>>> When it's linear and the balancer is stopped the patch works.
>>>>
>>>>>
>>>>>> BTW, when I run the blk_mq_map_queues it works for every irq affinity.
>>>>>
>>>>> But its probably not aligned to the device vector affinity.
>>>>
>>>> but I guess it's better in some cases.
>>>>
>>>> I've checked the situation before Leon's patch and set all the vetcors
>>>> to CPU 0. In this case (I think that this was the initial report by
>>>> Steve), we use the affinity_hint (Israel's and Saeed's patches were we
>>>> use dev->priv.irq_info[vector].mask) and it worked fine.
>>>>
>>>> Steve,
>>>> Can you share your configuration (kernel, HCA, affinity map, connect
>>>> command, lscpu) ?
>>>> I want to repro it in my lab.
>>>>
>>>
>>> - linux-4.18-rc1 + the nvme/nvmet inline_data_size patches + patches to
>>> enable ib_get_vector_affinity() in cxgb4 + sagi's patch + leon's mlx5
>>> patch so I can change the affinity via procfs.
>>
>> ohh, now I understand that you where complaining regarding the affinity
>> change reflection to mlx5_ib_get_vector_affinity and not regarding the
>> failures on connecting while the affinity overlaps (that is working good
>> before Leon's patch).
>> So this is a known issue since we used a static hint that never changes
>> from dev->priv.irq_info[vector].mask.
>>
>> IMO we must fulfil the user wish to connect to N queues and not reduce it
>> because of affinity overlaps. So in order to push Leon's patch we must
>> also fix the blk_mq_rdma_map_queues to do a best effort mapping according
>> the affinity and map the rest in naive way (in that way we will *always*
>> map all the queues).
>
> Max,
>
> I have no clue what is needed to do int blq_mq*, but my patch only gave
> to users ability reconfigure their affinity mask after driver is loaded.
Yes I know, but since the only user of this API is the blk-mq-rdma and
the nvme_rdma driver that can't establish connection with your patch - I
suggest to wait with pushing it and fix the mapping of
blk_mq_rdma_map_queues
>
> Thanks
>
>>
>> -Max.
>>
^ permalink raw reply
* Re: [PATCH next] bonding: pass link-local packets to bonding master also.
From: Michal Soltys @ 2018-07-17 9:55 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार),
Stephen Hemminger
Cc: Mahesh Bandewar, Jay Vosburgh, Andy Gospodarek, Veaceslav Falico,
David Miller, Netdev
In-Reply-To: <CAF2d9jjTh2ksyfe_n8yzvBB6ux8CPXWbr+m7XzKYR3iwkOcE8Q@mail.gmail.com>
On 07/17/2018 01:57 AM, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Mon, Jul 16, 2018 at 4:33 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>> On Sun, 15 Jul 2018 18:12:46 -0700
>> Mahesh Bandewar <mahesh@bandewar.net> wrote:
>>
>>> From: Mahesh Bandewar <maheshb@google.com>
>>>
>>> Commit b89f04c61efe ("bonding: deliver link-local packets with
>>> skb->dev set to link that packets arrived on") changed the behavior
>>> of how link-local-multicast packets are processed. The change in
>>> the behavior broke some legacy use cases where these packets are
>>> expected to arrive on bonding master device also.
>>>
>>> This patch passes the packet to the stack with the link it arrived
>>> on as well as passes to the bonding-master device to preserve the
>>> legacy use case.
>>>
>>> Reported-by: Michal Soltys <soltys@ziu.info>
>>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>>
>> Thanks for fixing this.
>>
>> Why not add a Fixes: tag instead of just talking about the commit?
>> That helps the stable maintainers know which versions of the kernel
>> need the patch.
> Well, I thought about it. It's definitely 'related' but not sure it
> 'fixes' in true sense. It definitely fixes the broken legacy case
> though. Is that sufficient to add 'fixes' tag?
>
It's __not__ broken legacy case. It's normal behavior, starting with
specification covering LLDP itself (IEEE Std 802.1AB-2016, page 18, '6.8 LLDP
and Link Aggregation') and ending with a linux bridge actively doing stp via
in-kernel implementation or with userspace helper (or inactively passing) and
being blind to bpdus. Not mentioning a very recent kernel feature like
per-port group_fwd_mask rendered useless in this case.
Unless you also consider attaching a bond to a linux bridge as a broken legacy
use case. Among other things mentioned in the other thread.
In this context, the comment in code/log message IMHO (of the attached patch),
should be changed - as it will be just confusing for anyone reading it in the
future.
(and I'd very much like the fix to hit relevant stable kernels as well)
^ permalink raw reply
* [PATCH net-next v2] net: Move skb decrypted field, avoid explicity copy
From: Stefano Brivio @ 2018-07-17 9:52 UTC (permalink / raw)
To: David S. Miller; +Cc: Boris Pismenny, Stephen Rothwell, netdev
Commit 784abe24c903 ("net: Add decrypted field to skb")
introduced a 'decrypted' field that is explicitly copied on skb
copy and clone.
Move it between headers_start[0] and headers_end[0], so that we
don't need to copy it explicitly as it's copied by the memcpy()
in __copy_skb_header().
While at it, drop the assignment in __skb_clone(), it was
already redundant.
This doesn't change the size of sk_buff or cacheline boundaries.
The 15-bits hole before tc_index becomes a 14-bits hole, and
will be again a 15-bits hole when this change is merged with
commit 8b7008620b84 ("net: Don't copy pfmemalloc flag in
__copy_skb_header()").
v2: as reported by kbuild test robot (oops, I forgot to build
with CONFIG_TLS_DEVICE it seems), we can't use
CHECK_SKB_FIELD() on a bit-field member. Just drop the
check for the moment being, perhaps we could think of some
magic to also check bit-field members one day.
Fixes: 784abe24c903 ("net: Add decrypted field to skb")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
include/linux/skbuff.h | 9 ++++-----
net/core/skbuff.c | 6 ------
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 3ceb8dcc54da..14bc9ebe30f2 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -630,7 +630,6 @@ typedef unsigned char *sk_buff_data_t;
* @hash: the packet hash
* @queue_mapping: Queue mapping for multiqueue devices
* @xmit_more: More SKBs are pending for this queue
- * @decrypted: Decrypted SKB
* @ndisc_nodetype: router type (from link layer)
* @ooo_okay: allow the mapping of a socket to a queue to be changed
* @l4_hash: indicate hash is a canonical 4-tuple hash over transport
@@ -641,6 +640,7 @@ typedef unsigned char *sk_buff_data_t;
* @no_fcs: Request NIC to treat last 4 bytes as Ethernet FCS
* @csum_not_inet: use CRC32c to resolve CHECKSUM_PARTIAL
* @dst_pending_confirm: need to confirm neighbour
+ * @decrypted: Decrypted SKB
* @napi_id: id of the NAPI struct this skb came from
* @secmark: security marking
* @mark: Generic packet mark
@@ -737,11 +737,7 @@ struct sk_buff {
peeked:1,
head_frag:1,
xmit_more:1,
-#ifdef CONFIG_TLS_DEVICE
- decrypted:1;
-#else
__unused:1;
-#endif
/* fields enclosed in headers_start/headers_end are copied
* using a single memcpy() in __copy_skb_header()
@@ -797,6 +793,9 @@ struct sk_buff {
__u8 tc_redirected:1;
__u8 tc_from_ingress:1;
#endif
+#ifdef CONFIG_TLS_DEVICE
+ __u8 decrypted:1;
+#endif
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index cfd6c6f35f9c..c4e24ac27464 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -805,9 +805,6 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
* It is not yet because we do not want to have a 16 bit hole
*/
new->queue_mapping = old->queue_mapping;
-#ifdef CONFIG_TLS_DEVICE
- new->decrypted = old->decrypted;
-#endif
memcpy(&new->headers_start, &old->headers_start,
offsetof(struct sk_buff, headers_end) -
@@ -868,9 +865,6 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
C(head_frag);
C(data);
C(truesize);
-#ifdef CONFIG_TLS_DEVICE
- C(decrypted);
-#endif
refcount_set(&n->users, 1);
atomic_inc(&(skb_shinfo(skb)->dataref));
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible
From: Dave Taht @ 2018-07-17 9:38 UTC (permalink / raw)
To: Paolo Abeni
Cc: Cong Wang, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiří Pírko, ast, Daniel Borkmann,
Marcelo Ricardo Leitner, eyal.birger
In-Reply-To: <7f151d07041f0c0d3ecebad1629bf5803ed4133d.camel@redhat.com>
On Tue, Jul 17, 2018 at 2:16 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hi,
>
> On Mon, 2018-07-16 at 16:39 -0700, Cong Wang wrote:
> > On Fri, Jul 13, 2018 at 2:55 AM Paolo Abeni <pabeni@redhat.com> wrote:
> > >
> > > When mirred is invoked from the ingress path, and it wants to redirect
> > > the processed packet, it can now use the ACT_REDIRECT action,
> > > filling the tcf_result accordingly.
> > >
> > > This avoids a skb_clone() in the TC S/W data path giving a ~10%
> > > improvement in forwarding performances. Overall TC S/W performances
> > > are now comparable to the kernel openswitch datapath.
>
> Thank you for the feedback.
>
> > Avoiding skb_clone() for redirection is cool, but why need to use
> > skb_do_redirect() here?
>
> Well, it's not needed. I tried to reduce code duplication, and I tried
> to avoid adding another TC_ACT_* value.
>
> > There is a subtle difference here:
> >
> > skb_do_redirect() calls __bpf_rx_skb() which calls
> > dev_forward_skb().
> >
> > while the current mirred action doesn't scrub packets when
> > redirecting to ingress (from egress). Although I forget if it is
> > intentionally.
>
> Understood.
>
> A possible option out of this issues would be adding another action
> value - TC_ACT_MIRRED ? - and handle it in sch_handle_egress()[1] with
> the appropriate semantic. That should address also Daniel and Eyal
> concerns.
>
> Would you consider the above acceptable?
Our dream has been to be able to specify a 1 liner:
tc qdisc add dev eth0 ingress cake bandwidth 200mbit besteffort wash
and be done with it, eliminating ifb, mirred, etc, entirely.
(I am otherwise delighted to see anything appear that makes inbound
shaping cheaper along the lines of this patchset)
>
> Thanks,
>
> Paolo
>
>
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
^ permalink raw reply
* Re: [PATCH next] bonding: pass link-local packets to bonding master also.
From: Michal Soltys @ 2018-07-17 9:32 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार),
Jay Vosburgh
Cc: Mahesh Bandewar, Andy Gospodarek, Veaceslav Falico, David Miller,
Netdev, Stephen Hemminger
In-Reply-To: <CAF2d9jgFEn2POF0L-ZXAwgtC_mqbni8ir9zT7EvrbxLd6CSQpg@mail.gmail.com>
On 07/17/2018 01:53 AM, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Mon, Jul 16, 2018 at 2:24 PM, Jay Vosburgh
> <jay.vosburgh@canonical.com> wrote:
>> Mahesh Bandewar <mahesh@bandewar.net> wrote:
>>
>>> From: Mahesh Bandewar <maheshb@google.com>
>>>
>>> Commit b89f04c61efe ("bonding: deliver link-local packets with
>>> skb->dev set to link that packets arrived on") changed the behavior
>>> of how link-local-multicast packets are processed. The change in
>>> the behavior broke some legacy use cases where these packets are
>>> expected to arrive on bonding master device also.
>>>
>>> This patch passes the packet to the stack with the link it arrived
>>> on as well as passes to the bonding-master device to preserve the
>>> legacy use case.
>>
>> Michal, can you test this? I'm travelling this week and won't
>> be able to run the patch.
Yes, will test today and report.
^ permalink raw reply
* Re: [PATCH net-next] net: Move skb decrypted field, avoid explicity copy
From: kbuild test robot @ 2018-07-17 9:25 UTC (permalink / raw)
To: Stefano Brivio
Cc: kbuild-all, David S. Miller, Boris Pismenny, Stephen Rothwell,
netdev
In-Reply-To: <d277733a2eb3b5ffa2cbdbe4bd2a261d8fb60a0f.1531811764.git.sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6201 bytes --]
Hi Stefano,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Stefano-Brivio/net-Move-skb-decrypted-field-avoid-explicity-copy/20180717-152125
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from net//core/skbuff.c:41:
net//core/skbuff.c: In function '__copy_skb_header':
net//core/skbuff.c:787:31: error: attempt to take address of bit-field structure member 'decrypted'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^
include/linux/compiler.h:316:19: note: in definition of macro '__compiletime_assert'
bool __cond = !(condition); \
^~~~~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> net//core/skbuff.c:787:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^~~~~~~~~~~~
include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^~~~~~~~~~~~~~~~~~~
>> net//core/skbuff.c:787:15: note: in expansion of macro 'offsetof'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^~~~~~~~
>> net//core/skbuff.c:837:2: note: in expansion of macro 'CHECK_SKB_FIELD'
CHECK_SKB_FIELD(decrypted);
^~~~~~~~~~~~~~~
net//core/skbuff.c:789:31: error: attempt to take address of bit-field structure member 'decrypted'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^
include/linux/compiler.h:316:19: note: in definition of macro '__compiletime_assert'
bool __cond = !(condition); \
^~~~~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
net//core/skbuff.c:789:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^~~~~~~~~~~~
include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^~~~~~~~~~~~~~~~~~~
net//core/skbuff.c:789:15: note: in expansion of macro 'offsetof'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^~~~~~~~
>> net//core/skbuff.c:837:2: note: in expansion of macro 'CHECK_SKB_FIELD'
CHECK_SKB_FIELD(decrypted);
^~~~~~~~~~~~~~~
vim +/CHECK_SKB_FIELD +837 net//core/skbuff.c
784
785 /* Make sure a field is enclosed inside headers_start/headers_end section */
786 #define CHECK_SKB_FIELD(field) \
> 787 BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
788 offsetof(struct sk_buff, headers_start)); \
789 BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
790 offsetof(struct sk_buff, headers_end)); \
791
792 static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
793 {
794 new->tstamp = old->tstamp;
795 /* We do not copy old->sk */
796 new->dev = old->dev;
797 memcpy(new->cb, old->cb, sizeof(old->cb));
798 skb_dst_copy(new, old);
799 #ifdef CONFIG_XFRM
800 new->sp = secpath_get(old->sp);
801 #endif
802 __nf_copy(new, old, false);
803
804 /* Note : this field could be in headers_start/headers_end section
805 * It is not yet because we do not want to have a 16 bit hole
806 */
807 new->queue_mapping = old->queue_mapping;
808
809 memcpy(&new->headers_start, &old->headers_start,
810 offsetof(struct sk_buff, headers_end) -
811 offsetof(struct sk_buff, headers_start));
812 CHECK_SKB_FIELD(protocol);
813 CHECK_SKB_FIELD(csum);
814 CHECK_SKB_FIELD(hash);
815 CHECK_SKB_FIELD(priority);
816 CHECK_SKB_FIELD(skb_iif);
817 CHECK_SKB_FIELD(vlan_proto);
818 CHECK_SKB_FIELD(vlan_tci);
819 CHECK_SKB_FIELD(transport_header);
820 CHECK_SKB_FIELD(network_header);
821 CHECK_SKB_FIELD(mac_header);
822 CHECK_SKB_FIELD(inner_protocol);
823 CHECK_SKB_FIELD(inner_transport_header);
824 CHECK_SKB_FIELD(inner_network_header);
825 CHECK_SKB_FIELD(inner_mac_header);
826 CHECK_SKB_FIELD(mark);
827 #ifdef CONFIG_NETWORK_SECMARK
828 CHECK_SKB_FIELD(secmark);
829 #endif
830 #ifdef CONFIG_NET_RX_BUSY_POLL
831 CHECK_SKB_FIELD(napi_id);
832 #endif
833 #ifdef CONFIG_XPS
834 CHECK_SKB_FIELD(sender_cpu);
835 #endif
836 #ifdef CONFIG_TLS_DEVICE
> 837 CHECK_SKB_FIELD(decrypted);
838 #endif
839 #ifdef CONFIG_NET_SCHED
840 CHECK_SKB_FIELD(tc_index);
841 #endif
842
---
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: 64662 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible
From: Paolo Abeni @ 2018-07-17 9:15 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger
In-Reply-To: <CAM_iQpVodV_BxKR8T-9Zn26g6gM=PLsip7bjv6SMCB13yQ6YMA@mail.gmail.com>
Hi,
On Mon, 2018-07-16 at 16:39 -0700, Cong Wang wrote:
> On Fri, Jul 13, 2018 at 2:55 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > When mirred is invoked from the ingress path, and it wants to redirect
> > the processed packet, it can now use the ACT_REDIRECT action,
> > filling the tcf_result accordingly.
> >
> > This avoids a skb_clone() in the TC S/W data path giving a ~10%
> > improvement in forwarding performances. Overall TC S/W performances
> > are now comparable to the kernel openswitch datapath.
Thank you for the feedback.
> Avoiding skb_clone() for redirection is cool, but why need to use
> skb_do_redirect() here?
Well, it's not needed. I tried to reduce code duplication, and I tried
to avoid adding another TC_ACT_* value.
> There is a subtle difference here:
>
> skb_do_redirect() calls __bpf_rx_skb() which calls
> dev_forward_skb().
>
> while the current mirred action doesn't scrub packets when
> redirecting to ingress (from egress). Although I forget if it is
> intentionally.
Understood.
A possible option out of this issues would be adding another action
value - TC_ACT_MIRRED ? - and handle it in sch_handle_egress()[1] with
the appropriate semantic. That should address also Daniel and Eyal
concerns.
Would you consider the above acceptable?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net-next 7/9] net: hns3: Fix for reset_level default assignment probelm
From: Sergei Shtylyov @ 2018-07-17 9:37 UTC (permalink / raw)
To: Salil Mehta, davem
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm, Yunsheng Lin
In-Reply-To: <20180716153627.476-8-salil.mehta@huawei.com>
Hello!
On 7/16/2018 6:36 PM, Salil Mehta wrote:
> From: Yunsheng Lin <linyunsheng@huawei.com>
>
> handle->reset_level is assigned to HNAE3_NONE_RESET when client is
> initialized, if a tx timeout happens right after initialization,
> then handle->reset_level is not resetted to HNAE3_FUNC_RESET in
s/resetted/reset/.
> hclge_reset_event, which will cause reset event not properly
> handled problem.
>
> This patch fixes it by setting handle->reset_level properly when
> client is initialized.
>
> Fixes: 6d4c3981a8d8 ("net: hns3: Changes to make enet watchdog timeout func common for PF/VF")
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Leon Romanovsky @ 2018-07-17 8:58 UTC (permalink / raw)
To: Max Gurtovoy
Cc: Steve Wise, Sagi Grimberg, Doug Ledford, Jason Gunthorpe,
RDMA mailing list, Saeed Mahameed, linux-netdev
In-Reply-To: <3f827784-3089-2375-9feb-b3c1701d7471@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]
On Tue, Jul 17, 2018 at 11:46:40AM +0300, Max Gurtovoy wrote:
>
>
> On 7/16/2018 8:08 PM, Steve Wise wrote:
> > Hey Max:
> >
> >
>
> Hey,
>
> > On 7/16/2018 11:46 AM, Max Gurtovoy wrote:
> > >
> > >
> > > On 7/16/2018 5:59 PM, Sagi Grimberg wrote:
> > > >
> > > > > Hi,
> > > > > I've tested this patch and seems problematic at this moment.
> > > >
> > > > Problematic how? what are you seeing?
> > >
> > > Connection failures and same error Steve saw:
> > >
> > > [Mon Jul 16 16:19:11 2018] nvme nvme0: Connect command failed, error
> > > wo/DNR bit: -16402
> > > [Mon Jul 16 16:19:11 2018] nvme nvme0: failed to connect queue: 2 ret=-18
> > >
> > >
> > > >
> > > > > maybe this is because of the bug that Steve mentioned in the NVMe
> > > > > mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
> > > > > initiator and I'll run his suggestion as well.
> > > >
> > > > Is your device irq affinity linear?
> > >
> > > When it's linear and the balancer is stopped the patch works.
> > >
> > > >
> > > > > BTW, when I run the blk_mq_map_queues it works for every irq affinity.
> > > >
> > > > But its probably not aligned to the device vector affinity.
> > >
> > > but I guess it's better in some cases.
> > >
> > > I've checked the situation before Leon's patch and set all the vetcors
> > > to CPU 0. In this case (I think that this was the initial report by
> > > Steve), we use the affinity_hint (Israel's and Saeed's patches were we
> > > use dev->priv.irq_info[vector].mask) and it worked fine.
> > >
> > > Steve,
> > > Can you share your configuration (kernel, HCA, affinity map, connect
> > > command, lscpu) ?
> > > I want to repro it in my lab.
> > >
> >
> > - linux-4.18-rc1 + the nvme/nvmet inline_data_size patches + patches to
> > enable ib_get_vector_affinity() in cxgb4 + sagi's patch + leon's mlx5
> > patch so I can change the affinity via procfs.
>
> ohh, now I understand that you where complaining regarding the affinity
> change reflection to mlx5_ib_get_vector_affinity and not regarding the
> failures on connecting while the affinity overlaps (that is working good
> before Leon's patch).
> So this is a known issue since we used a static hint that never changes
> from dev->priv.irq_info[vector].mask.
>
> IMO we must fulfil the user wish to connect to N queues and not reduce it
> because of affinity overlaps. So in order to push Leon's patch we must
> also fix the blk_mq_rdma_map_queues to do a best effort mapping according
> the affinity and map the rest in naive way (in that way we will *always*
> map all the queues).
Max,
I have no clue what is needed to do int blq_mq*, but my patch only gave
to users ability reconfigure their affinity mask after driver is loaded.
Thanks
>
> -Max.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net-next] liquidio: Using NULL instead of plain integer
From: YueHaibing @ 2018-07-17 9:27 UTC (permalink / raw)
To: derek.chickles, satananda.burla
Cc: linux-kernel, netdev, felix.manlunas, raghu.vatsavayi, davem,
YueHaibing
Fixes the following sparse warnings:
drivers/net/ethernet/cavium/liquidio/lio_main.c:3068:23: warning:
Using plain integer as NULL pointer
drivers/net/ethernet/cavium/liquidio/lio_main.c:2909:23: warning:
Using plain integer as NULL pointer
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c:385:27: warning:
Using plain integer as NULL pointer
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/lio_main.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index 1f8b7f6..91dce8b 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -382,7 +382,7 @@ void cn23xx_vf_ask_pf_to_do_flr(struct octeon_device *oct)
mbox_cmd.recv_len = 0;
mbox_cmd.recv_status = 0;
mbox_cmd.fn = NULL;
- mbox_cmd.fn_arg = 0;
+ mbox_cmd.fn_arg = NULL;
octeon_mbox_write(oct, &mbox_cmd);
}
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index a60d5af..dd76477 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2906,7 +2906,7 @@ static int liquidio_set_vf_vlan(struct net_device *netdev, int vfidx,
vfidx + 1; /* vfidx is 0 based, but vf_num (param2) is 1 based */
nctrl.ncmd.s.more = 0;
nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
- nctrl.cb_fn = 0;
+ nctrl.cb_fn = NULL;
nctrl.wait_time = LIO_CMD_WAIT_TM;
octnet_send_nic_ctrl_pkt(oct, &nctrl);
@@ -3065,7 +3065,7 @@ static int liquidio_set_vf_link_state(struct net_device *netdev, int vfidx,
nctrl.ncmd.s.param2 = linkstate;
nctrl.ncmd.s.more = 0;
nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
- nctrl.cb_fn = 0;
+ nctrl.cb_fn = NULL;
nctrl.wait_time = LIO_CMD_WAIT_TM;
octnet_send_nic_ctrl_pkt(oct, &nctrl);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-17 8:46 UTC (permalink / raw)
To: Steve Wise, Sagi Grimberg, Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Saeed Mahameed,
linux-netdev
In-Reply-To: <243215dc-2b06-9c99-a0cb-8a45e0257077@opengridcomputing.com>
On 7/16/2018 8:08 PM, Steve Wise wrote:
> Hey Max:
>
>
Hey,
> On 7/16/2018 11:46 AM, Max Gurtovoy wrote:
>>
>>
>> On 7/16/2018 5:59 PM, Sagi Grimberg wrote:
>>>
>>>> Hi,
>>>> I've tested this patch and seems problematic at this moment.
>>>
>>> Problematic how? what are you seeing?
>>
>> Connection failures and same error Steve saw:
>>
>> [Mon Jul 16 16:19:11 2018] nvme nvme0: Connect command failed, error
>> wo/DNR bit: -16402
>> [Mon Jul 16 16:19:11 2018] nvme nvme0: failed to connect queue: 2 ret=-18
>>
>>
>>>
>>>> maybe this is because of the bug that Steve mentioned in the NVMe
>>>> mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
>>>> initiator and I'll run his suggestion as well.
>>>
>>> Is your device irq affinity linear?
>>
>> When it's linear and the balancer is stopped the patch works.
>>
>>>
>>>> BTW, when I run the blk_mq_map_queues it works for every irq affinity.
>>>
>>> But its probably not aligned to the device vector affinity.
>>
>> but I guess it's better in some cases.
>>
>> I've checked the situation before Leon's patch and set all the vetcors
>> to CPU 0. In this case (I think that this was the initial report by
>> Steve), we use the affinity_hint (Israel's and Saeed's patches were we
>> use dev->priv.irq_info[vector].mask) and it worked fine.
>>
>> Steve,
>> Can you share your configuration (kernel, HCA, affinity map, connect
>> command, lscpu) ?
>> I want to repro it in my lab.
>>
>
> - linux-4.18-rc1 + the nvme/nvmet inline_data_size patches + patches to
> enable ib_get_vector_affinity() in cxgb4 + sagi's patch + leon's mlx5
> patch so I can change the affinity via procfs.
ohh, now I understand that you where complaining regarding the affinity
change reflection to mlx5_ib_get_vector_affinity and not regarding the
failures on connecting while the affinity overlaps (that is working good
before Leon's patch).
So this is a known issue since we used a static hint that never changes
from dev->priv.irq_info[vector].mask.
IMO we must fulfil the user wish to connect to N queues and not reduce
it because of affinity overlaps. So in order to push Leon's patch we
must also fix the blk_mq_rdma_map_queues to do a best effort mapping
according the affinity and map the rest in naive way (in that way we
will *always* map all the queues).
-Max.
^ permalink raw reply
* [PATCH iproute2 net-next] devlink: Add support for devlink-region access
From: Alex Vesker @ 2018-07-17 8:34 UTC (permalink / raw)
To: netdev, jiri; +Cc: Alex Vesker
Devlink region allows access to driver defined address regions.
Each device can create its supported address regions and register
them. A device which exposes a region will allow access to it
using devlink.
This support allows reading and dumping regions snapshots as well
as presenting information such as region size and current available
snapshots.
A snapshot represents a memory image of a region taken by the driver.
If a device collects a snapshot of an address region it can be later
exposed using devlink region read or dump commands.
This functionality allows for future analyses on the snapshots.
The dump command is designed to read the full address space of a
region or of a snapshot unlike the read command which allows
reading only a specific section in a region/snapshot indicated by
an address and a length, current support is for reading and dumping
for a previously taken snapshot ID.
New commands added:
devlink region show [ DEV/REGION ]
devlink region delete DEV/REGION snapshot SNAPSHOT_ID
devlink region dump DEV/REGION [ snapshot SNAPSHOT_ID ]
devlink region read DEV/REGION [ snapshot SNAPSHOT_ID ]
address ADDRESS length length
Signed-off-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
devlink/devlink.c | 485 +++++++++++++++++++++++++++++++++++++++++++++-
man/man8/devlink-region.8 | 131 +++++++++++++
man/man8/devlink.8 | 1 +
3 files changed, 616 insertions(+), 1 deletion(-)
create mode 100644 man/man8/devlink-region.8
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 42fa716..784bb84 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -17,6 +17,7 @@
#include <getopt.h>
#include <limits.h>
#include <errno.h>
+#include <inttypes.h>
#include <linux/genetlink.h>
#include <linux/devlink.h>
#include <libmnl/libmnl.h>
@@ -194,6 +195,10 @@ static void ifname_map_free(struct ifname_map *ifname_map)
#define DL_OPT_PARAM_NAME BIT(18)
#define DL_OPT_PARAM_VALUE BIT(19)
#define DL_OPT_PARAM_CMODE BIT(20)
+#define DL_OPT_HANDLE_REGION BIT(21)
+#define DL_OPT_REGION_SNAPSHOT_ID BIT(22)
+#define DL_OPT_REGION_ADDRESS BIT(23)
+#define DL_OPT_REGION_LENGTH BIT(24)
struct dl_opts {
uint32_t present; /* flags of present items */
@@ -221,6 +226,10 @@ struct dl_opts {
const char *param_name;
const char *param_value;
enum devlink_param_cmode cmode;
+ char *region_name;
+ uint32_t region_snapshot_id;
+ uint64_t region_address;
+ uint64_t region_length;
};
struct dl {
@@ -364,6 +373,16 @@ static const enum mnl_attr_data_type devlink_policy[DEVLINK_ATTR_MAX + 1] = {
[DEVLINK_ATTR_PARAM_VALUES_LIST] = MNL_TYPE_NESTED,
[DEVLINK_ATTR_PARAM_VALUE] = MNL_TYPE_NESTED,
[DEVLINK_ATTR_PARAM_VALUE_CMODE] = MNL_TYPE_U8,
+ [DEVLINK_ATTR_REGION_NAME] = MNL_TYPE_STRING,
+ [DEVLINK_ATTR_REGION_SIZE] = MNL_TYPE_U64,
+ [DEVLINK_ATTR_REGION_SNAPSHOTS] = MNL_TYPE_NESTED,
+ [DEVLINK_ATTR_REGION_SNAPSHOT] = MNL_TYPE_NESTED,
+ [DEVLINK_ATTR_REGION_SNAPSHOT_ID] = MNL_TYPE_U32,
+ [DEVLINK_ATTR_REGION_CHUNKS] = MNL_TYPE_NESTED,
+ [DEVLINK_ATTR_REGION_CHUNK] = MNL_TYPE_NESTED,
+ [DEVLINK_ATTR_REGION_CHUNK_DATA] = MNL_TYPE_BINARY,
+ [DEVLINK_ATTR_REGION_CHUNK_ADDR] = MNL_TYPE_U64,
+ [DEVLINK_ATTR_REGION_CHUNK_LEN] = MNL_TYPE_U64,
};
static int attr_cb(const struct nlattr *attr, void *data)
@@ -502,6 +521,20 @@ static int strslashrsplit(char *str, char **before, char **after)
return 0;
}
+static int strtouint64_t(const char *str, uint64_t *p_val)
+{
+ char *endptr;
+ unsigned long long int val;
+
+ val = strtoull(str, &endptr, 10);
+ if (endptr == str || *endptr != '\0')
+ return -EINVAL;
+ if (val > ULONG_MAX)
+ return -ERANGE;
+ *p_val = val;
+ return 0;
+}
+
static int strtouint32_t(const char *str, uint32_t *p_val)
{
char *endptr;
@@ -687,6 +720,64 @@ static int dl_argv_handle_both(struct dl *dl, char **p_bus_name,
return 0;
}
+static int __dl_argv_handle_region(char *str, char **p_bus_name,
+ char **p_dev_name, char **p_region)
+{
+ char *handlestr;
+ int err;
+
+ err = strslashrsplit(str, &handlestr, p_region);
+ if (err) {
+ pr_err("Region identification \"%s\" is invalid\n", str);
+ return err;
+ }
+ err = strslashrsplit(handlestr, p_bus_name, p_dev_name);
+ if (err) {
+ pr_err("Region identification \"%s\" is invalid\n", str);
+ return err;
+ }
+ return 0;
+}
+
+static int dl_argv_handle_region(struct dl *dl, char **p_bus_name,
+ char **p_dev_name, char **p_region)
+{
+ char *str = dl_argv_next(dl);
+ unsigned int slash_count;
+
+ if (!str) {
+ pr_err("Expected \"bus_name/dev_name/region\" identification.\n");
+ return -EINVAL;
+ }
+
+ slash_count = strslashcount(str);
+ if (slash_count != 2) {
+ pr_err("Wrong region identification string format.\n");
+ pr_err("Expected \"bus_name/dev_name/region\" identification.\n"".\n");
+ return -EINVAL;
+ }
+
+ return __dl_argv_handle_region(str, p_bus_name, p_dev_name, p_region);
+}
+
+static int dl_argv_uint64_t(struct dl *dl, uint64_t *p_val)
+{
+ char *str = dl_argv_next(dl);
+ int err;
+
+ if (!str) {
+ pr_err("Unsigned number argument expected\n");
+ return -EINVAL;
+ }
+
+ err = strtouint64_t(str, p_val);
+ if (err) {
+ pr_err("\"%s\" is not a number or not within range\n", str);
+ return err;
+ }
+ return 0;
+}
+
static int dl_argv_uint32_t(struct dl *dl, uint32_t *p_val)
{
char *str = dl_argv_next(dl);
@@ -879,6 +970,13 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
if (err)
return err;
o_found |= DL_OPT_HANDLEP;
+ } else if (o_required & DL_OPT_HANDLE_REGION) {
+ err = dl_argv_handle_region(dl, &opts->bus_name,
+ &opts->dev_name,
+ &opts->region_name);
+ if (err)
+ return err;
+ o_found |= DL_OPT_HANDLE_REGION;
}
while (dl_argc(dl)) {
@@ -1059,6 +1157,27 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
if (err)
return err;
o_found |= DL_OPT_PARAM_CMODE;
+ } else if (dl_argv_match(dl, "snapshot") &&
+ (o_all & DL_OPT_REGION_SNAPSHOT_ID)) {
+ dl_arg_inc(dl);
+ err = dl_argv_uint32_t(dl, &opts->region_snapshot_id);
+ if (err)
+ return err;
+ o_found |= DL_OPT_REGION_SNAPSHOT_ID;
+ } else if (dl_argv_match(dl, "address") &&
+ (o_all & DL_OPT_REGION_ADDRESS)) {
+ dl_arg_inc(dl);
+ err = dl_argv_uint64_t(dl, &opts->region_address);
+ if (err)
+ return err;
+ o_found |= DL_OPT_REGION_ADDRESS;
+ } else if (dl_argv_match(dl, "length") &&
+ (o_all & DL_OPT_REGION_LENGTH)) {
+ dl_arg_inc(dl);
+ err = dl_argv_uint64_t(dl, &opts->region_length);
+ if (err)
+ return err;
+ o_found |= DL_OPT_REGION_LENGTH;
} else {
pr_err("Unknown option \"%s\"\n", dl_argv(dl));
return -EINVAL;
@@ -1161,6 +1280,24 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
return -EINVAL;
}
+ if ((o_required & DL_OPT_REGION_SNAPSHOT_ID) &&
+ !(o_found & DL_OPT_REGION_SNAPSHOT_ID)) {
+ pr_err("Region snapshot id expected.\n");
+ return -EINVAL;
+ }
+
+ if ((o_required & DL_OPT_REGION_ADDRESS) &&
+ !(o_found & DL_OPT_REGION_ADDRESS)) {
+ pr_err("Region address value expected.\n");
+ return -EINVAL;
+ }
+
+ if ((o_required & DL_OPT_REGION_LENGTH) &&
+ !(o_found & DL_OPT_REGION_LENGTH)) {
+ pr_err("Region length value expected.\n");
+ return -EINVAL;
+ }
+
return 0;
}
@@ -1176,6 +1313,11 @@ static void dl_opts_put(struct nlmsghdr *nlh, struct dl *dl)
mnl_attr_put_strz(nlh, DEVLINK_ATTR_DEV_NAME, opts->dev_name);
mnl_attr_put_u32(nlh, DEVLINK_ATTR_PORT_INDEX,
opts->port_index);
+ } else if (opts->present & DL_OPT_HANDLE_REGION) {
+ mnl_attr_put_strz(nlh, DEVLINK_ATTR_BUS_NAME, opts->bus_name);
+ mnl_attr_put_strz(nlh, DEVLINK_ATTR_DEV_NAME, opts->dev_name);
+ mnl_attr_put_strz(nlh, DEVLINK_ATTR_REGION_NAME,
+ opts->region_name);
}
if (opts->present & DL_OPT_PORT_TYPE)
mnl_attr_put_u16(nlh, DEVLINK_ATTR_PORT_TYPE,
@@ -1231,6 +1373,15 @@ static void dl_opts_put(struct nlmsghdr *nlh, struct dl *dl)
if (opts->present & DL_OPT_PARAM_CMODE)
mnl_attr_put_u8(nlh, DEVLINK_ATTR_PARAM_VALUE_CMODE,
opts->cmode);
+ if (opts->present & DL_OPT_REGION_SNAPSHOT_ID)
+ mnl_attr_put_u32(nlh, DEVLINK_ATTR_REGION_SNAPSHOT_ID,
+ opts->region_snapshot_id);
+ if (opts->present & DL_OPT_REGION_ADDRESS)
+ mnl_attr_put_u64(nlh, DEVLINK_ATTR_REGION_CHUNK_ADDR,
+ opts->region_address);
+ if (opts->present & DL_OPT_REGION_LENGTH)
+ mnl_attr_put_u64(nlh, DEVLINK_ATTR_REGION_CHUNK_LEN,
+ opts->region_length);
}
static int dl_argv_parse_put(struct nlmsghdr *nlh, struct dl *dl,
@@ -1533,6 +1684,49 @@ static void pr_out_u64(struct dl *dl, const char *name, uint64_t val)
return pr_out_uint(dl, name, val);
}
+static void pr_out_region_chunk_start(struct dl *dl, uint64_t addr)
+{
+ if (dl->json_output) {
+ jsonw_name(dl->jw, "address");
+ jsonw_uint(dl->jw, addr);
+ jsonw_name(dl->jw, "data");
+ jsonw_start_array(dl->jw);
+ }
+}
+
+static void pr_out_region_chunk_end(struct dl *dl)
+{
+ if (dl->json_output)
+ jsonw_end_array(dl->jw);
+}
+
+static void pr_out_region_chunk(struct dl *dl, uint8_t *data, uint32_t len,
+ uint64_t addr)
+{
+ static uint64_t align_val;
+ uint32_t i = 0;
+
+ pr_out_region_chunk_start(dl, addr);
+ while (i < len) {
+ if (!dl->json_output)
+ if (!(align_val % 16))
+ pr_out("%s%016"PRIx64" ",
+ align_val ? "\n" : "",
+ addr);
+
+ align_val++;
+
+ if (dl->json_output)
+ jsonw_printf(dl->jw, "%d", data[i]);
+ else
+ pr_out("%02x ", data[i]);
+
+ addr++;
+ i++;
+ }
+ pr_out_region_chunk_end(dl);
+}
+
static void pr_out_dev(struct dl *dl, struct nlattr **tb)
{
pr_out_handle(dl, tb);
@@ -3070,6 +3264,10 @@ static const char *cmd_name(uint8_t cmd)
case DEVLINK_CMD_PARAM_SET: return "set";
case DEVLINK_CMD_PARAM_NEW: return "new";
case DEVLINK_CMD_PARAM_DEL: return "del";
+ case DEVLINK_CMD_REGION_GET: return "get";
+ case DEVLINK_CMD_REGION_SET: return "set";
+ case DEVLINK_CMD_REGION_NEW: return "new";
+ case DEVLINK_CMD_REGION_DEL: return "del";
default: return "<unknown cmd>";
}
}
@@ -3093,6 +3291,11 @@ static const char *cmd_obj(uint8_t cmd)
case DEVLINK_CMD_PARAM_NEW:
case DEVLINK_CMD_PARAM_DEL:
return "param";
+ case DEVLINK_CMD_REGION_GET:
+ case DEVLINK_CMD_REGION_SET:
+ case DEVLINK_CMD_REGION_NEW:
+ case DEVLINK_CMD_REGION_DEL:
+ return "region";
default: return "<unknown obj>";
}
}
@@ -3117,6 +3320,8 @@ static bool cmd_filter_check(struct dl *dl, uint8_t cmd)
return false;
}
+static void pr_out_region(struct dl *dl, struct nlattr **tb);
+
static int cmd_mon_show_cb(const struct nlmsghdr *nlh, void *data)
{
struct dl *dl = data;
@@ -3160,6 +3365,17 @@ static int cmd_mon_show_cb(const struct nlmsghdr *nlh, void *data)
pr_out_mon_header(genl->cmd);
pr_out_param(dl, tb, false);
break;
+ case DEVLINK_CMD_REGION_GET: /* fall through */
+ case DEVLINK_CMD_REGION_SET: /* fall through */
+ case DEVLINK_CMD_REGION_NEW: /* fall through */
+ case DEVLINK_CMD_REGION_DEL:
+ mnl_attr_parse(nlh, sizeof(*genl), attr_cb, tb);
+ if (!tb[DEVLINK_ATTR_BUS_NAME] || !tb[DEVLINK_ATTR_DEV_NAME] ||
+ !tb[DEVLINK_ATTR_REGION_NAME])
+ return MNL_CB_ERROR;
+ pr_out_mon_header(genl->cmd);
+ pr_out_region(dl, tb);
+ break;
}
return MNL_CB_OK;
}
@@ -4941,11 +5157,275 @@ static int cmd_resource(struct dl *dl)
return -ENOENT;
}
+static void pr_out_region_handle_start(struct dl *dl, struct nlattr **tb)
+{
+ const char *bus_name = mnl_attr_get_str(tb[DEVLINK_ATTR_BUS_NAME]);
+ const char *dev_name = mnl_attr_get_str(tb[DEVLINK_ATTR_DEV_NAME]);
+ const char *region_name = mnl_attr_get_str(tb[DEVLINK_ATTR_REGION_NAME]);
+ char buf[256];
+
+ sprintf(buf, "%s/%s/%s", bus_name, dev_name, region_name);
+ if (dl->json_output) {
+ jsonw_name(dl->jw, buf);
+ jsonw_start_object(dl->jw);
+ } else {
+ pr_out("%s:", buf);
+ }
+}
+
+static void pr_out_region_handle_end(struct dl *dl)
+{
+ if (dl->json_output)
+ jsonw_end_object(dl->jw);
+ else
+ pr_out("\n");
+}
+
+static void pr_out_region_snapshots_start(struct dl *dl, bool array)
+{
+ if (dl->json_output) {
+ jsonw_name(dl->jw, "snapshot");
+ jsonw_start_array(dl->jw);
+ } else {
+ if (g_indent_newline)
+ pr_out("snapshot %s", array ? "[" : "");
+ else
+ pr_out(" snapshot %s", array ? "[" : "");
+ }
+}
+
+static void pr_out_region_snapshots_end(struct dl *dl, bool array)
+{
+ if (dl->json_output)
+ jsonw_end_array(dl->jw);
+ else if (array)
+ pr_out("]");
+}
+
+static void pr_out_region_snapshots_id(struct dl *dl, struct nlattr **tb, int index)
+{
+ uint32_t snapshot_id;
+
+ if (!tb[DEVLINK_ATTR_REGION_SNAPSHOT_ID])
+ return;
+
+ snapshot_id = mnl_attr_get_u32(tb[DEVLINK_ATTR_REGION_SNAPSHOT_ID]);
+
+ if (dl->json_output)
+ jsonw_uint(dl->jw, snapshot_id);
+ else
+ pr_out("%s%u", index ? " " : "", snapshot_id);
+}
+
+static void pr_out_snapshots(struct dl *dl, struct nlattr **tb)
+{
+ struct nlattr *tb_snapshot[DEVLINK_ATTR_MAX + 1] = {};
+ struct nlattr *nla_sanpshot;
+ int err, index = 0;
+
+ pr_out_region_snapshots_start(dl, true);
+ mnl_attr_for_each_nested(nla_sanpshot, tb[DEVLINK_ATTR_REGION_SNAPSHOTS]) {
+ err = mnl_attr_parse_nested(nla_sanpshot, attr_cb, tb_snapshot);
+ if (err != MNL_CB_OK)
+ return;
+ pr_out_region_snapshots_id(dl, tb_snapshot, index++);
+ }
+ pr_out_region_snapshots_end(dl, true);
+}
+
+static void pr_out_snapshot(struct dl *dl, struct nlattr **tb)
+{
+ pr_out_region_snapshots_start(dl, false);
+ pr_out_region_snapshots_id(dl, tb, 0);
+ pr_out_region_snapshots_end(dl, false);
+}
+
+static void pr_out_region(struct dl *dl, struct nlattr **tb)
+{
+ pr_out_region_handle_start(dl, tb);
+
+ if (tb[DEVLINK_ATTR_REGION_SIZE])
+ pr_out_u64(dl, "size",
+ mnl_attr_get_u64(tb[DEVLINK_ATTR_REGION_SIZE]));
+
+ if (tb[DEVLINK_ATTR_REGION_SNAPSHOTS])
+ pr_out_snapshots(dl, tb);
+
+ if (tb[DEVLINK_ATTR_REGION_SNAPSHOT_ID])
+ pr_out_snapshot(dl, tb);
+
+ pr_out_region_handle_end(dl);
+}
+
+static int cmd_region_show_cb(const struct nlmsghdr *nlh, void *data)
+{
+ struct genlmsghdr *genl = mnl_nlmsg_get_payload(nlh);
+ struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
+ struct dl *dl = data;
+
+ mnl_attr_parse(nlh, sizeof(*genl), attr_cb, tb);
+ if (!tb[DEVLINK_ATTR_BUS_NAME] || !tb[DEVLINK_ATTR_DEV_NAME] ||
+ !tb[DEVLINK_ATTR_REGION_NAME] || !tb[DEVLINK_ATTR_REGION_SIZE])
+ return MNL_CB_ERROR;
+
+ pr_out_region(dl, tb);
+
+ return MNL_CB_OK;
+}
+
+static int cmd_region_show(struct dl *dl)
+{
+ struct nlmsghdr *nlh;
+ uint16_t flags = NLM_F_REQUEST | NLM_F_ACK;
+ int err;
+
+ if (dl_argc(dl) == 0)
+ flags |= NLM_F_DUMP;
+
+ nlh = mnlg_msg_prepare(dl->nlg, DEVLINK_CMD_REGION_GET, flags);
+
+ if (dl_argc(dl) > 0) {
+ err = dl_argv_parse_put(nlh, dl, DL_OPT_HANDLE_REGION, 0);
+ if (err)
+ return err;
+ }
+
+ pr_out_section_start(dl, "regions");
+ err = _mnlg_socket_sndrcv(dl->nlg, nlh, cmd_region_show_cb, dl);
+ pr_out_section_end(dl);
+ return err;
+}
+
+static int cmd_region_snapshot_del(struct dl *dl)
+{
+ struct nlmsghdr *nlh;
+ int err;
+
+ nlh = mnlg_msg_prepare(dl->nlg, DEVLINK_CMD_REGION_DEL,
+ NLM_F_REQUEST | NLM_F_ACK);
+
+ err = dl_argv_parse_put(nlh, dl, DL_OPT_HANDLE_REGION |
+ DL_OPT_REGION_SNAPSHOT_ID, 0);
+ if (err)
+ return err;
+
+ return _mnlg_socket_sndrcv(dl->nlg, nlh, NULL, NULL);
+}
+
+static int cmd_region_read_cb(const struct nlmsghdr *nlh, void *data)
+{
+ struct nlattr *nla_entry, *nla_chunk_data, *nla_chunk_addr;
+ struct genlmsghdr *genl = mnl_nlmsg_get_payload(nlh);
+ struct nlattr *tb_field[DEVLINK_ATTR_MAX + 1] = {};
+ struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
+ struct dl *dl = data;
+ int err;
+
+ mnl_attr_parse(nlh, sizeof(*genl), attr_cb, tb);
+ if (!tb[DEVLINK_ATTR_BUS_NAME] || !tb[DEVLINK_ATTR_DEV_NAME] ||
+ !tb[DEVLINK_ATTR_REGION_CHUNKS])
+ return MNL_CB_ERROR;
+
+ mnl_attr_for_each_nested(nla_entry, tb[DEVLINK_ATTR_REGION_CHUNKS]) {
+ err = mnl_attr_parse_nested(nla_entry, attr_cb, tb_field);
+ if (err != MNL_CB_OK)
+ return MNL_CB_ERROR;
+
+ nla_chunk_data = tb_field[DEVLINK_ATTR_REGION_CHUNK_DATA];
+ if (!nla_chunk_data)
+ continue;
+
+ nla_chunk_addr = tb_field[DEVLINK_ATTR_REGION_CHUNK_ADDR];
+ if (!nla_chunk_addr)
+ continue;
+
+ pr_out_region_chunk(dl, mnl_attr_get_payload(nla_chunk_data),
+ mnl_attr_get_payload_len(nla_chunk_data),
+ mnl_attr_get_u64(nla_chunk_addr));
+ }
+ return MNL_CB_OK;
+}
+
+static int cmd_region_dump(struct dl *dl)
+{
+ struct nlmsghdr *nlh;
+ int err;
+
+ nlh = mnlg_msg_prepare(dl->nlg, DEVLINK_CMD_REGION_READ,
+ NLM_F_REQUEST | NLM_F_ACK | NLM_F_DUMP);
+
+ err = dl_argv_parse_put(nlh, dl, DL_OPT_HANDLE_REGION |
+ DL_OPT_REGION_SNAPSHOT_ID, 0);
+ if (err)
+ return err;
+
+ pr_out_section_start(dl, "dump");
+ err = _mnlg_socket_sndrcv(dl->nlg, nlh, cmd_region_read_cb, dl);
+ pr_out_section_end(dl);
+ if (!dl->json_output)
+ pr_out("\n");
+ return err;
+}
+
+static int cmd_region_read(struct dl *dl)
+{
+ struct nlmsghdr *nlh;
+ int err;
+
+ nlh = mnlg_msg_prepare(dl->nlg, DEVLINK_CMD_REGION_READ,
+ NLM_F_REQUEST | NLM_F_ACK | NLM_F_DUMP);
+
+ err = dl_argv_parse_put(nlh, dl, DL_OPT_HANDLE_REGION |
+ DL_OPT_REGION_ADDRESS | DL_OPT_REGION_LENGTH |
+ DL_OPT_REGION_SNAPSHOT_ID, 0);
+ if (err)
+ return err;
+
+ pr_out_section_start(dl, "read");
+ err = _mnlg_socket_sndrcv(dl->nlg, nlh, cmd_region_read_cb, dl);
+ pr_out_section_end(dl);
+ if (!dl->json_output)
+ pr_out("\n");
+ return err;
+}
+
+static void cmd_region_help(void)
+{
+ pr_err("Usage: devlink region show [ DEV/REGION ]\n");
+ pr_err(" devlink region del DEV/REGION snapshot SNAPSHOT_ID\n");
+ pr_err(" devlink region dump DEV/REGION [ snapshot SNAPSHOT_ID ]\n");
+ pr_err(" devlink region read DEV/REGION [ snapshot SNAPSHOT_ID ] address ADDRESS length LENGTH\n");
+}
+
+static int cmd_region(struct dl *dl)
+{
+ if (dl_no_arg(dl)) {
+ return cmd_region_show(dl);
+ } else if (dl_argv_match(dl, "help")) {
+ cmd_region_help();
+ return 0;
+ } else if (dl_argv_match(dl, "show")) {
+ dl_arg_inc(dl);
+ return cmd_region_show(dl);
+ } else if (dl_argv_match(dl, "del")) {
+ dl_arg_inc(dl);
+ return cmd_region_snapshot_del(dl);
+ } else if (dl_argv_match(dl, "dump")) {
+ dl_arg_inc(dl);
+ return cmd_region_dump(dl);
+ } else if (dl_argv_match(dl, "read")) {
+ dl_arg_inc(dl);
+ return cmd_region_read(dl);
+ }
+ pr_err("Command \"%s\" not found\n", dl_argv(dl));
+ return -ENOENT;
+}
+
static void help(void)
{
pr_err("Usage: devlink [ OPTIONS ] OBJECT { COMMAND | help }\n"
" devlink [ -f[orce] ] -b[atch] filename\n"
- "where OBJECT := { dev | port | sb | monitor | dpipe | resource }\n"
+ "where OBJECT := { dev | port | sb | monitor | dpipe | resource | region }\n"
" OPTIONS := { -V[ersion] | -n[no-nice-names] | -j[json] | -p[pretty] | -v[verbose] }\n");
}
@@ -4975,6 +5455,9 @@ static int dl_cmd(struct dl *dl, int argc, char **argv)
} else if (dl_argv_match(dl, "resource")) {
dl_arg_inc(dl);
return cmd_resource(dl);
+ } else if (dl_argv_match(dl, "region")) {
+ dl_arg_inc(dl);
+ return cmd_region(dl);
}
pr_err("Object \"%s\" not found\n", dl_argv(dl));
return -ENOENT;
diff --git a/man/man8/devlink-region.8 b/man/man8/devlink-region.8
new file mode 100644
index 0000000..ff10cdb
--- /dev/null
+++ b/man/man8/devlink-region.8
@@ -0,0 +1,131 @@
+.TH DEVLINK\-REGION 8 "10 Jan 2018" "iproute2" "Linux"
+.SH NAME
+devlink-region \- devlink address region access
+.SH SYNOPSIS
+.sp
+.ad l
+.in +8
+.ti -8
+.B devlink
+.RI "[ " OPTIONS " ]"
+.B region
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR OPTIONS " := { "
+\fB\-V\fR[\fIersion\fR] |
+\fB\-n\fR[\fIno-nice-names\fR] }
+
+.ti -8
+.BR "devlink region show"
+.RI "[ " DEV/REGION " ]"
+
+.ti -8
+.BR "devlink region del"
+.RI "" DEV/REGION ""
+.BR "snapshot"
+.RI "" SNAPSHOT_ID ""
+
+.ti -8
+.BR "devlink region dump"
+.RI "" DEV/REGION ""
+.BR "snapshot"
+.RI "" SNAPSHOT_ID ""
+
+.ti -8
+.BR "devlink region read"
+.RI "" DEV/REGION ""
+.BR "[ "
+.BR "snapshot"
+.RI "" SNAPSHOT_ID ""
+.BR "]"
+.BR "address"
+.RI "" ADDRESS "
+.BR "length"
+.RI "" LENGTH ""
+
+.ti -8
+.B devlink region help
+
+.SH "DESCRIPTION"
+.SS devlink region show - Show all supported address regions names, snapshots and sizes
+
+.PP
+.I "DEV/REGION"
+- specifies the devlink device and address-region to query.
+
+.SS devlink region del - Delete a snapshot specified by address-region name and snapshot ID
+
+.PP
+.I "DEV/REGION"
+- specifies the devlink device and address-region to delete the snapshot from
+
+.PP
+snapshot
+.I "SNAPSHOT_ID"
+- specifies the snapshot ID to delete
+
+.SS devlink region dump - Dump all the available data from a region or from snapshot of a region
+
+.PP
+.I "DEV/REGION"
+- specifies the device and address-region to dump from.
+
+.PP
+snapshot
+.I "SNAPSHOT_ID"
+- specifies the snapshot-id of the region to dump.
+
+.SS devlink region read - Read from a specific region address for a given length
+
+.PP
+.I "DEV/REGION"
+- specifies the device and address-region to read from.
+
+.PP
+snapshot
+.I "SNAPSHOT_ID"
+- specifies the snapshot-id of the region to read.
+
+.PP
+address
+.I "ADDRESS"
+- specifies the address to read from.
+
+.PP
+length
+.I "LENGTH"
+- specifies the length of data to read.
+
+.SH "EXAMPLES"
+.PP
+devlink region show
+.RS 4
+List available address regions and snapshot.
+.RE
+.PP
+devlink region del pci/0000:00:05.0/cr-space snapshot 1
+.RS 4
+Delete snapshot id 1 from cr-space address region from device pci/0000:00:05.0.
+.RE
+.PP
+devlink region dump pci/0000:00:05.0/cr-space snapshot 1
+.RS 4
+Dump the snapshot taken from cr-space address region with ID 1
+.RE
+.PP
+devlink region read pci/0000:00:05.0/cr-space snapshot 1 address 0x10 legth 16
+.RS 4
+Read from address 0x10, 16 Bytes of snapshot ID 1 taken from cr-space address region
+
+.SH SEE ALSO
+.BR devlink (8),
+.BR devlink-dev (8),
+.BR devlink-port (8),
+.BR devlink-monitor (8),
+.br
+
+.SH AUTHOR
+Alex Vesker <valex@mellanox.com>
diff --git a/man/man8/devlink.8 b/man/man8/devlink.8
index 7986310..4cf6762 100644
--- a/man/man8/devlink.8
+++ b/man/man8/devlink.8
@@ -112,6 +112,7 @@ Exit status is 0 if command was successful or a positive integer upon failure.
.BR devlink-monitor (8),
.BR devlink-sb (8),
.BR devlink-resource (8),
+.BR devlink-region (8),
.br
.SH REPORTING BUGS
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] net: Move skb decrypted field, avoid explicity copy
From: kbuild test robot @ 2018-07-17 8:18 UTC (permalink / raw)
To: Stefano Brivio
Cc: kbuild-all, David S. Miller, Boris Pismenny, Stephen Rothwell,
netdev
In-Reply-To: <d277733a2eb3b5ffa2cbdbe4bd2a261d8fb60a0f.1531811764.git.sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5173 bytes --]
Hi Stefano,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Stefano-Brivio/net-Move-skb-decrypted-field-avoid-explicity-copy/20180717-152125
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.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
GCC_VERSION=8.1.0 make.cross ARCH=ia64
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:10,
from include/linux/list.h:9,
from include/linux/module.h:9,
from net//core/skbuff.c:41:
net//core/skbuff.c: In function '__copy_skb_header':
>> net//core/skbuff.c:787:31: error: attempt to take address of bit-field structure member 'decrypted'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^~~~~~~
include/linux/compiler.h:316:19: note: in definition of macro '__compiletime_assert'
bool __cond = !(condition); \
^~~~~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
net//core/skbuff.c:787:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^~~~~~~~~~~~
include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^~~~~~~~~~~~~~~~~~~
net//core/skbuff.c:787:15: note: in expansion of macro 'offsetof'
BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
^~~~~~~~
net//core/skbuff.c:837:2: note: in expansion of macro 'CHECK_SKB_FIELD'
CHECK_SKB_FIELD(decrypted);
^~~~~~~~~~~~~~~
net//core/skbuff.c:789:31: error: attempt to take address of bit-field structure member 'decrypted'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^~~~~~~
include/linux/compiler.h:316:19: note: in definition of macro '__compiletime_assert'
bool __cond = !(condition); \
^~~~~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
net//core/skbuff.c:789:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^~~~~~~~~~~~
include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^~~~~~~~~~~~~~~~~~~
net//core/skbuff.c:789:15: note: in expansion of macro 'offsetof'
BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
^~~~~~~~
net//core/skbuff.c:837:2: note: in expansion of macro 'CHECK_SKB_FIELD'
CHECK_SKB_FIELD(decrypted);
^~~~~~~~~~~~~~~
vim +/decrypted +787 net//core/skbuff.c
795bb1c0 Jesper Dangaard Brouer 2016-02-08 784
b1937227 Eric Dumazet 2014-09-28 785 /* Make sure a field is enclosed inside headers_start/headers_end section */
b1937227 Eric Dumazet 2014-09-28 786 #define CHECK_SKB_FIELD(field) \
b1937227 Eric Dumazet 2014-09-28 @787 BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
b1937227 Eric Dumazet 2014-09-28 788 offsetof(struct sk_buff, headers_start)); \
b1937227 Eric Dumazet 2014-09-28 789 BUILD_BUG_ON(offsetof(struct sk_buff, field) > \
b1937227 Eric Dumazet 2014-09-28 790 offsetof(struct sk_buff, headers_end)); \
b1937227 Eric Dumazet 2014-09-28 791
:::::: The code at line 787 was first introduced by commit
:::::: b1937227316417aa7568d01e6fa1f272e98fb890 net: reorganize sk_buff for faster __copy_skb_header()
:::::: TO: Eric Dumazet <edumazet@google.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 50921 bytes --]
^ permalink raw reply
* [PATCH v2] net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI
From: Alexander Sverdlin @ 2018-07-17 8:16 UTC (permalink / raw)
To: netdev
Cc: Alexander Sverdlin, David S. Miller, Aleksey Makarov,
Sunil Goutham, Raghu Vatsavayi, Vijaya Mohan Guvva
In-Reply-To: <20180717010159.GD10593@intel.com>
Octeon Ethernet drivers work perfectly without PCI.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
---
drivers/net/ethernet/cavium/Kconfig | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig
index 043e3c11c42b..ba65ed49f480 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -4,7 +4,6 @@
config NET_VENDOR_CAVIUM
bool "Cavium ethernet drivers"
- depends on PCI
default y
---help---
Select this option if you want enable Cavium network support.
@@ -15,7 +14,7 @@ if NET_VENDOR_CAVIUM
config THUNDER_NIC_PF
tristate "Thunder Physical function driver"
- depends on 64BIT
+ depends on 64BIT && PCI
select THUNDER_NIC_BGX
---help---
This driver supports Thunder's NIC physical function.
@@ -28,13 +27,13 @@ config THUNDER_NIC_PF
config THUNDER_NIC_VF
tristate "Thunder Virtual function driver"
imply CAVIUM_PTP
- depends on 64BIT
+ depends on 64BIT && PCI
---help---
This driver supports Thunder's NIC virtual function
config THUNDER_NIC_BGX
tristate "Thunder MAC interface driver (BGX)"
- depends on 64BIT
+ depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
select THUNDER_NIC_RGX
@@ -44,7 +43,7 @@ config THUNDER_NIC_BGX
config THUNDER_NIC_RGX
tristate "Thunder MAC interface driver (RGX)"
- depends on 64BIT
+ depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
---help---
@@ -53,7 +52,7 @@ config THUNDER_NIC_RGX
config CAVIUM_PTP
tristate "Cavium PTP coprocessor as PTP clock"
- depends on 64BIT
+ depends on 64BIT && PCI
imply PTP_1588_CLOCK
default y
---help---
@@ -65,7 +64,7 @@ config CAVIUM_PTP
config LIQUIDIO
tristate "Cavium LiquidIO support"
- depends on 64BIT
+ depends on 64BIT && PCI
depends on MAY_USE_DEVLINK
imply PTP_1588_CLOCK
select FW_LOADER
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox