From: Olof Johansson <hidden> Date: 2013-05-29 21:46:05
Sorry, that was not a great bug report.
So, looks like it's the removal of NET_SKBUFF_DATA_USES_OFFSET that
does it for me.
The devices I've seen it with are with asix usb-ethernet adapters (on
Tegra seaboard) and with mv643xx_eth on cubox (dove).
I'll try to get a better stacktrace out of it. Simon, maybe you can
reproduce on shmobile hardware?
On Wed, May 29, 2013 at 2:21 PM, Olof Johansson [off-list ref] wrote:
Simon,
On Thu, May 23, 2013 at 11:51 PM, Simon Horman [off-list ref] wrote:
quoted
In order to mitigate ongoing incresase in the size of struct skbuff
use 16 bit integer offsets rather than pointers for inner_*_headers.
This appears to reduce the size of struct skbuff from 0xd0 to 0xc0
bytes on x86_64 with the following all unset.
CONFIG_XFRM
CONFIG_NF_CONNTRACK
CONFIG_NF_CONNTRACK_MODULE
NET_SKBUFF_NF_DEFRAG_NEEDED
CONFIG_BRIDGE_NETFILTER
CONFIG_NET_SCHED
CONFIG_IPV6_NDISC_NODETYPE
CONFIG_NET_DMA
CONFIG_NETWORK_SECMARK
Signed-off-by: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
From: Simon Horman <horms@verge.net.au> Date: 2013-05-29 22:53:39
On Wed, May 29, 2013 at 02:46:05PM -0700, Olof Johansson wrote:
Sorry, that was not a great bug report.
So, looks like it's the removal of NET_SKBUFF_DATA_USES_OFFSET that
does it for me.
The devices I've seen it with are with asix usb-ethernet adapters (on
Tegra seaboard) and with mv643xx_eth on cubox (dove).
I'll try to get a better stacktrace out of it. Simon, maybe you can
reproduce on shmobile hardware?
Sure, I will try and reproduce it.
I did subsequently post some fixes for fallout resulting from
the patch listed below. Those changes are now net-next.
Are you seeing the crash with those patches?
The fix-up patches are:
net,ipv4,ipv6: Correct assignment of skb->network_header to skb->tail
sctp: Correct access to skb->{network,transport}_header
ipv4: Correct comparisons and calculations using skb->tail and skb-transport_header
ipv6: Correct comparisons and calculations using skb->tail and skb-transport_header
net: Correct comparisons and calculations using skb->tail and skb-transport_header
cxgb3: Correct comparisons and calculations using skb->tail and skb-transport_header
isdn: Correct comparison of skb->tail and skb-transport_header
net: Fix build warnings after mac_header and transport_header became __u16.
On Wed, May 29, 2013 at 2:21 PM, Olof Johansson [off-list ref] wrote:
quoted
Simon,
On Thu, May 23, 2013 at 11:51 PM, Simon Horman [off-list ref] wrote:
quoted
In order to mitigate ongoing incresase in the size of struct skbuff
use 16 bit integer offsets rather than pointers for inner_*_headers.
This appears to reduce the size of struct skbuff from 0xd0 to 0xc0
bytes on x86_64 with the following all unset.
CONFIG_XFRM
CONFIG_NF_CONNTRACK
CONFIG_NF_CONNTRACK_MODULE
NET_SKBUFF_NF_DEFRAG_NEEDED
CONFIG_BRIDGE_NETFILTER
CONFIG_NET_SCHED
CONFIG_IPV6_NDISC_NODETYPE
CONFIG_NET_DMA
CONFIG_NETWORK_SECMARK
Signed-off-by: Simon Horman <horms@verge.net.au>
From: Olof Johansson <hidden> Date: 2013-05-29 23:02:14
Hi,
On Wed, May 29, 2013 at 3:54 PM, Simon Horman [off-list ref] wrote:
On Wed, May 29, 2013 at 02:46:05PM -0700, Olof Johansson wrote:
quoted
Sorry, that was not a great bug report.
So, looks like it's the removal of NET_SKBUFF_DATA_USES_OFFSET that
does it for me.
The devices I've seen it with are with asix usb-ethernet adapters (on
Tegra seaboard) and with mv643xx_eth on cubox (dove).
I'll try to get a better stacktrace out of it. Simon, maybe you can
reproduce on shmobile hardware?
Sure, I will try and reproduce it.
I did subsequently post some fixes for fallout resulting from
the patch listed below. Those changes are now net-next.
Are you seeing the crash with those patches?
The fix-up patches are:
net,ipv4,ipv6: Correct assignment of skb->network_header to skb->tail
sctp: Correct access to skb->{network,transport}_header
ipv4: Correct comparisons and calculations using skb->tail and skb-transport_header
ipv6: Correct comparisons and calculations using skb->tail and skb-transport_header
net: Correct comparisons and calculations using skb->tail and skb-transport_header
cxgb3: Correct comparisons and calculations using skb->tail and skb-transport_header
isdn: Correct comparison of skb->tail and skb-transport_header
net: Fix build warnings after mac_header and transport_header became __u16.
Ah, no, looks like those didn't make it into the 0529 linux-next.
I've merged net-next on top and retested, and I no longer see the panics.
Thanks!
-Olof
From: Simon Horman <horms@verge.net.au> Date: 2013-05-30 03:00:11
On Wed, May 29, 2013 at 04:02:12PM -0700, Olof Johansson wrote:
Hi,
On Wed, May 29, 2013 at 3:54 PM, Simon Horman [off-list ref] wrote:
quoted
On Wed, May 29, 2013 at 02:46:05PM -0700, Olof Johansson wrote:
quoted
Sorry, that was not a great bug report.
So, looks like it's the removal of NET_SKBUFF_DATA_USES_OFFSET that
does it for me.
The devices I've seen it with are with asix usb-ethernet adapters (on
Tegra seaboard) and with mv643xx_eth on cubox (dove).
I'll try to get a better stacktrace out of it. Simon, maybe you can
reproduce on shmobile hardware?
Sure, I will try and reproduce it.
I did subsequently post some fixes for fallout resulting from
the patch listed below. Those changes are now net-next.
Are you seeing the crash with those patches?
The fix-up patches are:
net,ipv4,ipv6: Correct assignment of skb->network_header to skb->tail
sctp: Correct access to skb->{network,transport}_header
ipv4: Correct comparisons and calculations using skb->tail and skb-transport_header
ipv6: Correct comparisons and calculations using skb->tail and skb-transport_header
net: Correct comparisons and calculations using skb->tail and skb-transport_header
cxgb3: Correct comparisons and calculations using skb->tail and skb-transport_header
isdn: Correct comparison of skb->tail and skb-transport_header
net: Fix build warnings after mac_header and transport_header became __u16.
Ah, no, looks like those didn't make it into the 0529 linux-next.
I've merged net-next on top and retested, and I no longer see the panics.
Great news, sorry for the mess.
FWIW I did not have any luck reproducing the problem (without the fix-ups)
on the mackerel board.