From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750972AbdISBzf (ORCPT ); Mon, 18 Sep 2017 21:55:35 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:59950 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750733AbdISBze (ORCPT ); Mon, 18 Sep 2017 21:55:34 -0400 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 19 Sep 2017 10:55:27 +0900 From: Byungchul Park To: Steven Rostedt Cc: "Paul E. McKenney" , 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, kernel-team@lge.com Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu Message-ID: <20170919015527.GE5994@X58A-UD3R> 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> <20170918122931.0e3341f3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170918122931.0e3341f3@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote: > 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. Hello Steven, I really agree with this. Currently, in case that more than two locks participates in a deadlock, the report informs insuffucuently. Thanks, Byungchul > > 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