Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751569AbdI1Xqs (ORCPT ); Thu, 28 Sep 2017 19:46:48 -0400 Received: from alln-iport-2.cisco.com ([173.37.142.89]:28664 "EHLO alln-iport-2.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbdI1Xqq (ORCPT ); Thu, 28 Sep 2017 19:46:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQChic1Z/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1yBUi6dcIFUIpg9CoU7AoQlVwECAQEBAQECayiFGAEBAQECASc?= =?us-ascii?q?RAj8FCwsOCi48GwYOiikFCKkFOotDAQEBAQEBAQEBAQEBAQEBAQEBAR+DK4ICg?= =?us-ascii?q?VGCIIJyincFihKIOo5cizucK0iUWAIRGQGBOVeBDngViAaHewGBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,451,1500940800"; d="scan'208";a="10194185" Date: Thu, 28 Sep 2017 16:46:23 -0700 From: Govindarajulu Varadarajan To: Sinan Kaya CC: , , , , , , , Subject: Re: [PATCH 3/4] pci aer: fix deadlock in do_recovery In-Reply-To: <2dc437fe-2ab4-23e3-44f3-f06feaf88d86@codeaurora.org> Message-ID: References: <20170927214220.41216-1-gvaradar@cisco.com> <20170927214220.41216-4-gvaradar@cisco.com> <2dc437fe-2ab4-23e3-44f3-f06feaf88d86@codeaurora.org> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.157.132.141] X-ClientProxiedBy: xch-rcd-008.cisco.com (173.37.102.18) To XCH-RCD-012.cisco.com (173.37.102.22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1372 Lines: 35 On Thu, 28 Sep 2017, Sinan Kaya wrote: > On 9/27/2017 5:42 PM, Govindarajulu Varadarajan wrote: >> CPU0 CPU1 >> --------------------------------------------------------------------- >> __driver_attach() >> device_lock(&dev->mutex) <--- device mutex lock here >> driver_probe_device() >> pci_enable_sriov() >> pci_iov_add_virtfn() >> pci_device_add() >> aer_isr() <--- pci aer error >> do_recovery() >> broadcast_error_message() >> pci_walk_bus() >> down_read(&pci_bus_sem) <--- rd sem > > How about releasing the device_lock here on CPU0?> pci_device_add() is called by driver's pci probe function. device_lock(dev) should be held before calling pci driver probe function. > or in other words keep device_lock as short as possible? The problem is not the duration device_lock is held. It is the order two locks are aquired. We cannot control or implement a restriction that during device_lock() is held, driver probe should not call pci function which aquires pci_bus_sem. And in case of pci aer, aer handler needs to call driver err_handler() for which we need to hold device_lock() before calling err_handler(). In order to find all the devices on a pci bus, we should hold pci_bus_sem to do pci_walk_bus(). >> down_write(&pci_bus_sem) <-- stuck on wr sem >> report_error_detected() >> device_lock(&dev->mutex)<--- DEAD LOCK