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: <20141121162506.GA15461@htj.dyndns.org>
Date:	Fri, 21 Nov 2014 11:25:06 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	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

Hello, Frederic.

On Fri, Nov 21, 2014 at 03:13:35PM +0100, Frederic Weisbecker wrote:
...
> 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.

I'm not familiar with the innards of fault handling, so can you please
help me understand what may actually break?  Here are what I currently
understand.

* Static percpu areas wouldn't trigger fault lazily.  Note that this
  is not necessarily because the first percpu chunk which contains the
  static area is embedded inside the kernel linear mapping.  Depending
  on the memory layout and boot param, percpu allocator may choose to
  map the first chunk in vmalloc space too; however, this still works
  out fine because at that point there are no other page tables and
  the PUD entries covering the first chunk is faulted in before other
  pages tables are copied from the kernel one.

* NMI used to be a problem because vmalloc fault handler couldn't
  safely nest inside NMI handler but this has been fixed since and it
  should work fine from NMI handlers now.

* Function tracers are problematic because they may end up nesting
  inside themselves through triggering a vmalloc fault while accessing
  dynamic percpu memory area.  This may lead to recursive locking and
  other surprises.

Are there other cases where the lazy vmalloc faults can break things?

Thanks.

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