Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752903Ab3EUUO5 (ORCPT ); Tue, 21 May 2013 16:14:57 -0400 Received: from mail-lb0-f179.google.com ([209.85.217.179]:37795 "EHLO mail-lb0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751762Ab3EUUOz (ORCPT ); Tue, 21 May 2013 16:14:55 -0400 MIME-Version: 1.0 In-Reply-To: <1369158390.6828.148.camel@gandalf.local.home> References: <1369158390.6828.148.camel@gandalf.local.home> Date: Tue, 21 May 2013 22:14:54 +0200 Message-ID: Subject: Re: [PATCH][3.10] nohz: Fix lockup on restart from wrong error code From: Frederic Weisbecker To: Steven Rostedt Cc: LKML , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , "Paul E. McKenney" , Andrew Morton , Paul Gortmaker , Tejun Heo Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1819 Lines: 38 2013/5/21 Steven Rostedt : > commit a382bf934449 "nohz: Assign timekeeping duty to a CPU outside the > full dynticks range" added a cpu notifier callback that would prevent > the time keeping CPU from going offline if the have_nohz_full_mask was > set. > > This also prevents the CPU from going offline on system reboot. > > Worse yet, the return code was -EINVAL, but the notifier does not > recognize error codes, and it must be wrapped by a notifier_from_errno() > function. This means that even though the CPU would fail to go down, the > notifier would think it succeeded, and the cpu down process would > continue. > > This caused two different problems. One, the migration thread after > moving tasks from the CPU would park itself and then a task, namely the > reboot task, could migrate onto that CPU. Then the reboot task spins > waiting for the cpu to go idle. But because the reboot task happens to > be spinning on the cpu its waiting for, the system hangs. Can that happen if that CPU is the boot CPU? Note this is the only possible timekeeper with the upstream code. > > The other error that happened was that the sched_domain re-setup would > get confused, and in get_group() the cpu = cpumask_first() would process > a mask that had nothing set, and return cpu > nr_cpu_ids. Later it would > reference the per_cpu sg with this CPU and get a bogus pointer and > crash. Ouch, when are we doing this domain re-setup? I remember we repartition the domains after cpu down/up but I don't understand how that can interfere with this issue. -- 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/