* Stable request for gso feature flag and error handling fixes
@ 2015-07-08 0:38 Jay Vosburgh
2015-07-08 2:20 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Jay Vosburgh @ 2015-07-08 0:38 UTC (permalink / raw
To: netdev; +Cc: David S. Miller
Please consider commit
commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3
Author: Florian Westphal <fw@strlen.de>
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 <fw@strlen.de>
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, jay.vosburgh@canonical.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Stable request for gso feature flag and error handling fixes
2015-07-08 0:38 Stable request for gso feature flag and error handling fixes Jay Vosburgh
@ 2015-07-08 2:20 ` David Miller
2015-07-08 5:10 ` Jay Vosburgh
0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2015-07-08 2:20 UTC (permalink / raw
To: jay.vosburgh; +Cc: netdev
From: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Tue, 07 Jul 2015 17:38:50 -0700
> Please consider commit
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Stable request for gso feature flag and error handling fixes
2015-07-08 2:20 ` David Miller
@ 2015-07-08 5:10 ` Jay Vosburgh
2015-07-08 5:58 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Jay Vosburgh @ 2015-07-08 5:10 UTC (permalink / raw
To: David Miller; +Cc: netdev
David Miller <davem@davemloft.net> wrote:
>From: Jay Vosburgh <jay.vosburgh@canonical.com>
>Date: Tue, 07 Jul 2015 17:38:50 -0700
>
>> Please consider commit
>
>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:
> for -stable kernels prior to 3.18 back to 3.10.
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, jay.vosburgh@canonical.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Stable request for gso feature flag and error handling fixes
2015-07-08 5:10 ` Jay Vosburgh
@ 2015-07-08 5:58 ` David Miller
0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2015-07-08 5:58 UTC (permalink / raw
To: jay.vosburgh; +Cc: netdev
From: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Tue, 07 Jul 2015 22:10:53 -0700
> 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?
I don't know and I frankly don't care.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-07-08 5:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-08 0:38 Stable request for gso feature flag and error handling fixes Jay Vosburgh
2015-07-08 2:20 ` David Miller
2015-07-08 5:10 ` Jay Vosburgh
2015-07-08 5:58 ` David Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.