Re: frequent lockups in 3.18rc4

[Dave Jones <davej@redhat.com>]

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