Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2365711ybi; Mon, 17 Jun 2019 03:38:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqx3sompcKlLQ99SStzqLGAC5Km0E1LxNdTmfYTHoJ2iZafZgjhLtyF2eHgghh/ggm466Z26 X-Received: by 2002:a63:5202:: with SMTP id g2mr2060797pgb.386.1560767937501; Mon, 17 Jun 2019 03:38:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560767937; cv=none; d=google.com; s=arc-20160816; b=Wk/coZC1Zq3Z+x2AuCCFcfzIbRPH9sgqi+HNhLM+26KNP7Ed6Sh+u5Tp2ZxpgU+fjP WRa1gL5Yf499CBG2ZYNmGsy+8v/8DMedOqhQex08EcLx3S5c57aH5iu/PLC1EGgw1v40 z9RRv89Y0FtmBHDaHhTbcDv9qwDyrxfs56FjH/TAeCxw6TGbPQ8mcCr5UthSnL381E7b abId8XAP0X+rWSRsW9khdFZ9iJcWVU8IjrXuwQgEJXOhS3f/qHN6ixg+789eV9qjgd2s DQW/S7gLtweiVsFrRUO9+XSWbLh1vJ9bLuM2AcHQUS1OXZeHEsZtBZqn1IQqo2JaBRIp 2o0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=QEKWp+Bpt2/WXbOPnDG6otKRq/qFtxi8yqFPhSJmv+k=; b=F0uPJOhGQlLDvdFqE/6IwDl3N8QhEwZ+U/hmmjEgKlUAH6c7ETpzB0j7MXgA6j4MGn 84vfLXzIuABqktVTVn4/OWkt9Pvoyxfh0kRRUvGoKh1fzvqRDiWJUHEVRmilGIARPBAX mP2jKpysX4WU0s9gODh/B3yHxI3WASCUOSZNP6H+BjBy8IK7YXljvLQi8M3vmP4mk+dp 0R3Icb3ORGFbUBKMflmABNtDDBbJ/FObZCGMV7lhdY3nCXhxkAYZfSYgGDJM5uDvetCE 5OsqaUUpm7o8rm6g51iuLoEsNLARzzRN3HBL0C2uKCXXJXh0lnsXK1OpNGLtjd5nABX+ cAHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c17si9667898plo.46.2019.06.17.03.38.41; Mon, 17 Jun 2019 03:38:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727696AbfFQKhJ (ORCPT + 99 others); Mon, 17 Jun 2019 06:37:09 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:43167 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726091AbfFQKhJ (ORCPT ); Mon, 17 Jun 2019 06:37:09 -0400 Received: from 79.184.254.20.ipv4.supernova.orange.pl (79.184.254.20) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.267) id 4bde88e79f44df54; Mon, 17 Jun 2019 12:37:06 +0200 From: "Rafael J. Wysocki" To: Lukas Wunner Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Westerberg , "Rafael J. Wysocki" , Keith Busch , Alex Williamson , Alexandru Gagniuc Subject: Re: [PATCH] PCI/PME: Fix race on PME polling Date: Mon, 17 Jun 2019 12:37:06 +0200 Message-ID: <1957149.eOSnrBRbHu@kreacher> In-Reply-To: <0113014581dbe2d1f938813f1783905bd81b79db.1560079442.git.lukas@wunner.de> References: <0113014581dbe2d1f938813f1783905bd81b79db.1560079442.git.lukas@wunner.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, June 9, 2019 1:29:33 PM CEST Lukas Wunner wrote: > Since commit df17e62e5bff ("PCI: Add support for polling PME state on > suspended legacy PCI devices"), the work item pci_pme_list_scan() polls > the PME status flag of devices and wakes them up if the bit is set. > > The function performs a check whether a device's upstream bridge is in > D0 for otherwise the device is inaccessible, rendering PME polling > impossible. However the check is racy because it is performed before > polling the device. If the upstream bridge runtime suspends to D3hot > after pci_pme_list_scan() checks its power state and before it invokes > pci_pme_wakeup(), the latter will read the PMCSR as "all ones" and > mistake it for a set PME status flag. I am seeing this race play out as > a Thunderbolt controller going to D3cold and occasionally immediately > going to D0 again because PM polling was performed at just the wrong > time. > > Avoid by checking for an "all ones" PMCSR in pci_check_pme_status(). > > Fixes: 58ff463396ad ("PCI PM: Add function for checking PME status of devices") > Tested-by: Mika Westerberg > Signed-off-by: Lukas Wunner > Cc: stable@vger.kernel.org # v2.6.34+ > Cc: Rafael J. Wysocki > --- > drivers/pci/pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 8abc843b1615..eed5db9f152f 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -1989,6 +1989,8 @@ bool pci_check_pme_status(struct pci_dev *dev) > pci_read_config_word(dev, pmcsr_pos, &pmcsr); > if (!(pmcsr & PCI_PM_CTRL_PME_STATUS)) > return false; > + if (pmcsr == 0xffff) > + return false; > > /* Clear PME status. */ > pmcsr |= PCI_PM_CTRL_PME_STATUS; > Added to my 5.3 queue, thanks!