From: Andy Lutomirski <luto@amacapital.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Denys Vlasenko <dvlasenk@redhat.com>,
Brian Gerst <brgerst@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Oleg Nesterov <oleg@redhat.com>, Waiman Long <waiman.long@hp.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 05/11] mm: Introduce arch_pgd_init_late()
Date: Tue, 22 Sep 2015 11:37:18 -0700 [thread overview]
Message-ID: <CALCETrUp2rmUSfKcTphEybfTQ8Kh58kRUekG80vx0TpZURo50g@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFy2oQztH_8TXgyAn944SpvD5wb9k=Os3fSYTB8V1Gc45w@mail.gmail.com>
On Tue, Sep 22, 2015 at 11:26 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Sep 22, 2015 at 11:00 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> I really really hate the vmalloc fault thing. It seems to work,
>> rather to my surprise. It doesn't *deserve* to work, because of
>> things like the percpu TSS accesses in the entry code that happen
>> without a valid stack.
>
> The thing is, I think you're misguided in your hatred.
>
> The reason I say that is because I think we should just embrace the
> fact that faults can and do happen in the kernel in very inconvenient
> places, and not just in code we "control".
>
> Even if you get rid of the vmalloc fault, you'll still have debug
> faults, and you'll still have NMI's and horrible crazy machine check
> faults.
>
> I actually think teh vmalloc fault is a good way to just let people
> know "pretty much anything can trap, deal with it".
>
> And I think trying to eliminate them is the wrong thing, because it
> forces us to be so damn synchronized. This whole patch-series is a
> prime example of why that is a bad bad things. We want to have _less_
> synchronization.
Sure, pretty much anything can trap, but we need to do *something* to
deal with it.
Debug faults can't happen with bad stacks any more (now that we honor
the kprobe blacklist), which means that debug faults could, in theory,
move off the IST stack. The SYSENTER + debug mess doesn't have any
stack problem.
NMIs and MCEs are special, and we deal with that using IST and all
kinds of mess.
I don't think that anyone really wants to move #PF to IST, which means
that we simply cannot handle vmalloc faults that happen when switching
stacks after SYSCALL, no matter what fanciness we shove into the
page_fault asm. If we move #PF to IST, then we have to worry about
page_fault -> nmi -> page_fault, which would be a clusterf*ck.
AMD gave us a pile of misguided architectural turds, and we have to
deal with it. My preference is to simplify dealing with it by getting
rid of vmalloc faults so that we can at least reliably touch percpu
memory without faulting.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-09-22 18:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 6:23 [PATCH 00/11] x86/mm: Implement lockless pgd_alloc()/pgd_free() Ingo Molnar
2015-09-22 6:23 ` [PATCH 01/11] x86/mm/pat: Don't free PGD entries on memory unmap Ingo Molnar
2015-09-22 17:41 ` Linus Torvalds
2015-09-22 18:03 ` Andy Lutomirski
2015-09-22 6:23 ` [PATCH 02/11] x86/mm/hotplug: Remove pgd_list use from the memory hotplug code Ingo Molnar
2015-09-22 17:48 ` Linus Torvalds
2015-09-23 11:44 ` Oleg Nesterov
2015-09-29 8:42 ` Ingo Molnar
2015-09-29 16:51 ` Oleg Nesterov
2015-09-22 6:23 ` [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable() Ingo Molnar
2015-10-06 3:35 ` Kamezawa Hiroyuki
2016-02-12 19:04 ` Andy Lutomirski
2016-03-10 6:45 ` Andy Lutomirski
2016-03-10 9:56 ` Ingo Molnar
2016-03-11 1:52 ` Andy Lutomirski
2015-09-22 6:23 ` [PATCH 04/11] x86/mm/hotplug: Simplify sync_global_pgds() Ingo Molnar
2015-09-22 6:23 ` [PATCH 05/11] mm: Introduce arch_pgd_init_late() Ingo Molnar
2015-09-22 17:55 ` Linus Torvalds
2015-09-22 18:00 ` Andy Lutomirski
2015-09-22 18:26 ` Linus Torvalds
2015-09-22 18:37 ` Andy Lutomirski [this message]
2015-09-22 18:44 ` Linus Torvalds
2015-09-22 18:52 ` Andy Lutomirski
2015-09-22 6:23 ` [PATCH 06/11] x86/virt/guest/xen: Remove use of pgd_list from the Xen guest code Ingo Molnar
2015-09-22 17:58 ` Linus Torvalds
2015-09-29 8:44 ` Ingo Molnar
2015-09-22 6:23 ` [PATCH 07/11] x86/mm: Remove pgd_list use from vmalloc_sync_all() Ingo Molnar
2015-09-22 17:59 ` Linus Torvalds
2015-09-22 6:23 ` [PATCH 08/11] x86/mm/pat/32: Remove pgd_list use from the PAT code Ingo Molnar
2015-09-22 6:23 ` [PATCH 09/11] x86/mm: Make pgd_alloc()/pgd_free() lockless Ingo Molnar
2015-09-22 6:23 ` [PATCH 10/11] x86/mm: Remove pgd_list leftovers Ingo Molnar
2015-09-22 6:23 ` [PATCH 11/11] x86/mm: Simplify pgd_alloc() Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrUp2rmUSfKcTphEybfTQ8Kh58kRUekG80vx0TpZURo50g@mail.gmail.com \
--to=luto@amacapital.net \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=waiman.long@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox