* Re: [PATCH net-next 4/5] ipv6: Compute multipath hash for sent ICMP errors from offending packet
From: Jakub Sitnicki @ 2016-10-27 22:00 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber, edumazet
In-Reply-To: <20161027.112413.1616222035100737672.davem@davemloft.net>
On Thu, Oct 27, 2016 at 03:24 PM GMT, David Miller wrote:
> From: Jakub Sitnicki <jkbs@redhat.com>
> Date: Mon, 24 Oct 2016 11:28:51 +0200
>
>> diff --git a/include/linux/icmpv6.h b/include/linux/icmpv6.h
>> index 57086e9..6282e03 100644
>> --- a/include/linux/icmpv6.h
>> +++ b/include/linux/icmpv6.h
>> @@ -45,4 +45,6 @@ extern void icmpv6_flow_init(struct sock *sk,
>> const struct in6_addr *saddr,
>> const struct in6_addr *daddr,
>> int oif);
>> +struct ipv6hdr;
>> +extern u32 icmpv6_multipath_hash(const struct ipv6hdr *iph);
>> #endif
>
> We do not use "extern" in external function declarations in header file any more.
My mistake, will remote it.
^ permalink raw reply
* Re: [PATCH net-next 0/5] Route ICMPv6 errors with the flow when ECMP in use
From: Hannes Frederic Sowa @ 2016-10-27 21:54 UTC (permalink / raw)
To: David Miller, jkbs; +Cc: netdev, linux-kernel
In-Reply-To: <20161027.112331.1872860838376990837.davem@davemloft.net>
Hi,
On 27.10.2016 17:23, David Miller wrote:
> From: Jakub Sitnicki <jkbs@redhat.com>
> Date: Mon, 24 Oct 2016 11:28:47 +0200
>
>> However, for it to work IPv6 flow labels have to be same in both
>> directions (i.e. reflected) or need to be chosen in a manner that
>> ensures that the flow going in the opposite direction would actually
>> be routed to a given path.
>
> My understanding is that this is not really guaranteed, and that
> entities are nearly encouraged to set the flow label in whatever
> manner makes sense for their use case.
In general this is true.
> I think we really cannot have any kind of hard dependency on how
> flow labels are set and used by the internet.
Probably/Hopefully ECMP setups are set up by the same entity that also
operates the servers, thus they can easily control the reflection of
flow labels on those servers. This might be especially important for
anycast services hosted behind ECMP services.
If the flow labels don't match, these patches are just best effort and
don't improve nor worsen the situation (lot's of traffic afaik still
carries 0 as flow label which indeed does help).
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: David Miller @ 2016-10-27 21:42 UTC (permalink / raw)
To: mst; +Cc: john.fastabend, brouer, shrijeet, tom, netdev, shm, roopa,
nikolay
In-Reply-To: <20161028002814-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 28 Oct 2016 00:30:35 +0300
> Something I'd like to understand is how does XDP address the
> problem that 100Byte packets are consuming 4K of memory now.
Via page pools. We're going to make a generic one, but right now
each and every driver implements a quick list of pages to allocate
from (and thus avoid the DMA man/unmap overhead, etc.)
^ permalink raw reply
* [net-next PATCH 3/3] net: Add support for XPS with QoS via traffic classes
From: Alexander Duyck @ 2016-10-27 15:40 UTC (permalink / raw)
To: netdev; +Cc: john.r.fastabend, tom, intel-wired-lan, davem
In-Reply-To: <20161027153539.13989.14349.stgit@ahduyck-blue-test.jf.intel.com>
This patch adds support for setting and using XPS when QoS via traffic
classes is enabled. With this change we will factor in the priority and
traffic class mapping of the packet and use that information to correctly
select the queue.
This allows us to define a set of queues for a given traffic class via
mqprio and then configure the XPS mapping for those queues so that the
traffic flows can avoid head-of-line blocking between the individual CPUs
if so desired.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
include/linux/netdevice.h | 5 +-
net/core/dev.c | 136 +++++++++++++++++++++++++++++++++------------
net/core/net-sysfs.c | 31 +++++++---
3 files changed, 122 insertions(+), 50 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d045432..56f90f7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -732,8 +732,8 @@ struct xps_dev_maps {
struct rcu_head rcu;
struct xps_map __rcu *cpu_map[0];
};
-#define XPS_DEV_MAPS_SIZE (sizeof(struct xps_dev_maps) + \
- (nr_cpu_ids * sizeof(struct xps_map *)))
+#define XPS_DEV_MAPS_SIZE(_tcs) (sizeof(struct xps_dev_maps) + \
+ (nr_cpu_ids * (_tcs) * sizeof(struct xps_map *)))
#endif /* CONFIG_XPS */
#define TC_MAX_QUEUE 16
@@ -1920,6 +1920,7 @@ int netdev_set_prio_tc_map(struct net_device *dev, u8 prio, u8 tc)
return 0;
}
+int netdev_txq_to_tc(struct net_device *dev, unsigned int txq);
void netdev_reset_tc(struct net_device *dev);
int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset);
int netdev_set_num_tc(struct net_device *dev, u8 num_tc);
diff --git a/net/core/dev.c b/net/core/dev.c
index d124081..37c1096 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1948,6 +1948,23 @@ static void netif_setup_tc(struct net_device *dev, unsigned int txq)
}
}
+int netdev_txq_to_tc(struct net_device *dev, unsigned int txq)
+{
+ if (dev->num_tc) {
+ struct netdev_tc_txq *tc = &dev->tc_to_txq[0];
+ int i;
+
+ for (i = 0; i < TC_MAX_QUEUE; i++, tc++) {
+ if ((txq - tc->offset) < tc->count)
+ return i;
+ }
+
+ return -1;
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_XPS
static DEFINE_MUTEX(xps_map_mutex);
#define xmap_dereference(P) \
@@ -1985,18 +2002,22 @@ static bool remove_xps_queue_cpu(struct net_device *dev,
struct xps_dev_maps *dev_maps,
int cpu, u16 offset, u16 count)
{
+ int tc = dev->num_tc ? : 1;
bool active = false;
- int i;
+ int tci;
count += offset;
- i = count;
- do {
- if (i-- == offset) {
- active = true;
- break;
- }
- } while (remove_xps_queue(dev_maps, cpu, i));
+ for (tci = cpu * tc; tc--; tci++) {
+ int i = count;
+
+ do {
+ if (i-- == offset) {
+ active = true;
+ break;
+ }
+ } while (remove_xps_queue(dev_maps, tci, i));
+ }
return active;
}
@@ -2075,20 +2096,28 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
u16 index)
{
struct xps_dev_maps *dev_maps, *new_dev_maps = NULL;
+ int i, cpu, tci, numa_node_id = -2;
+ int maps_sz, num_tc = 1, tc = 0;
struct xps_map *map, *new_map;
- int maps_sz = max_t(unsigned int, XPS_DEV_MAPS_SIZE, L1_CACHE_BYTES);
- int cpu, numa_node_id = -2;
bool active = false;
+ if (dev->num_tc) {
+ num_tc = dev->num_tc;
+ tc = netdev_txq_to_tc(dev, index);
+ if (tc < 0)
+ return -EINVAL;
+ }
+
+ maps_sz = XPS_DEV_MAPS_SIZE(num_tc);
+ if (maps_sz < L1_CACHE_BYTES)
+ maps_sz = L1_CACHE_BYTES;
+
mutex_lock(&xps_map_mutex);
dev_maps = xmap_dereference(dev->xps_maps);
/* allocate memory for queue storage */
- for_each_online_cpu(cpu) {
- if (!cpumask_test_cpu(cpu, mask))
- continue;
-
+ for_each_cpu_and(cpu, cpu_online_mask, mask) {
if (!new_dev_maps)
new_dev_maps = kzalloc(maps_sz, GFP_KERNEL);
if (!new_dev_maps) {
@@ -2096,25 +2125,35 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
return -ENOMEM;
}
- map = dev_maps ? xmap_dereference(dev_maps->cpu_map[cpu]) :
+ tci = cpu * num_tc + tc;
+ map = dev_maps ? xmap_dereference(dev_maps->cpu_map[tci]) :
NULL;
map = expand_xps_map(map, cpu, index);
if (!map)
goto error;
- RCU_INIT_POINTER(new_dev_maps->cpu_map[cpu], map);
+ RCU_INIT_POINTER(new_dev_maps->cpu_map[tci], map);
}
if (!new_dev_maps)
goto out_no_new_maps;
for_each_possible_cpu(cpu) {
+ /* copy maps belonging to foreign traffic classes */
+ tci = cpu * num_tc;
+ for (i = 0; dev_maps && i < tc; i++, tci++) {
+ /* fill in the new device map from the old device map */
+ map = xmap_dereference(dev_maps->cpu_map[tci]);
+ RCU_INIT_POINTER(new_dev_maps->cpu_map[tci], map);
+ }
+
+ tci = cpu * num_tc + tc;
if (cpumask_test_cpu(cpu, mask) && cpu_online(cpu)) {
/* add queue to CPU maps */
int pos = 0;
- map = xmap_dereference(new_dev_maps->cpu_map[cpu]);
+ map = xmap_dereference(new_dev_maps->cpu_map[tci]);
while ((pos < map->len) && (map->queues[pos] != index))
pos++;
@@ -2128,26 +2167,37 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
#endif
} else if (dev_maps) {
/* fill in the new device map from the old device map */
- map = xmap_dereference(dev_maps->cpu_map[cpu]);
- RCU_INIT_POINTER(new_dev_maps->cpu_map[cpu], map);
+ map = xmap_dereference(dev_maps->cpu_map[tci]);
+ RCU_INIT_POINTER(new_dev_maps->cpu_map[tci], map);
}
+ /* copy maps belonging to foreign traffic classes */
+ for (i = tc, tci++; dev_maps && (++i < num_tc); tci++) {
+ /* fill in the new device map from the old device map */
+ map = xmap_dereference(dev_maps->cpu_map[tci]);
+ RCU_INIT_POINTER(new_dev_maps->cpu_map[tci], map);
+ }
}
rcu_assign_pointer(dev->xps_maps, new_dev_maps);
/* Cleanup old maps */
- if (dev_maps) {
- for_each_possible_cpu(cpu) {
- new_map = xmap_dereference(new_dev_maps->cpu_map[cpu]);
- map = xmap_dereference(dev_maps->cpu_map[cpu]);
+ if (!dev_maps)
+ goto out_no_old_maps;
+
+ for_each_possible_cpu(cpu) {
+ tci = cpu * num_tc;
+ for (i = 0; i < num_tc; i++, tci++) {
+ new_map = xmap_dereference(new_dev_maps->cpu_map[tci]);
+ map = xmap_dereference(dev_maps->cpu_map[tci]);
if (map && map != new_map)
kfree_rcu(map, rcu);
}
-
- kfree_rcu(dev_maps, rcu);
}
+ kfree_rcu(dev_maps, rcu);
+
+out_no_old_maps:
dev_maps = new_dev_maps;
active = true;
@@ -2162,11 +2212,13 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
/* removes queue from unused CPUs */
for_each_possible_cpu(cpu) {
- if (cpumask_test_cpu(cpu, mask) && cpu_online(cpu))
- continue;
-
- if (remove_xps_queue(dev_maps, cpu, index))
- active = true;
+ tci = cpu * num_tc;
+ for (i = 0; i < tc; i++, tci++)
+ active |= remove_xps_queue(dev_maps, tci, index);
+ if (!cpumask_test_cpu(cpu, mask) || !cpu_online(cpu))
+ active |= remove_xps_queue(dev_maps, tci, index);
+ for (i = tc, tci++; ++i < num_tc; tci++)
+ active |= remove_xps_queue(dev_maps, tci, index);
}
/* free map if not active */
@@ -2182,11 +2234,15 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
error:
/* remove any maps that we added */
for_each_possible_cpu(cpu) {
- new_map = xmap_dereference(new_dev_maps->cpu_map[cpu]);
- map = dev_maps ? xmap_dereference(dev_maps->cpu_map[cpu]) :
- NULL;
- if (new_map && new_map != map)
- kfree(new_map);
+ tci = cpu * num_tc;
+ for (i = 0; i < num_tc; i++, tci++) {
+ new_map = xmap_dereference(new_dev_maps->cpu_map[tci]);
+ map = dev_maps ?
+ xmap_dereference(dev_maps->cpu_map[tci]) :
+ NULL;
+ if (new_map && new_map != map)
+ kfree(new_map);
+ }
}
mutex_unlock(&xps_map_mutex);
@@ -3146,8 +3202,14 @@ static inline int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
rcu_read_lock();
dev_maps = rcu_dereference(dev->xps_maps);
if (dev_maps) {
- map = rcu_dereference(
- dev_maps->cpu_map[skb->sender_cpu - 1]);
+ unsigned int tci = skb->sender_cpu - 1;
+
+ if (dev->num_tc) {
+ tci *= dev->num_tc;
+ tci += netdev_get_prio_tc_map(dev, skb->priority);
+ }
+
+ map = rcu_dereference(dev_maps->cpu_map[tci]);
if (map) {
if (map->len == 1)
queue_index = map->queues[0];
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 6e4f347..763c1e1 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1190,29 +1190,38 @@ static ssize_t show_xps_map(struct netdev_queue *queue,
struct netdev_queue_attribute *attribute, char *buf)
{
struct net_device *dev = queue->dev;
+ int cpu, len, num_tc = 1, tc = 0;
struct xps_dev_maps *dev_maps;
cpumask_var_t mask;
unsigned long index;
- int i, len;
if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
return -ENOMEM;
index = get_netdev_queue_index(queue);
+ if (dev->num_tc) {
+ num_tc = dev->num_tc;
+ tc = netdev_txq_to_tc(dev, index);
+ if (tc < 0)
+ return -EINVAL;
+ }
+
rcu_read_lock();
dev_maps = rcu_dereference(dev->xps_maps);
if (dev_maps) {
- for_each_possible_cpu(i) {
- struct xps_map *map =
- rcu_dereference(dev_maps->cpu_map[i]);
- if (map) {
- int j;
- for (j = 0; j < map->len; j++) {
- if (map->queues[j] == index) {
- cpumask_set_cpu(i, mask);
- break;
- }
+ for_each_possible_cpu(cpu) {
+ int i, tci = cpu * num_tc + tc;
+ struct xps_map *map;
+
+ map = rcu_dereference(dev_maps->cpu_map[tci]);
+ if (!map)
+ continue;
+
+ for (i = map->len; i--;) {
+ if (map->queues[i] == index) {
+ cpumask_set_cpu(cpu, mask);
+ break;
}
}
}
^ permalink raw reply related
* [net-next PATCH 2/3] net: Refactor removal of queues from XPS map and apply on num_tc changes
From: Alexander Duyck @ 2016-10-27 15:40 UTC (permalink / raw)
To: netdev; +Cc: john.r.fastabend, tom, intel-wired-lan, davem
In-Reply-To: <20161027153539.13989.14349.stgit@ahduyck-blue-test.jf.intel.com>
This patch updates the code for removing queues from the XPS map and makes
it so that we can apply the code any time we change either the number of
traffic classes or the mapping of a given block of queues. This way we
avoid having queues pulling traffic from a foreign traffic class.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/core/dev.c | 79 ++++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 56 insertions(+), 23 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d4d45bf..d124081 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1953,32 +1953,56 @@ static void netif_setup_tc(struct net_device *dev, unsigned int txq)
#define xmap_dereference(P) \
rcu_dereference_protected((P), lockdep_is_held(&xps_map_mutex))
-static struct xps_map *remove_xps_queue(struct xps_dev_maps *dev_maps,
- int cpu, u16 index)
+static bool remove_xps_queue(struct xps_dev_maps *dev_maps,
+ int tci, u16 index)
{
struct xps_map *map = NULL;
int pos;
if (dev_maps)
- map = xmap_dereference(dev_maps->cpu_map[cpu]);
+ map = xmap_dereference(dev_maps->cpu_map[tci]);
+ if (!map)
+ return false;
- for (pos = 0; map && pos < map->len; pos++) {
- if (map->queues[pos] == index) {
- if (map->len > 1) {
- map->queues[pos] = map->queues[--map->len];
- } else {
- RCU_INIT_POINTER(dev_maps->cpu_map[cpu], NULL);
- kfree_rcu(map, rcu);
- map = NULL;
- }
+ for (pos = map->len; pos--;) {
+ if (map->queues[pos] != index)
+ continue;
+
+ if (map->len > 1) {
+ map->queues[pos] = map->queues[--map->len];
break;
}
+
+ RCU_INIT_POINTER(dev_maps->cpu_map[tci], NULL);
+ kfree_rcu(map, rcu);
+ return false;
}
- return map;
+ return true;
}
-static void netif_reset_xps_queues_gt(struct net_device *dev, u16 index)
+static bool remove_xps_queue_cpu(struct net_device *dev,
+ struct xps_dev_maps *dev_maps,
+ int cpu, u16 offset, u16 count)
+{
+ bool active = false;
+ int i;
+
+ count += offset;
+ i = count;
+
+ do {
+ if (i-- == offset) {
+ active = true;
+ break;
+ }
+ } while (remove_xps_queue(dev_maps, cpu, i));
+
+ return active;
+}
+
+static void netif_reset_xps_queues(struct net_device *dev, u16 offset,
+ u16 count)
{
struct xps_dev_maps *dev_maps;
int cpu, i;
@@ -1990,21 +2014,16 @@ static void netif_reset_xps_queues_gt(struct net_device *dev, u16 index)
if (!dev_maps)
goto out_no_maps;
- for_each_possible_cpu(cpu) {
- for (i = index; i < dev->num_tx_queues; i++) {
- if (!remove_xps_queue(dev_maps, cpu, i))
- break;
- }
- if (i == dev->num_tx_queues)
- active = true;
- }
+ for_each_possible_cpu(cpu)
+ active |= remove_xps_queue_cpu(dev, dev_maps, cpu, offset,
+ count);
if (!active) {
RCU_INIT_POINTER(dev->xps_maps, NULL);
kfree_rcu(dev_maps, rcu);
}
- for (i = index; i < dev->num_tx_queues; i++)
+ for (i = offset + (count - 1); count--; i--)
netdev_queue_numa_node_write(netdev_get_tx_queue(dev, i),
NUMA_NO_NODE);
@@ -2012,6 +2031,11 @@ static void netif_reset_xps_queues_gt(struct net_device *dev, u16 index)
mutex_unlock(&xps_map_mutex);
}
+static void netif_reset_xps_queues_gt(struct net_device *dev, u16 index)
+{
+ netif_reset_xps_queues(dev, index, dev->num_tx_queues - index);
+}
+
static struct xps_map *expand_xps_map(struct xps_map *map,
int cpu, u16 index)
{
@@ -2175,6 +2199,9 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
#endif
void netdev_reset_tc(struct net_device *dev)
{
+#ifdef CONFIG_XPS
+ netif_reset_xps_queues_gt(dev, 0);
+#endif
dev->num_tc = 0;
memset(dev->tc_to_txq, 0, sizeof(dev->tc_to_txq));
memset(dev->prio_tc_map, 0, sizeof(dev->prio_tc_map));
@@ -2186,6 +2213,9 @@ int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset)
if (tc >= dev->num_tc)
return -EINVAL;
+#ifdef CONFIG_XPS
+ netif_reset_xps_queues(dev, offset, count);
+#endif
dev->tc_to_txq[tc].count = count;
dev->tc_to_txq[tc].offset = offset;
return 0;
@@ -2197,6 +2227,9 @@ int netdev_set_num_tc(struct net_device *dev, u8 num_tc)
if (num_tc > TC_MAX_QUEUE)
return -EINVAL;
+#ifdef CONFIG_XPS
+ netif_reset_xps_queues_gt(dev, 0);
+#endif
dev->num_tc = num_tc;
return 0;
}
^ permalink raw reply related
* [net-next PATCH 1/3] net: Move functions for configuring traffic classes out of inline headers
From: Alexander Duyck @ 2016-10-27 15:40 UTC (permalink / raw)
To: netdev; +Cc: john.r.fastabend, tom, intel-wired-lan, davem
In-Reply-To: <20161027153539.13989.14349.stgit@ahduyck-blue-test.jf.intel.com>
The functions for configuring the traffic class to queue mappings have
other effects that need to be addressed. Instead of trying to export a
bunch of new functions just relocate the functions so that we can
instrument them directly with the functionality they will need.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
include/linux/netdevice.h | 31 +++----------------------------
net/core/dev.c | 29 +++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 458c876..d045432 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1920,34 +1920,9 @@ int netdev_set_prio_tc_map(struct net_device *dev, u8 prio, u8 tc)
return 0;
}
-static inline
-void netdev_reset_tc(struct net_device *dev)
-{
- dev->num_tc = 0;
- memset(dev->tc_to_txq, 0, sizeof(dev->tc_to_txq));
- memset(dev->prio_tc_map, 0, sizeof(dev->prio_tc_map));
-}
-
-static inline
-int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset)
-{
- if (tc >= dev->num_tc)
- return -EINVAL;
-
- dev->tc_to_txq[tc].count = count;
- dev->tc_to_txq[tc].offset = offset;
- return 0;
-}
-
-static inline
-int netdev_set_num_tc(struct net_device *dev, u8 num_tc)
-{
- if (num_tc > TC_MAX_QUEUE)
- return -EINVAL;
-
- dev->num_tc = num_tc;
- return 0;
-}
+void netdev_reset_tc(struct net_device *dev);
+int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset);
+int netdev_set_num_tc(struct net_device *dev, u8 num_tc);
static inline
int netdev_get_num_tc(struct net_device *dev)
diff --git a/net/core/dev.c b/net/core/dev.c
index f55fb45..d4d45bf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2173,6 +2173,35 @@ int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
EXPORT_SYMBOL(netif_set_xps_queue);
#endif
+void netdev_reset_tc(struct net_device *dev)
+{
+ dev->num_tc = 0;
+ memset(dev->tc_to_txq, 0, sizeof(dev->tc_to_txq));
+ memset(dev->prio_tc_map, 0, sizeof(dev->prio_tc_map));
+}
+EXPORT_SYMBOL(netdev_reset_tc);
+
+int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset)
+{
+ if (tc >= dev->num_tc)
+ return -EINVAL;
+
+ dev->tc_to_txq[tc].count = count;
+ dev->tc_to_txq[tc].offset = offset;
+ return 0;
+}
+EXPORT_SYMBOL(netdev_set_tc_queue);
+
+int netdev_set_num_tc(struct net_device *dev, u8 num_tc)
+{
+ if (num_tc > TC_MAX_QUEUE)
+ return -EINVAL;
+
+ dev->num_tc = num_tc;
+ return 0;
+}
+EXPORT_SYMBOL(netdev_set_num_tc);
+
/*
* Routine to help set real_num_tx_queues. To avoid skbs mapped to queues
* greater then real_num_tx_queues stale skbs on the qdisc must be flushed.
^ permalink raw reply related
* [net-next PATCH 0/3] Add support for XPS when using DCB
From: Alexander Duyck @ 2016-10-27 15:39 UTC (permalink / raw)
To: netdev; +Cc: john.r.fastabend, tom, intel-wired-lan, davem
This patch series enables proper isolation between traffic classes when
using XPS while DCB is enabled. Previously enabling XPS would cause the
traffic to be potentially pulled from one traffic class into another on
egress. This change essentially multiplies the XPS map by the number of
traffic classes and allows us to do a lookup per traffic class for a given
CPU.
To guarantee the isolation I invalidate the XPS map for any queues that are
moved from one traffic class to another, or if we change the number of
traffic classes.
---
Alexander Duyck (3):
net: Move functions for configuring traffic classes out of inline headers
net: Refactor removal of queues from XPS map and apply on num_tc changes
net: Add support for XPS with QoS via traffic classes
include/linux/netdevice.h | 36 +------
net/core/dev.c | 228 +++++++++++++++++++++++++++++++++++----------
net/core/net-sysfs.c | 31 ++++--
3 files changed, 202 insertions(+), 93 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Michael S. Tsirkin @ 2016-10-27 21:30 UTC (permalink / raw)
To: John Fastabend
Cc: Jesper Dangaard Brouer, David Miller, shrijeet, tom, netdev, shm,
roopa, nikolay
In-Reply-To: <58126CF4.5090500@gmail.com>
On Thu, Oct 27, 2016 at 02:09:08PM -0700, John Fastabend wrote:
> On 16-10-27 01:55 AM, Jesper Dangaard Brouer wrote:
> > On Wed, 26 Oct 2016 13:11:22 -0400 (EDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: "Michael S. Tsirkin" <mst@redhat.com>
> >> Date: Wed, 26 Oct 2016 20:07:19 +0300
> >>
> >>> On Wed, Oct 26, 2016 at 12:52:45PM -0400, David Miller wrote:
> >>>> From: "Michael S. Tsirkin" <mst@redhat.com>
> >>>> Date: Wed, 26 Oct 2016 19:36:45 +0300
> >>>>
> >>>>> On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
> >>>>>> On Sat, 22 Oct 2016 04:07:23 +0000
> >>>>>> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
> >>>>>>
> >>>>>>> This patch adds support for xdp ndo and also inserts the xdp program
> >>>>>>> call into the merged RX buffers and big buffers paths
> >>>>>>
> >>>>>> I really appreciate you are doing this for virtio_net.
> >>>>>>
> >>>>>> My first question is: Is the (packet) page data writable?
> >>>>>> (MST might be able to answer?)
> >>>>>>
> >>>>>> As this is currently an XDP requirement[1].
> >>>>>
> >>>>> I'm not sure I understand what does writable mean.
> >>>>> Could you explain a bit more pls?
> >>>>> We do copy data into skb ATM but I plan to change that.
> >>>>
> >>>> The packet data area must be writable,
> >>>
> >>> This is the part I don't fully understand.
> >>> It's in RAM so of course it's writeable.
> >>
> >> Pages in SKB frag lists are not usually writable, because they share
> >> space with data from other packets the way drivers usually carve up
> >> pages to receive packets into.
> >>
> >> It is therefore illegal for the networking code to write into SKB frag
> >> pages.
> >>
> >> Pages used for XDP processed packets must not have this restriction.
> >>
> >>> We share pages between arbitrary multiple packets. I think that's
> >>> OK
> >>
> >> That's exactly what is not allowed with XDP.
> >>
> >> Each packet must be the sole user of a page, otherwise the semantics
> >> required by XDP are not met.
> >
> > Looking at the virtio_net.c code, the function call receive_big() might
> > actually be okay for XDP, unless the incoming packet is larger than
> > PAGE_SIZE and thus uses several pages (via a linked list in page->private).
> >
> > The receive_mergeable() does not look compatible with XDP.
> >
>
> Looks to me the correct conditions can be met by getting the correct
> feature negotiation to happen, specifically no VIRTIO_NET_F_MRG_RXBUF
> and one of the TSO/ECN/GSO feature bits set the big_packets flag as
> Jesper notes.
>
> Srijeet, are you going to give this a try? I'm trying to get the device
> side working by the way on the vhost interface.
>
> Thanks,
> John
Something I'd like to understand is how does XDP address the
problem that 100Byte packets are consuming 4K of memory now.
--
MST
^ permalink raw reply
* [net 4/4] i40e: fix call of ndo_dflt_bridge_getlink()
From: Jeff Kirsher @ 2016-10-27 21:27 UTC (permalink / raw)
To: davem
Cc: Huaibin Wang, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Carolyn Wyborny, Nicolas Dichtel, Jeff Kirsher
In-Reply-To: <1477603677-39957-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Huaibin Wang <huaibin.wang@6wind.com>
Order of arguments is wrong.
The wrong code has been introduced by commit 7d4f8d871ab1, but is compiled
only since commit 9df70b66418e.
Note that this may break netlink dumps.
Fixes: 9df70b66418e ("i40e: Remove incorrect #ifdef's")
Fixes: 7d4f8d871ab1 ("switchdev; add VLAN support for port's bridge_getlink")
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Huaibin Wang <huaibin.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6abc130..31c97e3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9034,7 +9034,7 @@ static int i40e_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
return 0;
return ndo_dflt_bridge_getlink(skb, pid, seq, dev, veb->bridge_mode,
- nlflags, 0, 0, filter_mask, NULL);
+ 0, 0, nlflags, filter_mask, NULL);
}
/* Hardware supports L4 tunnel length of 128B (=2^7) which includes
--
2.7.4
^ permalink raw reply related
* [net 3/4] i40e: disable MSI-X interrupts if we cannot reserve enough vectors
From: Jeff Kirsher @ 2016-10-27 21:27 UTC (permalink / raw)
To: davem
Cc: Guilherme G Piccoli, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477603677-39957-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
If we fail on allocating enough MSI-X interrupts, we should disable
them since they were previously enabled in this point of code.
Not disabling them can lead to WARN_ON() being triggered and subsequent
failure in enabling MSI as a fallback; the below message was shown without
this patch while we played with interrupt allocation in i40e driver:
[ 21.461346] sysfs: cannot create duplicate filename '/devices/pci0007:00/0007:00:00.0/0007:01:00.3/msi_irqs'
[ 21.461459] ------------[ cut here ]------------
[ 21.461514] WARNING: CPU: 64 PID: 1155 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x88/0xc0
Also, we noticed that without this patch, if we modprobe the module without
enough MSI-X interrupts (triggering the above warning), unload the module
and re-load it again, we got a crash on the system.
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 050d005..6abc130 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7684,6 +7684,7 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->flags &= ~I40E_FLAG_MSIX_ENABLED;
kfree(pf->msix_entries);
pf->msix_entries = NULL;
+ pci_disable_msix(pf->pdev);
return -ENODEV;
} else if (v_actual == I40E_MIN_MSIX) {
--
2.7.4
^ permalink raw reply related
* [net 2/4] i40e: Fix configure TCs after initial DCB disable
From: Jeff Kirsher @ 2016-10-27 21:27 UTC (permalink / raw)
To: davem
Cc: David Ertman, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477603677-39957-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: David Ertman <david.m.ertman@intel.com>
in commit a036244c068612a43fa8c0f33a0eb4daa4d8dba0 a fix
was put into place to avoid a kernel panic when a non-
supported traffic class configuration was put into place
and then lldp was enabled/disabled on the link partner
switch. This fix caused it to be necessary to
unload/reload the driver to reenable DCB once a supported
TC config was in place.
The root cause of the original panic was that the function
i40e_pf_get_default_tc was allowing for a default TC other
than TC 0, and only TC 0 is supported as a default.
This patch removes the get_default_tc function and replaces
it with a #define since there is only one TC supported as
a default.
Change-Id: I448371974e946386d0a7718d73668b450b7c72ef
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Ronald Bynoe <ronald.j.bynoe@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 31 ++++-------------------------
2 files changed, 5 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 2030d7c..6d61e44 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -92,6 +92,7 @@
#define I40E_AQ_LEN 256
#define I40E_AQ_WORK_LIMIT 66 /* max number of VFs + a little */
#define I40E_MAX_USER_PRIORITY 8
+#define I40E_DEFAULT_TRAFFIC_CLASS BIT(0)
#define I40E_DEFAULT_MSG_ENABLE 4
#define I40E_QUEUE_WAIT_RETRY_LIMIT 10
#define I40E_INT_NAME_STR_LEN (IFNAMSIZ + 16)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ac1faee..050d005 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -4641,29 +4641,6 @@ static u8 i40e_pf_get_num_tc(struct i40e_pf *pf)
}
/**
- * i40e_pf_get_default_tc - Get bitmap for first enabled TC
- * @pf: PF being queried
- *
- * Return a bitmap for first enabled traffic class for this PF.
- **/
-static u8 i40e_pf_get_default_tc(struct i40e_pf *pf)
-{
- u8 enabled_tc = pf->hw.func_caps.enabled_tcmap;
- u8 i = 0;
-
- if (!enabled_tc)
- return 0x1; /* TC0 */
-
- /* Find the first enabled TC */
- for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- if (enabled_tc & BIT(i))
- break;
- }
-
- return BIT(i);
-}
-
-/**
* i40e_pf_get_pf_tc_map - Get bitmap for enabled traffic classes
* @pf: PF being queried
*
@@ -4673,7 +4650,7 @@ static u8 i40e_pf_get_tc_map(struct i40e_pf *pf)
{
/* If DCB is not enabled for this PF then just return default TC */
if (!(pf->flags & I40E_FLAG_DCB_ENABLED))
- return i40e_pf_get_default_tc(pf);
+ return I40E_DEFAULT_TRAFFIC_CLASS;
/* SFP mode we want PF to be enabled for all TCs */
if (!(pf->flags & I40E_FLAG_MFP_ENABLED))
@@ -4683,7 +4660,7 @@ static u8 i40e_pf_get_tc_map(struct i40e_pf *pf)
if (pf->hw.func_caps.iscsi)
return i40e_get_iscsi_tc_map(pf);
else
- return i40e_pf_get_default_tc(pf);
+ return I40E_DEFAULT_TRAFFIC_CLASS;
}
/**
@@ -5029,7 +5006,7 @@ static void i40e_dcb_reconfigure(struct i40e_pf *pf)
if (v == pf->lan_vsi)
tc_map = i40e_pf_get_tc_map(pf);
else
- tc_map = i40e_pf_get_default_tc(pf);
+ tc_map = I40E_DEFAULT_TRAFFIC_CLASS;
#ifdef I40E_FCOE
if (pf->vsi[v]->type == I40E_VSI_FCOE)
tc_map = i40e_get_fcoe_tc_map(pf);
@@ -5717,7 +5694,7 @@ static int i40e_handle_lldp_event(struct i40e_pf *pf,
u8 type;
/* Not DCB capable or capability disabled */
- if (!(pf->flags & I40E_FLAG_DCB_ENABLED))
+ if (!(pf->flags & I40E_FLAG_DCB_CAPABLE))
return ret;
/* Ignore if event is not for Nearest Bridge */
--
2.7.4
^ permalink raw reply related
* [net 1/4] ixgbe: fix panic when using macvlan with l2-fwd-offload enabled
From: Jeff Kirsher @ 2016-10-27 21:27 UTC (permalink / raw)
To: davem
Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1477603677-39957-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Fix NULL pointer dereference in the case where a macvlan interface is
brought up while the PF is still down:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffffa0170fb2>] ixgbe_alloc_rx_buffers+0x42/0x1a0 [ixgbe]
Call Trace:
[<ffffffffa017336b>] ixgbe_configure_rx_ring+0x2eb/0x3d0 [ixgbe]
[<ffffffffa0173811>] ixgbe_fwd_ring_up+0xd1/0x380 [ixgbe]
[<ffffffffa0179709>] ixgbe_fwd_add+0x149/0x230 [ixgbe]
[<ffffffffa0113480>] macvlan_open+0x260/0x2b0 [macvlan]
Reported-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a244d9a..bd93d82 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9135,10 +9135,14 @@ static void *ixgbe_fwd_add(struct net_device *pdev, struct net_device *vdev)
goto fwd_add_err;
fwd_adapter->pool = pool;
fwd_adapter->real_adapter = adapter;
- err = ixgbe_fwd_ring_up(vdev, fwd_adapter);
- if (err)
- goto fwd_add_err;
- netif_tx_start_all_queues(vdev);
+
+ if (netif_running(pdev)) {
+ err = ixgbe_fwd_ring_up(vdev, fwd_adapter);
+ if (err)
+ goto fwd_add_err;
+ netif_tx_start_all_queues(vdev);
+ }
+
return fwd_adapter;
fwd_add_err:
/* unwind counter and free adapter struct */
--
2.7.4
^ permalink raw reply related
* [net 0/4][pull request] Intel Wired LAN Driver Updates 2016-10-27
From: Jeff Kirsher @ 2016-10-27 21:27 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene,
guru.anbalagane
This series contains fixes to ixgbe and i40e.
Emil fixes a NULL pointer dereference when a macvlan interface is brought
up while the PF is still down.
David root caused the original panic that was fixed by commit id
(a036244c068612 "i40e: Fix kernel panic on enable/disable LLDP") and the
fix was not quite correct, so removed the get_default_tc() and replaced
it with a #define since there is only one TC supported as a default.
Guilherme Piccoli fixes an issue where if we modprobe the driver module
without enough MSI-X interrupts, then unload the module and reload it
again, the kernel would crash. So if we fail to allocate enough MSI-X
interrupts, we should disable them since they were previously enabled.
Huaibin Wang found that the order of the arguments for
ndo_dflt_bridge_getlink() were in the correct order, so fix the order.
The following are changes since commit d5d32e4b76687f4df9ad3ba8d3702b7347f51fa6:
net: ipv6: Do not consider link state for nexthop validation
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 40GbE
David Ertman (1):
i40e: Fix configure TCs after initial DCB disable
Emil Tantilov (1):
ixgbe: fix panic when using macvlan with l2-fwd-offload enabled
Guilherme G Piccoli (1):
i40e: disable MSI-X interrupts if we cannot reserve enough vectors
Huaibin Wang (1):
i40e: fix call of ndo_dflt_bridge_getlink()
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 34 +++++----------------------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 ++++++----
3 files changed, 15 insertions(+), 32 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Florian Fainelli @ 2016-10-27 21:25 UTC (permalink / raw)
To: Jon Mason, Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, devicetree, netdev,
linux-kernel, bcm-kernel-feedback-list, rafal, linux-arm-kernel
In-Reply-To: <20161027212106.GA25693@broadcom.com>
On 10/27/2016 02:21 PM, Jon Mason wrote:
> On Thu, Oct 27, 2016 at 11:17:57AM +0200, Andrew Lunn wrote:
>> On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> index ba5ecc1..f92caee 100644
>>> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>>> -------------------------------------------------------------
>>>
>>> Required properties:
>>> - - compatible: "brcm,amac" or "brcm,nsp-amac"
>>> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
>>> - reg: Address and length of the GMAC registers,
>>> Address and length of the GMAC IDM registers
>>> + Address and length of the NIC Port Manager registers (optional)
>>> - reg-names: Names of the registers. Must have both "amac_base" and
>>> - "idm_base"
>>> + "idm_base". "nicpm_base" is optional (required for NS2)
>>> - interrupts: Interrupt number
>>>
>>> Optional properties:
>>> - mac-address: See ethernet.txt file in the same directory
>>> +- brcm,enet-phy-lane-swap:
>>> + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
>>
>> Maybe i'm missing something here, but the patch to the PHY swapped the
>> lanes. This seems to be a PHY property, not a MAC property. And it
>> swapped them unconditionally....
>
> It swapped them based on (from patch 1/5)
> if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
> phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP)
>
> That flag is being set in the driver based on whether the lanes need
> to be swapped (which depends on the SKU of NS2). The only SKU of NS2
> we have upstream right now has it swapped, but one that should be
> pushed out in the next few weeks will not have this flag present.
> There is no way to detect it, and having a separate compat string
> seemed overkill.
Andrew has a point thought that this is a property that is associated
with the PHY, and not with the Ethernet MAC per se, as such, you can put
it in the Ethernet PHY node, and look up the proper from
drivers/net/phy/broadcom.c, and come up with a Broadcom Ethernet PHY
binding document (sorry).
There is no need to have a specific compatible string allocated, using
the (mostly) generic Ethernet PHY binding, plus this property documented
would be good enough.
--
Florian
^ permalink raw reply
* Re: [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-10-27 21:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161027091757.GC12841@lunn.ch>
On Thu, Oct 27, 2016 at 11:17:57AM +0200, Andrew Lunn wrote:
> On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
> > Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> > index ba5ecc1..f92caee 100644
> > --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> > +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> > @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> > -------------------------------------------------------------
> >
> > Required properties:
> > - - compatible: "brcm,amac" or "brcm,nsp-amac"
> > + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
> > - reg: Address and length of the GMAC registers,
> > Address and length of the GMAC IDM registers
> > + Address and length of the NIC Port Manager registers (optional)
> > - reg-names: Names of the registers. Must have both "amac_base" and
> > - "idm_base"
> > + "idm_base". "nicpm_base" is optional (required for NS2)
> > - interrupts: Interrupt number
> >
> > Optional properties:
> > - mac-address: See ethernet.txt file in the same directory
> > +- brcm,enet-phy-lane-swap:
> > + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
>
> Maybe i'm missing something here, but the patch to the PHY swapped the
> lanes. This seems to be a PHY property, not a MAC property. And it
> swapped them unconditionally....
It swapped them based on (from patch 1/5)
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP)
That flag is being set in the driver based on whether the lanes need
to be swapped (which depends on the SKU of NS2). The only SKU of NS2
we have upstream right now has it swapped, but one that should be
pushed out in the next few weeks will not have this flag present.
There is no way to detect it, and having a separate compat string
seemed overkill.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* Re: [PATCH v2] net: skip genenerating uevents for network namespaces that are exiting
From: David Miller @ 2016-10-27 21:15 UTC (permalink / raw)
To: avagin-GEFAQzZX7r8dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477361393-24876-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
From: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Date: Mon, 24 Oct 2016 19:09:53 -0700
> No one can see these events, because a network namespace can not be
> destroyed, if it has sockets.
>
> Unlike other devices, uevent-s for network devices are generated
> only inside their network namespaces. They are filtered in
> kobj_bcast_filter()
>
> My experiments shows that net namespaces are destroyed more 30% faster
> with this optimization.
>
> Here is a perf output for destroying network namespaces without this
> patch.
...
> It's very critical to optimize the exit path for network namespaces,
> because they are destroyed under net_mutex and many namespaces can be
> destroyed for one iteration.
>
> v2: use dev_set_uevent_suppress()
>
> Cc: Cong Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v2 net 1/1] net sched filters: fix notification of filter delete with proper handle
From: David Miller @ 2016-10-27 21:12 UTC (permalink / raw)
To: jhs; +Cc: netdev, daniel, xiyou.wangcong, eric.dumazet, jiri
In-Reply-To: <1477354707-7210-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 24 Oct 2016 20:18:27 -0400
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Daniel says:
>
> While trying out [1][2], I noticed that tc monitor doesn't show the
> correct handle on delete:
>
> $ tc monitor
> qdisc clsact ffff: dev eno1 parent ffff:fff1
> filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...]
> deleted filter dev eno1 ingress protocol all pref 49152 bpf handle 0xf3be0c80
>
> some context to explain the above:
> The user identity of any tc filter is represented by a 32-bit
> identifier encoded in tcm->tcm_handle. Example 0x2a in the bpf filter
> above. A user wishing to delete, get or even modify a specific filter
> uses this handle to reference it.
> Every classifier is free to provide its own semantics for the 32 bit handle.
> Example: classifiers like u32 use schemes like 800:1:801 to describe
> the semantics of their filters represented as hash table, bucket and
> node ids etc.
> Classifiers also have internal per-filter representation which is different
> from this externally visible identity. Most classifiers set this
> internal representation to be a pointer address (which allows fast retrieval
> of said filters in their implementations). This internal representation
> is referenced with the "fh" variable in the kernel control code.
>
> When a user successfuly deletes a specific filter, by specifying the correct
> tcm->tcm_handle, an event is generated to user space which indicates
> which specific filter was deleted.
>
> Before this patch, the "fh" value was sent to user space as the identity.
> As an example what is shown in the sample bpf filter delete event above
> is 0xf3be0c80. This is infact a 32-bit truncation of 0xffff8807f3be0c80
> which happens to be a 64-bit memory address of the internal filter
> representation (address of the corresponding filter's struct cls_bpf_prog);
>
> After this patch the appropriate user identifiable handle as encoded
> in the originating request tcm->tcm_handle is generated in the event.
> One of the cardinal rules of netlink rules is to be able to take an
> event (such as a delete in this case) and reflect it back to the
> kernel and successfully delete the filter. This patch achieves that.
>
> Note, this issue has existed since the original TC action
> infrastructure code patch back in 2004 as found in:
> https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/
>
> [1] http://patchwork.ozlabs.org/patch/682828/
> [2] http://patchwork.ozlabs.org/patch/682829/
>
> Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.")
> Reported-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied and queued up for -stable, thanks Jamal.
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: John Fastabend @ 2016-10-27 21:09 UTC (permalink / raw)
To: Jesper Dangaard Brouer, David Miller
Cc: mst, shrijeet, tom, netdev, shm, roopa, nikolay
In-Reply-To: <20161027105514.4c0374dd@redhat.com>
On 16-10-27 01:55 AM, Jesper Dangaard Brouer wrote:
> On Wed, 26 Oct 2016 13:11:22 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Wed, 26 Oct 2016 20:07:19 +0300
>>
>>> On Wed, Oct 26, 2016 at 12:52:45PM -0400, David Miller wrote:
>>>> From: "Michael S. Tsirkin" <mst@redhat.com>
>>>> Date: Wed, 26 Oct 2016 19:36:45 +0300
>>>>
>>>>> On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
>>>>>> On Sat, 22 Oct 2016 04:07:23 +0000
>>>>>> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
>>>>>>
>>>>>>> This patch adds support for xdp ndo and also inserts the xdp program
>>>>>>> call into the merged RX buffers and big buffers paths
>>>>>>
>>>>>> I really appreciate you are doing this for virtio_net.
>>>>>>
>>>>>> My first question is: Is the (packet) page data writable?
>>>>>> (MST might be able to answer?)
>>>>>>
>>>>>> As this is currently an XDP requirement[1].
>>>>>
>>>>> I'm not sure I understand what does writable mean.
>>>>> Could you explain a bit more pls?
>>>>> We do copy data into skb ATM but I plan to change that.
>>>>
>>>> The packet data area must be writable,
>>>
>>> This is the part I don't fully understand.
>>> It's in RAM so of course it's writeable.
>>
>> Pages in SKB frag lists are not usually writable, because they share
>> space with data from other packets the way drivers usually carve up
>> pages to receive packets into.
>>
>> It is therefore illegal for the networking code to write into SKB frag
>> pages.
>>
>> Pages used for XDP processed packets must not have this restriction.
>>
>>> We share pages between arbitrary multiple packets. I think that's
>>> OK
>>
>> That's exactly what is not allowed with XDP.
>>
>> Each packet must be the sole user of a page, otherwise the semantics
>> required by XDP are not met.
>
> Looking at the virtio_net.c code, the function call receive_big() might
> actually be okay for XDP, unless the incoming packet is larger than
> PAGE_SIZE and thus uses several pages (via a linked list in page->private).
>
> The receive_mergeable() does not look compatible with XDP.
>
Looks to me the correct conditions can be met by getting the correct
feature negotiation to happen, specifically no VIRTIO_NET_F_MRG_RXBUF
and one of the TSO/ECN/GSO feature bits set the big_packets flag as
Jesper notes.
Srijeet, are you going to give this a try? I'm trying to get the device
side working by the way on the vhost interface.
Thanks,
John
^ permalink raw reply
* Re: [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-10-27 20:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, Rob Herring, Mark Rutland,
rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <eff0c717-ec4b-1dce-992a-ad5e958800f5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Oct 26, 2016 at 02:50:39PM -0700, Florian Fainelli wrote:
> On 10/26/2016 12:36 PM, Jon Mason wrote:
> > Add support for the variant of amac hardware present in the Broadcom
> > Northstar2 based SoCs. Northstar2 requires an additional register to be
> > configured with the port speed/duplexity (NICPM). This can be added to
> > the link callback to hide it from the instances that do not use this.
> > Also, the bgmac_chip_reset() was intentionally removed to prevent the
> > resetting of the chip to the default values on open. Finally, clearing
> > of the pending interrupts on init is required due to observed issues on
> > some platforms.
> >
> > Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> > ---
>
> > +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> > +{
> > + struct bgmac *bgmac = netdev_priv(net_dev);
> > + u32 val;
> > +
> > + if (!bgmac->plat.nicpm_base)
> > + return;
> > +
> > + val = NICPM_IOMUX_CTRL_INIT_VAL;
> > + switch (bgmac->net_dev->phydev->speed) {
> > + default:
> > + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> > + case SPEED_1000:
> > + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_100:
> > + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_10:
> > + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + }
> > +
> > + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> > +
> > + usleep_range(10, 100);
>
> Does not seem like a good idea, do you need that sleep?
Oops, that's not supposed to be there. Removed.
> > +
> > + bgmac_adjust_link(bgmac->net_dev);
> > +}
> > +
> > static int platform_phy_connect(struct bgmac *bgmac)
> > {
> > struct phy_device *phy_dev;
> >
> > - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> > - bgmac_adjust_link);
> > + if (bgmac->plat.nicpm_base)
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_nicpm_speed_set);
> > + else
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_adjust_link);
> > if (!phy_dev) {
> > dev_err(bgmac->dev, "Phy connect failed\n");
> > return -ENODEV;
> > }
> >
> > + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> > + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> > +
> > return 0;
> > }
> >
> > @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, bgmac);
> >
> > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> > + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> > +
> > /* Set the features of the 4707 family */
> > bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> > bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> > @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> > if (IS_ERR(bgmac->plat.idm_base))
> > return PTR_ERR(bgmac->plat.idm_base);
> >
> > + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> > + if (regs) {
> > + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> > + regs);
> > + if (IS_ERR(bgmac->plat.nicpm_base))
> > + return PTR_ERR(bgmac->plat.nicpm_base);
> > + }
> > +
> > bgmac->read = platform_bgmac_read;
> > bgmac->write = platform_bgmac_write;
> > bgmac->idm_read = platform_bgmac_idm_read;
> > @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> > static const struct of_device_id bgmac_of_enet_match[] = {
> > {.compatible = "brcm,amac",},
> > {.compatible = "brcm,nsp-amac",},
> > + {.compatible = "brcm,ns2-amac",},
> > {},
> > };
> >
> > diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> > index 38876ec..1796208 100644
> > --- a/drivers/net/ethernet/broadcom/bgmac.c
> > +++ b/drivers/net/ethernet/broadcom/bgmac.c
> > @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> > /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> > static void bgmac_chip_init(struct bgmac *bgmac)
> > {
> > + /* Clear any erroneously pending interrupts */
> > + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> > +
> > /* 1 interrupt per received frame */
> > bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
> >
> > @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> > struct bgmac *bgmac = netdev_priv(net_dev);
> > int err = 0;
> >
> > - bgmac_chip_reset(bgmac);
> > -
>
> Is this removal intentional? Maybe it should be special cased with
> checking for a NS2 BGMAC instance and not do it in that case?
The reset seems completely unnecessary. There is already 2 resets in
the probe routine, another reset serves no purpose. I can add it
back, as it does not seem to have the negative effect I was seeing
before.
Of course, if I remove this one I should remove the reset in the close
too (which seems even more unnecessary, but I didn't remove it).
Thanks,
Jon
> --
> Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: bgmac: fix spelling mistake: "connecton" -> "connection"
From: David Miller @ 2016-10-27 20:37 UTC (permalink / raw)
To: colin.king
Cc: f.fainelli, jon.mason, arnd, rafal, tremyfr, netdev, linux-kernel
In-Reply-To: <20161024224618.10383-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Mon, 24 Oct 2016 23:46:18 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net] flow_dissector: fix vlan tag handling
From: David Miller @ 2016-10-27 20:36 UTC (permalink / raw)
To: arnd; +Cc: e, hadarh, jiri, aduyck, tom, netdev, linux-kernel
In-Reply-To: <20161024214058.1896091-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 24 Oct 2016 23:40:30 +0200
> gcc warns about an uninitialized pointer dereference in the vlan
> priority handling:
>
> net/core/flow_dissector.c: In function '__skb_flow_dissect':
> net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> As pointed out by Jiri Pirko, the variable is never actually used
> without being initialized first as the only way it end up uninitialized
> is with skb_vlan_tag_present(skb)==true, and that means it does not
> get accessed.
>
> However, the warning hints at some related issues that I'm addressing
> here:
>
> - the second check for the vlan tag is different from the first one
> that tests the skb for being NULL first, causing both the warning
> and a possible NULL pointer dereference that was not entirely fixed.
> - The same patch that introduced the NULL pointer check dropped an
> earlier optimization that skipped the repeated check of the
> protocol type
> - The local '_vlan' variable is referenced through the 'vlan' pointer
> but the variable has gone out of scope by the time that it is
> accessed, causing undefined behavior
>
> Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
> in a local variable allows the compiler to further optimize the
> later check. With those changes, the warning also disappears.
>
> Fixes: 3805a938a6c2 ("flow_dissector: Check skb for VLAN only if skb specified.")
> Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH] net: ipv6: Do not consider link state for nexthop validation
From: David Miller @ 2016-10-27 20:34 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1477337243-10650-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Mon, 24 Oct 2016 12:27:23 -0700
> Similar to IPv4, do not consider link state when validating next hops.
>
> Currently, if the link is down default routes can fail to insert:
> $ ip -6 ro add vrf blue default via 2100:2::64 dev eth2
> RTNETLINK answers: No route to host
>
> With this patch the command succeeds.
>
> Fixes: 8c14586fc320 ("net: ipv6: Use passed in table for nexthop lookups")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied and queued up for -stable.
^ permalink raw reply
* [patch net-next v2] rocker: set physical device for port netdevice
From: Jiri Pirko @ 2016-10-27 20:32 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Jiri Pirko <jiri@mellanox.com>
Do this so the sysfs has "device" link correctly set.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
v1->v2:
- make pdev non-const as pointerd out by kbuild test robot
---
drivers/net/ethernet/rocker/rocker_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 2e81b70..55b2ab9 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2534,7 +2534,7 @@ static void rocker_port_dev_addr_init(struct rocker_port *rocker_port)
#define ROCKER_PORT_MAX_MTU 9000
static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
{
- const struct pci_dev *pdev = rocker->pdev;
+ struct pci_dev *pdev = rocker->pdev;
struct rocker_port *rocker_port;
struct net_device *dev;
int err;
@@ -2542,6 +2542,7 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
dev = alloc_etherdev(sizeof(struct rocker_port));
if (!dev)
return -ENOMEM;
+ SET_NETDEV_DEV(dev, &pdev->dev);
rocker_port = netdev_priv(dev);
rocker_port->dev = dev;
rocker_port->rocker = rocker;
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v2] net: ipv6: Fix processing of RAs in presence of VRF
From: David Miller @ 2016-10-27 20:31 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1477331555-9438-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Mon, 24 Oct 2016 10:52:35 -0700
> rt6_add_route_info and rt6_add_dflt_router were updated to pull the FIB
> table from the device index, but the corresponding rt6_get_route_info
> and rt6_get_dflt_router functions were not leading to the failure to
> process RA's:
>
> ICMPv6: RA: ndisc_router_discovery failed to add default route
>
> Fix the 'get' functions by using the table id associated with the
> device when applicable.
>
> Also, now that default routes can be added to tables other than the
> default table, rt6_purge_dflt_routers needs to be updated as well to
> look at all tables. To handle that efficiently, add a flag to the table
> denoting if it is has a default route via RA.
>
> Fixes: ca254490c8dfd ("net: Add VRF support to IPv6 stack")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] kalmia: avoid potential uninitialized variable use
From: David Miller @ 2016-10-27 20:28 UTC (permalink / raw)
To: arnd; +Cc: netdev, linux-usb, linux-kernel
In-Reply-To: <20161024155430.3077348-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 24 Oct 2016 17:54:18 +0200
> The kalmia_send_init_packet() returns zero or a negative return
> code, but gcc has no way of knowing that there cannot be a
> positive return code, so it determines that copying the ethernet
> address at the end of kalmia_bind() will access uninitialized
> data:
>
> drivers/net/usb/kalmia.c: In function ‘kalmia_bind’:
> arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)ðernet_addr+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> *((short *)to + 2) = *((short *)from + 2);
> ^
> drivers/net/usb/kalmia.c:138:5: note: ‘*((void *)ðernet_addr+4)’ was declared here
>
> This warning is harmless, but for consistency, we should make
> the check for the return code match what the driver does everywhere
> else and just progate it, which then gets rid of the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox