From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150AbcLIVLf (ORCPT ); Fri, 9 Dec 2016 16:11:35 -0500 Received: from mga07.intel.com ([134.134.136.100]:52387 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbcLIVLc (ORCPT ); Fri, 9 Dec 2016 16:11:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,325,1477983600"; d="scan'208";a="40901514" Date: Fri, 9 Dec 2016 13:11:09 -0800 From: "Raj, Ashok" To: Bjorn Helgaas Cc: Keith Busch , linux-pci@vger.kernel.org, Bjorn Helgaas , linux-kernel@vger.kernel.org, stable@vger.kernel.org, ashok.raj@intel.com Subject: Re: [PATCH 3/3] pciehp: Fix race condition handling surprise link-down Message-ID: <20161209211109.GA18093@otc-nc-03> References: <1479544367-7195-1-git-send-email-ashok.raj@intel.com> <1479544367-7195-4-git-send-email-ashok.raj@intel.com> <20161207234054.GL22129@bhelgaas-glaptop.roam.corp.google.com> <20161208000433.GD25959@localhost.localdomain> <20161208151158.GB19822@bhelgaas-glaptop.roam.corp.google.com> <20161208172058.GH25959@localhost.localdomain> <20161208175009.GA28421@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208175009.GA28421@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn Thanks. I have resent the last patch again with consistent lock usage as you had requested. I did attempt to make things a bit more easier to understand in one my earlier experiments, but that resulted in very substantial changes. Certainly something we should look in future to make the state machine more robust. Cheers, Ashok On Thu, Dec 08, 2016 at 11:50:09AM -0600, Bjorn Helgaas wrote: > > Yes, the alloc_ordered_workqueue is what I had in mind, though switching > > to that is not as simple as calling the different API. I am looking into > > that for longer term, but for the incremental fix, do you think we can > > go forward with Raj's proposal? > > I'd like to at least see a consistent locking strategy for protecting > p_slot->state. All the existing updates are protected by > p_slot->lock, but the one Raj is adding is protected by > p_slot->hotplug_lock. > > Bjorn