From: Timo Teras <timo.teras@iki.fi>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [bisected] [oops] gre/gro oops in skb_gro_receive+0x118/0x453
Date: Fri, 16 May 2014 20:38:35 +0300 [thread overview]
Message-ID: <20140516203835.5941ea3f@vostro> (raw)
In-Reply-To: <1400260430.7973.222.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, 16 May 2014 10:13:50 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2014-05-16 at 20:01 +0300, Timo Teras wrote:
> Documentation/oops-tracing.txtscripts/decodecode
> > I believe it crashes, but cannot say with 100% certainty. I can
> > test later on if needed. Based on earlier experiment, the only way
> > to avoid the crash was to turn off gro on gre1.
> >
> > In any case I don't think it should make any effect, since the GRE
> > packets arrive IPseced. eth0 is receiving ESP packets - and I
> > believe there's no ESP GRO support. Only after decryption they go
> > to gre1, so gre1 gro is basically the place where received packets
> > are coalesced.
>
> Oh this is definitely useful.
>
> I thought we might have a problem now with have GRE enabled GRO in
> native GRO layer. I was wondering if the double attempt to GRO
> packets a second time was a problem.
>
> So it looks like ESP provides packets that are not very gentle for
> skb_gro_receive()...
>
> Could you provide scripts/decodecode output ?
[ 286.930813] Code: 54 29 56 50 c7 46 54 00 00 00 00 29
d1 89 8e b4 00 00 00 e9 09 03 00 00 8b 45 f0 f6 80 87
00 00 00 01 8b 45 e8 0f 84 cf 00 00 00 <8a> 00 88 45 d8
0f b6 d0 8b 45 f0 8b 80 ac 00 00 00 89 45 d4 05
All code
========
0: 54 push %esp
1: 29 56 50 sub %edx,0x50(%esi)
4: c7 46 54 00 00 00 00 movl $0x0,0x54(%esi)
b: 29 d1 sub %edx,%ecx
d: 89 8e b4 00 00 00 mov %ecx,0xb4(%esi)
13: e9 09 03 00 00 jmp 0x321
18: 8b 45 f0 mov -0x10(%ebp),%eax
1b: f6 80 87 00 00 00 01 testb $0x1,0x87(%eax)
22: 8b 45 e8 mov -0x18(%ebp),%eax
25: 0f 84 cf 00 00 00 je 0xfa
2b:* 8a 00 mov (%eax),%al <-- trapping instruction
2d: 88 45 d8 mov %al,-0x28(%ebp)
30: 0f b6 d0 movzbl %al,%edx
33: 8b 45 f0 mov -0x10(%ebp),%eax
36: 8b 80 ac 00 00 00 mov 0xac(%eax),%eax
3c: 89 45 d4 mov %eax,-0x2c(%ebp)
3f: 05 .byte 0x5
Code starting with the faulting instruction
===========================================
0: 8a 00 mov (%eax),%al
2: 88 45 d8 mov %al,-0x28(%ebp)
5: 0f b6 d0 movzbl %al,%edx
8: 8b 45 f0 mov -0x10(%ebp),%eax
b: 8b 80 ac 00 00 00 mov 0xac(%eax),%eax
11: 89 45 d4 mov %eax,-0x2c(%ebp)
14: 05 .byte 0x5
Unfortunately, I do not have fully matching identical .s, or debug
built kernel. I can do that on Monday if this does not help.
Additionally, the .s file from separate, but similar build, that seems
to have matching assembly is as follows:
movl 168(%esi), %edx # MEM[(const struct sk_buff *)skb_19(D)].end, D.55920
subl 172(%esi), %edx # MEM[(const struct sk_buff *)skb_19(D)].head, D.55920
movb $1, 43(%esi) #, MEM[(struct napi_gro_cb *)skb_19(D) + 24B].free
leal -384(%ecx), %eax #, delta_truesize
subl %edx, %eax # D.55920, delta_truesize
movl 84(%esi), %edx # skb_19(D)->data_len, D.55922
subl %edx, 80(%esi) # D.55922, skb_19(D)->len
movl $0, 84(%esi) #, skb_19(D)->data_len
subl %edx, %ecx # D.55922, tmp300
movl %ecx, 180(%esi) # tmp300, skb_19(D)->truesize
jmp .L572 #
.L568:
movl -16(%ebp), %eax # %sfp, skb
testb $1, 135(%eax) #, *skb_19(D)
movl -24(%ebp), %eax # %sfp, D.55921
je .L573 #,
## Crash on the next opcode
movb (%eax), %al # MEM[(struct skb_shared_info *)_29].nr_frags, D.55923
movb %al, -40(%ebp) # D.55923, %sfp
movzbl %al, %edx # D.55923, nr_frags
movl -16(%ebp), %eax # %sfp, skb
movl 172(%eax), %eax # skb_19(D)->head, skb_19(D)->head
movl %eax, -44(%ebp) # skb_19(D)->head, %sfp
addl $1073741824, %eax #, page
shrl $12, %eax #, page
sall $5, %eax #, page
addl mem_map, %eax # mem_map, page
movl (%eax), %ecx # MEM[(const long unsigned int *)page_213], D.55925
movl %eax, %edi # page, D.55929
andb $128, %ch #, D.55925
je .L574 #,
movl 28(%eax), %esi # page_213->D.14510.first_page, head
movl (%eax), %ecx # MEM[(const long unsigned int *)page_213], D.55925
andb $128, %ch #, D.55925
je .L587 #,
movl %esi, %edi # head, D.55929
jmp .L574 #
next prev parent reply other threads:[~2014-05-16 17:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 7:40 [bisected] [oops] gre/gro oops in skb_gro_receive+0x118/0x453 Timo Teras
2014-05-16 12:59 ` Eric Dumazet
2014-05-16 14:34 ` Timo Teras
2014-05-16 16:29 ` Eric Dumazet
2014-05-16 16:40 ` Timo Teras
2014-05-16 16:50 ` Eric Dumazet
2014-05-16 17:01 ` Timo Teras
2014-05-16 17:13 ` Eric Dumazet
2014-05-16 17:38 ` Timo Teras [this message]
2014-05-16 18:04 ` Eric Dumazet
2014-05-16 18:34 ` [PATCH] net: gro: make sure skb->cb[] initial content has not to be zero Eric Dumazet
2014-05-16 19:08 ` Timo Teras
2014-05-16 21:25 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140516203835.5941ea3f@vostro \
--to=timo.teras@iki.fi \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.