Stable request for gso feature flag and error handling fixes

Please consider commit

commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3

Author: Florian Westphal <[email protected]>
Date:   Mon Oct 20 13:49:16 2014 +0200

net: gso: use feature flag argument in all protocol gso handlers

and, at your discretion, the related commit

commit 330966e501ffe282d7184fde4518d5e0c24bc7f8

Author: Florian Westphal <[email protected]>
Date:   Mon Oct 20 13:49:17 2014 +0200

net: make skb_gso_segment error handling more robust

for -stable kernels prior to 3.18 back to 3.10.

We have observed kernel panics when an openvswitch bridge is
populated with virtual devices (veth, for example) that have expansive feature sets that include NETIF_F_GSO_GRE.

The failure occurs when foreign GRE encapsulated traffic
(explicitly not including the initial packets of a connection) arrives at the system (likely via a switch flood event). The packets are GRO accumulated, and passed to the OVS receive processing. As the connection is not in the OVS kernel datapath table, the call path is:

	ovs_dp_upcall ->
	     queue_gso_packets ->
		__skb_gso_segment(skb, NETIF_F_SG, false)

	Without the first patch cited above, __skb_gso_segment returns

NULL, as the features from the device (including GSO_GRE) are used in place of the _SG feature supplied to the call.

Without the second patch cited above, the kernel panics when it
later dereferences the NULL skb pointer in queue_userspace_packet.

Strictly speaking, with the first place applied the panic is
avoided (as the NULL return does not occur), but including the second patch may still be prudent.

	Thanks,

	-J

---
-Jay Vosburgh, [email protected]

From: Jay Vosburgh <[email protected]>
Date: Tue, 07 Jul 2015 17:38:50 -0700

When you ask me to consider commits for -stable you have to tell me what -stable releases you want me to submit them for.

Currently I am only doing -stable submissions for 4.1.x, 3.18.x and 3.14.x

I did say:

So, this would be just for 3.14.x. My apologies if I buried
that too far into the message.

Are the other -stable tree maintainers picking up patches after
you've submitted to 4.1/3.18/3.14, or is it necessary to make separate requests?

	-J

---
-Jay Vosburgh, [email protected]

From: Jay Vosburgh <[email protected]>
Date: Tue, 07 Jul 2015 22:10:53 -0700

I don't know and I frankly don't care.