Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752691AbaKUXdM (ORCPT ); Fri, 21 Nov 2014 18:33:12 -0500 Received: from mail-qg0-f44.google.com ([209.85.192.44]:39215 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100AbaKUXdL (ORCPT ); Fri, 21 Nov 2014 18:33:11 -0500 MIME-Version: 1.0 In-Reply-To: References: <20141120233920.GC25393@htj.dyndns.org> <20141121162742.GB15461@htj.dyndns.org> <20141121170805.GD30603@home.goodmis.org> Date: Fri, 21 Nov 2014 15:33:09 -0800 X-Google-Sender-Auth: 1yNk_Ueh4zR6eUIO7QQ3hG0NZSQ Message-ID: Subject: Re: frequent lockups in 3.18rc4 From: Linus Torvalds To: Andy Lutomirski Cc: Thomas Gleixner , Steven Rostedt , Tejun Heo , "linux-kernel@vger.kernel.org" , Arnaldo Carvalho de Melo , Peter Zijlstra , Frederic Weisbecker , Don Zickus , Dave Jones , "the arch/x86 maintainers" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 21, 2014 at 3:03 PM, Andy Lutomirski wrote: > On Fri, Nov 21, 2014 at 2:55 PM, Linus Torvalds > 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 paravirt anywhere. > At the risk of going deeper down the rabbit hole, I grepped for > pgd_list. I found: Ugh. > __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. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/