Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756517AbaKTAt1 (ORCPT ); Wed, 19 Nov 2014 19:49:27 -0500 Received: from mail-lb0-f182.google.com ([209.85.217.182]:65236 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753629AbaKTAt0 (ORCPT ); Wed, 19 Nov 2014 19:49:26 -0500 MIME-Version: 1.0 In-Reply-To: References: <20141118145234.GA7487@redhat.com> <20141118215540.GD35311@redhat.com> <20141119021902.GA14216@redhat.com> <20141119145902.GA13387@redhat.com> <20141119190215.GA10796@lerouge> <20141119225615.GA11386@lerouge> From: Andy Lutomirski Date: Wed, 19 Nov 2014 16:49:03 -0800 Message-ID: Subject: Re: frequent lockups in 3.18rc4 To: Linus Torvalds Cc: Thomas Gleixner , "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 Wed, Nov 19, 2014 at 4:40 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 4:30 PM, Andy Lutomirski wrote: >> >> This is why I think that the grsec kernels will crash on very large >> memory systems. They don't seem to get this right for the kernel >> stack, and a page fault trying to access the stack is a big no-no. > > For something like a stack, that's trivial, you could just probe it > before the actual task switch. I thought so for a while, too, but now I disagree. On PGE hardware, it seems entirely possible that the new stack would be in the TLB even if it's not visible via cr3. Then, as soon as the TLB entry expires, we double-fault. > > So I wouldn't worry about the kernel stack itself (although I think > vmallocing it isn't likely worth it), I don't want vmalloc to avoid low-order allocations -- I want it to have guard pages. The fact that a user-triggerable stack overflow is basically root right now and doesn't reliably OOPS scares me. > I'd worry more about some other > random dynamic percpu allocation. Although they arguably shouldn't > happen for low-level code that cannot handle the dynamic > pgd-population. And they generally don't. This issue ought to be limited to nokprobes code, and I doubt that any of that code touches dynamic per-cpu things. > > It's really tracing that tends to be a special case not because of any > particular low-level code issue, but because instrumenting itself > recursively tends to be a bad idea. > > Linus -- Andy Lutomirski AMA Capital Management, LLC -- 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/