Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932266AbaKTWL2 (ORCPT ); Thu, 20 Nov 2014 17:11:28 -0500 Received: from mail-qc0-f169.google.com ([209.85.216.169]:33468 "EHLO mail-qc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756761AbaKTWL0 (ORCPT ); Thu, 20 Nov 2014 17:11:26 -0500 Date: Thu, 20 Nov 2014 17:11:22 -0500 From: Tejun Heo To: Thomas Gleixner Cc: Frederic Weisbecker , Linus Torvalds , Dave Jones , Don Zickus , Linux Kernel , the arch/x86 maintainers , Peter Zijlstra , Andy Lutomirski , Arnaldo Carvalho de Melo Subject: Re: frequent lockups in 3.18rc4 Message-ID: <20141120221122.GA25393@htj.dyndns.org> References: <20141119145902.GA13387@redhat.com> <20141119190215.GA10796@lerouge> <20141119225615.GA11386@lerouge> <20141119235033.GE11386@lerouge> <20141120122339.GA14877@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 20, 2014 at 10:58:26PM +0100, Thomas Gleixner wrote: > It's completely undocumented behaviour, whether it has been that way > for ever or not. And I agree with Fredric, that it is insane. Actuallu > it's beyond insane, really. This is exactly the same for any address in the vmalloc space. .. > So in the scheduler if the same task gets reselected you check that > sequence count and update the PGD if different. If a task switch > happens then you also need to check the sequence count and act > accordingly. That isn't enough tho. What if the percpu allocated pointer gets passed to another CPU without task switching? You'd at least need to send IPIs to all CPUs so that all the active PGDs get updated synchronously. > What really frightens me is the potential and well hidden fuckup > potential which lurks around the corner and the hard to debug once in > a while fallout which might be caused by this. Lazy vmalloc population through fault is something we accepted as reasonable as it works fine for most of the kernel. If the lazy loading can be improved so that it doesn't depend on faulting, great. For the time being, we can make percpu accessors complain when called from nmi handlers so that the problematic ones can be easily identified. Thanks. -- tejun -- 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/