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:	Wed, 11 Jan 2012 09:22:07 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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

Le mardi 10 janvier 2012 à 15:44 -0800, Linus Torvalds a écrit :
> 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.
> 

Thanks Linus for all the input.

I'll redo extensive bisection today, waiting at least 30 minutes before
telling a point is good (or not).

Maybe bug can sometime hide a long time before triggering.

[ I'll first make sure 3.2 is rock solid ]



--
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/