lkml.org 
[lkml]   [2014]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [3.15-rc3] rtmutex-debug assertion.
    On Wed, Apr 30, 2014 at 11:13:57AM +0200, Thomas Gleixner wrote:
    > On Tue, 29 Apr 2014, Dave Jones wrote:
    > > This is trickier to reproduce than it first seemed, as logging slows
    > > things down so much. But after a few hours, it logged that the
    > > call that triggered this was..
    > >
    > > futex(uaddr=0x7f55ff8c4000, op=0x6, val=0x200000006223800b, utime=0x7f55ff8c4000, uaddr2=0x7f55ff8c4000, val3=-123)
    > >
    > > Those addresses come from an mmap we made on startup..
    > >
    > > [init] mapping[3]: (zeropage PROT_READ | PROT_WRITE) 0x7f55ff8c4000 (1MB)
    > >
    > > op = FUTEX_LOCK_PI
    > >
    > > val seems to be garbage.
    > >
    > > I'll do another run, just to see if it's always the same set of values,
    > > but it's going to probably take an overnight run.
    >
    > Do you have the full fuzzing log, so I can see what happened
    > before/around that?

    This is tough, because it takes a long time to reproduce when the
    logging is enabled, and that ends up generating a lot of output.
    I've tried to cut it down some using just 4 threads, but that's
    still over 30M of logs.
    http://www.codemonkey.org.uk/junk/futex.tar.xz

    In this run, child0 was the pid that faulted.
    You can see the last line in trinity-child0.log has a similar
    fingerprint to the trace above.

    One thing that does look suspicious, is that all 4 threads were doing
    op=0x6 right before the kernel went south.

    Hope this helps.

    Dave



    \
     
     \ /
      Last update: 2014-05-02 07:21    [W:4.237 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site