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: <20141121141332.GA8808@lerouge>
Date:	Fri, 21 Nov 2014 15:13:35 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>, Don Zickus <dzickus@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...capital.net>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: frequent lockups in 3.18rc4

On Fri, Nov 21, 2014 at 01:54:00AM +0100, Thomas Gleixner wrote:
> On Thu, 20 Nov 2014, Tejun Heo wrote:
> > Sure, this could have been better but I missed it at the beginning
> > and this is the first time I hear about this issue.
> 
> So the issues Frederic talked about in that very thread about
> recursive faults and the need that perf had to emulate percpu stuff in
> order to work around them have never been communicated to you?
> 
> I that's the case then that's not your problem, but a serious problem
> in our overall process.

So when the issue arised 4 years ago, it was a problem only for NMIs.
Like Linus says: "what happens in NMI stays in NMI". Ok no that's not quite
what he says :-)  But NMIs happen to be a corner case for about everything
and it's sometimes better to fix things from NMI itself, or have an NMI
special case rather than grow the whole infrastructure in complexity to
support this very corner case.

Not saying that's the only valid approach to take wrt. NMIs but those vmalloc faults
seemed to be well established and generally known (except perhaps for percpu)
and NMI was the only corner case, and we are used to that, so fixing the issue
for NMIs only felt like the right direction when we fixed the callchain thing
with other perf developers.

I certainly should have talked to Tejun about that but it took a bit of time
for me to realize that randomly faultable memory is a dangerous behaviour.

Add to that a bit of the "take the infrastrusture as granted" problem when
you're not well experienced enough...

Anyway, I really hope we fix that, that's a bomb waiting to explode.
--
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/