All of lore.kernel.org
 help / color / mirror / Atom feed
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	#

  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.