From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932493AbdIRQ3o (ORCPT ); Mon, 18 Sep 2017 12:29:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:55340 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932402AbdIRQ3i (ORCPT ); Mon, 18 Sep 2017 12:29:38 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C54121BCE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 18 Sep 2017 12:29:31 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Neeraj Upadhyay , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, sramana@codeaurora.org, prsood@codeaurora.org, pkondeti@codeaurora.org, markivx@codeaurora.org, peterz@infradead.org Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu Message-ID: <20170918122931.0e3341f3@gandalf.local.home> In-Reply-To: <20170918162412.GM3521@linux.vnet.ibm.com> References: <8f33e48e-ac6d-2c88-e16f-20b698c06292@codeaurora.org> <20170917010015.GW3521@linux.vnet.ibm.com> <20170918111105.15f687da@gandalf.local.home> <20170918160125.GL3521@linux.vnet.ibm.com> <20170918121213.312c82b0@gandalf.local.home> <20170918162412.GM3521@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Sep 2017 09:24:12 -0700 "Paul E. McKenney" wrote: > As soon as I work through the backlog of lockdep complaints that > appeared in the last merge window... :-( > > sparse_irq_lock, I am looking at you!!! ;-) I just hit one too, and decided to write a patch to show a chain of 3 when applicable. For example: Chain exists of: cpu_hotplug_lock.rw_sem --> smpboot_threads_lock --> (complete)&self->parked Possible unsafe locking scenario by crosslock: CPU0 CPU1 CPU2 ---- ---- ---- lock(smpboot_threads_lock); lock((complete)&self->parked); lock(cpu_hotplug_lock.rw_sem); lock(smpboot_threads_lock); lock(cpu_hotplug_lock.rw_sem); unlock((complete)&self->parked); *** DEADLOCK *** :-) -- Steve