lkml.org 
[lkml]   [2014]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: frequent lockups in 3.18rc4
    On Thu, Dec 11, 2014 at 01:49:17PM -0800, Linus Torvalds wrote:

    > Maybe it's worth it to concentrate on just testing current kernels,
    > and instead try to limit the triggering some other way. In particular,
    > you had a trinity run that was *only* testing lsetxattr(). Is that
    > really *all* that was going on? Obviously trinity will be using
    > timers, fork, and other things? Can you recreate that lsetxattr thing,
    > and just try to get as many problem reports as possible from one
    > particular kernel (say, 3.18, since that should be a reasonable modern
    > base with hopefully not a lot of other random issues)?

    Something that's still making me wonder if it's some kind of hardware
    problem is the non-deterministic nature of this bug.
    Take the example above, by limiting trinity to doing nothing but lsetxattr's.
    Why would the bug sometimes take 3-4 hours to shake out, and another
    run take just 45 minutes.

    "different entropy" really shouldn't matter a huge amount here. Even if
    we end up picking different pathnames to pass in, it's the same source
    (proc,sys,/dev). The other arguments are a crapshoot, but it seems
    unlikely that it would matter hugely whatever values they are.

    If it *is* a kernel bug, it's not going to be in lsetxattr, but rather
    some kind of scheduling or mm related thing that happens in some corner
    case when we're under extreme load. That I can drive up the loadavg with
    lsetxattr is I suspect just a symptom rather than the cause.

    If enough callers pass in huge 'len' arguments, and an mmap that's big
    enough to cover that size, I could see that giving the kernel a lot of
    work to do.

    Another thing I keep thinking is "well, how is this different from
    a forkbomb?". The user account I'm running under has no ulimit set on
    the maximum memory size for eg, but if that were the problem, surely
    I'd be seeing the oom-killer rather than lockups.

    Dave



    \
     
     \ /
      Last update: 2014-12-12 20:21    [W:4.211 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site