[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyzg=vJqRwh2CsK8WD-E5nRPjdiasMaTBx6qygQhDrGLA@mail.gmail.com>
Date: Fri, 21 Nov 2014 14:55:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andy Lutomirski <luto@...capital.net>,
Steven Rostedt <rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
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 1:11 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> I'm fine with that. I just think it's not horrid enough, but that can
> be fixed easily :)
Oh, I think it's plenty horrid.
Anyway, here's an actual patch. As usual, it has seen absolutely no
actual testing, but I did try to make sure it compiles and seems to do
the right thing on:
- x86-32 no-PAE
- x86-32 no-PAE with PARAVIRT
- x86-32 PAE
- x86-64
also, I just removed the noise that is "vmalloc_sync_all()", since
it's just all garbage and nothing actually uses it. Yeah, it's used by
"register_die_notifier()", which makes no sense what-so-ever.
Whatever. It's gone.
Can somebody actually *test* this? In particular, in any kind of real
paravirt environment? Or, any comments even without testing?
I *really* am not proud of the mess wrt the whole
#ifdef CONFIG_PARAVIRT
#ifdef CONFIG_X86_32
...
but I think that from a long-term perspective, we're actually better
off with this kind of really ugly - but very explcit - hack that very
clearly shows what is going on.
The old code that actually "walked" the page tables was more
"portable", but was somewhat misleading about what was actually going
on.
Comments?
Linus
View attachment "patch.diff" of type "text/plain" (6316 bytes)
Powered by blists - more mailing lists