Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next 01/14] gso: Remove arbitrary checks for unsupported GSO
From: Tom Herbert @ 2016-05-05  1:02 UTC (permalink / raw)
  To: davem, netdev; +Cc: kernel-team
In-Reply-To: <1462410164-1953217-1-git-send-email-tom@herbertland.com>

In several gso_segment functions there are checks of gso_type against
a seemingly abitrary list of SKB_GSO_* flags. This seems like an
attempt to identify unsupported GSO types, but since the stack is
the one that set these GSO types in the first place this seems
unnecessary to do. If a combination isn't valid in the first
place that stack should not allow setting it.

This is a code simplication especially for add new GSO types.

Signed-off-by: Tom Herbert <tom@herbertland.com>
---
 net/ipv4/af_inet.c     | 18 ------------------
 net/ipv4/gre_offload.c | 14 --------------
 net/ipv4/tcp_offload.c | 19 -------------------
 net/ipv4/udp_offload.c | 10 ----------
 net/ipv6/ip6_offload.c | 18 ------------------
 net/ipv6/udp_offload.c | 13 -------------
 6 files changed, 92 deletions(-)

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 2e6e65f..7f08d45 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1205,24 +1205,6 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
 	int ihl;
 	int id;
 
-	if (unlikely(skb_shinfo(skb)->gso_type &
-		     ~(SKB_GSO_TCPV4 |
-		       SKB_GSO_UDP |
-		       SKB_GSO_DODGY |
-		       SKB_GSO_TCP_ECN |
-		       SKB_GSO_GRE |
-		       SKB_GSO_GRE_CSUM |
-		       SKB_GSO_IPIP |
-		       SKB_GSO_SIT |
-		       SKB_GSO_TCPV6 |
-		       SKB_GSO_UDP_TUNNEL |
-		       SKB_GSO_UDP_TUNNEL_CSUM |
-		       SKB_GSO_TCP_FIXEDID |
-		       SKB_GSO_TUNNEL_REMCSUM |
-		       SKB_GSO_PARTIAL |
-		       0)))
-		goto out;
-
 	skb_reset_network_header(skb);
 	nhoff = skb_network_header(skb) - skb_mac_header(skb);
 	if (unlikely(!pskb_may_pull(skb, sizeof(*iph))))
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index e88190a..ecd1e09 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -26,20 +26,6 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
 	int gre_offset, outer_hlen;
 	bool need_csum, ufo;
 
-	if (unlikely(skb_shinfo(skb)->gso_type &
-				~(SKB_GSO_TCPV4 |
-				  SKB_GSO_TCPV6 |
-				  SKB_GSO_UDP |
-				  SKB_GSO_DODGY |
-				  SKB_GSO_TCP_ECN |
-				  SKB_GSO_TCP_FIXEDID |
-				  SKB_GSO_GRE |
-				  SKB_GSO_GRE_CSUM |
-				  SKB_GSO_IPIP |
-				  SKB_GSO_SIT |
-				  SKB_GSO_PARTIAL)))
-		goto out;
-
 	if (!skb->encapsulation)
 		goto out;
 
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index 02737b6..5c59649 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -83,25 +83,6 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
 
 	if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
 		/* Packet is from an untrusted source, reset gso_segs. */
-		int type = skb_shinfo(skb)->gso_type;
-
-		if (unlikely(type &
-			     ~(SKB_GSO_TCPV4 |
-			       SKB_GSO_DODGY |
-			       SKB_GSO_TCP_ECN |
-			       SKB_GSO_TCP_FIXEDID |
-			       SKB_GSO_TCPV6 |
-			       SKB_GSO_GRE |
-			       SKB_GSO_GRE_CSUM |
-			       SKB_GSO_IPIP |
-			       SKB_GSO_SIT |
-			       SKB_GSO_UDP_TUNNEL |
-			       SKB_GSO_UDP_TUNNEL_CSUM |
-			       SKB_GSO_TUNNEL_REMCSUM |
-			       0) ||
-			     !(type & (SKB_GSO_TCPV4 |
-				       SKB_GSO_TCPV6))))
-			goto out;
 
 		skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
 
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 097060de..b556ef6 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -209,16 +209,6 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
 
 	if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
 		/* Packet is from an untrusted source, reset gso_segs. */
-		int type = skb_shinfo(skb)->gso_type;
-
-		if (unlikely(type & ~(SKB_GSO_UDP | SKB_GSO_DODGY |
-				      SKB_GSO_UDP_TUNNEL |
-				      SKB_GSO_UDP_TUNNEL_CSUM |
-				      SKB_GSO_TUNNEL_REMCSUM |
-				      SKB_GSO_IPIP |
-				      SKB_GSO_GRE | SKB_GSO_GRE_CSUM) ||
-			     !(type & (SKB_GSO_UDP))))
-			goto out;
 
 		skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
 
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index f5eb184..9ad743b 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -69,24 +69,6 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
 	bool encap, udpfrag;
 	int nhoff;
 
-	if (unlikely(skb_shinfo(skb)->gso_type &
-		     ~(SKB_GSO_TCPV4 |
-		       SKB_GSO_UDP |
-		       SKB_GSO_DODGY |
-		       SKB_GSO_TCP_ECN |
-		       SKB_GSO_TCP_FIXEDID |
-		       SKB_GSO_TCPV6 |
-		       SKB_GSO_GRE |
-		       SKB_GSO_GRE_CSUM |
-		       SKB_GSO_IPIP |
-		       SKB_GSO_SIT |
-		       SKB_GSO_UDP_TUNNEL |
-		       SKB_GSO_UDP_TUNNEL_CSUM |
-		       SKB_GSO_TUNNEL_REMCSUM |
-		       SKB_GSO_PARTIAL |
-		       0)))
-		goto out;
-
 	skb_reset_network_header(skb);
 	nhoff = skb_network_header(skb) - skb_mac_header(skb);
 	if (unlikely(!pskb_may_pull(skb, sizeof(*ipv6h))))
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 5429f6b..ac858c4 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -36,19 +36,6 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
 
 	if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
 		/* Packet is from an untrusted source, reset gso_segs. */
-		int type = skb_shinfo(skb)->gso_type;
-
-		if (unlikely(type & ~(SKB_GSO_UDP |
-				      SKB_GSO_DODGY |
-				      SKB_GSO_UDP_TUNNEL |
-				      SKB_GSO_UDP_TUNNEL_CSUM |
-				      SKB_GSO_TUNNEL_REMCSUM |
-				      SKB_GSO_GRE |
-				      SKB_GSO_GRE_CSUM |
-				      SKB_GSO_IPIP |
-				      SKB_GSO_SIT) ||
-			     !(type & (SKB_GSO_UDP))))
-			goto out;
 
 		skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
 
-- 
2.8.0.rc2

^ permalink raw reply related

* [PATCH net-next 00/14] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
From: Tom Herbert @ 2016-05-05  1:02 UTC (permalink / raw)
  To: davem, netdev; +Cc: kernel-team

This patch set:
  - Fixes GRE6 to process translate flags correctly from configuration
  - Adds support for GSO and GRO for ip6ip6 and ip4ip6
  - Add support for FOU and GUE in IPv6
  - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
  - Fixes ip6_input to deal with UDP encapsulations
  - Some other minor fixes


Tested:
   Tested a variety of case, but not the full matrix (which is quite
   large now). Most of the obivous cases (e.g. GRE) work fine. Still
   some issues probably with GSO/GRO being effective in all cases.

    - IPv4/GRE/GUE/IPv6 with RCO
      1 TCP_STREAM
      	6616 Mbps
      200 TCP_RR
	1244043 tps
        141/243/446 90/95/99% latencies
	86.61% CPU utilization
    - IPv6/GRE/GUE/IPv6 with RCO
      1 TCP_STREAM
	6940 Mbps
      200 TCP_RR
	1270903 tps
	138/236/440 90/95/99% latencies
	87.51% CPU utilization

     - IP6IP6
      1 TCP_STREAM
	2576 Mbps
      200 TCP_RR
	498981 tps
	388/498/631 90/95/99% latencies
	19.75% CPU utilization (1 CPU saturated)

     - IP6IP6/GUE/IPv6 with RCO
      1 TCP_STREAM
	1854 Mbps
      200 TCP_RR
	1233818 tps
	143/244/451 90/95/99% latencies
	87.57 CPU utilization

     - IP4IP6
      1 TCP_STREAM
      200 TCP_RR
	763774 tps
	250/318/466 90/95/99% latencies
	35.25% CPU utilization (1 CPU saturated)

     - GRE with keyid
      200 TCP_RR
	744173 tps
	258/332/461 90/95/99% latencies
	34.59% CPU utilization (1 CPU saturated)
      

Tom Herbert (14):
  gso: Remove arbitrary checks for unsupported GSO
  gre6: Fix flag translations
  udp: Don't set skb->encapsulation with RCO
  fou: Call setup_udp_tunnel_sock
  fou: Split out {fou,gue}_build_header
  fou: Add encap ops for IPv6 tunnels
  ipv6: Fix nexthdr for reinjection
  ipv6: Change "final" protocol processing for encapsulation
  fou: Support IPv6 in fou
  ip6_tun: Add infrastructure for doing encapsulation
  ip6_gre: Add support for fou/gue encapsulation
  ip6_tunnel: Add support for fou/gue encapsulation
  ip6ip6: Support for GSO/GRO
  ip4ip6: Support for GSO/GRO

 include/linux/netdev_features.h |   8 ++-
 include/linux/netdevice.h       |   2 +
 include/linux/skbuff.h          |   4 ++
 include/net/fou.h               |  10 +--
 include/net/inet_common.h       |   5 ++
 include/net/ip6_tunnel.h        |  22 +++++-
 net/core/ethtool.c              |   1 +
 net/ipv4/af_inet.c              |  30 ++-------
 net/ipv4/fou.c                  | 144 ++++++++++++++++++++++++----------------
 net/ipv4/gre_offload.c          |  14 ----
 net/ipv4/tcp_offload.c          |  19 ------
 net/ipv4/udp_offload.c          |  20 ++----
 net/ipv6/Makefile               |   4 +-
 net/ipv6/fou6.c                 | 140 ++++++++++++++++++++++++++++++++++++++
 net/ipv6/ip6_gre.c              |  95 +++++++++++++++++++++++---
 net/ipv6/ip6_input.c            |  24 +++++--
 net/ipv6/ip6_offload.c          |  76 +++++++++++++++------
 net/ipv6/ip6_tunnel.c           | 101 ++++++++++++++++++++++++++--
 net/ipv6/ip6_tunnel_core.c      | 108 ++++++++++++++++++++++++++++++
 net/ipv6/udp_offload.c          |  13 ----
 20 files changed, 652 insertions(+), 188 deletions(-)
 create mode 100644 net/ipv6/fou6.c
 create mode 100644 net/ipv6/ip6_tunnel_core.c

-- 
2.8.0.rc2

^ permalink raw reply

* [PATCH net-next v3] macvtap: add namespace support to the sysfs device class
From: Marc Angel @ 2016-05-05  0:34 UTC (permalink / raw)
  To: netdev; +Cc: ebiederm
In-Reply-To: <20160504.160445.640444073175153113.davem@davemloft.net>

When creating macvtaps that are expected to have the same ifindex
in different network namespaces, only the first one will succeed.
The others will fail with a sysfs_warn_dup warning due to them trying
to create the following sysfs link (with 'NN' the ifindex of macvtapX):

/sys/class/macvtap/tapNN -> /sys/devices/virtual/net/macvtapX/tapNN

This is reproducible by running the following commands:

ip netns add ns1
ip netns add ns2
ip link add veth0 type veth peer name veth1
ip link set veth0 netns ns1
ip link set veth1 netns ns2
ip netns exec ns1 ip l add link veth0 macvtap0 type macvtap
ip netns exec ns2 ip l add link veth1 macvtap1 type macvtap

The last command will fail with "RTNETLINK answers: File exists" (along
with the kernel warning) but retrying it will work because the ifindex
was incremented.

The 'net' device class is isolated between network namespaces so each
one has its own hierarchy of net devices.
This isn't the case for the 'macvtap' device class.
The problem occurs half-way through the netdev registration, when
`macvtap_device_event` is called-back to create the 'tapNN' macvtap
class device under the 'macvtapX' net class device.

This patch adds namespace support to the 'macvtap' device class so
that /sys/class/macvtap is no longer shared between net namespaces.

However, making the macvtap sysfs class namespace-aware has the side
effect of changing /sys/devices/virtual/net/macvtapX/tapNN  into
/sys/devices/virtual/net/macvtapX/macvtap/tapNN.

This is due to Commit 24b1442 ("Driver-core: Always create class
directories for classses that support namespaces") and the fact that
class devices supporting namespaces are really not supposed to be placed
directly under other class devices.

To avoid breaking userland, a tapNN symlink pointing to macvtap/tapNN is
created inside the macvtapX directory.

Signed-off-by: Marc Angel <marc@arista.com>
---
 drivers/net/macvtap.c | 36 ++++++++++++++++++++++++++----------
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..d89820f 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -129,7 +129,18 @@ static DEFINE_MUTEX(minor_lock);
 static DEFINE_IDR(minor_idr);
 
 #define GOODCOPY_LEN 128
-static struct class *macvtap_class;
+static const void *macvtap_net_namespace(struct device *d)
+{
+	struct net_device *dev = to_net_dev(d->parent);
+	return dev_net(dev);
+}
+
+static struct class macvtap_class = {
+	.name = "macvtap",
+	.owner = THIS_MODULE,
+	.ns_type = &net_ns_type_operations,
+	.namespace = macvtap_net_namespace,
+};
 static struct cdev macvtap_cdev;
 
 static const struct proto_ops macvtap_socket_ops;
@@ -1278,10 +1289,12 @@ static int macvtap_device_event(struct notifier_block *unused,
 	struct device *classdev;
 	dev_t devt;
 	int err;
+	char tap_name[IFNAMSIZ];
 
 	if (dev->rtnl_link_ops != &macvtap_link_ops)
 		return NOTIFY_DONE;
 
+	snprintf(tap_name, IFNAMSIZ, "tap%d", dev->ifindex);
 	vlan = netdev_priv(dev);
 
 	switch (event) {
@@ -1295,16 +1308,21 @@ static int macvtap_device_event(struct notifier_block *unused,
 			return notifier_from_errno(err);
 
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		classdev = device_create(macvtap_class, &dev->dev, devt,
-					 dev, "tap%d", dev->ifindex);
+		classdev = device_create(&macvtap_class, &dev->dev, devt,
+					 dev, tap_name);
 		if (IS_ERR(classdev)) {
 			macvtap_free_minor(vlan);
 			return notifier_from_errno(PTR_ERR(classdev));
 		}
+		err = sysfs_create_link(&dev->dev.kobj, &classdev->kobj,
+					tap_name);
+		if (err)
+			return notifier_from_errno(err);
 		break;
 	case NETDEV_UNREGISTER:
+		sysfs_remove_link(&dev->dev.kobj, tap_name);
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		device_destroy(macvtap_class, devt);
+		device_destroy(&macvtap_class, devt);
 		macvtap_free_minor(vlan);
 		break;
 	}
@@ -1330,11 +1348,9 @@ static int macvtap_init(void)
 	if (err)
 		goto out2;
 
-	macvtap_class = class_create(THIS_MODULE, "macvtap");
-	if (IS_ERR(macvtap_class)) {
-		err = PTR_ERR(macvtap_class);
+	err = class_register(&macvtap_class);
+	if (err)
 		goto out3;
-	}
 
 	err = register_netdevice_notifier(&macvtap_notifier_block);
 	if (err)
@@ -1349,7 +1365,7 @@ static int macvtap_init(void)
 out5:
 	unregister_netdevice_notifier(&macvtap_notifier_block);
 out4:
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 out3:
 	cdev_del(&macvtap_cdev);
 out2:
@@ -1363,7 +1379,7 @@ static void macvtap_exit(void)
 {
 	rtnl_link_unregister(&macvtap_link_ops);
 	unregister_netdevice_notifier(&macvtap_notifier_block);
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 	cdev_del(&macvtap_cdev);
 	unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
 	idr_destroy(&minor_idr);
-- 
2.8.0

^ permalink raw reply related

* Re: [PATCH net-next v2] macvtap: add namespace support to the sysfs device class
From: Marc Angel @ 2016-05-05  0:33 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Eric W. Biederman
In-Reply-To: <20160504.160445.640444073175153113.davem@davemloft.net>

On Wed, May 4, 2016 at 9:04 PM, David Miller <davem@davemloft.net> wrote:
> From: Marc Angel <marc@arista.com>
> Date: Tue,  3 May 2016 20:30:54 +0200
>
>> @@ -1274,6 +1285,7 @@ static int macvtap_device_event(struct notifier_block *unused,
>>                               unsigned long event, void *ptr)
>>  {
>>       struct net_device *dev = netdev_notifier_info_to_dev(ptr);
>> +     const char *tap_name = kasprintf(GFP_KERNEL, "tap%d", dev->ifindex);
>>       struct macvlan_dev *vlan;
>>       struct device *classdev;
>>       dev_t devt;
>
> This 'tap_name' buffer seems to be leaked in several code paths.

Sorry about that... V3 should be better.

^ permalink raw reply

* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-05-05  0:30 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Kangjie Lu, Nicolas Dichtel

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/core/rtnetlink.c

between commit:

  5f8e44741f9f ("net: fix infoleak in rtnetlink")

from the net tree and commit:

  270cb4d05b29 ("rtnl: align nlattr properly when needed")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/core/rtnetlink.c
index 65763c29f845,d471f097c739..000000000000
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@@ -1180,17 -1173,15 +1173,17 @@@ static noinline_for_stack int rtnl_fill
  
  static int rtnl_fill_link_ifmap(struct sk_buff *skb, struct net_device *dev)
  {
 -	struct rtnl_link_ifmap map = {
 -		.mem_start   = dev->mem_start,
 -		.mem_end     = dev->mem_end,
 -		.base_addr   = dev->base_addr,
 -		.irq         = dev->irq,
 -		.dma         = dev->dma,
 -		.port        = dev->if_port,
 -	};
 +	struct rtnl_link_ifmap map;
 +
 +	memset(&map, 0, sizeof(map));
 +	map.mem_start   = dev->mem_start;
 +	map.mem_end     = dev->mem_end;
 +	map.base_addr   = dev->base_addr;
 +	map.irq         = dev->irq;
 +	map.dma         = dev->dma;
 +	map.port        = dev->if_port;
 +
- 	if (nla_put(skb, IFLA_MAP, sizeof(map), &map))
+ 	if (nla_put_64bit(skb, IFLA_MAP, sizeof(map), &map, IFLA_PAD))
  		return -EMSGSIZE;
  
  	return 0;

^ permalink raw reply

* Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: John Stultz @ 2016-05-05  0:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Eliezer Tamir, Arnd Bergmann, y2038 Mailman List, netdev, lkml,
	Oleg Nesterov, Arjan van de Ven, Alexander Viro,
	linux-fsdevel@vger.kernel.org, Thomas Gleixner, Linus Torvalds,
	David S. Miller, Deepa Dinamani
In-Reply-To: <20160504165115.e0247881921fdcd0af4a394c@linux-foundation.org>

On Wed, May 4, 2016 at 4:51 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 04 May 2016 23:08:11 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
>> > But I'm less comfortable making the call on this one. It looks
>> > relatively straight forward, but it would be good to have maintainer
>> > acks before I add it to my tree.
>>
>> Agreed. Feel free to add my
>>
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>>
>> at least (whoever picks it up).
>
> In reply to [1/3] John said
>
> : Looks ok at the first glance. I've queued these up for testing,
> : however I only got #1 and #3 of the set. Are you hoping these two
> : patches will go through tip/timers/core or are you looking for acks so
> : they can go via another tree?
>
> However none of the patches are in linux-next.
>
> John had qualms about [2/3], but it looks like a straightforward
> substitution in areas which will get plenty of testing

Yea. My main concern is just not stepping on any other maintainers toes.

> I'll grab the patches for now to get them some external testing.

I'd be just as happy if the set went through you Andrew.

For the set: Acked-by: John Stultz <john.stultz@linaro.org>

thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

^ permalink raw reply

* [PATCH net-next] cnic: call cp->stop_hw() in cnic_start_hw() on allocation failure
From: Jon Maxwell @ 2016-05-04 23:55 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, jmaxwell, ivecera, Jon Maxwell

We recently had a system crash in the cnic module. Vmcore analysis confirmed 
that "ip link up" was executed which failed due to an allocation failure 
because of memory fragmentation. Futher analysis revealed that the cnic irq 
vector was still allocated after the "ip link up" that failed. When 
"ip link down" was executed it called free_msi_irqs() which crashed the system 
because the cnic irq was still inuse.

PANIC: "kernel BUG at drivers/pci/msi.c:411!"

The code execution was:

cnic_netdev_event()
if (event == NETDEV_UP) {
.
.
       ▹       if (!cnic_start_hw(dev))
cnic_start_hw()
calls cnic_cm_open() which failed with -ENOMEM
cnic_start_hw() then took the err1 path:

err1:↩
       cp->free_resc(dev);↩ <---- frees resources but not irq vector
       pci_dev_put(dev->pcidev);↩
       return err;↩
}↩

This returns control back to cnic_netdev_event() but now the cnic irq vector 
is still allocated even although cnic_cm_open() failed. The next 
"ip link down" while trigger the crash. 

The cnic_start_hw() routine is not handling the allocation failure correctly. 
Fix this by checking whether CNIC_DRV_STATE_HANDLES_IRQ flag is set indicating 
that the hardware has been started in cnic_start_hw(). If it has then call 
cp->stop_hw() which frees the cnic irq vector and cnic resources. Otherwise 
just maintain the previous behaviour and free cnic resources. 

I reproduced this by injecting an ENOMEM error into cnic_cm_alloc_mem()s return
code. 

# ip link set dev enpX down
# ip link set dev enpX up <--- hit's allocation failure
# ip link set dev enpX down <--- crashes here

With this patch I confirmed there was no crash in the reproducer.

Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
---
 drivers/net/ethernet/broadcom/cnic.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index b69dc58..b1d2ac8 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -5350,7 +5350,10 @@ static int cnic_start_hw(struct cnic_dev *dev)
 	return 0;
 
 err1:
-	cp->free_resc(dev);
+	if (ethdev->drv_state & CNIC_DRV_STATE_HANDLES_IRQ)
+		cp->stop_hw(dev);
+	else
+		cp->free_resc(dev);
 	pci_dev_put(dev->pcidev);
 	return err;
 }
-- 
1.8.3.1

^ permalink raw reply related

* Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: Andrew Morton @ 2016-05-04 23:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Arjan van de Ven, Eliezer Tamir, y2038, netdev, lkml,
	Oleg Nesterov, John Stultz, Deepa Dinamani,
	linux-fsdevel@vger.kernel.org, Thomas Gleixner, Linus Torvalds,
	David S. Miller, Alexander Viro
In-Reply-To: <4256673.7Gok2HNpOM@wuerfel>

On Wed, 04 May 2016 23:08:11 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> > But I'm less comfortable making the call on this one. It looks
> > relatively straight forward, but it would be good to have maintainer
> > acks before I add it to my tree.
> 
> Agreed. Feel free to add my
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> at least (whoever picks it up).

In reply to [1/3] John said

: Looks ok at the first glance. I've queued these up for testing,
: however I only got #1 and #3 of the set. Are you hoping these two
: patches will go through tip/timers/core or are you looking for acks so
: they can go via another tree?

However none of the patches are in linux-next.

John had qualms about [2/3], but it looks like a straightforward
substitution in areas which will get plenty of testing

I'll grab the patches for now to get them some external testing.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

^ permalink raw reply

* Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions
From: John Stultz @ 2016-05-04 23:45 UTC (permalink / raw)
  To: Dean Jenkins
  Cc: Guodong Xu, lkml, Mark Craske, David S. Miller, YongQin Liu,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	Ivan Vecera, David B. Robins
In-Reply-To: <5728837D.60702-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>

On Tue, May 3, 2016 at 3:54 AM, Dean Jenkins <Dean_Jenkins-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> On 03/05/16 11:04, Guodong Xu wrote:
>>
>> did you test on ARM 64-bit system or ARM 32-bit? I ask because HiKey
>> is an ARM 64-bit system. I suggest we should be careful on that. I saw
>> similar issues when transferring to a 64-bit system in other net
>> drivers.
>
> We used 32-bit ARM and never tested on 64-bit ARM so I suggest that the
> commits need to be reviewed with 64-bit OS in mind.
>>
>>
>> Do you have any suggestion on this regard?
>
> Try testing on a Linux PC x86 32-bit OS which has has a kernel containing my
> ASIX commits. This will help to confirm whether the failure is related to
> 32-bit or 64-bit OS. Then try with Linux PC x86 64-bit OS, this should fail
> otherwise it points to something specific in your ARM 64-bit platform.

Just as a sample point, I have managed to reproduce exactly this issue
on an x86_64 system by simply scp'ing a large file.

[  417.819276] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  417.823415] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0xef830347, offset 4
[  417.827502] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x31e2b348, offset 4
[  417.843779] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  417.847921] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x8af91035, offset 4
[  417.852004] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x8521fa03, offset 4
[  418.273394] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  418.277532] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x33cd9c7c, offset 4
[  418.281683] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x3d850896, offset 4
[  418.286227] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x86443357, offset 4
[  418.290319] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0xee6c81d1, offset 4

I don't have any 32bit x86 installs around so I'm not sure I can easly
test there, but its clear its not arm64 specific.

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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

* [net-next] MAINTAINERS: Cleanup Intel Wired LAN maintainers list
From: Jeff Kirsher @ 2016-05-04 22:49 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene

With the recent "retirements" and other changes, make the maintainers
list a lot less confusing and a bit more straight forward.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Shannon Nelson <sln@onemain.com>
---
 MAINTAINERS | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2b74fde..e425912 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5748,13 +5748,6 @@ F:	drivers/char/hw_random/ixp4xx-rng.c
 
 INTEL ETHERNET DRIVERS
 M:	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-R:	Jesse Brandeburg <jesse.brandeburg@intel.com>
-R:	Shannon Nelson <shannon.nelson@intel.com>
-R:	Carolyn Wyborny <carolyn.wyborny@intel.com>
-R:	Don Skidmore <donald.c.skidmore@intel.com>
-R:	Bruce Allan <bruce.w.allan@intel.com>
-R:	John Ronciak <john.ronciak@intel.com>
-R:	Mitch Williams <mitch.a.williams@intel.com>
 L:	intel-wired-lan@lists.osuosl.org (moderated for non-subscribers)
 W:	http://www.intel.com/support/feedback.htm
 W:	http://e1000.sourceforge.net/
-- 
2.5.5

^ permalink raw reply related

* [PATCH net-next] tcp: two more missing bh disable
From: Eric Dumazet @ 2016-05-04 22:27 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20160504.170641.134283593327091145.davem@davemloft.net>

From: Eric Dumazet <edumazet@google.com>

percpu_counter only have protection against preemption.

TCP stack uses them possibly from BH, so we need BH protection
in contexts that could be run in process context

Fixes: c10d9310edf5 ("tcp: do not assume TCP code is non preemptible")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/ipv4/inet_connection_sock.c |    2 ++
 net/ipv4/tcp_ipv4.c             |    2 ++
 2 files changed, 4 insertions(+)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 7ce112aa3a7b50c8c2c97b4e59e86128f90fd7f6..fa8c39804bdbae867dd5c08f1e308202c1aa1c52 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -706,7 +706,9 @@ void inet_csk_destroy_sock(struct sock *sk)
 
 	sk_refcnt_debug_release(sk);
 
+	local_bh_disable();
 	percpu_counter_dec(sk->sk_prot->orphan_count);
+	local_bh_enable();
 	sock_put(sk);
 }
 EXPORT_SYMBOL(inet_csk_destroy_sock);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 761bc492c5e3070212efe91c3940e4712d9d6ef6..a7ab9472d64560d86ea24ac1b6e1a7800f89989d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1839,7 +1839,9 @@ void tcp_v4_destroy_sock(struct sock *sk)
 	tcp_free_fastopen_req(tp);
 	tcp_saved_syn_free(tp);
 
+	local_bh_disable();
 	sk_sockets_allocated_dec(sk);
+	local_bh_enable();
 
 	if (mem_cgroup_sockets_enabled && sk->sk_memcg)
 		sock_release_memcg(sk);

^ permalink raw reply related

* Re: [PATC net-next] tcp: must block bh in __inet_twsk_hashdance()
From: Eric Dumazet @ 2016-05-04 22:21 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20160504.170641.134283593327091145.davem@davemloft.net>

On Wed, 2016-05-04 at 17:06 -0400, David Miller wrote:

> I pushed them in by hand, they should really be there now.
> 
> Thanks for letting me know.

Thanks David

Further tests show two additional missing local_bh_disable() protections
around percpu_counter_dec() and one sk_sockets_allocated_dec()

Will send the patch in few minutes.

^ permalink raw reply

* Re: [net-next 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-05-04
From: David Miller @ 2016-05-04 21:48 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1462379208-3997-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed,  4 May 2016 09:26:34 -0700

> This series contains updates to ixgbe, ixgbevf and traffic class helpers.

Pulled, thanks Jeff.

^ permalink raw reply

* Re: [PATCH net 0/2] bnxt_en: 2 bug fixes.
From: David Miller @ 2016-05-04 21:12 UTC (permalink / raw)
  To: michael.chan; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>

From: Michael Chan <michael.chan@broadcom.com>
Date: Wed,  4 May 2016 16:56:42 -0400

> Fix crash on ppc64 due to missing memory barrier and restore multicast
> after reset.

Looks good, series applied, thanks.

^ permalink raw reply

* Re: [Y2038] [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: Arnd Bergmann @ 2016-05-04 21:08 UTC (permalink / raw)
  To: y2038
  Cc: John Stultz, Deepa Dinamani, netdev, lkml, Alexander Viro,
	linux-fsdevel@vger.kernel.org, Thomas Gleixner, David S. Miller,
	Linus Torvalds, Andrew Morton, Eliezer Tamir, Arjan van de Ven,
	Oleg Nesterov
In-Reply-To: <CALAqxLVB8XiRrFKxK3GzBxw-CfEmC=Dh-CrTOEqT144ngZg-Dw@mail.gmail.com>

On Wednesday 04 May 2016 13:04:37 John Stultz wrote:
> On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > struct timespec is not y2038 safe.
> > Even though timespec might be sufficient to represent
> > timeouts, use struct timespec64 here as the plan is to
> > get rid of all timespec reference in the kernel.
> >
> > The patch transitions the common functions:
> > poll_select_set_timeout() and select_estimate_accuracy()
> > to use timespec64. And, all the syscalls that use these
> > functions are transitioned in the same patch.
> >
> > The restart block parameters for poll uses monotonic time.
> > Use timespec64 here as well to assign timeout value. This
> > parameter in the restart block need not change because
> > this only holds the monotonic timestamp at which timeout
> > should occur. And, unsigned long data type should be big
> > enough for this timestamp.
> >
> > The system call interfaces will be handled in a separate
> > series.
> >
> > Compat interfaces need not change as timespec64 is an
> > alias to struct timespec on a 64 bit system.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > ---
> > Resending to include John and Thomas on this patch as well.
> > This is to include this patch also in John's tree.
> > This will let all 3 patches in the series to merged through the same tree.
> >
> >  fs/eventpoll.c       | 12 +++++-----
> >  fs/select.c          | 67 +++++++++++++++++++++++++++++-----------------------
> >  include/linux/poll.h | 11 +++++----
> >  net/socket.c         |  8 ++++---
> >  4 files changed, 54 insertions(+), 44 deletions(-)
> 
> 
> So with the other two patches, I'm more comfortable queueing and
> sending through to Thomas.

Note that of course patch 3 depends on patch 2, otherwise it would
be a simple rename.

> But I'm less comfortable making the call on this one. It looks
> relatively straight forward, but it would be good to have maintainer
> acks before I add it to my tree.

Agreed. Feel free to add my

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

at least (whoever picks it up). The file hasn't changed much in the past
decade, these are all the people who did more than 1 patch for fs/select.c
in git history:

      7 Al Viro
      6 Eliezer Tamir
      6 Arjan van de Ven
      4 Andrew Morton
      3 Linus Torvalds
      3 Heiko Carstens
      2 Vadim Lobanov
      2 Roland McGrath
      2 Oleg Nesterov
      2 Jiri Slaby
      2 Guillaume Knispel
      2 Eric Dumazet
      2 Dipankar Sarma
      2 Alexey Dobriyan

adding a few more to Cc, maybe someone else finds the time to take a
second look.

	Arnd

^ permalink raw reply

* Re: [PATCH next] drivers: fix dev->trans_start removal fallout
From: David Miller @ 2016-05-04 21:07 UTC (permalink / raw)
  To: fw; +Cc: netdev
In-Reply-To: <1462395367-16704-1-git-send-email-fw@strlen.de>

From: Florian Westphal <fw@strlen.de>
Date: Wed,  4 May 2016 22:56:07 +0200

> kbuild test robot reported a build failure on s390.
> While at it, also fix missing conversion in the tilera driver.
> 
> Fixes: 9b36627acecd5792 ("net: remove dev->trans_start")
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>

Applied.

^ permalink raw reply

* Re: [PATCH next] bonding: update documentation section after dev->trans_start removal
From: David Miller @ 2016-05-04 21:07 UTC (permalink / raw)
  To: fw; +Cc: netdev
In-Reply-To: <1462395107-18703-1-git-send-email-fw@strlen.de>

From: Florian Westphal <fw@strlen.de>
Date: Wed,  4 May 2016 22:51:47 +0200

> Drivers that use LLTX need to update trans_start of the netdev_queue.
> (Most drivers don't use LLTX; stack does this update if .ndo_start_xmit
>  returned TX_OK).
> 
> Signed-off-by: Florian Westphal <fw@strlen.de>

Applied.

^ permalink raw reply

* Re: [PATC net-next] tcp: must block bh in __inet_twsk_hashdance()
From: David Miller @ 2016-05-04 21:06 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1462386131.5535.353.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 May 2016 11:22:11 -0700

> On Wed, 2016-05-04 at 00:54 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Tue, 03 May 2016 17:10:50 -0700
>> 
>> > From: Eric Dumazet <edumazet@google.com>
>> > 
>> > __inet_twsk_hashdance() might be called from process context,
>> > better block BH before acquiring bind hash and established locks
>> > 
>> > Fixes: c10d9310edf5 ("tcp: do not assume TCP code is non preemptible")
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> 
>> Applied.
> 
> David, I do not see these two patches in net-next ?
> 
> (This one, and the "tcp: fix lockdep splat in tcp_snd_una_update()" one)

I pushed them in by hand, they should really be there now.

Thanks for letting me know.

^ permalink raw reply

* Re: [patch] usbnet: smsc95xx: silence an uninitialized variable warning
From: David Miller @ 2016-05-04 21:00 UTC (permalink / raw)
  To: dan.carpenter; +Cc: steve.glendinning, netdev, linux-usb
In-Reply-To: <20160504062201.GF22064@mwanda>

From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 4 May 2016 09:22:01 +0300

> If the call to fn() fails then "buf" is uninitialized.  Just return the
> error code in that case.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Applied.

Please, in the future, use a consistent subsystem prefixing scheme.  In these
two patches you used "x/y:"" and "x: y:"

Thanks.

^ permalink raw reply

* Re: [patch] usbnet/smsc75xx: silence uninitialized variable warning
From: David Miller @ 2016-05-04 20:59 UTC (permalink / raw)
  To: dan.carpenter; +Cc: steve.glendinning, netdev, linux-usb
In-Reply-To: <20160504062102.GE22064@mwanda>

From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 4 May 2016 09:21:02 +0300

> If the fn() calls fail then "buf" is uninitialized.  Just return early
> in that situation.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Applied.

^ permalink raw reply

* [PATCH net 1/2] bnxt_en: Need memory barrier when processing the completion ring.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>

The code determines if the next ring entry is valid before proceeding
further to read the rest of the entry.  The CPU can re-order and read
the rest of the entry first, possibly reading a stale entry, if DMA
of a new entry happens right after reading it.  This issue can be
readily seen on a ppc64 system, causing it to crash.

Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 72eb29e..f33ff20 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1388,6 +1388,10 @@ static int bnxt_poll_work(struct bnxt *bp, struct bnxt_napi *bnapi, int budget)
 		if (!TX_CMP_VALID(txcmp, raw_cons))
 			break;
 
+		/* The valid test of the entry must be done first before
+		 * reading any further.
+		 */
+		rmb();
 		if (TX_CMP_TYPE(txcmp) == CMP_TYPE_TX_L2_CMP) {
 			tx_pkts++;
 			/* return full budget so NAPI will complete. */
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net 2/2] bnxt_en: Setup multicast properly after resetting device.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>

The multicast/all-multicast internal flags are not properly restored
after device reset.  This could lead to unreliable multicast operations
after an ethtool configuration change for example.

Call bnxt_mc_list_updated() and setup the vnic->mask in bnxt_init_chip()
to fix the issue.

Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f33ff20..9d4e8e1 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4042,9 +4042,11 @@ static int bnxt_alloc_rfs_vnics(struct bnxt *bp)
 }
 
 static int bnxt_cfg_rx_mode(struct bnxt *);
+static bool bnxt_mc_list_updated(struct bnxt *, u32 *);
 
 static int bnxt_init_chip(struct bnxt *bp, bool irq_re_init)
 {
+	struct bnxt_vnic_info *vnic = &bp->vnic_info[0];
 	int rc = 0;
 
 	if (irq_re_init) {
@@ -4100,13 +4102,22 @@ static int bnxt_init_chip(struct bnxt *bp, bool irq_re_init)
 		netdev_err(bp->dev, "HWRM vnic filter failure rc: %x\n", rc);
 		goto err_out;
 	}
-	bp->vnic_info[0].uc_filter_count = 1;
+	vnic->uc_filter_count = 1;
 
-	bp->vnic_info[0].rx_mask = CFA_L2_SET_RX_MASK_REQ_MASK_BCAST;
+	vnic->rx_mask = CFA_L2_SET_RX_MASK_REQ_MASK_BCAST;
 
 	if ((bp->dev->flags & IFF_PROMISC) && BNXT_PF(bp))
-		bp->vnic_info[0].rx_mask |=
-				CFA_L2_SET_RX_MASK_REQ_MASK_PROMISCUOUS;
+		vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_PROMISCUOUS;
+
+	if (bp->dev->flags & IFF_ALLMULTI) {
+		vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_ALL_MCAST;
+		vnic->mc_list_count = 0;
+	} else {
+		u32 mask = 0;
+
+		bnxt_mc_list_updated(bp, &mask);
+		vnic->rx_mask |= mask;
+	}
 
 	rc = bnxt_cfg_rx_mode(bp);
 	if (rc)
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net 0/2] bnxt_en: 2 bug fixes.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
  To: davem; +Cc: netdev

Fix crash on ppc64 due to missing memory barrier and restore multicast
after reset.

Michael Chan (2):
  bnxt_en: Need memory barrier when processing the completion ring.
  bnxt_en: Setup multicast properly after resetting device.

 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

-- 
1.8.3.1

^ permalink raw reply

* [PATCH next] drivers: fix dev->trans_start removal fallout
From: Florian Westphal @ 2016-05-04 20:56 UTC (permalink / raw)
  To: netdev; +Cc: Florian Westphal

kbuild test robot reported a build failure on s390.
While at it, also fix missing conversion in the tilera driver.

Fixes: 9b36627acecd5792 ("net: remove dev->trans_start")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 0bb98bc..922a443 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -2026,7 +2026,7 @@ static void tile_net_tx_timeout(struct net_device *dev)
 {
 	PDEBUG("tile_net_tx_timeout()\n");
 	PDEBUG("Transmit timeout at %ld, latency %ld\n", jiffies,
-	       jiffies - dev->trans_start);
+	       jiffies - dev_trans_start(dev));
 
 	/* XXX: ISSUE: This doesn't seem useful for us. */
 	netif_wake_queue(dev);
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 7871537..b7b7477 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3481,7 +3481,7 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q *queue, int index,
 		}
 	}
 
-	queue->card->dev->trans_start = jiffies;
+	netif_trans_update(queue->card->dev);
 	if (queue->card->options.performance_stats) {
 		queue->card->perf_stats.outbound_do_qdio_cnt++;
 		queue->card->perf_stats.outbound_do_qdio_start_time =
-- 
2.7.3

^ permalink raw reply related

* [PATCH next] bonding: update documentation section after dev->trans_start removal
From: Florian Westphal @ 2016-05-04 20:51 UTC (permalink / raw)
  To: netdev; +Cc: Florian Westphal

Drivers that use LLTX need to update trans_start of the netdev_queue.
(Most drivers don't use LLTX; stack does this update if .ndo_start_xmit
 returned TX_OK).

Signed-off-by: Florian Westphal <fw@strlen.de>
---
 Documentation/networking/bonding.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 334b49e..57f52cd 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1880,8 +1880,8 @@ or more peers on the local network.
 
 	The ARP monitor relies on the device driver itself to verify
 that traffic is flowing.  In particular, the driver must keep up to
-date the last receive time, dev->last_rx, and transmit start time,
-dev->trans_start.  If these are not updated by the driver, then the
+date the last receive time, dev->last_rx.  Drivers that use NETIF_F_LLTX
+flag must also update netdev_queue->trans_start.  If they do not, then the
 ARP monitor will immediately fail any slaves using that driver, and
 those slaves will stay down.  If networking monitoring (tcpdump, etc)
 shows the ARP requests and replies on the network, then it may be that
-- 
2.7.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox