From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751813AbdITQY4 (ORCPT ); Wed, 20 Sep 2017 12:24:56 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:60282 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbdITQYy (ORCPT ); Wed, 20 Sep 2017 12:24:54 -0400 Date: Wed, 20 Sep 2017 18:24:47 +0200 From: Sebastian Andrzej Siewior To: "Paul E. McKenney" Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, tglx@linutronix.de Subject: Re: native_smp_send_reschedule() splat from rt_mutex_lock()? Message-ID: <20170920162447.5j5kcs3t6kzbilql@linutronix.de> References: <20170918165110.GA9975@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170918165110.GA9975@linux.vnet.ibm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-09-18 09:51:10 [-0700], Paul E. McKenney wrote: > Hello! Hi, > [11072.586518] sched: Unexpected reschedule of offline CPU#6! > [11072.587578] ------------[ cut here ]------------ > [11072.588563] WARNING: CPU: 0 PID: 59 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40 > [11072.591543] Modules linked in: > [11072.591543] CPU: 0 PID: 59 Comm: rcub/10 Not tainted 4.14.0-rc1+ #1 > [11072.610596] Call Trace: > [11072.611531] resched_curr+0x61/0xd0 > [11072.611531] switched_to_rt+0x8f/0xa0 > [11072.612647] rt_mutex_setprio+0x25c/0x410 > [11072.613591] task_blocks_on_rt_mutex+0x1b3/0x1f0 > [11072.614601] rt_mutex_slowlock+0xa9/0x1e0 > [11072.615567] rt_mutex_lock+0x29/0x30 > [11072.615567] rcu_boost_kthread+0x127/0x3c0 > In theory, I could work around this by excluding CPU-hotplug operations > while doing RCU priority boosting, but in practice I am very much hoping > that there is a more reasonable solution out there... so in CPUHP_TEARDOWN_CPU / take_cpu_down() / __cpu_disable() the CPU is marked as offline and interrupt handling is disabled. Later in CPUHP_AP_SCHED_STARTING / sched_cpu_dying() all tasks are migrated away. Did this hit a random task during a CPU-hotplug operation which was not yet migrated away from the dying CPU? In theory a futex_unlock() of a RT task could also produce such a backtrace. > Thanx, Paul > Sebastian