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

On Fri, Nov 21, 2014 at 8:38 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> If you move the vmalloc fixup before exception_enter() and return if
> the fault was from vmalloc, then you can't recurse.  You need to be
> careful not to touch anything that uses RCU before exception_enter,
> though.

This is probably the right thing to do anyway.

The vmalloc fixup is purely about filling in hardware structures, so
there really shouldn't be any need for RCU or anything else. It should
probably be done first, before *anything* else (like the whole
kmemcheck/kmmio fault etc handling)

That said, the whole vmalloc_fault fixup routine does some odd things,
over and beyond just filling in the page tables. So I'm not 100% sure
that is safe as-is. The 32-bit version looks fine, but the x86-64
version is very very dubious.

The x86-64 version does crazy things like:

 - uses "current->active_mm", which is very dubious
 - flush lazy mmu mode
 - walk down further in the page tables

and those are just bugs, imnsho. Get rid of that crap. The 32-bit code
does it right.

(The 64-bit mode also has a "WARN_ON_ONCE(in_nmi())", which I guess is
good - but it's good because the 64-bit version is written the way it
is).

                    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ