On Wed, Dec 30, 2015 at 9:30 AM, Jacob Siverskog <jacob@teenage.engineering> wrote: > On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet <eduma...@google.com> wrote:
>> At this point corruption already happened. >> We can not possibly detect every possible corruption caused by bugs >> elsewhere in the kernel and just 'recover' at this point. >> We must indeed find the root cause and fix it, instead of trying to hide it. >> >> How often can you trigger this bug ? > > Ok. I don't have a good repro to trigger it unfortunately, I've seen it just a > few times when bringing up/down network interfaces. Does the trace > give any clue? > > [<c02fc0a8>] (__skb_recv_datagram) from [<c0398f1c>] > (udpv6_recvmsg+0x1d0/0x6d0) > [<c0398f1c>] (udpv6_recvmsg) from [<c0367a2c>] (inet_recvmsg+0x38/0x4c) > [<c0367a2c>] (inet_recvmsg) from [<c02efff4>] (___sys_recvmsg+0x94/0x170) > [<c02efff4>] (___sys_recvmsg) from [<c02f0d74>] (__sys_recvmsg+0x3c/0x6c) > [<c02f0d74>] (__sys_recvmsg) from [<c000f1e0>] (ret_fast_syscall+0x0/0x3c) Not really : it only shows the point where the corruption is detected, not the point where the corruption happened. This might be caused by a netfilter module, a buggy driver... it is hard to know. You might add some traces on the skb itself, like its length or/and content. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
