From patchwork Tue Jul 3 06:50:40 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pingfan Liu X-Patchwork-Id: 938417 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41KZhx1mSDz9s29 for ; Tue, 3 Jul 2018 16:58:41 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="BifqwtDC"; dkim-atps=neutral Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 41KZhx0BhbzF1Qp for ; Tue, 3 Jul 2018 16:58:41 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="BifqwtDC"; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:400e:c00::242; helo=mail-pf0-x242.google.com; envelope-from=kernelfans@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="BifqwtDC"; dkim-atps=neutral Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 41KZXr5YlpzF1MY for ; Tue, 3 Jul 2018 16:51:40 +1000 (AEST) Received: by mail-pf0-x242.google.com with SMTP id e10-v6so530794pfn.1 for ; Mon, 02 Jul 2018 23:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=9ejno87GyeulgdnAebRnV2Zex8zHD6PleTSMZDbb+jI=; b=BifqwtDCFSHMcPabs1Bh9/CyM2p1LbQR/l+26FowG946FQ+3chTBAR5QgHF67sQjgc 1WZTS37cRoMRoPoSGawITY5DNYJDJ4uEBp+rxK6IK4p7TaNc1hbP6FG0Bzppi4lOwMHr P5mQEbxxsavU7YncBC7U4Pe5qxmrmISwKjCOfY8++nj0DuK+R+r9eYqvhQy7VPynw1vF ycJZQ78QNnShCkCmIZgycwgUqfQFq9fj/pW6NQVFysY/BlcVyf576ulqC5SdTYNZ9tWH qptVS4XFpygMMj/H6+zAO3f7+AIMz8ce1VIhkgzj+iGw0jNqMHLoVKKqxCSOh6n2mnU0 kvnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=9ejno87GyeulgdnAebRnV2Zex8zHD6PleTSMZDbb+jI=; b=JyKSN6ZK7XAB11V/BV5bMna7LvBZP3EuXmojBgAA8NdNVYXgPvT0zcvRxrABo3dUUi ksvo4CApkKOdN+0CsJ4LzGaylJBewkjMfPyoU19xJ9mxA2NaTSwiYCXLDFyg+6au+Ct3 EYvOS9oNndkGsjJOyfT15gZ9ydVnGh28XhkqUIZAPlikrmji26dCrtNRS65fLwXj2Jz6 Bu0/lmvkFwe7Z418irWBGmfKARmgUs8W+5YscxJlxE4EUVRR3DiWqzv3ODm9CK5g32si zSktSms44vFbYG5Z2YXoM2/SaqZEiEOWr6Bn0JO5mi37wRIHLYxILmYJo42HFs1lQnlV vJNA== X-Gm-Message-State: APt69E2jyGlNHFCNsJayvcJq/B8v6kJoH+gyOD91W6ScNgK4HfjlZkOU Y/iGMgCjR2UjI2vlh5NabQ== X-Google-Smtp-Source: AAOMgpdyHfY7IfXmh16bgzGm3fOZd/ietu45vS2ArjouRdpg9HU8P7QmfJSO18YfkBqdZYbJATKfYA== X-Received: by 2002:a65:6243:: with SMTP id q3-v6mr21853883pgv.273.1530600699193; Mon, 02 Jul 2018 23:51:39 -0700 (PDT) Received: from mylaptop.nay.redhat.com ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id e189-v6sm981122pfe.52.2018.07.02.23.51.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 23:51:38 -0700 (PDT) From: Pingfan Liu To: linux-kernel@vger.kernel.org Subject: [PATCHv3 2/4] drivers/base: utilize device tree info to shutdown devices Date: Tue, 3 Jul 2018 14:50:40 +0800 Message-Id: <1530600642-25090-3-git-send-email-kernelfans@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1530600642-25090-1-git-send-email-kernelfans@gmail.com> References: <1530600642-25090-1-git-send-email-kernelfans@gmail.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Grygorii Strashko , Greg Kroah-Hartman , "Rafael J . Wysocki" , linuxppc-dev@lists.ozlabs.org, Pingfan Liu , Christoph Hellwig , Bjorn Helgaas , linux-pci@vger.kernel.org, Dave Young Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" commit 52cdbdd49853 ("driver core: correct device's shutdown order") places an assumption of supplier<-consumer order on the process of probe. But it turns out to break down the parent <- child order in some scene. E.g in pci, a bridge is enabled by pci core, and behind it, the devices have been probed. Then comes the bridge's module, which enables extra feature(such as hotplug) on this bridge. This will break the parent<-children order and cause failure when "kexec -e" in some scenario. The detailed description of the scenario: An IBM Power9 machine on which, two drivers portdrv_pci and shpchp(a mod) match the PCI_CLASS_BRIDGE_PCI, but neither of them success to probe due to some issue. For this case, the bridge is moved after its children in devices_kset. Then, when "kexec -e", a ata-disk behind the bridge can not write back buffer in flight due to the former shutdown of the bridge which clears the BusMaster bit. It is a little hard to impose both "parent<-child" and "supplier<-consumer" order on devices_kset. Take the following scene: step0: before a consumer's probing, (note child_a is supplier of consumer_a) [ consumer-X, child_a, ...., child_z] [... consumer_a, ..., consumer_z, ...] supplier-X ^^^^^^^^^^ affected range ^^^^^^^^^^ step1: when probing, moving consumer-X after supplier-X [ child_a, ...., child_z] [.... consumer_a, ..., consumer_z, ...] supplier-X, consumer-X step2: the children of consumer-X should be re-ordered to maintain the seq [... consumer_a, ..., consumer_z, ....] supplier-X [consumer-X, child_a, ...., child_z] step3: the consumer_a should be re-ordered to maintain the seq [... consumer_z, ...] supplier-X [ consumer-X, child_a, consumer_a ..., child_z] It requires two nested recursion to drain out all out-of-order item in "affected range". To avoid such complicated code, this patch suggests to utilize the info in device tree, instead of using the order of devices_kset during shutdown. It iterates the device tree, and firstly shutdown a device's children and consumers. After this patch, the buggy commit is hollow and left to clean. Cc: Greg Kroah-Hartman Cc: Rafael J. Wysocki Cc: Grygorii Strashko Cc: Christoph Hellwig Cc: Bjorn Helgaas Cc: Dave Young Cc: linux-pci@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Pingfan Liu --- drivers/base/core.c | 48 +++++++++++++++++++++++++++++++++++++++++++----- include/linux/device.h | 1 + 2 files changed, 44 insertions(+), 5 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index a48868f..684b994 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1446,6 +1446,7 @@ void device_initialize(struct device *dev) INIT_LIST_HEAD(&dev->links.consumers); INIT_LIST_HEAD(&dev->links.suppliers); dev->links.status = DL_DEV_NO_DRIVER; + dev->shutdown = false; } EXPORT_SYMBOL_GPL(device_initialize); @@ -2811,7 +2812,6 @@ static void __device_shutdown(struct device *dev) * lock is to be held */ parent = get_device(dev->parent); - get_device(dev); /* * Make sure the device is off the kset list, in the * event that dev->*->shutdown() doesn't remove it. @@ -2842,23 +2842,60 @@ static void __device_shutdown(struct device *dev) dev_info(dev, "shutdown\n"); dev->driver->shutdown(dev); } - + dev->shutdown = true; device_unlock(dev); if (parent) device_unlock(parent); - put_device(dev); put_device(parent); spin_lock(&devices_kset->list_lock); } +/* shutdown dev's children and consumer firstly, then itself */ +static int device_for_each_child_shutdown(struct device *dev) +{ + struct klist_iter i; + struct device *child; + struct device_link *link; + + /* already shutdown, then skip this sub tree */ + if (dev->shutdown) + return 0; + + if (!dev->p) + goto check_consumers; + + /* there is breakage of lock in __device_shutdown(), and the redundant + * ref++ on srcu protected consumer is harmless since shutdown is not + * hot path. + */ + get_device(dev); + + klist_iter_init(&dev->p->klist_children, &i); + while ((child = next_device(&i))) + device_for_each_child_shutdown(child); + klist_iter_exit(&i); + +check_consumers: + list_for_each_entry_rcu(link, &dev->links.consumers, s_node) { + if (!link->consumer->shutdown) + device_for_each_child_shutdown(link->consumer); + } + + __device_shutdown(dev); + put_device(dev); + return 0; +} + /** * device_shutdown - call ->shutdown() on each device to shutdown. */ void device_shutdown(void) { struct device *dev; + int idx; + idx = device_links_read_lock(); spin_lock(&devices_kset->list_lock); /* * Walk the devices list backward, shutting down each in turn. @@ -2866,11 +2903,12 @@ void device_shutdown(void) * devices offline, even as the system is shutting down. */ while (!list_empty(&devices_kset->list)) { - dev = list_entry(devices_kset->list.prev, struct device, + dev = list_entry(devices_kset->list.next, struct device, kobj.entry); - __device_shutdown(dev); + device_for_each_child_shutdown(dev); } spin_unlock(&devices_kset->list_lock); + device_links_read_unlock(idx); } /* diff --git a/include/linux/device.h b/include/linux/device.h index 055a69d..8a0f784 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1003,6 +1003,7 @@ struct device { bool offline:1; bool of_node_reused:1; bool dma_32bit_limit:1; + bool shutdown:1; /* one direction: false->true */ }; static inline struct device *kobj_to_dev(struct kobject *kobj)