From patchwork Wed Apr 20 14:44:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukas Wunner X-Patchwork-Id: 8890611 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B464D9F39A for ; Wed, 20 Apr 2016 14:42:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id AD5AE2012B for ; Wed, 20 Apr 2016 14:42:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AF4D82024C for ; Wed, 20 Apr 2016 14:42:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753589AbcDTOmN (ORCPT ); Wed, 20 Apr 2016 10:42:13 -0400 Received: from mailout2.hostsharing.net ([83.223.90.233]:46428 "EHLO mailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753351AbcDTOmN (ORCPT ); Wed, 20 Apr 2016 10:42:13 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout2.hostsharing.net (Postfix) with ESMTPS id 50C6D10189BE7; Wed, 20 Apr 2016 16:42:09 +0200 (CEST) Received: from localhost (6-38-90-81.adsl.cmo.de [81.90.38.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by h08.hostsharing.net (Postfix) with ESMTPSA id EBEC8603DA4A; Wed, 20 Apr 2016 16:42:07 +0200 (CEST) X-Mailbox-Line: From 7be989e10e72ac58951737bbd455955940388d82 Mon Sep 17 00:00:00 2001 Message-Id: <7be989e10e72ac58951737bbd455955940388d82.1461162854.git.lukas@wunner.de> In-Reply-To: <158b8ef6bf71ae69ef54871e4762b98deb981d6e.1461162854.git.lukas@wunner.de> References: <158b8ef6bf71ae69ef54871e4762b98deb981d6e.1461162854.git.lukas@wunner.de> From: Lukas Wunner Date: Wed, 20 Apr 2016 16:44:27 +0200 Subject: [PATCH v2 2/2] PCI: Do not treat EPROBE_DEFER as device attach failure To: linux-pci@vger.kernel.org Cc: linux-pm@vger.kernel.org, Bjorn Helgaas Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Linux 4.5 introduced a behavioral change in device probing during the suspend process with commit 013c074f8642 ("PM / sleep: prohibit devices probing during suspend/hibernation"): It defers device probing during the entire suspend process, starting from the prepare phase and ending with the complete phase. A rule existed before that "we rely on sub- systems not to do any probing once a device is suspended" but it is enforced only now (Alan Stern, https://lkml.org/lkml/2015/9/15/908). This resulted in a WARN splat if a PCI device (e.g. Thunderbolt) is plugged in while the system is asleep: Upon waking up, pciehp_resume() discovers new devices in the resume phase and immediately tries to bind them to a driver. Since probing is now deferred, device_attach() returns -EPROBE_DEFER, which provoked a WARN in pci_bus_add_device(). Linux 4.6-rc1 aggravates the situation with commit ab1a187bba5c ("PCI: Check device_attach() return value always"): If device_attach() returns a negative value, pci_bus_add_device() now removes the sysfs and procfs entries for the device and pci_bus_add_devices() subsequently locks up with a BUG. Even with the BUG fixed we're still in trouble because the device remains on the deferred probing list even though its sysfs and procfs entries are gone and its children won't be added. Fix by not interpreting -EPROBE_DEFER as failure. The device will be probed eventually (through device_unblock_probing() in dpm_complete()) and there is proper locking in place to avoid races (e.g. if devices are unplugged again und thus deleted from the system before deferred probing happens, I have tested this). Also, those functions which dereference dev->driver (e.g. pci_pm_*()) do contain proper NULL pointer checks. So it seems safe to ignore -EPROBE_DEFER. Cc: Grygorii Strashko Cc: Alan Stern Cc: Rafael J. Wysocki Cc: Bjorn Helgaas Signed-off-by: Lukas Wunner Acked-by: Rafael J. Wysocki --- v2: Split commit in two, explain when exactly deferred probing will happen (Bjorn Helgaas). drivers/pci/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 23a39fd..dd7cdbe 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -294,7 +294,7 @@ void pci_bus_add_device(struct pci_dev *dev) dev->match_driver = true; retval = device_attach(&dev->dev); - if (retval < 0) { + if (retval < 0 && retval != -EPROBE_DEFER) { dev_warn(&dev->dev, "device attach failed (%d)\n", retval); pci_proc_detach_device(dev); pci_remove_sysfs_dev_files(dev);