lkml.org 
[lkml]   [2012]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3.5-rc6 futex_wait_requeue_pi oops.
On Fri, Jul 13, 2012 at 09:11:57PM +0200, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Dave Jones wrote:
>
> > On Fri, Jul 13, 2012 at 08:47:38PM +0200, Thomas Gleixner wrote:
> > > On Fri, 13 Jul 2012, Dave Jones wrote:
> > >
> > > > Looks like calling futex() with garbage makes things unhappy.
> > >
> > > WARN_ON(!&q.pi_state);
> > > pi_mutex = &q.pi_state->pi_mutex;
> > > ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1);
> > > debug_rt_mutex_free_waiter(&rt_waiter);
> > >
> > > So there is some weird way which causes q.pi_state = NULL. Dave, did
> > > you see the warning before the oops happened ?
> >
> > No, that didn't seem to trigger.
>
> Yuck. The rt_mutex is embedded in pi_state and not a pointer and the
> thing explodes in __lock_acquire if the raw lock protecting the
> rtmutex internals.
>
> Can you decode the exact code line ?

Hmm. I think I rebuilt the kernel, so things may be slightly different, though
what I see surprises me..

decoding the Code: line shows..

Code: d8 45 0f 45 e0 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 f8 00 00 00 8b 05 e2 af fa 00 49 89 ff 89 f3 41 89 d2 85 c0 0f 84 02 01 00 00 <49> 8b 07 ba 01 00 00 00 48 3d 20 c4 0c 82 44 0f 44 e2 83 fb 01



0000000000000000 <.text>:
0: d8 45 0f fadds 0xf(%rbp)
3: 45 e0 4c rex.RB loopne 0x52
6: 89 75 f0 mov %esi,-0x10(%rbp)
9: 4c 89 7d f8 mov %r15,-0x8(%rbp)
d: 85 c0 test %eax,%eax
f: 0f 84 f8 00 00 00 je 0x10d
15: 8b 05 e2 af fa 00 mov 0xfaafe2(%rip),%eax # 0xfaaffd
1b: 49 89 ff mov %rdi,%r15
1e: 89 f3 mov %esi,%ebx
20: 41 89 d2 mov %edx,%r10d
23: 85 c0 test %eax,%eax
25: 0f 84 02 01 00 00 je 0x12d

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


Disassembly of section .text:

0000000000000000 <.text>:
0: 49 8b 07 mov (%r15),%rax
3: ba 01 00 00 00 mov $0x1,%edx
8: 48 3d 20 c4 0c 82 cmp $0xffffffff820cc420,%rax
e: 44 0f 44 e2 cmove %edx,%r12d
12: 83 fb 01 cmp $0x1,%ebx




The only instance of 49 8b 07 followed by ba 01 in kernel/lockdep.o is this ..

/*
* Lockdep should run with IRQs disabled, otherwise we could
* get an interrupt which would want to take locks, which would
* end up in lockdep and have you got a head-ache already?
*/
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
3f88: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 3f8e <__lock_acquire+0x4e>
3f8e: 49 89 ff mov %rdi,%r15
3f91: 89 f3 mov %esi,%ebx
3f93: 41 89 d2 mov %edx,%r10d
3f96: 85 c0 test %eax,%eax
3f98: 0f 84 02 01 00 00 je 40a0 <__lock_acquire+0x160>
return 0;

if (lock->key == &__lockdep_no_validate__)
3f9e: 49 8b 07 mov (%r15),%rax <<<<<<<<<<<<<<<<<<
check = 1;
3fa1: ba 01 00 00 00 mov $0x1,%edx


Seems to add up. Though the bytes in the code: line following don't match what's in the object..

3fa6: 48 3d 00 00 00 00 cmp $0x0,%rax
3fac: 44 0f 44 e2 cmove %edx,%r12d


That line at 3fa6 got changed from an actual address to a NULL.
I guess that's the &__lockdep_no_validate__ comparison.
Though it seems odd that the kernel text would change.
Does lockdep do that when it gets disabled or something ?

Dave



\
 
 \ /
  Last update: 2012-07-13 22:41    [W:0.086 / U:2.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site