lkml.org 
[lkml]   [2014]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: frequent lockups in 3.18rc4
    On Fri, Nov 21, 2014 at 2:55 PM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    > On Fri, Nov 21, 2014 at 1:11 PM, Thomas Gleixner <tglx@linutronix.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.

    At the risk of going deeper down the rabbit hole, I grepped for
    pgd_list. I found:

    __set_pmd_pte in pageattr.c. It appears to be completely incorrect.
    Unless I've misunderstood, other than the very first line, it will
    either do nothing at all or crash when it falls off the end of the
    page tables that it's pointlessly trying to update.

    sync_global_pgds: OK, I guess -- this is for hot-add of memory, right?
    But if we teach the context switch code to check that the kernel
    stack is okay, that can be removed, I think. (We absolutely MUST keep
    the static per-cpu stuff populated everywhere before running user
    code, but that's never in hot-added memory.)

    xen_mm_pin_all and xen_mm_unpin_all: I have no clue. I wonder how
    that works with SHARED_KERNEL_PMD.

    Anyone want to attack these? It would be kind of nice to remove
    pgd_list entirely. (I realize that doing so precludes the use of
    bloody enormous 512GB kernel pages, but any attempt to use *those* is
    so completely screwed without a major reworking of all of this (or
    perhaps stop_machine) that keeping pgd_list around just for that is
    probably a mistake.)

    --Andy


    \
     
     \ /
      Last update: 2014-11-22 00:41    [W:4.856 / U:0.396 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site