netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* GPF in ip6_dst_lookup_tail
@ 2012-09-27 14:03 Dave Jones
  2012-10-02 13:59 ` Dave Jones
  0 siblings, 1 reply; 7+ messages in thread
From: Dave Jones @ 2012-09-27 14:03 UTC (permalink / raw)
  To: netdev

Trinity bug of the day. I added some code to fabricate sockaddr's.
This seems to be the first casualty of that.


general protection fault: 0000 [#1] SMP 
Modules linked in: ipt_ULOG tun fuse binfmt_misc nfnetlink nfc caif_socket caif phonet can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack kvm_intel kvm usb_debug crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core
CPU 4 
Pid: 21651, comm: trinity-child4 Not tainted 3.6.0-rc7+ #55
RIP: 0010:[<ffffffff81628797>]  [<ffffffff81628797>] ip6_dst_lookup_tail+0x147/0x380
RSP: 0018:ffff8800144c3a48  EFLAGS: 00010286
RAX: 8000000000000011 RBX: ffff8800144c3b00 RCX: 0000000000000001
RDX: ffff8800144c2000 RSI: 0000000000000000 RDI: 0000000000000282
RBP: ffff8800144c3ae8 R08: 0000000000000014 R09: ffff8800034708c0
R10: ffffffff81c34a60 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8800144c3bf0 R14: ffffffff81cd9580 R15: ffff8801052e4200
FS:  00007f74949af740(0000) GS:ffff880148400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000051f7000 CR3: 00000000a8f72000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process trinity-child4 (pid: 21651, threadinfo ffff8800144c2000, task ffff880003470000)
Stack:
 ffffffff81628730 ffffffff810dafbf ffff880003470000 0000000000000000
 ffff8800144c3aa8 0000000000000282 ffff8800144c3aa8 ffff88013d79dd40
 ffff8801052e4200 0000000000000003 0000000000000001 0000000000000000
Call Trace:
 [<ffffffff81628730>] ? ip6_dst_lookup_tail+0xe0/0x380
 [<ffffffff810dafbf>] ? lock_release_holdtime.part.26+0xf/0x180
 [<ffffffff81556b20>] ? sock_def_wakeup+0x1b0/0x1b0
 [<ffffffff81628a9b>] ip6_sk_dst_lookup_flow+0xcb/0x1b0
 [<ffffffff81649d8d>] udpv6_sendmsg+0x6ad/0xc40
 [<ffffffff81023af9>] ? native_sched_clock+0x19/0x80
 [<ffffffff810db438>] ? trace_hardirqs_off_caller+0x28/0xd0
 [<ffffffff810db4ed>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff815e613a>] inet_sendmsg+0x12a/0x240
 [<ffffffff815e6010>] ? inet_create+0x6f0/0x6f0
 [<ffffffff815562a1>] ? sock_update_classid+0xb1/0x390
 [<ffffffff81556340>] ? sock_update_classid+0x150/0x390
 [<ffffffff8155115c>] sock_sendmsg+0xbc/0xf0
 [<ffffffff810b46c9>] ? local_clock+0x99/0xc0
 [<ffffffff810dff4f>] ? lock_release_non_nested+0x2df/0x320
 [<ffffffff810dafbf>] ? lock_release_holdtime.part.26+0xf/0x180
 [<ffffffff81553740>] sys_sendto+0x130/0x180
 [<ffffffff816af8ad>] system_call_fastpath+0x1a/0x1f
Code: c0 74 19 80 3d 0e 4d 6d 00 00 75 10 e8 73 cb af ff 85 c0 0f 85 e3 01 00 00 0f 1f 00 48 8b 03 48 8b 80 98 00 00 00 48 85 c0 74 09 <f6> 80 6d 01 00 00 de 74 48 e8 3b db a6 ff 85 c0 74 0d 80 3d d5 

The disassembly points here..

 983         rcu_read_lock();
 984         rt = (struct rt6_info *) *dst;
 985         n = rt->n;
 986         if (n && !(n->nud_state & NUD_VALID)) {
     db2:       48 85 c0                test   %rax,%rax
     db5:       74 09                   je     dc0 <ip6_dst_lookup_tail+0x150>
     db7:       f6 80 6d 01 00 00 de    testb  $0xde,0x16d(%rax)
     dbe:       74 48                   je     e08 <ip6_dst_lookup_tail+0x198>

'rt->n' is 0x8000000000000011, which looks like one of the garbage values trinity generates

	Dave

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GPF in ip6_dst_lookup_tail
  2012-09-27 14:03 Dave Jones
@ 2012-10-02 13:59 ` Dave Jones
  0 siblings, 0 replies; 7+ messages in thread
From: Dave Jones @ 2012-10-02 13:59 UTC (permalink / raw)
  To: netdev

On Thu, Sep 27, 2012 at 10:03:23AM -0400, Dave Jones wrote:

 > general protection fault: 0000 [#1] SMP 
 > Modules linked in: ipt_ULOG tun fuse binfmt_misc nfnetlink nfc caif_socket caif phonet can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack kvm_intel kvm usb_debug crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core
 > CPU 4 
 > Pid: 21651, comm: trinity-child4 Not tainted 3.6.0-rc7+ #55
 > RIP: 0010:[<ffffffff81628797>]  [<ffffffff81628797>] ip6_dst_lookup_tail+0x147/0x380
 > RSP: 0018:ffff8800144c3a48  EFLAGS: 00010286
 > RAX: 8000000000000011 RBX: ffff8800144c3b00 RCX: 0000000000000001
 > RDX: ffff8800144c2000 RSI: 0000000000000000 RDI: 0000000000000282
 > RBP: ffff8800144c3ae8 R08: 0000000000000014 R09: ffff8800034708c0
 > R10: ffffffff81c34a60 R11: 0000000000000000 R12: 0000000000000000
 > R13: ffff8800144c3bf0 R14: ffffffff81cd9580 R15: ffff8801052e4200
 > FS:  00007f74949af740(0000) GS:ffff880148400000(0000) knlGS:0000000000000000
 > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 > CR2: 00000000051f7000 CR3: 00000000a8f72000 CR4: 00000000001407e0
 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 > Process trinity-child4 (pid: 21651, threadinfo ffff8800144c2000, task ffff880003470000)
 > Stack:
 >  ffffffff81628730 ffffffff810dafbf ffff880003470000 0000000000000000
 >  ffff8800144c3aa8 0000000000000282 ffff8800144c3aa8 ffff88013d79dd40
 >  ffff8801052e4200 0000000000000003 0000000000000001 0000000000000000
 > Call Trace:
 >  [<ffffffff81628730>] ? ip6_dst_lookup_tail+0xe0/0x380
 >  [<ffffffff810dafbf>] ? lock_release_holdtime.part.26+0xf/0x180
 >  [<ffffffff81556b20>] ? sock_def_wakeup+0x1b0/0x1b0
 >  [<ffffffff81628a9b>] ip6_sk_dst_lookup_flow+0xcb/0x1b0
 >  [<ffffffff81649d8d>] udpv6_sendmsg+0x6ad/0xc40
 >  [<ffffffff81023af9>] ? native_sched_clock+0x19/0x80
 >  [<ffffffff810db438>] ? trace_hardirqs_off_caller+0x28/0xd0
 >  [<ffffffff810db4ed>] ? trace_hardirqs_off+0xd/0x10
 >  [<ffffffff815e613a>] inet_sendmsg+0x12a/0x240
 >  [<ffffffff815e6010>] ? inet_create+0x6f0/0x6f0
 >  [<ffffffff815562a1>] ? sock_update_classid+0xb1/0x390
 >  [<ffffffff81556340>] ? sock_update_classid+0x150/0x390
 >  [<ffffffff8155115c>] sock_sendmsg+0xbc/0xf0
 >  [<ffffffff810b46c9>] ? local_clock+0x99/0xc0
 >  [<ffffffff810dff4f>] ? lock_release_non_nested+0x2df/0x320
 >  [<ffffffff810dafbf>] ? lock_release_holdtime.part.26+0xf/0x180
 >  [<ffffffff81553740>] sys_sendto+0x130/0x180
 >  [<ffffffff816af8ad>] system_call_fastpath+0x1a/0x1f
 > Code: c0 74 19 80 3d 0e 4d 6d 00 00 75 10 e8 73 cb af ff 85 c0 0f 85 e3 01 00 00 0f 1f 00 48 8b 03 48 8b 80 98 00 00 00 48 85 c0 74 09 <f6> 80 6d 01 00 00 de 74 48 e8 3b db a6 ff 85 c0 74 0d 80 3d d5 
 > 
 > The disassembly points here..
 > 
 >  983         rcu_read_lock();
 >  984         rt = (struct rt6_info *) *dst;
 >  985         n = rt->n;
 >  986         if (n && !(n->nud_state & NUD_VALID)) {
 >      db2:       48 85 c0                test   %rax,%rax
 >      db5:       74 09                   je     dc0 <ip6_dst_lookup_tail+0x150>
 >      db7:       f6 80 6d 01 00 00 de    testb  $0xde,0x16d(%rax)
 >      dbe:       74 48                   je     e08 <ip6_dst_lookup_tail+0x198>
 > 
 > 'rt->n' is 0x8000000000000011, which looks like one of the garbage values trinity generates

I hit this a few more times last night.  I'm starting to doubt my theory of where
that value came from, as every instance is always 0x8000000000000011, which seems
a little too lucky.  Anyone have any idea what that number resembles ?

Working on some code to make this (and other bugs) more reproducable today..

	Dave

^ permalink raw reply	[flat|nested] 7+ messages in thread

* GPF in ip6_dst_lookup_tail
@ 2012-12-07 14:15 Dave Jones
  2012-12-07 17:43 ` David Miller
  2012-12-09  2:04 ` Eric Dumazet
  0 siblings, 2 replies; 7+ messages in thread
From: Dave Jones @ 2012-12-07 14:15 UTC (permalink / raw)
  To: netdev

I just hit this gpf in overnight testing.

general protection fault: 0000 [#1] PREEMPT SMP 
Modules linked in: sctp libcrc32c ipt_ULOG fuse binfmt_misc nfnetlink nfc caif_socket caif phonet bluetooth rfkill can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 nfsv3 nfs_acl nfs fscache lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables usb_debug microcode serio_raw pcspkr i2c_piix4 i2c_core r8169 mii vhost_net tun macvtap macvlan kvm_amd kvm
CPU 3 
Pid: 19371, comm: trinity-child3 Not tainted 3.7.0-rc8+ #6 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[<ffffffff815fe038>]  [<ffffffff815fe038>] ip6_dst_lookup_tail+0xe8/0x200
RSP: 0018:ffff880046277968  EFLAGS: 00010206
RAX: 2000000000000011 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff880046277b00 RSI: ffff880070a6cd80 RDI: ffff8800bb22d000
RBP: ffff8800462779f8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff880046277a10
R13: ffff880046277b00 R14: ffff8800bb22d000 R15: ffffffff81cb40c0
FS:  00007f0817b3f740(0000) GS:ffff88012b400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000000a7dfb000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process trinity-child3 (pid: 19371, threadinfo ffff880046276000, task ffff880044dca450)
Stack:
 ffff8800bb22d000 0000000000000002 0000000000000001 0000000000000000
 ffff880046277998 ffffffff81335b56 ffff8800462779b8 ffffffff81074cec
 0000000000000001 ffff880070a6cd80 ffff8800462779f8 00000000ae4317df
Call Trace:
 [<ffffffff81335b56>] ? __const_udelay+0x36/0x40
 [<ffffffff81074cec>] ? __rcu_read_unlock+0x5c/0xa0
 [<ffffffff81527945>] ? sk_dst_check+0x5/0x260
 [<ffffffff815fe3fb>] ip6_sk_dst_lookup_flow+0xcb/0x1b0
 [<ffffffff8161f45e>] udpv6_sendmsg+0x66e/0xb90
 [<ffffffff81335b56>] ? __const_udelay+0x36/0x40
 [<ffffffff81074cec>] ? __rcu_read_unlock+0x5c/0xa0
 [<ffffffff815bd4e4>] inet_sendmsg+0x114/0x230
 [<ffffffff815bd3d5>] ? inet_sendmsg+0x5/0x230
 [<ffffffff815261e9>] ? sock_update_classid+0xa9/0x2d0
 [<ffffffff81526270>] ? sock_update_classid+0x130/0x2d0
 [<ffffffff81520d1c>] sock_sendmsg+0xbc/0xf0
 [<ffffffff810b7ab2>] ? get_lock_stats+0x22/0x70
 [<ffffffff810bd037>] ? lock_release_non_nested+0x2b7/0x2f0
 [<ffffffff815210fc>] __sys_sendmsg+0x3ac/0x3c0
 [<ffffffff810b7b88>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff810b7ab2>] ? get_lock_stats+0x22/0x70
 [<ffffffff810b7f1e>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff8100a136>] ? native_sched_clock+0x26/0x90
 [<ffffffff810b7b88>] ? trace_hardirqs_off_caller+0x28/0xc0
 [<ffffffff81055e54>] ? do_setitimer+0x1c4/0x300
 [<ffffffff810b7f1e>] ? put_lock_stats.isra.23+0xe/0x40
 [<ffffffff811d6bea>] ? fget_light+0x3ca/0x500
 [<ffffffff810bdf9d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff815237d9>] sys_sendmsg+0x49/0x90
 [<ffffffff81684b42>] system_call_fastpath+0x16/0x1b
Code: 00 00 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b 7d f8 c9 c3 0f 1f 00 49 8b 34 24 48 8b 86 98 00 00 00 48 85 c0 74 c2 <f6> 80 6d 01 00 00 de 75 b9 48 8b 56 18 49 8d 75 24 b9 01 00 00 
RIP  [<ffffffff815fe038>] ip6_dst_lookup_tail+0xe8/0x200
 RSP <ffff880046277968>
---[ end trace f7dde22e5674fdd6 ]---



0000000000000000 <.text>:
   0:	00 00                	add    %al,(%rax)
   2:	48 8b 5d d8          	mov    -0x28(%rbp),%rbx
   6:	4c 8b 65 e0          	mov    -0x20(%rbp),%r12
   a:	4c 8b 6d e8          	mov    -0x18(%rbp),%r13
   e:	4c 8b 75 f0          	mov    -0x10(%rbp),%r14
  12:	4c 8b 7d f8          	mov    -0x8(%rbp),%r15
  16:	c9                   	leaveq 
  17:	c3                   	retq   
  18:	0f 1f 00             	nopl   (%rax)
  1b:	49 8b 34 24          	mov    (%r12),%rsi
  1f:	48 8b 86 98 00 00 00 	mov    0x98(%rsi),%rax
  26:	48 85 c0             	test   %rax,%rax
  29:	74 c2                	je     0xffffffffffffffed

/home/davej/tmp/tmp.YOesIDyrIr.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <.text>:
   0:	f6 80 6d 01 00 00 de 	testb  $0xde,0x16d(%rax)
   7:	75 b9                	jne    0xffffffffffffffc2
   9:	48 8b 56 18          	mov    0x18(%rsi),%rdx
   d:	49 8d 75 24          	lea    0x24(%r13),%rsi
  11:	b9                   	.byte 0xb9
  12:	01 00                	add    %eax,(%rax)
	...


which looks like an inlined copy of ipv6_addr_any

         * marked as OPTIMISTIC, we release the found
         * dst entry and replace it instead with the
         * dst entry of the nexthop router
         */
        rt = (struct rt6_info *) *dst;
        n = rt->n;
      dc:       48 8b 86 98 00 00 00    mov    0x98(%rsi),%rax
        if (n && !(n->nud_state & NUD_VALID)) {
      e3:       48 85 c0                test   %rax,%rax
      e6:       74 c2                   je     aa <ip6_dst_lookup_tail+0xaa>
      e8:       f6 80 6d 01 00 00 de    testb  $0xde,0x16d(%rax)
      ef:       75 b9                   jne    aa <ip6_dst_lookup_tail+0xaa>


RAX here is 2000000000000011 , which clearly isn't a valid rt address to dereference.

Suddenly this starts to look familiar..  I started seeing this around 3.6-rc7
back in September.  http://www.spinics.net/lists/netdev/msg211894.html

	Dave

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GPF in ip6_dst_lookup_tail
  2012-12-07 14:15 GPF in ip6_dst_lookup_tail Dave Jones
@ 2012-12-07 17:43 ` David Miller
  2012-12-07 18:04   ` Dave Jones
  2012-12-09  2:04 ` Eric Dumazet
  1 sibling, 1 reply; 7+ messages in thread
From: David Miller @ 2012-12-07 17:43 UTC (permalink / raw)
  To: davej; +Cc: netdev

From: Dave Jones <davej@redhat.com>
Date: Fri, 7 Dec 2012 09:15:25 -0500

> I just hit this gpf in overnight testing.

Hmmm, perhaps introduced by:

commit f950c0ecc78f745e490d615280e031de4dbb1306
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu Sep 20 18:29:56 2012 +0000

    ipv6: fix return value check in fib6_add()

and fixed by:

commit 188c517a050ec5b123e72cab76ea213721e5bd9d
Author: Lin Ming <mlin@ss.pku.edu.cn>
Date:   Tue Sep 25 15:17:07 2012 +0000

    ipv6: return errno pointers consistently for fib6_add_1()
    

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GPF in ip6_dst_lookup_tail
  2012-12-07 17:43 ` David Miller
@ 2012-12-07 18:04   ` Dave Jones
  2012-12-07 18:05     ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Dave Jones @ 2012-12-07 18:04 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

On Fri, Dec 07, 2012 at 12:43:15PM -0500, David Miller wrote:
 > From: Dave Jones <davej@redhat.com>
 > Date: Fri, 7 Dec 2012 09:15:25 -0500
 > 
 > > I just hit this gpf in overnight testing.
 > 
 > Hmmm, perhaps introduced by:
 > 
 > commit f950c0ecc78f745e490d615280e031de4dbb1306
 > Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
 > Date:   Thu Sep 20 18:29:56 2012 +0000
 > 
 >     ipv6: fix return value check in fib6_add()
 > 
 > and fixed by:
 > 
 > commit 188c517a050ec5b123e72cab76ea213721e5bd9d
 > Author: Lin Ming <mlin@ss.pku.edu.cn>
 > Date:   Tue Sep 25 15:17:07 2012 +0000
 > 
 >     ipv6: return errno pointers consistently for fib6_add_1()
 >     

That was in the build that I was running.
(It was Linus' tree from last night, sorry I neglected to mention that)

	Dave

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GPF in ip6_dst_lookup_tail
  2012-12-07 18:04   ` Dave Jones
@ 2012-12-07 18:05     ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2012-12-07 18:05 UTC (permalink / raw)
  To: davej; +Cc: netdev

From: Dave Jones <davej@redhat.com>
Date: Fri, 7 Dec 2012 13:04:28 -0500

> On Fri, Dec 07, 2012 at 12:43:15PM -0500, David Miller wrote:
>  > From: Dave Jones <davej@redhat.com>
>  > Date: Fri, 7 Dec 2012 09:15:25 -0500
>  > 
>  > > I just hit this gpf in overnight testing.
>  > 
>  > Hmmm, perhaps introduced by:
>  > 
>  > commit f950c0ecc78f745e490d615280e031de4dbb1306
>  > Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>  > Date:   Thu Sep 20 18:29:56 2012 +0000
>  > 
>  >     ipv6: fix return value check in fib6_add()
>  > 
>  > and fixed by:
>  > 
>  > commit 188c517a050ec5b123e72cab76ea213721e5bd9d
>  > Author: Lin Ming <mlin@ss.pku.edu.cn>
>  > Date:   Tue Sep 25 15:17:07 2012 +0000
>  > 
>  >     ipv6: return errno pointers consistently for fib6_add_1()
>  >     
> 
> That was in the build that I was running.
> (It was Linus' tree from last night, sorry I neglected to mention that)

Ok, it's something else then.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GPF in ip6_dst_lookup_tail
  2012-12-07 14:15 GPF in ip6_dst_lookup_tail Dave Jones
  2012-12-07 17:43 ` David Miller
@ 2012-12-09  2:04 ` Eric Dumazet
  1 sibling, 0 replies; 7+ messages in thread
From: Eric Dumazet @ 2012-12-09  2:04 UTC (permalink / raw)
  To: Dave Jones; +Cc: netdev

On Fri, Dec 7, 2012 at 6:15 AM, Dave Jones <davej@redhat.com> wrote:
> I just hit this gpf in overnight testing.
>
> general protection fault: 0000 [#1] PREEMPT SMP
> Modules linked in: sctp libcrc32c ipt_ULOG fuse binfmt_misc nfnetlink nfc caif_socket caif phonet bluetooth rfkill can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 nfsv3 nfs_acl nfs fscache lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables usb_debug microcode serio_raw pcspkr i2c_piix4 i2c_core r8169 mii vhost_net tun macvtap macvlan kvm_amd kvm
> CPU 3
> Pid: 19371, comm: trinity-child3 Not tainted 3.7.0-rc8+ #6 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> RIP: 0010:[<ffffffff815fe038>]  [<ffffffff815fe038>] ip6_dst_lookup_tail+0xe8/0x200
> RSP: 0018:ffff880046277968  EFLAGS: 00010206
> RAX: 2000000000000011 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff880046277b00 RSI: ffff880070a6cd80 RDI: ffff8800bb22d000
> RBP: ffff8800462779f8 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: ffff880046277a10
> R13: ffff880046277b00 R14: ffff8800bb22d000 R15: ffffffff81cb40c0
> FS:  00007f0817b3f740(0000) GS:ffff88012b400000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000004 CR3: 00000000a7dfb000 CR4: 00000000000007e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process trinity-child3 (pid: 19371, threadinfo ffff880046276000, task ffff880044dca450)
> Stack:
>  ffff8800bb22d000 0000000000000002 0000000000000001 0000000000000000
>  ffff880046277998 ffffffff81335b56 ffff8800462779b8 ffffffff81074cec
>  0000000000000001 ffff880070a6cd80 ffff8800462779f8 00000000ae4317df
> Call Trace:
>  [<ffffffff81335b56>] ? __const_udelay+0x36/0x40
>  [<ffffffff81074cec>] ? __rcu_read_unlock+0x5c/0xa0
>  [<ffffffff81527945>] ? sk_dst_check+0x5/0x260
>  [<ffffffff815fe3fb>] ip6_sk_dst_lookup_flow+0xcb/0x1b0
>  [<ffffffff8161f45e>] udpv6_sendmsg+0x66e/0xb90
>  [<ffffffff81335b56>] ? __const_udelay+0x36/0x40
>  [<ffffffff81074cec>] ? __rcu_read_unlock+0x5c/0xa0
>  [<ffffffff815bd4e4>] inet_sendmsg+0x114/0x230
>  [<ffffffff815bd3d5>] ? inet_sendmsg+0x5/0x230
>  [<ffffffff815261e9>] ? sock_update_classid+0xa9/0x2d0
>  [<ffffffff81526270>] ? sock_update_classid+0x130/0x2d0
>  [<ffffffff81520d1c>] sock_sendmsg+0xbc/0xf0
>  [<ffffffff810b7ab2>] ? get_lock_stats+0x22/0x70
>  [<ffffffff810bd037>] ? lock_release_non_nested+0x2b7/0x2f0
>  [<ffffffff815210fc>] __sys_sendmsg+0x3ac/0x3c0
>  [<ffffffff810b7b88>] ? trace_hardirqs_off_caller+0x28/0xc0
>  [<ffffffff810b7ab2>] ? get_lock_stats+0x22/0x70
>  [<ffffffff810b7f1e>] ? put_lock_stats.isra.23+0xe/0x40
>  [<ffffffff8100a136>] ? native_sched_clock+0x26/0x90
>  [<ffffffff810b7b88>] ? trace_hardirqs_off_caller+0x28/0xc0
>  [<ffffffff81055e54>] ? do_setitimer+0x1c4/0x300
>  [<ffffffff810b7f1e>] ? put_lock_stats.isra.23+0xe/0x40
>  [<ffffffff811d6bea>] ? fget_light+0x3ca/0x500
>  [<ffffffff810bdf9d>] ? trace_hardirqs_on+0xd/0x10
>  [<ffffffff815237d9>] sys_sendmsg+0x49/0x90
>  [<ffffffff81684b42>] system_call_fastpath+0x16/0x1b
> Code: 00 00 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b 7d f8 c9 c3 0f 1f 00 49 8b 34 24 48 8b 86 98 00 00 00 48 85 c0 74 c2 <f6> 80 6d 01 00 00 de 75 b9 48 8b 56 18 49 8d 75 24 b9 01 00 00
> RIP  [<ffffffff815fe038>] ip6_dst_lookup_tail+0xe8/0x200
>  RSP <ffff880046277968>
> ---[ end trace f7dde22e5674fdd6 ]---
>
>
>
> 0000000000000000 <.text>:
>    0:   00 00                   add    %al,(%rax)
>    2:   48 8b 5d d8             mov    -0x28(%rbp),%rbx
>    6:   4c 8b 65 e0             mov    -0x20(%rbp),%r12
>    a:   4c 8b 6d e8             mov    -0x18(%rbp),%r13
>    e:   4c 8b 75 f0             mov    -0x10(%rbp),%r14
>   12:   4c 8b 7d f8             mov    -0x8(%rbp),%r15
>   16:   c9                      leaveq
>   17:   c3                      retq
>   18:   0f 1f 00                nopl   (%rax)
>   1b:   49 8b 34 24             mov    (%r12),%rsi
>   1f:   48 8b 86 98 00 00 00    mov    0x98(%rsi),%rax
>   26:   48 85 c0                test   %rax,%rax
>   29:   74 c2                   je     0xffffffffffffffed
>
> /home/davej/tmp/tmp.YOesIDyrIr.o:     file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <.text>:
>    0:   f6 80 6d 01 00 00 de    testb  $0xde,0x16d(%rax)
>    7:   75 b9                   jne    0xffffffffffffffc2
>    9:   48 8b 56 18             mov    0x18(%rsi),%rdx
>    d:   49 8d 75 24             lea    0x24(%r13),%rsi
>   11:   b9                      .byte 0xb9
>   12:   01 00                   add    %eax,(%rax)
>         ...
>
>
> which looks like an inlined copy of ipv6_addr_any
>
>          * marked as OPTIMISTIC, we release the found
>          * dst entry and replace it instead with the
>          * dst entry of the nexthop router
>          */
>         rt = (struct rt6_info *) *dst;
>         n = rt->n;
>       dc:       48 8b 86 98 00 00 00    mov    0x98(%rsi),%rax
>         if (n && !(n->nud_state & NUD_VALID)) {
>       e3:       48 85 c0                test   %rax,%rax
>       e6:       74 c2                   je     aa <ip6_dst_lookup_tail+0xaa>
>       e8:       f6 80 6d 01 00 00 de    testb  $0xde,0x16d(%rax)
>       ef:       75 b9                   jne    aa <ip6_dst_lookup_tail+0xaa>
>
>
> RAX here is 2000000000000011 , which clearly isn't a valid rt address to dereference.
>

More exactly rt was fine, but n (rt->n) contains garbage

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-12-09  2:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-07 14:15 GPF in ip6_dst_lookup_tail Dave Jones
2012-12-07 17:43 ` David Miller
2012-12-07 18:04   ` Dave Jones
2012-12-07 18:05     ` David Miller
2012-12-09  2:04 ` Eric Dumazet
  -- strict thread matches above, loose matches on Subject: below --
2012-09-27 14:03 Dave Jones
2012-10-02 13:59 ` Dave Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).