linux-kernel - Re: [BUG] kernel freezes with latest tree

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]

Date:	Tue, 10 Jan 2012 15:44:38 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [BUG] kernel freezes with latest tree

On Tue, Jan 10, 2012 at 2:23 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> Maybe a recent change in NMI handling, or perf events ?

Unlikely. And it shouldn't show up in the merge commit anyway, those
things should be pretty independent.

> No idea why the bisection (I redid it carefully : same result) points to the above commit.

Ok, so the bisect is almost certainly correct. But just to be anal and
really careful, can you independently check both parents of the merge,
and then re-check the merge itself, and verify that the two parent
commits never hang, and that the merged state hangs.

Just to take any bisection issues out of the picture, and just verify
those three commits by hand.

But in the meantime, we should assume that it's the merge that is the problem.

I added Frederic to the cc, because he did the
tick_nohz_idle_enter_norcu(), so maybe he can tell if there is
something in that merge that looks suspicious (Frederic - see the
history of the thread on lkml. I thought maybe it was the lack of
irq-disable around set_cpu_sd_state_idle(), but Eric already tested
that). And Suresh because he worked on the whole nohz/nr_busy_cpus.
Maybe you guys see some obvious semantic clash..

Anybody? Any ideas? Clearly there can be a merge problem that doesn't
actually show as a real data conflict, just some semantic conflict,
but I don't see what such issues would be brouht in by the scheduler
merge anyway.

                       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/