linux-kernel - Re: frequent lockups in 3.18rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFy1_w1NrkeopMXsxGftO5F03JzKgn-8uTQRnEAXuoiXgg@mail.gmail.com>
Date:	Thu, 11 Dec 2014 13:49:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chris Mason <clm@...com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dâniel Fraga <fragabr@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: frequent lockups in 3.18rc4

On Thu, Dec 11, 2014 at 6:54 AM, Dave Jones <davej@...hat.com> wrote:
>
> So either one of those 'good's actually wasn't, or I'm just cursed.

Even if there was a good that wasn't, that last "bad"  (6f929b4e5a02)
is already sufficient just on its own to say that likely v3.16 already
had the problem.

Just do

   gitk v3.16..6f929b4e5a02

and cry.

(or "git diff --stat -M v3.16...6f929b4e5a02" to see what that commit
brought in from the common ancestor).

So I'd call that bisect a failure, and your "v3.16 is fine" is
actually suspect after all. Which *might* mean that it's some hardware
issue after all. Or there are multiple different problems, and while
v3.16 was fine, the problem was introduced earlier (in the common
ancestor of that staging tree), then fixed for 3.16, and then
re-introduced later again.

Anyway, you might as well stop bisecting. Regardless of where it lands
in the remaining pile, it's not going to give us any useful
information, methinks.

I'm stumped.

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)?

Together with perhaps config checks. You've done some those already.
Did it reproduce without preemption, for example?

Does anybody have any smart ideas?

                            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/