Re: frequent lockups in 3.18rc4
From: Linus Torvalds
Date: Fri Nov 21 2014 - 18:33:17 EST
On Fri, Nov 21, 2014 at 3:03 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Fri, Nov 21, 2014 at 2:55 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Anyway, here's an actual patch. As usual, it has seen absolutely no
>> actual testing,
.. ok, it boots and works fine as far as I can tell on x86-64 with no
> 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.
I think you found a rats nest.
I can't make heads nor tails of the logic. The !SHARED_KERNEL_PMD test
doesn't seem very sensible, since that's also the conditional for
adding anything to the list in the first place.
So I agree that the code doesn't make much sense. Although maybe it's
there just because that way the loop goes away at compile-time under
most circumstances. So maybe even that part does make sense.
And the "walk down to the pmd level" part actually looks ok. Remember:
this is on x86-32 only, and you have two cases: non-PAE where the
pmd/pud offset thing does nothing at all, and it just ends up
converting a "pgd_t *" to a "pmd_t *". And for PAE, the top pud level
always exists, and the pmd is folded, so despite what looks like
walking two levels, it really just walks the one level - the
force-allocated PGD entries.
So it won't "fall off the end of the page tables" like you imply. It
will just walk to the pmd level. And there it will populate all the
page tables with the same pmd.
So I think it works.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/